Self-Managed ArgoCD Explained: Benefits and Best Practices

The answer is yes, ArgoCD can manage itself. But how? You may ask. Then, read this TeraTip to know how you can set up your ArgoCD to manage itself.

First of all, what is ArgoCD? ArgoCD is a GitOps Continuous Delivery tool for Kubernetes, and it can help you by managing all your cluster resources constantly comparing their state on the cluster against the repositories of those resources.

First of all we will create a Minikube cluster for this PoC

minikube start

Once we got our cluster running let’s proceed installing ArgoCD on the argocd namespace using Helm and the official helm chart from the Argo project.

helm repo add argo https://argoproj.github.io/argo-helm

helm install argo argo/argo-cd -n argocd

Now, it's time to implement something known as the App of Apps pattern.

The App of Apps pattern consists in having an ArgoCD Application which consists of other ArgoCD Applications. You can take this repository as an example: https://github.com/JuanWigg/self-managed-argo

Basically here we have a main application, which is called applications. This main application will synchronize with our self-managed-argo repo, and, on this repo we have all of our other ArgoCD applications, for example a kube-prometheus stack, core applications, elastic search, and so on, but the most important thing is that we have an application for ArgoCD itself.

The main applications looks something like this:

apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: applications namespace: argocd spec: project: default destination: namespace: default server: https://kubernetes.default.svc source: repoURL: https://github.com/JuanWigg/self-managed-argo targetRevision: HEAD path: applications syncPolicy: automated: prune: false # Specifies if resources should be pruned during auto-syncing ( false by default ). selfHeal: true # Specifies if partial app sync should be executed when resources are changed only in target Kubernetes cluster and no git change detected ( false by default ). allowEmpty: false # Allows deleting all application resources during automatic syncing ( false by default ). syncOptions: - CreateNamespace=true

As you see, the path for the application is applications. We have that same folder on our repo, where we have all the applications ArgoCD it’s going to manage (including itself).

Just as an example i will leave the ArgoCD application code here:

apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: argocd namespace: argocd spec: project: default destination: namespace: argocd server: https://kubernetes.default.svc source: chart: argo-cd repoURL: https://argoproj.github.io/argo-helm targetRevision: 5.27.1 helm: releaseName: argo syncPolicy: automated: prune: false # Specifies if resources should be pruned during auto-syncing ( false by default ). selfHeal: true # Specifies if partial app sync should be executed when resources are changed only in target Kubernetes cluster and no git change detected ( false by default ). allowEmpty: false # Allows deleting all application resources during automatic syncing ( false by default ).

Make sure that the version you put on the application matches the version you deployed early with Helm.

Lastly, you need to apply the main application on the cluster using: kubectl apply -f applications.yaml

And there you have it! Now you have ArgoCD managing itself and all your applications in your cluster!

Juan Wiggenhauser

Cloud Engineer

Teracloud

---

To learn more about cloud computing, visit our blog for first-hand insights from our team. If you need an AWS-certified team to deploy, scale, or provision your IT resources to the cloud seamlessly, send us a message here.