Welcome back. You might have seen my last blog post on how to deploy a simple Django app using AWS.
Quick Summary: 1. Spin up an EC2 instance 2. Install nginx, django, gunicorn on your EC2 instance 3. Turn on gunicorn and nginx 4. Success.
Well, it is success until you terminate your connection to your EC2 instance.
How do we keep the app running even when we terminate gunicorn?
Based on the recommendations from those wiser than I, we’re going to experiment with Upstart today.
From the Upstart website:
> Upstart is an event-based replacement for the /sbin/init daemon > which handles starting of tasks and services during boot, stopping > them during shutdown and supervising them while the system is running.
Basically, you can write jobs in Upstart not only to keep your app running but you’ll be able to do asynchronous boot sequences instead of synchronous sequences.
Let’s get Started
Make sure you have your EC2 instance configured as described in my last blog post.
Also make sure nginx and gunicorn are both not running.
nginx starts automatically so make sure you run:
sudo service nginx stop
Since we’re using Ubuntu, Upstart comes already installed. You can check to see which version you have by running:
You should see a little something like this:
initctl (upstart 1.12.1) Copyright (C) 2006-2014 Canonical Ltd., 2011 Scott James Remnant This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Time to make our First Job
First step is to cd into /etc/init.
If you ls you’ll notice that there are a bunch of .conf files. We’re going to be making our own!
In order to write an Upstart job you need to make sure you either have a script block (called a stanza) or an exec script.
description "My first Upstart job" start on runlevel  stop on runlevel [!2345] script echo 'hello world' end script
Now you can start this by running:
sudo service myjob start
To see your awesome handiwork:
cd /var/log/upstart cat myjob.log
You’ll see your very first Upstart job.
Now we’ll actually get something running.
description "Gunicorn application server for Todo" start on runlevel  stop on runlevel [!2345] respawn setuidubuntu setgid www-data chdir /home/ubuntu/project-folder exec projectvirtualenv/bin/gunicorn --workers 2 project.wsgi:application
Save your file and now try:
sudo service myjob start
Visit your public IP address and blamo! You’ve got your Django app live for the world to see. Close out your terminal window. Is your app still running? It should be.
Let’s go over a few lines of what your job is doing.
start on runlevel  stop on runlevel [!2345]
Basically this means we’re going to run our service when the system is at runlevels 2, 3, 4 or 5. Then when the system is not at any of those (rebooting, shutting down, etc) we’ll stop running our service.
This tells Upstart to restart our job if it fails. This means we don’t need to worry about rerunning all of our commands every single time something goes down. In our case, everytime something fails, it will restart our todo app.
setuidubuntu setgid www-data chdir /home/ubuntu/project-folder
Next we’re setting our user and the group owners and changing directories into our project directory so we can run gunicorn from the right place.
execprojectvirtualenv/bin/gunicorn --workers 2 project.wsgi:application
Since this is an Upstart job, we need to have at least one script stanza or one exec script. So we have our exec script that basically starts gunicorn with 2 workers. We can set all sorts of configuration for gunicorn here as well.
If you’re ever wondering if something went wrong and you want to try to troubleshoot, just check out your log:
If you want to find out more about Upstart, you should visit their site.
This tutorial brushes just the tiniest surface ever of Upstart, there’s a bunch more that you can have it do for you but every project has it’s own needs. Hopefully this tutorial inspires you to go out there and figure out what else you can achieve with some fancy Upstart jobs of your own!
About the Author
Liz Tom is a Creative Technologist at iStrategyLabs in Washington D.C. Liz’s passion for full stack development and digital media makes her a natural fit at ISL. Before joining iStrategyLabs, she worked in the film industry doing everything from mopping blood off of floors to managing budgets. When she’s not in the office, you can find Liz attempting parkour and going to check out interactive displays at museums.