A Good Basic Setup
One of the intimidating things about deploying a Django application is
the number of decisions that need to be made.
Here are a recommended set of choices for deploying Django
apps. Most of these choices have alternatives, and some are decided
for you if you’re using a PaaS, but in the absence of a
reason to use an alternative, these should work reasonably well in most cases.
- Operating System
- Ubuntu LTS server: Ubuntu because it’s stable, it’s free, and it’s
popular among developers, so any Django or Python software is likely to
work well on it. LTS because of the long support guarantee, and server
since we don’t need costly graphical desktop environments on our
servers.
- Django version
- The latest released version: because it will be supported by security
fixes for the longest time, compared to any older version, and Django
has a history of putting out pretty stable releases. (Maybe wait a
couple of weeks after a new release to see if there’s a .1 release.)
- Database
PostgreSQL: because it and MySQL are the most popular free databases, so
it’s well supported, and MySQL is lacking some features. For example,
MySQL cannot perform schema changes in transactions, so if a schema
migration fails in the middle, your data could be left in an indeterminate
state.
Sometimes there are reasons to use another database than PostgreSQL.
Just be sure not to use SQLite, even though it’s very easy to set up.
It’s not suited for production use.
- Web server
Apache or nginx: both work well as front ends for Django applications.
It is important to have a web server handle incoming requests, rather than
having them go directly to the Django application, for a couple of reasons:
- Web servers are designed to efficiently process the load of incoming
requests, and deal with the wide variety of web clients. That lets
the WSGI server focus on hosting the Django application.
- The Django application should never be used to serve static files in
production. If the static files are not being served by another system,
the web server is used to either serve the static files, or proxy the
requests to something other than the Django application.
- WSGI server
mod_wsgi with Apache, or gunicorn: Either of these work well.
The WSGI server provides a Python process to run your Django application.
mod_wsgi can be convenient if you are already be using Apache on the
server for static files. Gunicorn is easier to configure and run.
In any case, never use runserver in production. It is not secure,
and performs poorly.
- Message queue server
- RabbitMQ: because it’s stable and popular. Redis is also
commonly used as a message queue server.
- Schema migration
- South: because it’s really the only choice available for schema migrations
in Django.
- RapidSMS Router
- DatabaseRouter: because it has the most features.
- Asynchronous task scheduler
- Celery: see Using Celery for Scheduling Tasks.
- Application settings
- Applications settings should be shared between different environments as
much as possible. Keeping settings files available to all developers
through your version control system keeps all of the developers on the same
page and allows new developers to get started on your project quickly. The
Django Book covers managing settings.py files between environments
within projects.