ArgoCD + Kustomize

In the previous chapter you used kustomize to deploy your application to two different environments (or overlays). But there was a catch: What if you have to adapt the descriptors even more, different storage, different cloud vendor, …?

In this case helm could fit the bill. With helm you can use templates to adapt the descriptor to almost anything. It’s true that with helm you can install and upgrade, but you can use it only if you want to use the template engine to generate the descriptors the way you need. This is exactly what Argo CD will do for you it will use the command helm template to generate kubernetes descriptors starting from a git repository.

Please have a look at the next link:

https://repository-gitea-system.apps.%BASE_SUBDOMAIN%/%USERNAME%/kitchensink-conf/src/branch/main/advanced/helm_base/templates

There you will find basically the same descriptors you should be already used to, like:

kitchensink-deployment.yaml ⇒ deployment descriptor of kitchensink
kitchensink-db-deployment.yaml ⇒ deployment descriptor of the kitchensink database
kitchensink-bc.yaml ⇒ BuildConfig in charge of building our application image using S2I

The only difference is that labels, namespace, etc. are not set all in the same way, there’s a greater degree of freedom because the helm template language is richer than the kustomize yaml directives.

Deploy Kitchensink app with ArgoCD + Helm

Now we are going to deploy the same application in the same way, but instead of using overlays we will use templates with helm.

cat <<EOF | oc apply -n openshift-gitops -f -
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: kitchensink-helm-app-%USERNAME%
  namespace: openshift-gitops
  finalizers:
    - resources-finalizer.argocd.argoproj.io
  labels:
    kitchensink-root-app: 'true'
    helm: 'true'
    username: %USERNAME%
spec:
  destination:
    name: in-cluster
    namespace: helm-%USERNAME%
  ignoreDifferences:
    - group: apps
      jqPathExpressions:
        - '.spec.template.spec.containers[].image'
      kind: Deployment
  project: default
  source:
    helm:
      parameters:
        - name: debug
          value: 'true'
        - name: baseNamespace
          value: 'helm-%USERNAME%'
    path: advanced/helm_base
    repoURL: "https://repository-gitea-system.apps.%BASE_SUBDOMAIN%/%USERNAME%/kitchensink-conf"
    targetRevision: main
  syncPolicy:
    automated:
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
EOF

helm

Parameters that allow us to adjust descriptor templates to particular needs.

...
    helm:
      parameters:
        - name: baseNamespace
          value: demo-6
...

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%%2Chelm%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.

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

The catch

This approach allows you to adjust descriptors with a greater degree of freedom at the expense of making it difficult to deploy in different environments which kustomize can do easily…

Wouldn’t if be perfect to use helm to generate the base descriptors for kustomize to put them into the right namespace with the right common labels, etc?