Helm chart
Helm is the package manager for Kubernetes.
We deploy all of our applications using a helm chart to Kubernetes.
Installing helm
Install helm along with the other tools using the links on the person onboarding doc.
Base charts
We provide opinionated, batteries included helm charts that give:
- a simple interface to provide application configuration,
- features that a wide variety of applications require,
- a standard approach for all applications,
- in built support for secrets from Azure KeyVault,
You shouldn’t need to understand helm to use our charts, for a simple app this is all the configuration you need:
java:
applicationPort: 4550
image: 'hmctspublic.azurecr.io/rpe/spring-boot-template:latest'
environment:
A_KEY: 'a value'
To see the full helm chart take a look at spring-boot-template.
The main base charts are:
What are values.*.template.yaml for?
We deploy the microservice helm charts for testing using Jenkins only on preview and AAT,
Jenkins will override the configuration of the helm chart using these files.
values.preview.template.yamlis for previewvalues.aat.template.yamlis for AAT
It is expected that values.yaml will provide a working chart out of the box that someone can install on their own machine,
The values.aat.template.yaml file should only include the absolute minimum config:
java:
environment:
# Don't modify below here
image: ${IMAGE_NAME}
ingressHost: ${SERVICE_FQDN}
The values.preview.template.yaml may contain additional config if other services are being
spun up on pull requests,
Some common examples:
- a postgresql database - this is included in chart-java , with sensible defaults built in,
- a Redis cache,
- chart-idam-pr - a job that registers your
redirect_uriin IDAM, - chart-blobstorage - creates Azure Blob storage for you, using Azure Service Operator,
- chart-servicebus - creates Azure Service Bus for you, using Azure Service Operator.
If you are using another sub-chart just for preview such as an embedded redis container, then you should make this conditional with:
Chart.yaml:
dependencies:
- name: redis
version: 10.6.18
repository: "https://charts.bitnami.com/bitnami"
condition: redis.enabled
values.yaml:
redis:
enabled: false
values.preview.template.yaml:
redis:
enabled: true
master:
persistence:
enabled: false
Advanced values for the preview environment
You can add additional value configurations for use within the preview environment which is useful when you want to test ccd/xui per pull request (PR). To make use of this feature you need the following:
- Your PR needs to have a label in the format of
pr-values: application(example:pr-values: ccd - You need to create a template using the name of
values.application.preview.template.yaml(example:values.ccd.preview.template.yamland add any specific values you need on the PR.
Providing you follow the above steps, the Jenkins library will parse the labels and form a list of templates to use, apply envsubst to override templated config and append the files to Helm.
Publishing helm charts
We publish charts in two different ways depending on the type of chart.
Microservice charts are published via Jenkins as they live with the code and changes to them are tested via the standard pipeline that everyone uses.
Base charts and non application charts are published via Azure DevOps.
Jenkins
Jenkins will deploy your application using your helm chart in the application’s repository on every master and pull request build.
On a master build after functional testing has passed the chart will be published if it has not already been published.
To publish a new version:
- Bump the version field in Chart.yaml in a pull request
- After approval and a passing build merge it to master
You should always publish a new version if you change values.yaml or requirements.yaml, Jenkins will automatically increase the version if you don’t do this, so you don’t need to worry too much.
Azure DevOps
Chart builds are run against the ‘preview’ AKS cluster, and chart are published to ‘hmctspublic’ Azure Container Registry.
See the chart-java pipeline for an example.
It does:
- on pull request: trigger a build that performs helm lint, helm install and helm test
- on tag: trigger a build that performs helm lint, helm install, helm test, helm package and publish to ‘hmctspublic’ ACR
Performing a Release
Performing a release consists of the following steps:
- Submit your PR which also includes a chart version bump (the version field in Chart.yaml)
- Wait for the PR validation build to pass and a colleague’s approval
- Merge the PR
- Create a Github release, tagging it with the same version number used in Chart.yaml
- The release build will be triggered, publishing the new chart version
Setting up an AzureDevOps chart build
Join the dcd_group_ado_user_v2 Microsoft Entra group, this will give you:
- Access to AzureDevOps,
- Read access to the CNP project where the chart builds live.
Add an azure-pipelines.yml file to your repo, using chart-java as a base.
Ask on #platops-help on slack for someone to setup the pipeline for you in AzureDevOps.
Adding Azure Resources when using Azure DevOps charts
Like Jenkins it is possible to add Azure resources to your charts when publishing via Azure DevOps. The following resources can be created:
Postgres Databases
Postgres databases can be added and test via the existing Postgres Instance in the chart-tests namespace.
Guidance can be found in the chart repository.
The database instance used for Azure DevOps builds is:
postgresql:
flexibleserver: chart-tests-flexibleserver-postgres-preview
Blob Storage
Blob storage is typically used by Application charts built via Jenkins but it is possible to use the blob storage chart to test other charts via ADO.
You must use the chart-tests resource group to test with Blob Storage:
blobstorage:
resourceGroup: "chart-tests-aso-rg"
Service Bus
Service bus topics and queues can be tested much in the same way as Postgres as there is an existing namespace for the chart-tests namespace.
Guidance is available via the chart repository.
resourceGroup: chart-tests-aso-rg
sbNamespace: chart-tests-servicebus
All charts
We follow a standard naming convention of chart-<name> for all Helm charts, you can find a list of all
charts using Github Search in the organisation.