Skip to content

Latest commit

 

History

History
134 lines (83 loc) · 5.79 KB

deployments.md

File metadata and controls

134 lines (83 loc) · 5.79 KB

Deployment

Github workflow is used to deploy to environments on Gov.uk PaaS.

Upon merging a PR to main a deployment to the development environment will be triggered. This will:

  1. Checkout the branch
  2. Login to Docker Hub
  3. Build docker image
  4. Upload docker image to Docker Hub
  5. Initialise Terraform
  6. Run the Terraform plan
  7. Apply the Terraform changes

PaaS

Some useful things to know about PaaS...

GOV.UK Platform as a Service (PaaS) is a cloud-hosting platform built by the Government Digital Service (GDS). GOV.UK PaaS manages the deployment of your apps, services and background tasks so you don’t need to hire people with specialist cloud skills.

GOV.UK PaaS uses the open source Cloud Foundry project, and runs on Amazon Web Services.

This repo has an organisation setup on PaaS. Speak to the org manager to authorise the creation of a personal account

The Cloud Coundry CLI can be used to manage apps hosted on PaaS - Setup Cloud Foundry CLI

Environments

This application runs through four environments:

  • dev
  • test
  • pre prod
  • prod

dev is deployed to automatically when a PR is merged into the main branch.

test, pre prod and prod deployments are triggered manually from the Github workflow tab

Each environment has a dedicated PaaS user account to run CI/CD jobs using Github workflows.

To find out the user account details, contact the org manager.

Github Actions

Actions are standalone commands that are combined into steps to create a job.

Workflows are made up of one or more jobs and can be scheduled or triggered by an event. The workflow is used to build, test, package, release, and deploy the application.

This repo has the following actions:

  • Build: This builds the Docker image
  • Test: Runs RSpec
  • Rubocop: Runs Rubocop
  • Deploy to Dev: Automatically triggers the 'Deploy to Environment' workflow when a PR is merged to main
  • Deploy to Test: Manual deployment trigger. Choose a a branch and that will trigger the 'Deploy to Environment' workflow
  • Deploy to Pre Prod: Manual deployment trigger. Choose a a branch and that will trigger the 'Deploy to Environment' workflow
  • Deploy to Production: Manual deployment trigger. Choose a a branch and that will trigger the 'Deploy to Environment' workflow
  • Deploy to Environment: Triggered by one of the above workflows. This is a generic workflow that accepts a target environment and git ref to checkout the code, build the docker image and deploy to the target environment.

Seed data

Seed data is destroyed and recreated in dev, test and pre prod environments.

prod does not get seeded with data automatically.

Environment variables

The application requires the following environment variables to deploy to an environment:

  • TF_VAR_paas_app_docker_image
  • TF_VAR_paas_user
  • TF_VAR_paas_password
  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY

They are stored in github secrets and consumed by the deploy jobs.

Databases

The application is backed by a PostgreSQL database hosted on PaaS.

The Conduit plugin on Cloud Foundry can be used to connect to a PostgreSQL database from your local machine

If you don't want to use Conduit, you can connect to a backing service via an SSH tunnel from your local machine. You might want to do this is to access the Postgres via a GUI for example.

Managing apps

PaaS hosted applications are run in a container. Connecting using SSH gives you secure access to the applications container.

Some thigns to be aware of... querks

  1. Read only DB mapping to the website (FYI)

The following command has been run on the CF CLI to restricts the website app to read only permissions of the Postgres instance

cf bind-service eyfs-ENV eyfs-postgres-ENV -c '{"read_only": true}'

This has been set on each environment because it can not be done using Terraform.

Note: When deploying to a new space or recreating the environment from scratch, this is a required manual step

  1. DNS remapping in production

On deploy to production, the DNS mapping is lost, meaning to the domain will 404. The the DNS route needs to be remapped to the domain again. Running the following using CF CLI will set the domain again.

cf target -s eyfs-prod
cf map-route eyfs-prod education.gov.uk --hostname help-for-early-years-providers

After deployment to production, this is run as part of the deploy task, no manual intervention required.

Documentation cross reference

Lots of how the infrastructure is created for this project has been made ontop of the shoulders of the Become a teacher team (BAT) They have more comprehensive documentation that shouldn't be repeated but referenced for completness