The basics of working with Supervisord

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com

I’ve come up with a system whereby:

1.) Jenkins pulls our code from the master branch on Github

2.) I wrote a build script that I store in /usr/local/bin

3.) Jenkins calls the build script as one of its build steps

4.) I wrote a script that finds the PIDS of existing instances of the app, and kills them:

#! /bin/sh  

ps aux | grep SSAM | awk '{print $2}' | xargs kill

5.) Jenkin calls the kill script as its last build step

6.) Can Jenkins launch new instances of the new version of the app? That is tricky. Normally Jenkins kills any child process that spawns during the build process. So it is easier to rely on Supervisord, instead of Jenkins, to restart the apps.

7.) Supervisord is suppose to keep 4 instances of the app running. When the kill script kills the old PIDs, the Supervisord immediately spins up 4 new instances.

I found this to be a great overview of the basics of Supervisord:

The program configuration files for Supervisor programs are found in the /etc/supervisor/conf.d directory, normally with one program per file and a .conf extension. A simple configuration for our script, saved at /etc/supervisor/conf.d/long_script.conf, would look like so:

[program:long_script]
command=/usr/local/bin/long.sh
autostart=true
autorestart=true
stderr_logfile=/var/log/long.err.log
stdout_logfile=/var/log/long.out.log

…Once our configuration file is created and saved, we can inform Supervisor of our new program through the supervisorctl command. First we tell Supervisor to look for any new or changed program configurations in the /etc/supervisor/conf.d directory with:

supervisorctl reread

Followed by telling it to enact any changes with:

supervisorctl update

Source