Getting the service up and running
Once the Cloud Platforms Terraform has run, the environments should populate (click on the Settings tab and choose Environments from the list)
You should now be able to clone the GitHub project locally, successfully run the tests, start the application on your local computer and see the /health and /info pages.
This is a good time to update README.md to replace the template readme with content more relevant to your service. See the service standards for inspiration.
Note that depending upon your project you may wish to limit access to your production service using an IP allowlist.
To control access by using roles assigned to users or services - ask in MOJ Slack channel #hmpps-auth-audit-registers for more details.
Typescript application secrets
If you are trying to create a Typescript application your deployment is probably failing. There are a few secrets that are only required by Typescript applications. Once these secrets are created your application should start deploying.
It’s worth running the command kubectl -n <your-new-service-name>-dev get events to try and spot which secrets are missing.
session secret
The Typescript template project requires a secret which is used to sign session cookies. This is how it knows that cookies haven’t been tampered with when presented by a client. Using the Cloud Platform secrets guide update the secret <your-new-service-name> by adding a new key SESSION_SECRET followed by a random value (don’t forget to base64 encode the value).
Note: Please do not use / configure the Cloud Platform Secrets Manager, since this prevents scheduled secret rotation scripts from running successfully.
authorization_code client
Users sign in to the UI application using the Oauth2 authorization_grant flow. After a successful sign in the UI application calls hmpps-auth to receive a valid access token. We need a client and secret to prove to hmpps-auth that we are allowed to request access tokens. These secrets are stored in Kubernetes secrets API_CLIENT_ID and API_CLIENT_SECRET.
To request a new authorization code client from hmpps-auth raise a ticket on the DPS Tech Team JIRA board in this format. Then ask in MOJ Slack channel #hmpps-auth-audit-registers for the ticket to be prioritised. Once the clients have been created in hmpps-auth the DPS Tech team will copy the secrets into your namespace.
client_credentials client
When a UI application needs to call an API it must prove that it is authorised to call that API using the Oauth2 client_credentials flow. The UI application calls hmpps-auth to request an access token it can present to other APIs as authorisation. We need a client and secret to prove to hmpps-auth we can have an access token. These secrets are stored in Kubernetes secrets SYSTEM_CLIENT_ID and SYSTEM_CLIENT_SECRET.
To request a new client credentials client from hmpps-auth raise a ticket on the DPS Tech Team JIRA board in this format. Then ask in MOJ Slack channel #hmpps-auth-audit-registers for the ticket to be prioritised. Once the clients have been created in hmpps-auth the DPS Tech team will copy the secrets into your namespace.
Checking the application is healthy
We have now deployed the application to dev and need to check it is up and running as expected. Run command kubectl -n <your-new-service-name>-dev get ingress where you should find the host of your application. In a browser go to page https://<hostname>/health and you should see a health page with status UP.
Troubleshooting - Missing certificate
If you see an error such as Your connection is not private or Potential security risk ahead then it implies that the application is not using the certificate we generated with terraform earlier. Look in project file helm_deploy/<your-new-service-name>/values.yaml for property generic-service.ingress.tlsSecretName - this is the secret we copy the certificate from. Then run command kubectl -n <your-new-service>-dev get secrets to find a secret of type kubernetes.io/tls - this is the secret holding the certificate and should match the secret name in our project. If not then go back to the cloud-platform-environments project for dev and find the certificates yaml. Change the property spec.secretName to match the real secret name and issue a PR. You may also need to do this for preprod and prod.
Edit this page here.