Argo CD Installation and Architecture
To start using Argo CD, we need to install it.
There are multiple ways you can do this. We are going to use Helm, our recommended package manager for Kubernetes-based applications. Note that Argo CD Helm Charts are community-maintained, even though they are located inside the official Argo CD GitHub organization.
Here I have a Kubernetes cluster - it’s running inside AWS EKS service, but we are not going to use anything too specific to AWS.
Let’s first add Argo CD Helm repository:
helm repo add argo https://argoproj.github.io/argo-helm
I’ve prepared a values file that overrides some of the configuration options. It’s not much - I disable an application set controller (more on that one in another article), disable TLS (don’t do that in production), and specify how to create an ingress for the Argo CD server.
I am using AWS’s Load Balancer controller for ingress - basically, it will create a new AWS ALB, which will let me access Argo CD over the internet. If you are using AWS and Kubernetes, but don’t know much about this Load Balancer Controller, here's a link to our free webinar about this tool.
With this values file, I can run helm install --namespace argo argocd argo/argo-cd --create-namespace -f cargo101.values.yaml
. Let’s look at what this Helm Chart created for us.
kubectl get pods
There are 6 components that are included in the default Argo CD installation. 3 of them: server, repo server and application controller, are the core of Argo CD. They are responsible for the API, Web UI, for synchronizing git repositories, generating Kubernetes manifests, diffing and rolling out changes.
Notifications Controller is a separate component, responsible for sending notifications about various Argo CD events to Slack, MS Teams and other messaging systems.
Argo CD Dex is actually just Dex, an identity provider, responsible for authentication for Argo CD. If you want to configure, for example, Okta or GitHub login, this authentication will happen through Dex. I highly recommend checking Dex out, as it’s a great utility for adding authentication to your applications.
Finally, Redis is here just for caching.
Notifications Controller, Redis and Dex are completely optional - we could configure Helm Release to skip installing those components all together. There are a few other optional components around Argo CD, like the aforementioned Application Set controller - those are a bit advanced and won’t be covered in this lightning course.
You might have noticed, that there is no database running for Argo CD. The reason for this is that Argo CD is using Kubernetes API as its database. All the Argo CD specific objects are implemented as Custom Resource Definitions, and Argo CD configuration is stored inside ConfigMaps and Secrets. We can check the current configuration by running kubectl get cm/argocd-cm -o yaml
.
Argo CD is completely Kubernetes-native, it absolutely depends on Kubernetes features, and it’s more or less impossible to run it outside a Kubernetes cluster.
Finally, now that installation is complete, I can copy and paste this command to get an initial admin password:
kubectl -n argo get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
I will also get a DNS name of my load balancer by running kubectl get ingress
.
Now let me go to the browser, open that url and log in with the username admin
and the password I just got via a command line. Seems like we have Argo CD up and running!
In the next lesson, we are going to talk about two important parts of Argo CD: Clusters and Repositories.
Here' the same article in video form for your convenience:
Series "Argo CD Lightning Course"
- What is Argo CD, and why would you need GitOps?
- Argo CD Installation and Architecture
- Argo CD Clusters and Repositories - Two Core Components
- How to deploy Applications within Projects in Argo CD
- Argo CD Self-Heal, Sync Windows and Diffing
- Argo Ecosystem: Argo CD, Argo Workflows, Argo Events, Argo Rollouts, Argo Everything