GitOps and Argo CD overview

GitOps approach

I am going to raise GitOps principles in this article and show you how it works in reality.

What is GitOps?

GitOps is a way of managing K8s applications where GIT repo is our main source of truth. The main idea is here that we compare the cluster state (live vs desired); and if something went wrong, we need a tool to detect the drift.

The core principle here is that our repository changes should match the cluster state. It is integrated with GIT, so it means that all the changes are traceable. We can roll back to a previous version if needed. By using a declarative approach we can centrally manage all the workflows from a GIT repo.

Let's discuss some tools to implement GitOps and see what benefits we can get from it. One of the tools is Argo CD. In the image below you can see the architecture diagram:

Among others you see three components:

1. API Server which expose the application API.
2. Repository Server - generate and return Kubernetes manifests.
3. Application Controller - Kubernetes controller which monitors the applications and compare the cluster state.

Challenges that we solve with Argo CD:

• Track changes in a GIT repo and automatically update a cluster.
• Manual changes will be reverted by Argo CD so out GIT repo will remain the source of truth.
• Argo CD supports yaml files and helm charts, kustomize applications, jsonnet files.
• We can sync changes by using Argo CD UI, Argo CD CLI, on a webhook or automatically.
• We can rollback to a previous state.

Argo CD is not only looking for a cluster state but also GIT state. Also a single deployment of Argo CD can manage multiple clusters as well.

Let's discuss some Argo CD concepts:

Application health tracks the health status of our apps, it can be:

• Healthy - optimal state.
• Progressing - it is not in a health state, but still in a pending state. If an app is too long on that state, we should check what is being changed.
• Suspended - paused or suspended job.
• Missing - there is no such a resource in a cluster.
• Degraded - failed state, it can't reach the health status.
• Unknown - resource is not healthy.

Also, it is worth mentioning the sync strategies:

• Manual or automatic sync.
• Auto-prune - if a file is deleted from a GIT repository, Argo CD deletes it from a cluster.
• Self-heal - any manual change will be noticed and turned back by Argo CD.

I would like to show you how it works with Argo CD as our main GitOps tool. So let's start.

Pre-requisite:

• Install kubectl CLI on the machine
• Install Minikube

1. Let's create a namespace and install Argo CD:

2. Next, we will fetch the password and port forward to access Argo CD server:

3. After that, by going to our localhost and port 8080 we can access Argo CD. There are no applications yet, so let's create one.

4. Let's create a yaml manifest which will be using a simple forked repo provided by Argo Cd where we can find the guestbook app:

5. Once we did it we can see that on Argo CD console we can see 1 app:

In general, the forked repo is looking this way: you just have a simple deployment file and a simple service.

To access the app you will do another port forward:

And the last step, we are going to visit our localhost on port 80:

Our application is healthy and fully in sync with our repo. Ok so now let's discuss some most important features of ARGO CD.

Argo CD Features

1. Let's presume that someone manually scale up the replicas to 3: kubectl scale deployment guestbook-ui --replicas=3 -n argocd
2. By vising Argo CD we see the status is out of sync. Actually, ArgoCD is showing us what is wrong.

You can see here that 3 pods were created:

After pressing the sync button ARGO CD calls our repo and sees that 1 replica is needed so it syncs with our repo:

You can easily sync by using the UI:

Now let's create a simple NGINX web server and show how rollback feature is working.

1. Le's create a simple app:

2. Now we have 2 apps and NGINX app has 3 pods as you can see:

3. Let's commit a change to our repo and change replicas to 1:

Now you can see that amount of replicas in Argo CD changed to 1 also:

4. Argo CD offers us a rollback feature to go back to a specific commit, so let's do it:

And we can see that now we have 3 pods but the status is out of sync as it's not aligned with our repo status:

It would be a great idea to get some notifications when the status of app is different. Argo CD offers us a native solution that is called Argo CD notifications. Let's install it. I want to integrate it with Slack so previously I created a channel and the app in Slack.

1. Install Argo CD notifications:

curl -o argocd-notifications.yaml https://raw.githubusercontent.com/argoproj-labs/argocd-notifications/release-1.0/manifests/install.yaml

kubectl apply -n argocd -f argocd-notifications.yaml

2. Install triggers and templates:

curl -o argocd-triggers-install.yaml https://raw.githubusercontent.com/argoproj-labs/argocd-notifications/release-1.0/catalog/install.yaml

kubectl apply -n argocd -f argocd-triggers-install.yaml

3. Then we need to add our Slack token to argocd-notification-secret:

4. Then we have to add a Slack token to our argocd-notification configmap:

5. And the last step is to add annotations to subscribe to our notifications:

6. After that we got notifications to our dedicated Slack channel:

This just a simple overview of how ARGO CD works, it has a lot to offer that I did not cover yet. In this post, you learned what is GitOps, how to install Argo CD, and how to deploy simple apps by using GitOps principles. Also, we managed to get some notifications about our apps.