5.1 Helm
This lab explains how to use Helm as manifest format together with Argo CD.
Helm Introduction
Helm is a Cloud Native Foundation project to define, install and manage applications in Kubernetes.
It can be used to package multiple Kubernetes resources into a single logical deployment unit.
Helm Charts are configured using values.yaml files. (e.g. images, image tags, hostnames, …).
When using helm charts together with Argo CD we can specify the values.yaml like this:
argocd app set argo-helm-$USER --values values-production.yaml
The --values flag can be repeated to support multiple values files.
Info
Values files must be in the same git repository as the Helm chart. The files can be in a different location in which case it can be accessed using a relative path relative to the root directory of the Helm chart.Helm Parameters
Similar to when using helm directly (helm install <release> --set replicaCount=2 ./mychart --namespace <namespace>), you are able to overwrite values from the values.yaml, by setting parameters.
argocd app set argo-helm-$USER --parameter replicaCount=2
Warning
Argo CD provides a mechanism to override the parameters of Argo CD applications. The Argo CD parameter overrides feature is provided mainly as a convenience to developers and is intended to be used in dev/test environments, vs. production environments.
Many consider this feature as anti-pattern to GitOps. So only use this feature when no other option is available!
Helm Release Name
By default, the Helm release name is equal to the Application name to which it belongs. Sometimes, especially on a centralised ArgoCD, you may want to override that name, and it is possible with the release-name flag on the cli:
argocd app set argo-helm-$USER --release-name <release>
Warning
Please note that overriding the Helm release name might cause problems when the chart you are deploying is using the app.kubernetes.io/instance label. ArgoCD injects this label with the value of the Application name for tracking purposes.Helm Hooks
Helm hooks are similar to the Argo CD Hooks from lab 4 .
Further Docs
Read more about the helm integration in the official documentation
Task 5.1.1: Deploy the simple-example as Helm Chart
Let’s deploy the simple-example from lab 1 using a helm chart .
First you’ll have to create a new Argo CD application.
argocd app create argo-helm-$USER --repo https://gitea.training.cluster.acend.ch/$USER/argocd-training-examples.git --path 'helm/simple-example' --dest-server https://kubernetes.default.svc --dest-namespace $USER --values values.yaml
Sync the application
Hint
To sync (deploy) the resources you can simply click sync in the web UI or execute the following command:
argocd app sync argo-helm-$USER
And verify the deployment:
kubectl get pod --namespace $USER --watch
Tell the application to sync automatically, to enable self-healing and auto-prune
Hint
argocd app set argo-helm-$USER --sync-policy automated
argocd app set argo-helm-$USER --self-heal
argocd app set argo-helm-$USER --auto-prune
Task 5.1.2: Scale the deployment to 2 replicas
We can set the helm parameter with the following command:
argocd app set argo-helm-$USER --parameter replicaCount=2
Warning
Only use this way of setting params in dev and test stages. Not for Production!Since the sync-policy is set to automated the second pod will be deployed immediately.
Task 5.1.3: Ingress
The proper and production ready way of overwriting values is by doing it in git.
Change the helm/simple-example/values.yaml file in your git repository
...
ingress:
enabled: true
hosts:
- host: helm-<username>.training.cluster.acend.ch
paths:
- path: /
tls:
- hosts:
- helm-<username>.training.cluster.acend.ch
secretName: acend-wildcard
...
Commit and push the changes to your repository.
Hint
git add helm/simple-example/values.yaml
git commit -m "Expose ingress"
git push
Open your Browser and verify whether you can access the application.
Task 5.1.4: Create a second application representing the production stage
Let’s now also deploy an application for the production stage.
Create a new values.yaml file for the production stage: helm/simple-example/values-production.yaml
And copy the content from the default helm/simple-example/values.yaml file.
Change the host in the helm/simple-example/values-production.yaml to the production url
...
ingress:
enabled: true
hosts:
- host: helm-<username>-prod.training.cluster.acend.ch
paths:
- path: /
tls:
- hosts:
- helm-<username>-prod.training.cluster.acend.ch
secretName: acend-wildcard
...
Commit and push the changes to your repository.
Hint
git add helm/simple-example/values-production.yaml
git commit -m "Add prod stage"
git push
Let’s create the production stage Argo CD application with the name argo-helm-prod-$USER and enable automated sync, self-healing and pruning.
Hint
argocd app create argo-helm-prod-$USER --repo https://gitea.training.cluster.acend.ch/$USER/argocd-training-examples.git --path 'helm/simple-example' --dest-server https://kubernetes.default.svc --dest-namespace $USER
argocd app set argo-helm-prod-$USER --sync-policy automated
argocd app set argo-helm-prod-$USER --self-heal
argocd app set argo-helm-prod-$USER --auto-prune
And verify the deployment:
kubectl get pod --namespace $USER --watch
Tell the Argo CD app to use the values-production.yaml values file
Hint
argocd app set argo-helm-prod-$USER --values values-production.yaml
Change for example the ingress hostname to something different in the values-production.yaml and verify whether you can access the new hostname.
Task 5.1.4: Delete the Applications
Delete the applications after you’ve explored the Argo CD Resources and the managed Kubernetes resources.
Hint
argocd app delete argo-helm-$USER
argocd app delete argo-helm-prod-$USER