Argo CD Clusters and Repositories - Two Core Components
Let’s talk about two resource types inside Argo CD: Clusters and Repositories. Both of those things are configured globally in your Argo CD server. I think you can easily guess what both of those resource types are, but let’s just go through configuring them.
Repositories
There are two types of Repositories in Argo CD - Git repositories and Helm repositories. As Argo CD is a GitOps tool, let’s focus on Git repositories for now. I am going to add a helm-lightning-course repository - it’s a public repo that contains a PGAdmin Helm Chart, the one that is written during our free Helm course.
I will select HTTPS connection method and specify the Repository URL. That’s actually everything I need! Of course, for private repositories I would also need to specify some kind of authentication - either with SSH keys, or with username and password.
There is also something called “Credentials Template” - you can basically specify a prefix that is identical for all your repositories - for example, github.com/mkdev-me, and specify which credentials should be used for all repository that start with this prefix.
This is handy if you don’t want to specify credentials for each repository individually, and you simply configure some kind of technical user that has access to all repositories of your organization, or of your team.
I am not going to do that, and will simply add a PGAdmin repository - ArgoCD confirms, that connection is succesful, meaning it is able to pull the code from this repository.
Clusters
The next thing we need to configure are clusters. The cluster where Argo CD is running is already here - it’s called “in-cluster”.
We already can deploy applications to the same cluster where Argo CD is running. But one of the core benefits of having a tool like Argo CD is the ability to deploy applications to many different clusters. Luckily, I do have another Kubernetes cluster!
To add it to Argo CD, I am going to use Argo CD’s command line interface - this CLI is a great little tool to do some ad-hoc operations on Argo CD server. If you have only a handful of Kubernetes clusters, then adding them with a CLI is totally okay. Just keep in mind, that once you treat your clusters like cattle, then you should automate adding them to Argo CD.
I am going to install the CLI with brew install argocd
.
Next, I need to log in to the server. I have to use grpc-web
option because I am using AWS ALB, and plaintext and skip-test-tls options because I did not configure TLS for my Argo CD - don’t do that in production.
argocd login SERVER:80 --grpc-web --skip-test-tls --plaintext
Before I will run a command to add a new cluster, I first need to add a Kubeconfig context for the new cluster:
aws eks update-kubeconfig --name mkdev-labs-euc1-cargo101prod
Now I can add this cluster to Argo CD:
argocd cluster add arn:aws:eks:eu-central-1:170837768887:cluster/mkdev-labs-euc1-cargo101prod --name mkdev-labs-euc1-cargo101prod
The first argument is the name of the Kubeconfig context that allows the CLI to connect to the API of the target cluster. Argo CLI needs this in order to create a new service account and cluster role - Argo CD server will use this service account to connect to this cluster. Note that this will give Argo CD a full cluster admin access on a target cluster - you will probably want to narrow this down if you have a big multi tenant cluster.
If we go back to the Argo CD Web UI, we will see this new cluster in place. It tells us that the cluster status is unknown - that’s because we did not deploy any applications yet.
Remember how I told you, that Argo CD stores everything inside Kubernetes’s API? Another example of it is how Argo CD stores this cluster information. If we run kubectl get secrets -n argo
, we will notice a Secret dedicated to storing the information about the new target cluster.
If we examing this secret, we’ll see a label argocd.argoproj.io/secret-type: cluster
- that’s how Argo CD is able to understand that information inside this secret is about the target Kubernetes cluster.
It’s time for us to deploy something with Argo CD. In the next lesson we are going to finally learn about Projects and Applications.
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