Outline
While Django makes it very simple to get an application running locally, the default configuration that's generated left untouched is unsuitible for production use. This lesson will show you how to separate your settings between development and production environments. Our Django application will be named conduit in this example, so sure to replace any references to conduit with the name of your Django application if it differs.
By default, our application's settings.py contains settings that should only be used for development, such as having DEBUG set to true, and having a hard-coded string for SECRET_KEY. One possible solution is exporting these settings to environment variables to separate our development and production environments, but environment variables can be a hassle to set up in development, especially when working with a team, so it makes sense to have some variables hard-coded in development. We'll be separating our configuration in to three files: a common file for storing the settings that remain the same in both development and production, and one for each of our production and development environments that will import the common settings.
Let’s get started
To get the full working version of this guide, clone the conduit-django repository and follow the instructions in the file called README.md to get everything installed and running. I've created a Production-Settings branch of the conduit project with the changes below.
Currently, our application has the following directory structure:
|-conduit/
|_|-settings.py
|-manage.py
|-requirements.txt
|-.gitignore
settings.py to our common settings
Create a folder named settings in the same folder as our settings.py file. Then, move settings.py into the settings folder, and rename the file to common.py
This common.py file will contain the settings that will be used in both development and production.
In the settings folder, create two files named development.py and production.py with the following:
from conduit.settings.common import *
The two files we created will import variables from the common.py file. They'll also contain settings specific to each environment. If you have additional environments that you want to set specific settings for (like for running tests), you can put them in the settings folder and import the common settings as well.
The resulting directory structure should look like this:
|-conduit/
|_|-settings/
|__|-common.py
|__|-development.py
|__|-production.py
|-manage.py
|-requirements.txt
|-.gitignore
Now that we have separate setting files for each environment, we can move environment specific settings to their respective folders. The settings to move will largely depend on what settings your app is using, but at a minimum you should move the hard-coded DEBUG and SECRET_KEY from the common settings to development settings, then in your production settings you can hard-code DEBUG to false and SECRET_KEY to read from an environment variable:
DEBUG = False
SECRET_KEY = os.environ['SECRET_KEY']
# SECURITY WARNING: update this when you have the production host
ALLOWED_HOSTS = ['0.0.0.0', 'localhost']
We also want to specify what ALLOWED_HOSTS are going to be set. Once you set DEBUG = FALSE THEN ALLOWED_HOSTS then needs to have a value for your project to run. Replace the values I've temporarily placed in here with your production host values.
By default, Django will continue to look for configuration in settings.py which no longer exists, so trying to run our server or any manage.py tasks will fail.
DJANGO_SETTINGS_MODULE
In wsgi.py and manage.py with conduit.settings.development, change
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "conduit.settings")
to
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "conduit.settings.development")
This makes our Django application use the development.py file when the DJANGO_SETTINGS_MODULE environment variable is not set. In production, we can change our application to read the settings from production.py by simply setting the DJANGO_SETTINGS_MODULE environment variable to conduit.settings.production
There are other areas that you may need to account for when deploying to production. The Django Documentation has a checklist of things you should also consider.
Production Database
With reguards to our database, we have been using the built-in db.sqlite3. Sqlite isn't considered a production solution database. You will want to upgrade to PostgreSQL or MySQL for your production version. The documentation below talk about deploying to production and setting up the production worthy database.