Introduction to ArgoCD: apps of apps
What are Apps of Apps or Cluster bootstrapping?
The App of Apps Pattern helps us define a root Application. So, rather than point to an application manifest fort every application creation, the Root App points to a folder which contains the Application yaml definition for each child App. Each child app’s Application yaml then points to a directory containing the actual application manifests be it in manifest file, Helm or Kustomize.
ArgoCD will watch the root application and synchronize any applications that it generates.
- You may have this question as to why is this even needed, whereas you can manually create the application via Argo CLI or Argo UI.
- But once the number of applications you manage increases, automation needs to be done.
- For example, if you have a new app that needs to be created & deployed in your cluster via ArgoCD, apart from Argo CLI and UI ( both are manual ) we really don't have any automation on the creation of apps except custom scripting.
Behold, Apps of apps
Actually, it took me a while to understand what exactly it is because the official doc is not well written (as of now).
Since the concept is pretty new and as far as I know, not many Argocd users are utilizing this.
Now that we know why & what let's go over to how.
- Root app: the single app you need to deploy to your cluster ( parent/root)
- Child app: your actual micro-service applications (child)
- Child app template: Argocd Application kind template describing your application
- Application manifests: the actual micro-service definitions
Git repo → root app → application templates → actual applications
- Kubernetes cluster
- Helm v3
- ArgoCD installed
For demonstration, here are the components described above :
- root app template: root.yaml
- application templates: manifests
- application definitions: charts/monitoring
Let’s take a look at
Name: suggests the name of my root application i.e root-app
namespace: all argocd based resources should reside in the argocd namespace itself
Finaliser: it's the Kubernetes CRD finalizer that helps in protection from accidental deletion of resources.
Destination: the cluster onto which the resources should deploy. If you have multiple clusters, mention the required one here.
namespace: the actual namespace in which you want to deploy your app
path: path inside your Git Repo where the application manifests are.
repoURL: the GIT repo address.
targetRevision: if it's HEAD, argocd will always sync to the master branch, if you need to be a different one, update that here. For example, staging branch for Dev environment, etc.
prune: this enables argocd to auto-remove your application and its created resources when you delete the manifest file from the Application templates directory.
selfHeal: this enables argocd to auto-apply the configs the same as the latest master branch changes even though new config updates have been done via kubectl.
Let’s look at one of the actual application templates inside manifests,
name: name of my application
namespace: I'm deploying the app to the kube-system namespace.
path: the path inside GIT repo where hem charts are for the app
targetRevision: I'm syncing the changes to the master branch.
repoURL: repo where the helm charts/manifests of the app is stored.
Once, we understand the above, we can proceed to try them out :
- Install the root app by running :
kubectl apply -f root.yaml -n argocd
- Once installed, go to your ArgoCD UI and you should be able to see:
4. Now that our root app is created and healthy, give it a minute, and any application template you create inside the manifests folder (in my case), will be automatically synced and created for you in the specified namespace.
5. In the above picture, you can see root app is managing multiple apps and auto-syncs when you make changes to the helm charts (Github repo in my case)
6. There’s a little arrow in each of the app, if you click on it, it will take you to the application page of it in argocd :
7. If you need to add a new application, the flow goes like this, add the actual helm chart/manifest file to your GIT repo → add an argocd template to your templates directory → sit back, and enjoy !!
8. I’ve added the node exporter argocd template and bam !! its automatically created :
- Syncing apps across multiple clusters.
- Let's say you want to have node-exporter in multiple clusters, it's not possible via apps-of-apps directly. For that, you can create an application template and in
destinationupdate your cluster name as registered in argocd.
- This problem is solved by Aplicationset from ArgoCD.
2. Support for multiple
values.yaml file for helm charts.
- Let’s say you want to apply node-selector to 2 clusters dev and prod each with their own customized values which are not possible at the moment.
Originally published at https://tanmay-bhat.github.io.