Development with Python

180 / 478

--bind unix:/tmp/superlists-staging.ottg.eu.socket \
superlists.
Upstart is joyously simple to configure (especially if you’ve ever had the dubious pleasure
of writing an init.d script), and is fairly self-explanatory.
start on net-device-up makes sure Gunicorn only runs once the server has
connected up to the Internet.
respawn will restart the process automatically if it crashes.
setuid makes the process run as the “elspeth” user.
chdir sets the working directory.
exec is the actual process to execute.
Upstart scripts live in /etc/init, and their names must end in .conf.
Now we can start Gunicorn with the start command:
:$ sudo start gunicorn-superlists-staging.ottg.eu
And we can rerun the FTs to see that everything still works. You can even test that the
site comes back up if you reboot the server!
Saving Our Changes: Adding Gunicorn to Our requirements.txt
Back in the local copy of your repo, we should add Gunicorn to the list of packages we
need in our virtualenvs:
$ source ../virtualenv/bin/activate # if necessary
(virtualenv)$ pip install gunicorn
(virtualenv)$ pip freeze > requirements.txt
(virtualenv)$ deactivate
$ git commit -am "Add gunicorn to virtualenv requirements"
$ git push
On Windows, at the time of writing, Gunicorn would pip install quite
happily, but it wouldn’t actually work if you tried to use it. Thankful‐
ly we only ever run it on the server, so that’s not a problem. And,
Windows support is
Automating
Let’s recap our provisioning and deployment procedures:
Provisioning
1. Assume we have a user account and home folder
152 | Chapter 8: Testing Deployment Using a Staging Site