Deployment

Deployment

• Deployment stack is EC2/RDS/S3
• Deployment config/scripts live in https://github.com/DemocracyClub/ee_deploy
• Static files are served from /static - they don't live on S3
• EE may be deployed across multiple EC2 front-ends
• Logs are at https://papertrailapp.com/groups/8169292/events

S3 buckets

Every Election has a number of associated S3 buckets:

Production

• s3://notice-of-election - for storing notice of election docs uploaded by users
• s3://ee-maps - for storing GeoJSON/TopoJSON maps for each election group (generated by manage.py export_boundaries)
• s3://lgbce-mirror - for storing files relating to boundary changes/Electoral Change Orders
• s3://dc-ee-short-term-backups - for storing database backups (to be imported by WDIV, WCIVF)
• s3://ons-cache - Copies of data we need from the ONS (in EE, we import ONSPD from here because we can't fetch it from https://geoportal.statistics.gov.uk/ on-the-fly)

Dev

• s3://notice-of-election-dev - dev/staging installs shove notice of election uploads in here

Database Replication

Every Election may run across multiple databases in production using postgres replication.

The process for adding/removing capacity is documented in https://github.com/DemocracyClub/ee_deploy#databases

As well as giving us extra capacity, this gives some extra resilience. With replicas, we can scale up the master or run a heavy maintenance task and still serve API reads off the replicas while we do it.

TODO: Create a playbook for adding/removing DB replicas