Introduction
In this article, we aim to introduce the concept of Argo CD and its core GitOps. Thus, to elucidate how Argo CD manages to make the deployment process more efficient.
GitOps
It is a code-based infrastructure and operational procedure that relies on Git as a source control system. Specifically, it is the practice of using Git pull requests to automatically verify and deploy changes to the system infrastructure. Even Git pulls define the essence of GitOps.
Argo CD
Argo CD is a declarative continuous delivery tool for Kubernetes. It follows the GitOps model by using Git repositories as the source of truth to define the desired state of the application.
Essentially, Argo CD was built to make continuous delivery to Kubernetes clusters more efficient and this is mainly due to the ability to track updates to branches, tags, or pins of a specific version of manifests during a Git commit.
How does Argo CD make the deployment process more efficient and what are the challenges faced with the traditional CD pipeline?
To answer this question and to understand the importance of using Argo CD in the deployment part, we present a comparative study of the continuous deployment part without and with Argo CD.
First approach – the classic CD pipeline
Pipeline workflow
During each commit, the continuous integration tool makes this new version tested, then it makes the build of the image ( small description ) and finally it makes the push to the docker repository.
At this point, the kubernetes manifest file undergoes changes and so we need some tools / steps to apply these changes on the kubernetes cluster.
To do this, it is necessary to
- Install a tool capable of controlling and applying these changes on the k8s cluster such as Kubectl
- Configure the Kubectl settings to give it access to the cluster
The challenges of this approach
– A security challenge
– we need to give access to external parties (Jenkins server) to the k8s cluster.
– In the condition that this application is deployed on the cloud using EKS for example, we need to share our cluster credentials with Jenkins so that it can apply changes every time we change the k8s manifest file.
– A visibility challenge
– Once Jenkins applies changes to the kubernetes cluster, it no longer has visibility into the status of the deployment. In this case, we can’t be sure if the deployment has been completed or if there are issues preventing it from firing.
The solution is therefore to use Argo CD to facilitate / solve the problems of the continuous deployment process.
How to use Argo CD?
The Argo CD workflow
- Deploy the Argo CD in the K8s cluster.
- Configure Argo CD to connect to the git repository and track changes.
- Argo CD detects changes in the Git repository and applies them to the cluster.
In the image below, we present in more detail how Argo CD works. Indeed, it manifests itself as an agent detecting changes on the resting Git (and also for the cluster) and in case the last two are not synchronized, it applies the last changes on the other part (the cluster or also the resting Git).
Second approach – the CD pipeline with Argo CD
Workflow
The continuous integration pipeline remains the same, the difference is in the continuous deployment pipeline where we no longer need to install tools to monitor the k8s cluster but rather Argo CD works as a listener detecting that the docker image has been changed so it steps in to make those changes to the cluster. Similarly, it works the other way around where it is also a listener for the cluster and if it is out of sync with the manifest file in the git, it also steps in to do the sync between the two.
The advantages of using Argo CD
The benefits of using Argo CD are many and varied and in this section we present some of the benefits that we consider essential.
- Easy rollback
When a new configuration fails at startup, we can roll back to the previous working state on the git repository.
Just declare the previous working state, and the cluster will be synchronised.
- Cluster disaster recovery
When for example we use an EKS and it crashes, we can create a new cluster and point it to the git repo where the full cluster configuration is defined.This way we get the exact same state as the previous one without any intervention from us.
This is because we have described the whole cluster in the code declaratively, and from this Argo cd gets the appointment of a declarative fool for continuous delivery.
Conclusion
At this point, we are satisfied that Argo CD makes improvements to the cd pipeline and makes it more efficient. Obviously, there are several other solutions to do this, such as Flux, and although they both follow the same path, there are differences between these tools. We can choose which one is more appropriate depending on certain features such as flexibility in code collaboration, what you need to manage and what is automatically offered by the tool, etc.
