Argocd — App of Apps

Introduction:

In my previous blog, I explained installing and getting started with argocd using helm. In this blog, I will explain how we can manage the argocd applications from github repository.

What we are going to achieve

First lets understand two things. An argocd application is the one where we define the github repository and target cluster to deploy the manifests from github repository. This argocd application is again a yaml manifest. Lets call this argocd application and the target real application manifest as real application throughout this blog.

So, we deployed the argocd application using helm in my previous blog by running helm install and helm upgrade. Now this is basically a command line approach. However as we understand its not a good approach to install anything from command line.

Incase we have different environments like dev, uat and prod, we might need to use multiple argocd applications to target different branches or different folders. So each time we want to apply the argocd application manifest by using kubectl. Instead we can have a master app that will monitor the repo where all these child argocd app manifests reside.

Dont get confused. The argocd application is itself a manifest that can be placed inside github repository and we can create an initial argocd application manually by using command line and this initial app can monitor the github repository to install other argocd applications. This is called app of apps approach or master child approach. Only the initial manifest is manual and all other argocd apps are applied automatically when they are placed in the respective folder

Lets get into action

App of Apps Step by step:

Currently there is nothing in my argocd application list.

Let me install my first argocd app (master app) by using a normal manifest. We can also use official helm from argocd to install the argocd app, but here am using a normal application manifest. The first argocd app has to be manual or it can be installed from a devops pipeline.

LEts run below to install the 1st argocd app (master app). As you can see, this is monitoring a folder “argocd-childapp” in the repo.

kubectl apply -f argocdapp.yml

#argocdapp.yml 
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: argocd-masterapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/anandambitionv2/appofapps.git
    targetRevision: main
    path: argocd-childapp
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Important Note: As you can see, my destination server is the same kubernetes cluster where Argocd is installed. This argocd application manifest wont work if there is no argocd running in the server. So you should target to install the application manifest in the cluster where you initially installed argocd server. But your real application manifest can be in a different cluster.

After applying, argocd app got added. Lets call this master app.

Now, lets say we need to add additional argocd apps here (seperately for dev, uat, prod or any other use case) . We can either have new manifests and apply those app manifests using kubectl which is something we need to avoid (the purpose of this blog) , but we want to make the master argocd app create child argocd apps.

How to achieve this

We simply place the child argocd app manifests in the repository that is monitored by the master argocd app

This is the github repo monitored by our master argocd app. Any manifest placed in this repository will be applied by Argocd. (be it deployment, service, pod etc etc)

https://github.com/anandambitionv2/appofapps.git

Inside this repo, we place the argocd child apps manifests and our argocd master app automatically applies these manifests.

I am placing the child app manifest and pushing the changes to repo

Since my 1st application (argocd-masterapp) is monitoring this repo and the folder argocd-childapp, any yaml manifest inside this folder gets installed. Since we have the application manifest , it gets installed

Usecase to have app of apps

Obviously in realtime environments, we would have multiple apps with dev, prod, uat environments. We could install a master app manually and the child arogcd apps can be created using argocd itself by placing the child apps in the target github repository where the real app exists. This child argocd app monitors the real apps.

A typical folder structure would look like below. The argocd child apps are in a folder and the actual app is in another folder. The child app should monitor the real app folder

Child app monitoring real app folder

Lets deploy real app.

I am adding some deployments to the real application folder

I have a manifest for namespace (ns.yml) and deployment (sap.yml) placed in my real application folder sap-prod-app. Now when I commit and push these changes, the namespace and deployment gets applied automatically. This is because my child app is monitoring the folder sap-prod-app in the repo. Any manifest placed inside the folder sap-prod-app gets applied on the kubernetes cluster.

NAmespace and deployment got created in cluster

Real time environments

Now if you have different environments, you will have a folder structure like this. Separate folders for dev and prod each for argocd app and the actual app. Argocd DEV app will monitor the real dev app and Argocd Prod app will monitor the real prod app. The master app will be in a totally different repository.

Branching:

As you could see, my argocd app is targeted to monitor the main branch, however there could be different branches for different environments (dev, uat, prod) or different folders for different environments. The important point is there should be a branch protection policy to avoid pushing to this branch directly. It should happen through a PR and merge which goes through an approval to avoid any misconfiguration getting applied to kubernetes cluster because anything that you push to this targeted branch is applied within seconds or destroyed within seconds.

Conclusion:

The argocd app of apps is a realtime use case. I will write other blogs to cover automatic image updates, rollouts etc.