If you have used GitHub for creating a pull-request, you might have come across this:
Have you ever wondered what these “checks” actually mean? And how the project actually implements these tests? Whether you know or don’t know the answer to this question, delve into this article and get a glimpse of ArgoCD’s world :)
So, what is ArgoCD?
As the name suggests, ArgoCD is a continuous delivery tool. And to understand how it works, let’s first look into how continuous delivery is implemented in most projects using common tools like Jenkins, Gitlab, etc (since Jenkins and Gitlab are also CD tools, one question would arise in your mind,” is ArgoCD a replacement of these established CD tools?”. So, let’s try to answer this question as well).
An example of a continuous deployment workflow without ArgoCD:
Let’s say we have a microservices application running in a Kubernetes cluster. Now, when you make some changes to your application, like adding a new feature or some bug fix, the CI tool like Jenkins will carry out the tests, and when tests are passed, Docker will create a new image and push it to the Docker depository.
But how does this new image get deployed to the Kubernetes cluster?
This is done by updating the application’s deployment YAML file with the new image tag(this will be done using Jenkins), and then it should be applied to Kubernetes using tools like Kubectl.
Following is an example:
However, there are some challenges to this approach:
- You need to set up tools like Kubectl, and Helm to access the Kubernetes cluster and execute changes on the build automation tools like Jenkins, which in turn means you need to configure these tools on Jenkins.
- You need to configure access to Kubernetes for these tools(when using cloud platforms like AWS, some more configuration will be required). Apart from being a tiring configuration process, this also becomes a security challenge as you have to share your cluster credentials with external services and tools.
- Once Jenkins has changed the config file for applying the changes to the cluster, it bears no responsibility for checking whether your changes were deployed successfully or not in the cluster. This can only be found by only following test steps.
2018: ArgoCD arrives
ArgoCD was created for improving the CD part of your application building and deployment process. It was purpose-made for Kubernetes and is based on Gitops principles.
So how does ArgoCD make the process more efficient?
ArgoCD does this by using the pull workflow. It is a part of the k8s cluster, and instead of pushing the manifest changes, it pulls the changes and applies them to the cluster.
Thus, the workflow can be listed as follows:
1)deploy ArgoCD in k8s cluster
2)configure ArgoCD to track the git repository
3)ArgoCD monitors for any changes and applies them automatically
So, when a developer applies some changes to the application source code, the CI pipeline tool like Jenkins will first test the changes, build the image, push the image to the docker repository and finally update the k8s manifest file.
_A POINT TO BE NOTED: _
It is considered best practice to separate the git repository for application source code and configuration code ie k8s manifest files. The benefit of doing this is that the application configuration file can not only be the deployment file but also configmap, secret, ingress, etc, and everything else the application needs to run in the cluster. And these manifest files can change completely independent of the application’s source code. And when you update, say, a service YAML file for the application, which is just the application configuration and not a part of the code, you don’t want to run the whole CI pipeline for the application when the app source code hasn’t even changed. Also, you don’t want to have complex logic in the pipeline to decide what actually changed.
So now, Jenkins will update the manifest file in a separate git repo where the k8s manifest files exist. And as soon as the configuration files for the repo change, ArgoCD will start tracking changes as we had initially configured it to monitor changes in the cluster, and it will pull and apply the changes in the cluster automatically.
ArgoCD supports k8s YAML files, helm charts, Kustomize files, and all other template files that generate k8s manifests. The repo which is tracked by ArgoCD is sometimes also known as the Gitops repository.
Thus, when the configuration files get changed by either Jenkins or by DevOps engineers, all of these changes will be tracked and applied in the cluster by ArgoCD. As a result, we have separate CI and CD, where the CI is completely owned by developers and configured on Jenkins for example, and the CD pipeline is owned by operations/ DevOps teams and configured using ArgoCD.
Benefits of using ArgoCD (answering the question, “Why ArgoCD?”)
a) Git as a single source of truth:
Since the whole k8s configuration is defined as code in the git repo, the config files don’t have to be manually applied from local laptops using helm or kubectl, as everyone will have the same interface for updating the cluster.
What happens if someone updates the cluster manually?
One point to be noted here is that ArgoCD tracks the changes in the config file repo, as well as in the whole cluster. It continuously tracks and compares the actual state of the cluster with the desired state. So, when someone manually does some changes, the actual state will be different from that defined in the configuration file, and thus ArgoCD will sync the changes, overwriting the manual change. Thus, this guarantees that the k8s manifests in git remain the single source of truth.
But let’s say we do need a way to quickly manually update the cluster. In that case, we can configure ArgoCD to not sync manual cluster changes automatically, and send an alert in such a case.
Also, the benefit of using git is that we can track all the changes made, as opposed to untraceable changes made directly to the cluster by using kubectl or helm, etc. This also provides better team collaboration.
b) easy rollback:
since git tracks all the changes, so we can easily revert back to a previous commit if the new git commit causes a failure in the application. This is especially useful when we have thousands of clusters that point to the same git repository. Thus, we don’t have to manually update all the clusters
but just changing the configuration file will do the work for us.
c) Cluster disaster recovery:
Let’s say we have a cluster in a region A. and for some reason, the cluster completely crashes. So, using the configuration file, we can create a new cluster easily, thus recreating the exact state as the previous one.
d) k8s access control with git and ArgoCD:
Since all team members should not have access to make changes to the config repo, especially in a production environment, we configure access rules in the git repositories.
Thus, using permissions, all team members can propose changes to the cluster, but only a handful of senior engineers can approve and merge those requests. In this way, we can manage cluster access indirectly via git, without having to create ClusterRole and user resources in Kubernetes.
Also, we need to only give access to the git repo and not the whole cluster. We also don’t need to give external cluster access to non-human users like Jenkins etc as we have ArgoCD inside the cluster which will apply those changes. Thus, no cluster credentials outside of K8s, resulting in better management of the security of our cluster.
e) ArgoCD as k8s extension:
ArgoCD uses existing k8s functionalities:
eg1) using etcd to store data
eg2)using k8s controllers for monitoring and comparing actual and desired states.
The major benefit is that we get visibility in the cluster as we can get real-time updates of the application state.
Now that we have learned about ArgoCD, let’s try to learn how we configure it in our project:
For doing this, we have to follow the following steps:
1)deploy ArgoCD into the k8s cluster
2)configure ArgoCD with k8s native YAML file:
The main component of ArgoCD is “application”, and we can define this application CRD (custom resource definition) in a k8s native YAML file.
While defining, we have to mention which git repository is to be synced with which k8s cluster.
How do we work with Multiple clusters using ArgoCD?
Since the same ArgoCD instance is able to sync a fleet of k8s clusters, we need to configure and manage ArgoCD only once.
Finally, is ArgoCD a replacement for other ci/cd tools?
Not really as we still need a CI pipeline to test and build app code changes. ArgoCD, as the name suggests is for the CD pipeline, along with its other functionalities.
But there are many alternatives for ArgoCD as well like fluxCD, Jenkinsx etc, to name a few. Each has its own functionality, which can be discussed in some other article :)
Outro:
There’s no better way to test-driveArgoCD than by diving in and playing with it. The purpose of the blog is to create awareness about CD pipeline tools like ArgoCD. To learn further it is recommended to go through ArgoCD’s Github and blogs
Have fun!
Top comments (0)