Cloud Platform technical overview
The Cloud Platform (CP) is a kubernetes cluster, running in the “moj-cp” Amazon AWS account, inside a Virtual Private Cloud (VPC) which isolates the cluster and the AWS resources used by services running in the cluster.
Where your code runs
A namespace is like a “fenced off” portion of the cluster. Your service runs inside one or more namespaces, and only your team has access to those namespaces. Access is controlled via membership in a specific github team within the MoJ github organisation, e.g. prisoner-money)
All namespaces are defined in the Cloud Platform Environments repository. Follow this guide to create a new namespace. To modify an existing namespace, you need to raise a PR with the relevant changes, and a member of the Cloud Platform team will review it for you.
The namespaces are defined in kubernetes YAML files. There is also a
resources directory inside each namespace directory. This contains terraform code which defines any AWS resources (e.g. an RDS database) that your namespace requires.
Typically, creating an AWS resource will also add secrets to your namespace, containing the access credentials required to use that resource.
How your code gets to the cluster
To deploy code to the CP, you will update a local YAML file which defines your deployment, and change the reference to your docker image.
e.g. you might change that reference from
ministryofjustice/my-application:1.4 and then apply the new definition to the cluster.
As soon as you do this, the cluster will recognise that the container which is currently running
ministryofjustice/my-application:1.3 is no longer the correct version, and will launch a new instance of
ministryofjustice/my-application:1.4 and delete the old one.
- Develop code in your local environment, and raise PRs in your team’s Github repositories
- Review and merge PR
- On merge, your CI/CD pipeline (e.g. CircleCI):
- creates docker image(s) from your code
- tags and pushes docker images to your docker repository (e.g. ECR or Docker Hub)
- updates your kubernetes yaml files (usually also in github) with new image tag values (this may be a manual step)
- Code is now ready to deploy to the cluster by using
kubectl applyto apply the updated yaml file to the cluster (this may also be done via a CD pipeline)
- Kubernetes recognises that the state of the cluster (specifically, your namespace) doesn’t match the desired state defined in your yaml files, and makes whatever changes are required (e.g. launches pods running your new docker image, and shuts down any pods running the old version)