Skip to main content

Migrating to the Cloud Platform from Template Deploy

These are some of the things to think about when migrating your application from Template Deploy (TD) to the Cloud Platform (CP).

Note to maintainers: This page is sometimes referenced for general migration advice. When we remove template deploy-specific pages, content on this page should be replaced by a generic migration advice page, and this page should link to that one, so that anyone following an old link can still find the information they need.

Production infrastructure

Any infrastructure resources, such as databases or cache servers, should be of the same size, and running the same software (e.g. postgres) version, for the CP version of your app. as for the TD version.

Allowing network traffic to/from your service

The IP numbers from which your app’s traffic originates will change. If your app. talks to any external services which care about its source IP addresses, you may need to arrange for those services to allow traffic from the cluster IPs.

If you have configured your service to allow inbound traffic from any specific IPs, you will need to add the corresponding config to your kubernetes deployment files.

This section of the user guide describes both of these procedures: IP filtering.

DNS changes

When you are ready to switch from the TD version of your app. to the production version deployed in CP, the last step will be to change the DNS entries such that visitors to your app’s domain are sent to the new CP version.

It’s important to plan this step carefully. Some things to think about include:

  • Who controls DNS for your app’s domain (MoJ? GDS?). For * domains, changing the DNS requires action from GDS, and you will need to plan for this.
  • Do you have users on private networks (e.g. DOM1, Quantum)? How confident are you that they will get the correct address after the DNS change? Some networks (e.g. Quantum), are known to have problems with DNS changes, so you may need to engage with the network operator (e.g. Atos, Vodafone) ahead of time.

AWS access

All AWS resources in the Cloud Platform are in a separate, moj-cp AWS account. Access to this account is tightly restricted, so if you are accustomed to using the AWS web console to help operate your service, you will need to do things differently in the Cloud Platform.

AWS region

Everything for the Cloud Platform is in the eu-west-2 (London) region. TD generally uses eu-west-1 (Ireland). For features not available in the London region (eg SES, at time of writing), cross-region links can be created and will be evaluated on request.


DNS and SSL are managed by cluster-shared services (cert-manager and external-dns)

  • Validation and deployment are managed by a single pipeline.
  • Renewals are automatic.

Does your service have users who are stuck with very old browsers? If so, consider the following:

  • CP SSL certificates are generated by LetsEncrypt. If the user’s browser does not recognise LetsEncrypt as a valid certificate authority, they may get security warnings when accessing your service, or they may not be permitted to access it at all.
  • TLS version:
    • At present there are a few remaining older applications/services, where there is a need to still allow some users with older browsers (that do not support TLS 1.2) to access these services.
    • Cloud Platforms intend to carry out work in the near future to:
      • Limit being able to utilise these older browsers to access just these older applications only.
      • Therefore for the remaining majority of the newer/services applications, there will be a requirement:
        • for a minimum TLS version of 1.2. Users with the older browsers will therefore not be able to access these newer services.
    • Please therefore bear this in mind when migrating from TD to the Cloud Platform.

Connections to/from service IPs

Inbound connections to service IPs are not possible on the Cloud Platform. Access to your service must go via HTTPS to a URL, not by inbound access to an IP number.

Connections to resources outside the cluster, using IP numbers rather than URLs, are allowed.

NB: UDP is not available at all.

Application Architecture

  1. Applications must log their entire output to STDOUT/STDERR.

    • A cluster-shared service (fluentbit) automatically collects all the outputs and sends them to ElasticSearch with no explicit configuration needed.
    • Services that capture the output to re-format or send to a different destination can be run as multi-container pods, but may be superfluous.
  2. You don’t need to run an init service (e.g. runit, or systemd) in your containers. Kubernetes will keep your services running, by itself.

  3. You don’t need to run cron in your containers. Use kubernetes cron jobs.

  4. Keep startup as quick as possible

    • Initialisation tasks such as database migrations or loading seed data should be configured as separate kubernetes jobs, not run as part of the initialisation of your main application. This is because, if your container takes too long to enter ready state, kubernetes will assume there’s a problem and kill it. This can lead to crash-looping, where your workloads never start successfully.
  5. Don’t use local disk storage. If you need to write to the filesystem use a persistent volume or, better still, an S3 bucket.

  6. Monitoring is included with the Cloud Platform

  7. Your application will be moved around, by kubernetes, from one worker node to another. i.e. your application should tolerate individual pods being killed and replaced.

  8. Always run at least 3 replicas of your core, user-facing services, to ensure users do not experience downtime when kubernetes moves your pods to another node

Additional features

  1. A shared, highly-available deployment of reverse-proxy instances based on AWS ELB and Nginx runs in front of all application instances and offers features like WAF, custom error pages or IP-based ACLs user-configurable per application but independent from its running state.

    • Basic auth can be quickly turned on/off at ingress level, useful when deploying dev services.
  2. Several AWS resource types are tested and documented as Terraform modules; they simplify deployment and default to best-practices options.

Obsoleted features

  1. Salt and CloudFormation are no longer used to define a deployment, replaced by any of Helm or Kubectl (see several reference app examples).

  2. Jenkins is no longer used to trigger deployments, teams are encouraged to configure CircleCI directly from their repositories.

  3. For application logs, the path awslogs + CloudWatch + Lambda is replaced by fluentbit.

  4. Gandi and AWS ACM SSL certs are replaced by Let’s Encrypt

This page was last reviewed on 8 June 2021. It needs to be reviewed again on 8 September 2021 .
This page was set to be reviewed before 8 September 2021. This might mean the content is out of date.