Tornado code deployment

Question

Is there a canonical code deployment strategy for tornado-based web application deployment. Our current configuration is 4 tornado processes running behind NginX? (Our specific use case is behind EC2.)

We've currently got a solution that works well enough, whereby we launch the four tornado processes and save the PIDs to a file in /tmp/. Upon deploying new code, we run the following sequence via fabric:

1. Do a git pull from the prod branch.
2. Remove the machine from the load balancer.
3. Wait for all in flight connections to finish with a sleep.
4. Kill all the tornadoes in the pid file and remove all *.pyc files.
5. Restart the tornadoes.
6. Attach the machine back to the load balancer.

We've taken some inspiration from this: http://agiletesting.blogspot.com/2009/12/deploying-tornado-in-production.html

Are there any other complete solutions out there?

Answer 1

We run Tornado+Nginx with supervisord as the supervisor.

Sample configuration (names changed)

[program:server]
process_name = server-%(process_num)s
command=/opt/current/vrun.sh /opt/current/app.py --port=%(process_num)s
stdout_logfile=/var/log/server/server.log
stderr_logfile=/var/log/server/server.err
numprocs = 6
numprocs_start = 7000

I've yet to find the "best" way to restart things, what I'll probably finally do is have Nginx have a "active" file which is updated letting HAProxy know that we're messing with configuration then wait a bit, swap things around, then re-enable everything.

We're using Capistrano (we've got a backlog task to move to Fabric), but instead of dealing with removing *.pyc files we symlink /opt/current to the release identifier.