What is Argo CD, and why would you need GitOps?

Welcome to the ArgoCD Lightning Course.

In this course, you will learn the basic concepts of ArgoCD, what is it used for and, most importantly, why you might need.

This course assumes you already know what Kubernetes is, as well some of it’s primary resource types, like Pods, Deployments, Services, ConfigMaps and Secrets. If you’ve never used Kubernetes before, you will hardly benefit from this lightning course.

Another prerequisite for this course is the knowledge of Helm - we are going to use and modify Helm Charts in order to demonstrate different features of ArgoCD. If you don’t know Helm, check out our Helm Lightning Course.

Cloud Native consulting: regardless if you are just getting started, or looking for a big shift from the old ways to the future, we are here to help. About consulting

Argo CD is a declarative GitOps deployment tool for Kubernetes.

Let’s unpack this definition by first defining what declarative is. When talking about Kubernetes, when we want to create a new object, for example a ConfigMap, we could run a kubectl command like this:

kubectl create configmap my-config \
  --from-literal=apiUrl=external.api.com

That would be an imperative way - we directly told kubectl what to do. If we want to change this ConfigMap, we need to run kubectl edit command. And if we want to automate this, we need to store these imperative commands inside a script.

But instead, we could run another command, kubectl apply and simply pass it the YAML definition of this ConfigMap:

kubectl apply -f my-config-map.yaml

That would be a declarative way to create this ConfigMap - we feed a declarative definition of our Kubernetes object to the kubectl. kubectl apply verifies if an object already exists, and if it doesn’t, it will create one - and if it does, it will simply update it.

Declarative tools simply look at your infrastructure definitions, like Kubernetes manifests, and apply them to your infrastructure. They are usually smart enough to figure out if they need to do a partial update, or if they need to replace an object - or even delete it.

The next part of Argo CD definition is a word “GitOps”:

The core idea of GitOps is having a Git repository that always contains declarative descriptions of the infrastructure currently desired in the production environment and an automated process to make the production environment match the described state in the repository.

GitOps

In other words, GitOps simply means an automation, that is triggered whenever there is a new commit in your repository, and which applies declarative manifests in your repository to your infrastructure.

For example, we could store plain YAML definitions of Kubernetes deployments in a GitHub repository, and then configure GitHub Actions to run kubectl apply on those definitions whenever we change them.

Or, we could use a tool that was purpose built for such and other GitOps workflows, like ArgoCD.

ArgoCD is purpose built for Kubernetes. It has a nice UI, role based access control, many integrations, as well as a rich ecosystem of tools from the Argo stack. ArgoCD can take Kubernetes manifests from your repository and apply them automatically to multiple environments, clusters and namespaces - and it can also force your live infrastructure to resemble the one you defined in the git repository.

In the next lessons, we are going to talk a lot about different features of ArgoCD, how it structures the projects and applications and so on. But for now, I’d like you to keep in mind, that ArgoCD, and all similar tools like FluxCD and Fleet, are nothing but a very powerful and good looking way to run kubectl apply at scale.

That’s it for this lesson.

Here' the same article in video form for your convenience: