Django¶

Configuration¶

We share the same configuration structure for almost every possible environment.

We use:

django-split-settings to organize django settings into multiple files and directories
.env files to store secret configuration
python-decouple to load .env files into django

Components¶

If you have some specific components like celery or mailgun installed, they could be configured in separate files. Just create a new file in server/settings/components/. Then add it into server/settings/__init__.py.

Environments¶

To run django on different environments just specify DJANGO_ENV environment variable. It must have the same name as one of the files from server/settings/environments/. Then, values from this file will override other settings.

Local settings¶

If you need some specific local configuration tweaks, you can create file server/settings/environments/local.py.template to server/settings/environments/local.py. It will be loaded into your settings automatically if exists.

cp server/settings/environments/local.py.template server/settings/environments/local.py

See local.py.template version for the reference.

Secret settings¶

We share the same mechanism for secret settings for all our tools. We use .env files for django, postgres, docker, etc.

Initially, you will need to copy file config/.env.template to config/.env:

cp config/.env.template config/.env

When adding any new secret django settings you will need to:

Add new key and value to config/.env
Add new key without value to config/.env.template, add a comment on how to get this value for other users
Add new variable inside django settings
Use python-decouple to load this env variable like so: MY_SECRET = config('MY_SECRET')

Secret settings in production¶

We do not store our secret settings inside our source code. All sensible settings are stored in config/.env file, which is not tracked by the version control.

So, how do we store secrets? We store them as secret environment variables in GitLab CI. Then we use dump-env to dump variables from both environment and .env file template. Then, this file is copied inside docker image and when this image is built - everything is ready for production.

Here’s an example:

We add a SECRET_DJANGO_SECRET_KEY variable to Gitlab CI secret variables
Then dump-env dumps SECRET_DJANGO_SECRET_KEY as DJANGO_SECRET_KEY and writes it to config/.env file
Then it is loaded by django inside the settings: SECRET_KEY = config('DJANGO_SECRET_KEY')

However, there are different options to store secret settings:

Depending on a project we use different tools. With dump-env being the default and the simplest one.

Extensions¶

We use different django extensions that make your life easier. Here’s a full list of the extensions for both development and production:

django-split-settings - organize django settings into multiple files and directories. Easily override and modify settings. Use wildcards in settings file paths and mark settings files as optional
django-axes - keep track of failed login attempts in django powered sites
django-csp - Content Security Policy for django
django-referrer-policy - middleware implementing the Referrer-Policy
django-health-check - checks for various conditions and provides reports when anomalous behavior is detected
django-add-default-value - this django Migration Operation can be used to transfer a Fields default value to the database scheme
django-deprecate-fields - this package allows deprecating model fields and allows removing them in a backwards compatible manner
django-migration-linter - detect backward incompatible migrations for your django project
zero-downtime-migrations - apply django migrations on PostgreSql without long locks on tables

Development only extensions:

django-debug-toolbar - a configurable set of panels that display various debug information about the current request/response
django-querycount - middleware that prints the number of DB queries to the runserver console
nplusone - auto-detecting the n+1 queries problem in django