Single Application, multiple sources — practical usage in ArgoCD

ArgoCD v2.6+ brings a long waited feature: now a single kind: Application can point to multiple sources like Helm Charts or GIT repositories.

That’s a new possibility to mix the things that are coming from 3rd party (e.g. official NextCloud Helm Chart) with something that we need to add, but the official Helm Chart does not allow doing so.

Notice: At the time of writing of this article (24.01.2023) ArgoCD 2.6 is in rc4, you may want to wait a few weeks for a stable release to deploy it on production. Check current ArgoCD releases here.

Let's have a look at some practical examples.

Example #1: External Application + Commonly used kinds

Create a generic Helm Chart in your GitOps repository at your private GIT instance with templates of the most common extras you add across all applications deployed in the cluster like kind: NetworkPolicy, kind: PodDisruptionBudget, kind: RoleBinding , kind: KubeArmorPolicyor some additional Ingresses or Services to expose on additional networks. Now use it as a second source for your kind: Application

---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nextcloud
  namespace: argocd
spec:
  project: default
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  sources:
    - chart: nextcloud
      repoURL: https://official-nextcloud-repo
      targetRevision: 25.0.0
    - repoURL: https://github.com/your-org/common-helm-charts.git
      path: charts/common-application-chart
      targetRevision: HEAD

In effect, you can see all of the required things together in ArgoCD, next to the application Pods and other resources, all in one view.

Just click on the “nextcloud” tile to see:

• Are the application Pods ok?
• Is the IP address allowed by the NetworkPolicy?
• What’s the disruption budget?
• Is the additional Ingress properly created?

In ArgoCD 2.5 and below you had to create e.g. “nextcloud” + “nextcloud-config”, now everything is in one place.

Example #2: Stateful Application + Backup definition

Bitnami’s PostgreSQL from official Helm Chart + backup CronJob and SeccompPolicy from local GIT repository

What about having a backup CronJob or Velero Backup definition with the application?

All the time when you want to check if the application behaves correctly you just click a single tile in ArgoCD and see:

• Are the Application Pods ok?
• How was the last backup?

It simplifies everything, no more extra Application tiles handling the synchronization of a single object.

Take a look at the advanced example with ApplicationSet generating an ArgoCD kind: Application per MariaDB instance with two sources:

---
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
    name: mariadb-dbs
    namespace: argocd
spec:
    goTemplate: true
    generators:
        - git:
              repoURL: https://my-git.org/some-org/cluster-repo.git
              revision: HEAD
              pathParamPrefix: ""
              files:
                  - path: "apps/dbs/mariadb-*.yaml"
    template:
        metadata:
            name: '{{trimSuffix ".yaml" .path.filename}}'
        spec:
            project: "dbs"
            sources:
                # Our extra Helm Chart
                - repoURL: https://my-git.org/some-org/common-helm-charts.git
                  targetRevision: HEAD
                  path: "charts/mariadb-extra-config"
                  helm:
                      releaseName: '{{trimSuffix ".yaml" .path.filename}}-backup'
                      values: |
                          instance: {{toJson .instance}}

                # Official installer
                - chart: mariadb
                  repoURL: https://charts.bitnami.com/bitnami
                  targetRevision: "{{.instance.chartVersion}}"
                  helm:
                      releaseName: '{{trimSuffix ".yaml" .path.filename}}'
                      values: |
                        architecture: standalone
                        primary:
                            # PVC is defined separately in "PVC" project
                            persistence:
                                enabled: true
                                existingClaim: {{.instance.pvcName}}
                            resources: {{toJson .instance.resources}}
                        
                        auth:
                            existingSecret: {{trimSuffix ".yaml" .path.filename}}

            destination:
                server: https://kubernetes.default.svc
                namespace: db
            syncPolicy:
                automated:
                    prune: false
                syncOptions:
                    - FailOnSharedResource=true

Case, where you still may want to have separate tiles

Single tile means single synchronization settings. You may probably want to avoid automatic synchronization with pruning for superior or stateful resources like Namespaces or PersistentVolume/PersistentVolumeClaim.

For Namespaces and PV/PVC I recommend to create separate two or three administrative tiles, properly configured for massive creation of such resources with proper caution.

Automation creating Namespaces with ResourceQuotas, NetworkPolicies and other per-namespace default objects. This `kind: Application` never prunes any resources.

Read more about my collection of good practices with ArgoCD at scale

Hygiene of an ArgoCD-built automation at a scale

Summary

ArgoCD is becoming a well developed software with a wide range of possibilities, v2.6 is introducing a change that will let you clean up the mess by grouping multiple kind: Application into logical pieces.

Stay tuned for more practical GitOps and ArgoCD articles, subscribe my newsletter and follow my profile.