Skip to main content

How to create a multi-site Django application using Mirrors

Start with the source application, from which the Divio mirrors will be created. Divio mirrors share the codebase of the source application, but run as wholly independent Docker containers. To learn more, refer to Divio Mirrors.

Create Divio mirrors​

Ensure that both Test and Live servers have been successfully deployed.

Create one or more mirrors.

Mirrors can be configured to deploy images either from the production environment or from matching environments of the source application. See Divio Mirrors for more information.

Apply environment variables to each mirror​

Database and media storage​

The following environment variables from the Test and Live environments of the source application will need to be applied to the corresponding environments on each of the mirrors:

  • DATABASE_URL
  • DEFAULT_STORAGE_DSN

For more information about environment variables, including how to retrieve their values, see How to manage your application's environment variables.

Using the Control Panel, add the environment variables to the Test and Live environments for each mirror.

SITE_ID​

The SITE_ID of the source application will be 1 by default. For each mirror, add a SITE_ID environment variable, incrementing it each time.

If two sites share the same SITE_ID, or if you save an object in the Sites admin before deploying a mirror with its SITE_ID in place, you may have unexpected results.

Deploy your mirrors​

Mirrors can be deployed from their own Dashboards, or from the Mirrors view of the source application.

In the Django Sites admin you will see each mirror now listed.

If you're using a Django application that makes use of the Sites framework, such as django CMS, you will see that it now has access to multiple independent sites. In django CMS for example this means that pages can be one site of the application or another.

Managing database migrations​

Typically when working with mirrors, code changes will be applied to the source application and then rolled out to each mirror over a period of time. At any given moment, not all mirrors may be deployed alongside the source application.

Because the deployment of any one of the sites runs any outstanding migrations in the shared database, it is possible for the database and codebase to become temporarily out of synchronisation for some sites.

Backwards-compatible migrations​

One solution to this is to adopt a two-step strategy for migrations that could be affected.

For example, suppose that a code change removes a database field. In that case, when the source application is deployed, it will immediately change the database schema, and any code in the mirrors that expects to find the field will fail.

Instead, you would need to:

  1. without changing the model field, remove code in views, model methods and so on that would attempt to use the field
  2. roll out the change to all mirrors
  3. remove the field
  4. migrate the database