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:

# In the Application spec.source.helm section:
valueFiles:
  - values-production.yaml

The --values flag can be repeated to support multiple values files.

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.

# In the Application spec.source.helm section:
parameters:
  - name: replicaCount
    value: "2"

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:

# In the Application spec.source.helm section:
releaseName: <release>

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.

Create a file argocd-helm-application.yaml with the following content and apply it:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: argo-helm-$USER
  namespace: openshift-gitops
spec:
  project: default
  source:
    repoURL: https://gitea.training.cluster.acend.ch/$USER/argocd-training-examples.git
    targetRevision: HEAD
    path: helm/simple-example
    helm:
      valueFiles:
        - values.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: $USER

oc apply -f argocd-helm-application.yaml

Sync the application

And verify the deployment:

oc get pod --namespace $USER --watch

Tell the application to sync automatically, to enable self-healing and auto-prune

  syncPolicy:
    automated:
      selfHeal: true
      prune: true

oc apply -f argocd-helm-application.yaml

Task 5.1.2: Scale the deployment to 2 replicas

We can set the helm parameter with the following command:

Edit argocd-helm-application.yaml to add the parameter override in spec.source.helm, then re-apply:

    helm:
      valueFiles:
        - values.yaml
      parameters:
        - name: replicaCount
          value: "2"

oc apply -f argocd-helm-application.yaml

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.

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.

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.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: argo-helm-prod-$USER
  namespace: openshift-gitops
spec:
  project: default
  source:
    repoURL: https://gitea.training.cluster.acend.ch/$USER/argocd-training-examples.git
    targetRevision: HEAD
    path: helm/simple-example
    helm:
      valueFiles:
        - values-production.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: $USER
  syncPolicy:
    automated:
      selfHeal: true
      prune: true

oc apply -f argocd-helm-application-prod.yaml

And verify the deployment:

oc get pod --namespace $USER --watch

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.5: Delete the Applications

Delete the applications after you’ve explored the Argo CD Resources and the managed Kubernetes resources.

oc delete application argo-helm-$USER argo-helm-prod-$USER -n openshift-gitops