Please note that the DGU applications do not run on a automated CI/CD pipeline, so please read this to ensure that your deployment is successful.
See Helm's documentation to get started with Helm.
See the GOV.UK Kubernetes cluster docs for an introduction to the cluster or ask #govuk-platform-engineering in Slack.
Local development uses k3d which runs a Kubernetes cluster locally using Docker.
- Install Helm
brew install helm
- Install Docker
Install from here
- Install k3d
brew install k3d
- Install kubectl
brew install kubectl- Clone the repository
git clone git@github.com:alphagov/govuk-dgu-charts.gitAdvantage of using k3d is that we don't need to worry about creating an ingress controller. This aligns with how we
run the cluster in EKS as that manages creation of the ingress controller for us.
- Create the
k3dcluster
k3d cluster create local-ckan --api-port 6550 -p "8081:80@loadbalancer" --registry-create local-registry- Switch kubectl to point to your local cluster:
kubectl config use-context k3d-local-ckan- Locate the port the registry is running on:
docker ps -f name=local-registryThe remaining steps will assume our local registry is running on localhost:53492
- Build a docker image
If we want to push an image to our local registry we have to tag our image. See here for background on local Docker registries.
So if our local registry is running at localhost:53492 and we want to build
ckan 2.10.4
we have to tag our image as follows:
docker build -t localhost:53492/ckan:2.10.4 -f docker/ckan/2.10.4.Dockerfile .Note: for Find build the dev.Dockerfile version
docker build -t localhost:53492/datagovuk_find:dev -f docker/dev.Dockerfile .- Push the image to our local registry
docker push localhost:53492/ckan:2.10.4- Use the image in our Helm chart
Currently govuk-dgu-charts/charts/ckan/values.yaml
points to the test environment:
environment: test
ckan:
replicaCount: 1
...
Update govuk-dgu-charts/ckan/images/test/ckan.yaml with our new image so it looks like this:
repository: local-registry:53492/ckan
tag: 2.10.4
branch: main
Note that local-registry matches the name of the registry we passed in step 1.
If we want to use a different image from a different environment then set environment appropriately.
- Apply the local dev Helm Chart
kubectl apply -f local-dev.yamlThis sets up some initial configuration in the cluster.
- Switch to the
datagovuknamespace
kubectl config set-context --current --namespace=datagovuk- Install the application Helm charts
helm install ckan-dev ./charts/ckan/ -n datagovuk
helm install datagovuk-dev ./charts/datagovuk/ -n datagovuk
helm install dgu-shared-dev ./charts/dgu-shared/ -n datagovukNow your local CKAN deployment will use the localhost:54392/ckan.2.10.4 image.
- On your local machine, update the
/etc/hostsfile as follows
127.0.0.1 localhost find.eks.test.govuk.digital ckan.eks.test.govuk.digitaldatagovuk-find can be accessed at find.eks.test.govuk.digital:8081
ckan can be accessed at ckan.eks.test.govuk.digital:8081
- update the
targetRevisioninckan-application.yamlordatagovuk-application.yamlto be the branch you want to test against. - update the target revision in Argo on
dgu-app-of-appsto be the branch you want to test, normally on the Integration cluster. - after testing is complete remember to set the target revision back to
mainindgu-app-of-apps. - if you are creating a PR drop the commit which updates the
targetRevisionin step 1.
When creating fine-grained API tokens, ensure that read/write permissions for PRs and Content are allowed (this will allow for PR and commit creation) and that CI user is used to create the PRs.
An ephemeral cluster is now available to test changes to the CKAN and datagovuk charts and infrastructure without impacting the other stable EKS environments.
To access the ephemeral cluster from your terminal you will need to log in to the govuk-test account
eval $(gds-cli aws govuk-test-admin -e --art 8h)and follow these steps to switch to the test environment.
To recreate the cluster from scratch if there is an existing ephemeral datagovuk cluster running, destroy the datagovuk cluster by deleting dgu-app-of-apps in the ephemeral Argo CD website and recreate the cluster by running the following command on the terminal under the charts directory (the environment variable passed in should match your ephemeral cluster name):
helm upgrade -n cluster-services datagovuk-argo-bootstrap argo-bootstrap --set environment=eph-aaa113To test your changes on the ephemeral cluster without merging them into the main branch:
- update the
targetRevisionin theckan-application.yamland/ordatagovuk-application.yamland push this change up to your branch onto Github - if you have deleted the
dgu-app-of-appsmodule then run thehelm upgradecommand as above - update the
targetRevisionindgu-app-of-appson the ephemeral Argo CD website. - after you have finished testing please remove the commit which changes the
targetRevisionbefore merging your changes into themainbranch
We have several Custom Resource Definitions (CRDs) installed in our Kubernetes clusters, and referenced by the Helm charts in this repository.
We use kubeconform to validate our Kubernetes manifests against schemas for those resources. This helps us ensure that our Helm charts are correct.
kubeconform runs in a GitHub Action as a pre-merge check and can also be run
locally.
You can run the validation tests locally by installing kubeconform and running
mkdir helm-dist
for c in charts/*; do
helm template "$(basename "$c")" "$c" --output-dir helm-dist
done
kubeconform -schema-location default \
-schema-location "https://raw.githubusercontent.com/datreeio/CRDs-catalog/main/{{.Group}}/{{.ResourceKind}}_{{.ResourceAPIVersion}}.json" \
-summary helm-distGOV.UK Platform Engineering team looks after this repo. If you're inside GDS, you can find us in #govuk-platform-engineering.