ArgoCD + Kustomize + Helm

Overview

In the chapter devoted to helm we discussed the possibility of using helm to generate the base descriptors for kustomize instead of using static descriptors. Well, this is what you’re going to do here.

Let’s recap here the key points of what we want to achieve:

Git is the source of truth
We want to deploy on different platforms and different environments

To accomplish this, we need to use helm and kustomize together. This is possible because Argo CD plugin framework allows to define custom plugins. In this exercise you will use one custom plugin called kustomized-helm^[1].

Figure 1. Difference between Template/Helm and Overlay/Kustomize

If you want to know more in detail the difference between Helm and Kustomize, click on the image.

Deploy Kitchensink app with ArgoCD + Kustomize + Helm

Now we want to deploy a JBoss EAP application using the helm templates kustomized for dev and test environments.

cat <<EOF | oc apply -n openshift-gitops -f -
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: kitchensink-kustomized-helm-%USERNAME%
  namespace: openshift-gitops
  labels:
    argocd-root-app: "true"
    username: %USERNAME%

spec:
  generators:
  - list:
      elements:
      - env: dev
        ns: helm-kustomize-dev-%USERNAME%
        desc: "Helm + Kustomize (Dev)"
      - env: test
        ns: helm-kustomize-test-%USERNAME%
        desc: "Helm + Kustomize (Test)"
  template:
    metadata:
      name: kitchensink-kustomized-helm-app-{{ env }}-%USERNAME%
      namespace: openshift-gitops
      labels:
        kitchensink-root-app: "true"
        kustomized-helm: "true"
        username: %USERNAME%
      finalizers:
      - resources-finalizer.argocd.argoproj.io
    spec:
      destination:
        namespace: '{{ ns }}'
        name: in-cluster
      project: default
      syncPolicy:
        automated:
          selfHeal: true
        syncOptions:
          - CreateNamespace=true
      source:
        path: advanced/overlays/{{ env }}
        repoURL: "https://repository-gitea-system.apps.%BASE_SUBDOMAIN%/%USERNAME%/kitchensink-conf"
        targetRevision: main
        plugin:
          env:
            - name: DEBUG
              value: 'false'
            - name: BASE_NAMESPACE
              value: 'cicd-tekton-%USERNAME%'
          name: kustomized-helm-v1.0
EOF

plugin

Custom plugin, variables are passed to it as environment variables.

...
        plugin:
          env:
            - name: DEBUG
              value: 'false'
          name: kustomized-helm
...

Check the deployment status in both Argo and OpenShift.

Argo

Open the following link to see the new Application objects you just created through the ApplicationSet in ArgoCD UI.

https://openshift-gitops-server-openshift-gitops.apps.%BASE_SUBDOMAIN%/applications?labels=username%253D%USERNAME%%2Ckustomized-helm%253Dtrue

OpenShift

To see the progress of deployment you should go to namespace helm-%USERNAME% in the OpenShift web console or just copy the following link.

dev

https://console-openshift-console.apps.%BASE_SUBDOMAIN%/topology/ns/helm-kustomize-dev-%USERNAME%?view=graph

test

https://console-openshift-console.apps.%BASE_SUBDOMAIN%/topology/ns/helm-kustomize-test-%USERNAME%?view=graph

Benefits of the GitOps/ArgoCD model

It provides an infrastructure base as code for application deployment.
It is based on Git, so everything we know about git is reused.
Allows deployment in multiple clusters in a simple way.
Includes the concept of a generator that simplifies complex deployments: multiple departments, business units, etc.
Not only deploys, but also fixes (un)voluntary modifications in the deployment environments.

Well, it’s time to set up webhooks to automate pipelines run.

1. How it is defined is out of the scope of this lab but if you want to know more you can have a look here and here