Cloud Platform technical overview
The Cloud Platform (CP) is a kubernetes cluster with associated AWS resources.
An Amazon AWS account “cloud-platform-aws” contains all of the platform, including running services.
A Virtual Private Cloud (VPC) provides a network for the platform, and offers control over incoming requests from the Internet.
Where your code runs
Within the cluster, services are network-isolated from each other using namespaces. Inside a namespace you run deployments, which consist of one or more docker containers. The code you write will run inside those containers.
Your namespace(s)
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.
AWS resources
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 a deployment (which contains a pod), and change the reference to your docker image.
e.g. you might change that reference from ministryofjustice/my-application:1.3 to 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.
Typical Workflow
- 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. GitHub Actions):
- 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)
- deploys to the cluster by using
kubectl apply, sending the updated yaml files to the cluster
- 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. Typically, it launches pods running your new docker image, and as they become responsive, it terminates pods running the old image version.