Foreman - process manager for your web applications.

A web application development model based on the idea of ​​scaling through processes is becoming increasingly popular. A modern application is a set of running processes that do not store states, each isolated from each other. Each such process is assigned its own local port, which allows you to transparently export your services for later use by someone else, maybe even with each other (for example, one serves http requests from users, accepting video url addresses, and the other slowly, but surely loads them and converts them). As a rule, in most cases http-services are simply installed as reverse proxy in nginx, but options are possible.

It's no secret that each developer has his own arsenal of tools, which allows him to somehow make his life easier. Today we will talk about a tool like Foreman. Using it, you can declare in one place all the processes that are needed to run your application. To do this, use the so-called Procfile, which looks like something like this:

web: mono ./awesome-app --port $PORT api: node ./api.js -p $PORT worker: bundle exec rake resque:work QUEUE=* habr: bundle exec ./bin/thin -a localhost -p $PORT 

As you can see, everything is quite simple, each line of the file contains the name of the process type and the line to start it.
')

▌ Installation and use

To start using it, you only need to install it using your system package manager or using rubygems:

 $ gem install foreman 

If your application uses Foreman, then launching it, if you have a ready-made Procfile, will look quite simple:

 $ editor .env $ foreman start 

Here is the start of all processes:



Foreman will set the necessary environment variables, start all the processes associated with your application, and also display the output of standard streams (stdout and stderr) each. As you can see, process names are colored in different colors, which allows them to be visually distinguished. The value of the $PORT variable is automatically set by Foreman separately for each process launched.

It should be noted that your processes should not be demonized themselves, because in this case Foreman will not be able to manage their start-stop cycle.

▌ Deploy

Foreman can export your launch tasks to upstart , as well as to classic unix init (which is not recommended, though ), bluepill , runit and supervisord . Systemd support is also on the way .

Export to upstart

 $ foreman export upstart /etc/init [foreman export] writing: /etc/init/testapp.conf [foreman export] writing: /etc/init/testapp-web.conf [foreman export] writing: /etc/init/testapp-web-1.conf [foreman export] writing: /etc/init/testapp-worker.conf [foreman export] writing: /etc/init/testapp-worker-1.conf [foreman export] writing: /etc/init/testapp-habr.conf [foreman export] writing: /etc/init/testapp-habr-1.conf 

After exporting to upstart, the following commands become available:

 $ start testapp $ stop testapp-habr $ restart testapp-worker-1 

Export to inittab

 $ foreman export inittab # ----- foreman testapp processes ----- TE01:4:respawn:/bin/su - testapp -c 'PORT=5000 mono ./awesome-app --port $PORT >> /var/log/testapp/web-1.log 2>&1' TE02:4:respawn:/bin/su - testapp -c 'PORT=5100 bundle exec rake resque:work QUEUE=* >> /var/log/testapp/worker-1.log 2>&1' TE03:4:respawn:/bin/su - testapp -c 'PORT=5200 bundle exec ./bin/thin -a localhost -p $PORT >> /var/log/testapp/habr-1.log 2>&1' # ----- end foreman testapp processes ----- 

▌ Opportunities

Parallelism

Foreman allows you to control the number of running instances of each type of process, which also overlaps with the idea of ​​scaling through processes. By the way, this approach has already managed to catch the fancy of Heroku users.

 #      «worker»,   «habr»   «web» $ foreman start -c habr=4 -c web=2 

 #   ,   ,    upstart $ foreman export upstart /etc/init -c habr=4 -c web=2 

 #    «worker» $ foreman start -c worker=0 

Environment variables

There is an approach that is gradually gaining popularity among developers, which is to store the configuration of the application in environment variables. Foreman and here is not left aside and allows you to simplify everything.

In order to use this feature, in the project directory you need to create an .env file containing an enumeration of all the necessary values ​​of environment variables, for example:

 APP_ENV=production DATABASE_URL=mysql://user:password@localhost/table 

A good practice here is to create and register with the version control system the sample.env file, which will contain an example of your application configuration. Thus, to deploy it in a new environment, you will need to copy the sample.env file to .env , edit it in accordance with your environment, and then launch Foreman.

You can also ask Foreman to start processes with environment variables from another file:

 $ foreman start -e development.env 

Port Assignment

By default, Foreman assigns ports to processes starting at 5000, and makes it in blocks of 100 pieces for each type of process, and in the order in which they are listed in the Procfile.

Say, for the Procfile example above, the web.1 process will get port 5000, worker.1 will be the 5100th, and habr.1 will be the 5200th. If you start two habr processes, then habr.2 will be assigned port number 5201.

You can also select the start port manually, for example:

 $ foreman start -p 7000 

▌ Conclusion

As you can see, there is absolutely nothing complicated in using such good practices, but this piece of time allows you to save enough to be in the arsenal of an advanced developer.

For more information about all the available options, you can refer to the documentation , as well as to the project repository page on github.