Development with Python

python3 manage.py test functional_tests --liveserver=superlists-staging.ottg.eu

A couple more steps!

Switching DEBUG to False and Setting ALLOWED_HOSTS

Django’s DEBUGmode is all very well for hacking about on your own server, but leaving

those pages full of tracebacks available

isn’t secure .

You’ll find the

DEBUG

setting at the top of

settings.py

. When we set this to

False

, we also

need to set another setting called

ALLOWED_HOSTS

. This was

added as a security feature

in Django 1.5. Unfortunately it doesn’t have a helpful comment in the default

set‐

tings.py

, but we can add one ourselves. Do this on the server:

server: superlists/settings.py.

# SECURITY WARNING: don't run with debug turned on in production!

DEBUG

False

TEMPLATE_DEBUG

DEBUG

# Needed when DEBUG=False

ALLOWED_HOSTS

[

'superlists-staging.ottg.eu'

]

[

...

]

And, once again, we restart Gunicorn and run the FT to check things still work.

Don’t commit these changes on the server. At the moment this is just

a hack to get things working, not a change we want to keep in our

repo. In general, to keep things simple, I’m only going to do Git

commits from the local PC, using

git push

and

git pull

when I

need to sync them up to the server.

Using Upstart to Make Sure Gunicorn Starts on Boot

Our final step is to make sure that the server starts up Gunicorn automatically on boot,

and reloads it automatically if it crashes. On Ubuntu, the way to do this is using Upstart:

server: /etc/init/gunicorn-superlists-staging.ottg.eu.conf.

description

"Gunicorn server for superlists-staging.ottg.eu"

start on net-device-up

stop on shutdown

respawn

setuid elspeth

chdir /home/elspeth/sites/superlists-staging.ottg.eu/source

exec

../virtualenv/bin/gunicorn

Getting to a Production-Ready Deployment

151