Overview

This is an overview of how CTS is deployed.

Server Architecture

CTS is deployed on the following stack using Fabric and SaltStack:

  • OS: Ubuntu 12.04 LTS
  • Python: 2.7
  • Database: Postgres 9.1
  • Application Server: Gunicorn
  • Frontend Server: Nginx
  • Cache: Memcached

Deploys are done to a single server, which will serve all the CTS instances under one domain name using URL prefixing.

For development and test purposes, CTS can be deployed to servers other than production. These are called environments, and there are two defined initially:

  • staging
  • production

The fab commands used to deploy and provision a server always take an environment name as the first argument, e.g. fab staging do_something.

When deploying to a server, the code is deployed from a branch of the code repository on GitHub. Which branch is used is controlled by a setting in the local file conf/pillar/<ENVIRONMENT>/env.sls, e.g. conf/pillar/staging/env.sls might contain:

environment: staging

domain: cts-staging.caktusgroup.com

repo:
  url: git@github.com:theirc/CTS.git
  branch: origin/develop

This indicates that the staging server will use the code from the origin/develop branch.

Country Instances

On a server, there can be multiple copies of CTS running, each with completely independent data. Each copy is called an instance.

All the instances on a server are running the same code, but they run in different processes and use different databases.

An Nginx server receives incoming requests and routes them to the appropriate instance based on the first part of the URL path. E.g. https://cts.rescue.org/IQ/ might go to an instance for Iraq, while https://cts.rescue.org/TR/ might go to an instance for Turkey.

The instances are defined in the file conf/pillar/project.sls and are the same for all environments. Here’s a sample excerpt from that file:

instances:
  turkey:
    name: Turkey
    prefix: /TR
    currency: TRY
    port: 8001
  iraq:
    name: Iraq
    prefix: /IQ
    currency: IQD
    port: 8002
  jordan:
    name: Jordan
    prefix: /JO
    currency: JOD
    port: 8003

Note that this file defines for each instance a human-readable name, a URL prefix, the international code for the instance’s currency, and an internal port where the instance will listen.

Logs for each instance are in /var/www/cts/log/<INSTANCE>/ on the server, where <INSTANCE> is the key of the instance in the configuration, e.g. iraq or turkey.

Some fab commands require an instance to be specified. Here’s an example of how that is done:

fab staging instance:iraq manage_shell

For each instance, there’s a file cts/settings/<INSTANCE>.py with the settings that are unique for that instance. See the existing files, such as cts/settings/jordan.py, to see what needs to be in the instance’s settings file. (Actually, very little needs to be in there.)

Local Development

When running locally (e.g. django-admin.py runserver), the environment name is dev and there’s only one instance, local, with no URL prefix. Since there’s no prefix, it should work the way developers are used to.