Usage in Production

The provisioning scripts are designed to be run independently of Vagrant in order to provision production environments that match those used in development. While provisioning is not as simple as vagrant up, it is very straightforward.

Production-specific features

There are several features that are only available in production environments. These include:

• Firewall
• Gunicorn

In addition, the following features behave differently when in a production environment:

• SSH access: the vagrant user is not on the list of SSH allowed users
• Nginx: Nginx site configs are tailored to production sites and support using Let’s Encrypt to add TLS.
• Python dependencies: only requirements.txt is considered, dev_requirements.txt is ignored
• Node dependencies: in package.json, only dependencies is considered, devDependencies is ignored
• The pull+ shortcut command performs additional steps

Configuration

Due to the additional features supported in production environments, some additional configuration may be required. The following are some of the things to consider:

• Configuring the firewall
• Configuring nginx, including Let’s Encrypt
• Configuring gunicorn
• Configuring supervisor

Provisioning

Provisioning in a production environment is not quite as simple as vagrant up, it requires a few more steps:

1. Create the /opt/app/src directory.

2. Copy the project source, including provisioning files into /opt/app/src. The provisioning files should be at /opt/app/src/provision. The easiest way to do this is probably to clone your git repository, if you use one.

3. Create an env.sh file (at /opt/app/src/provision/env.sh) and populate it accordingly.

4. Manually invoke the provisioning bootstrap script as root:

   $ /opt/app/src/provision/scripts/bootstrap.sh
   

5. Invoke the separate Let’s Encrypt configuration script as root:

   $ /opt/app/src/provision/scripts/letsencrypt.sh email@example.com example.com www.example.com
   

There are several final steps that automated provisioning does not take care of. This may be because they are unsafe to include in the provisioning process (e.g. in the event of re-provisioning), or because user input is required.

• sudo apt-get upgrade (see the limitations documentation for more details)

• In order to have sudo privileges, a password needs to be created for the webmaster user. When logged in as the webmaster user, simply run the passwd command to set a password.

• Run any necessary commands to prepare the project, including:

  • Build commands, e.g. to compile CSS
  • manage.py collectstatic
  • manage.py migrate

Warning

It is a good idea to ensure the sudo password for the webmaster user is set up and working prior to terminating the root user session used to run the provisioning scripts. Once the session is terminated, the root user will no longer be able to SSH into the server. If the webmaster user does not have a password configured, it will be unable to use sudo commands, and leave much of the server inaccessible.