Simple words about the Twelve-Factor App
The famous heroku provider supports a manifest called the 12 Factor Application (Twelve-Factor App). This is a set of best practices for developing modern web applications on any platform. Practitioners describe applications that are ready:
We can assume that the manifesto is partly adware - it is most convenient to deploy 12-factor applications on heroku. But since the manifesto is becoming more and more popular, part of the cloud providers include best practices in their environment, and these practices will be useful both to developers and those who deploy and administer applications.
The manifesto (there is an excellent translation in Habré) is too detailed and good for detailed study. In the same article, I will briefly highlight the main advantages.
All application code must be in the version control system. And to be developed for development, testing and on working servers from one repository. That, however, does not exclude that in deployments there may be code in various branches that have not yet been added to the release.
')
If you have several applications that use common code, then you should select the common code into a separate library, and declare it as a dependency. If at any development stage you have several loosely coupled applications in one repository, then you should divide the application into several, each of which should be a 12-factor application.
Applications should not have implicit dependencies. First, all dependencies, both system and library, must be specified in the dependency manifest. All modern languages ​​provide a package manager with a manifest of dependencies. In addition, dependencies should be isolated so that the system library does not “leak out” into applications.
So in Ruby uses Gemfile as a manifest format for declaring dependencies, bundle exec to isolate dependencies. In addition to the same operation of the application on different platforms, this will allow new developers to get involved in the project faster, or connect new dependencies faster.
There should be mentioned Docker, which isolates and explicitly declares even the envy of the OS.
Configuration is all parameters that change depending on where the application is running:
The code does not depend on the environment, and the configuration depends. Therefore, the code should be stored in the repository, and the configuration in the environment. If you can publish your code in open access without compromising personal accounts - you are doing everything right.
A rather popular option is to use pre-prepared configuration sets (development, test and production). This separation cannot be considered a good solution, since the addition of new environments (development joe, qa, staging) disproportionately increases the number of parameters that need to be maintained.
Third-party services are databases, mail services, cache servers and APIs of various services. A 12-factor application should not distinguish between local and remote services. Each service is a connected resource, the data for connecting to which (address and credentials) must be stored in the configuration.
Replacing a local database with Amazon RDS, or replacing a local mail server with a third-party one, should not affect application code.
Deploying an application consists of three separate steps:
When developing an application of 12 factors, it is necessary to strictly separate these stages. The build is initiated by the developer when he is ready to post changes. This may be a longer process, but changes cannot be made in the release code after this. On the other hand, the implementation phase should be as simple as possible, so that it can be performed automatically in case of equipment shutdown, or other errors, without intervention by the developer.
An application must run as one or more processes that do not maintain their internal state. The application can use the data in RAM or on disk as temporary storage. For example, when transcoding images. But any user data must be stored in a permanent storage (connected resource).
This primarily concerns session data, since the next user connection may occur to another process (due to a hardware failure, or a processor reset).
A PHP application can be run as a module inside Apache HTTPD, or a Java application can be launched inside Tomcat. On the contrary, the 12-factor application is completely self-sufficient, and does not rely on the presence of a web server.
This is typically implemented by using dependency declarations to add a web server library to an application such as Tornado in Python, Thin in Ruby, Jetty in Java, and ReactPHP in PHP.
Different tasks should be handled by different processes. For example, HTTP requests can be processed by the web process, and long-term background tasks are processed by the workflow. This will allow in the future to scale only those processes that are necessary.
It is important that the processes should not be demonized (should be executed, and not run). The process manager must monitor the output flow of the application and respond to errors and crashes.
This is a logical consequence of processes that do not retain their state. Maximize reliability by using processes that run quickly and complete their work correctly, even in an emergency.
Background processes should return the current task to the queue, and request processing processes should correctly terminate requests. Each task of any process must be available for re-execution (for example, using transactions).
Now there is a significant difference between development and deployment - it is done by different people, at different times and by different tools. When introducing 12 factors, you should try to make development and deployment as close as possible:
A log is a stream of events, and it is necessary to refer to it as a stream of events. The application should not write the data to the log file itself, much less manage the files (archive or delete). The factorial application displays the log of its work in stdout. The manager who launches the process should direct the analysis or archiving system to the logies.
This allows you to aggregate events from different processes, including both application processes and third-party services. The log analysis system allows analyzing the current state of the entire system, as well as analyzing previous work.
In the developer’s environment, logs are simply viewed in the console.
One-time administration processes (migrations, database fixes) should follow the same rules as other processes:
- horizontal scaling;
- continuous deployment;
- to modern cloud hosting.
We can assume that the manifesto is partly adware - it is most convenient to deploy 12-factor applications on heroku. But since the manifesto is becoming more and more popular, part of the cloud providers include best practices in their environment, and these practices will be useful both to developers and those who deploy and administer applications.
The manifesto (there is an excellent translation in Habré) is too detailed and good for detailed study. In the same article, I will briefly highlight the main advantages.
One application - one repository
All application code must be in the version control system. And to be developed for development, testing and on working servers from one repository. That, however, does not exclude that in deployments there may be code in various branches that have not yet been added to the release.
')
If you have several applications that use common code, then you should select the common code into a separate library, and declare it as a dependency. If at any development stage you have several loosely coupled applications in one repository, then you should divide the application into several, each of which should be a 12-factor application.
Explicit dependencies
Applications should not have implicit dependencies. First, all dependencies, both system and library, must be specified in the dependency manifest. All modern languages ​​provide a package manager with a manifest of dependencies. In addition, dependencies should be isolated so that the system library does not “leak out” into applications.
So in Ruby uses Gemfile as a manifest format for declaring dependencies, bundle exec to isolate dependencies. In addition to the same operation of the application on different platforms, this will allow new developers to get involved in the project faster, or connect new dependencies faster.
There should be mentioned Docker, which isolates and explicitly declares even the envy of the OS.
Configuration is the runtime properties
Configuration is all parameters that change depending on where the application is running:
- logins, passwords and addresses of databases;
- Third-party services and API keys.
The code does not depend on the environment, and the configuration depends. Therefore, the code should be stored in the repository, and the configuration in the environment. If you can publish your code in open access without compromising personal accounts - you are doing everything right.
A rather popular option is to use pre-prepared configuration sets (development, test and production). This separation cannot be considered a good solution, since the addition of new environments (development joe, qa, staging) disproportionately increases the number of parameters that need to be maintained.
Local and third-party services
Third-party services are databases, mail services, cache servers and APIs of various services. A 12-factor application should not distinguish between local and remote services. Each service is a connected resource, the data for connecting to which (address and credentials) must be stored in the configuration.
Replacing a local database with Amazon RDS, or replacing a local mail server with a third-party one, should not affect application code.
Separation of assembly, release and execution
Deploying an application consists of three separate steps:
- Assembly is the conversion of code into an executable package — loading dependencies, compiling files and resources.
- Release - assembly assembly with configuration. The release is immediately ready for launch in the execution environment.
- Execution - the launch of a number of processes from the release.
When developing an application of 12 factors, it is necessary to strictly separate these stages. The build is initiated by the developer when he is ready to post changes. This may be a longer process, but changes cannot be made in the release code after this. On the other hand, the implementation phase should be as simple as possible, so that it can be performed automatically in case of equipment shutdown, or other errors, without intervention by the developer.
Application - a set of processes
An application must run as one or more processes that do not maintain their internal state. The application can use the data in RAM or on disk as temporary storage. For example, when transcoding images. But any user data must be stored in a permanent storage (connected resource).
This primarily concerns session data, since the next user connection may occur to another process (due to a hardware failure, or a processor reset).
The application is server independent
A PHP application can be run as a module inside Apache HTTPD, or a Java application can be launched inside Tomcat. On the contrary, the 12-factor application is completely self-sufficient, and does not rely on the presence of a web server.
This is typically implemented by using dependency declarations to add a web server library to an application such as Tornado in Python, Thin in Ruby, Jetty in Java, and ReactPHP in PHP.
Scale using processes
Different tasks should be handled by different processes. For example, HTTP requests can be processed by the web process, and long-term background tasks are processed by the workflow. This will allow in the future to scale only those processes that are necessary.
It is important that the processes should not be demonized (should be executed, and not run). The process manager must monitor the output flow of the application and respond to errors and crashes.
Quick start and correct completion
This is a logical consequence of processes that do not retain their state. Maximize reliability by using processes that run quickly and complete their work correctly, even in an emergency.
Background processes should return the current task to the queue, and request processing processes should correctly terminate requests. Each task of any process must be available for re-execution (for example, using transactions).
Zoom in on development
Now there is a significant difference between development and deployment - it is done by different people, at different times and by different tools. When introducing 12 factors, you should try to make development and deployment as close as possible:
- Time - the code should fall into the working version a few hours after the developer wrote it.
- People - the developer should take part in the deployment of their code and monitor its work in the work.
- Tools - the development environment should be as close as possible to the testing environment (third-party services, OS).
Logs in stdout
A log is a stream of events, and it is necessary to refer to it as a stream of events. The application should not write the data to the log file itself, much less manage the files (archive or delete). The factorial application displays the log of its work in stdout. The manager who launches the process should direct the analysis or archiving system to the logies.
This allows you to aggregate events from different processes, including both application processes and third-party services. The log analysis system allows analyzing the current state of the entire system, as well as analyzing previous work.
In the developer’s environment, logs are simply viewed in the console.
Admin Tasks
One-time administration processes (migrations, database fixes) should follow the same rules as other processes:
- The task code must be stored in the repository to match the code of the main application.
- Dependencies must be declared in the main dependency manifest so that the process can be executed during normal deployment.
- The task configuration must be in environment variables so that it can be executed in different environments.
Source: https://habr.com/ru/post/261171/
All Articles