Argo CD is a popular open-source continuous delivery tool for Kubernetes. Argo CD automates the deployment of any application by continuously monitoring the Git repository and Kubernetes clusters and resolving any discrepancies between the two.

How is continuous delivery implemented in common projects?

Before diving into Argo CD, let’s take a step back and understand how continuous delivery is implemented without Argo CD. The conventional CI/CD pipeline gets triggered when a developer fixes some bugs or adds a new feature. After this, Jenkins will test the code and build the Docker image.

‍

The Docker image will be pushed to the Docker Hub repository by Jenkins. The new image is then deployed to the Kubernetes cluster. For this, Jenkins updates the k8 yaml file with anew image tag, and this yaml file is deployed in Kubernetes using Kubectl.

‍

However, there are a couple of challenges with this approach. First of all, we need to install tools like Helm or Kubectl on build automation tools like Jenkins. Then we need to configure access to K8s for these tools because Kubectl is just a client for Kubernetes. In order to access the K8 cluster, it needs to provide some credentials. If you are using a cloud platform, you need to configure access to them as well. This gives way to a lot of security challenges.

How does Argo CD solve the problem?

Argo CD is built for Kubernetes and is based on GitHub principles. Argo CD has reversed the workflow; instead of pushing the changes to K8s, it pulls them to the cluster. Argo CD is directly deployed on K8 clusters, and then it’s configured to connect with the GitHub repository. It tracks the GitHub repository, and if something changes there, it automatically pulls those changes and applies them to the cluster.

Argo CD workflow

Just like in any CI/CD pipeline, a developer pushes changes in the code or a new feature to the GitHub source code repository. Then Jenkins triggers continuous integration, resulting in a new Docker image and publishing it to the Docker repository. A pull request is made by a developer to modify the Kubernetes yaml file, which can either be done automatically or manually.

‍

After review, the pull request's updates are merged into the main branch. This triggers a webhook that notifies Argo CD of the update. Argo CD updates the Kubernetes cluster's state by comparing it with the application state. It modifies the cluster configuration as needed.

‍

Until the appropriate configuration is reached, Kubernetes uses its controllers to coordinate the modifications needed to cluster resources. Argo CD keeps track of developments and notifies the user when the application is in sync after the Kubernetes cluster is prepared. Argo CD also functions in the opposite way, keeping an eye on updates made to the Kubernetes cluster and deleting them if they conflict with the Git configuration as it stands at that moment.

Argo CD core components

The core components of Argo CD include:

• API server: The Web UI, CLI, and CI/CD systems can connect to and utilize the system due to the API server, which functions as a central hub. Its primary responsibilities include monitoring and reporting on applications, managing credentials for repositories and clusters (stored as K8s secrets), executing operations on applications (such as syncing or rolling back), ensuring that only authorized users have access to the system, enforcing role-based access control (RBAC), and listening for and forwarding Git webhook events.
• Repository server: The repository server works similarly to a private assistant by storing a copy of the application blueprints in a designated area nearby. It develops and returns comprehensive instructions for configuring the application in Kubernetes based on the information you provide, such as the location of the app blueprint, the version you want, where it resides in the blueprint, and any special adjustments.
• Application controller: In Kubernetes, the application controller functions as a vigilant watchdog over your applications. It always makes a comparison between the way your apps are really operating and how the documentation in the repository states they should be. It can make any necessary corrections if it finds any discrepancies or mismatches. In addition, it manages certain tasks according to your configurations for the launch, operation, and shutdown of the application.

Webhook support for Argo CD

When particular events take place during the continuous deployment process, webhooks are triggers or notifications that are sent to external systems or services. Webhooks provide a communication mechanism for Argo CD and other tools. Every three minutes, Argo CD pings Git repositories to find out if the manifests have changed. It is possible to configure the API server to receive webhook events in order to remove the polling latency. Gogs, Azure DevOps, Bitbucket, Bitbucket Server, GitHub, GitLab, and Bitbucket webhook alerts are all supported by Argo CD.

Argo configurations with Sync Hooks

These are custom scripts that can be executed prior to, during, or following an Argo CD sync operation. They are an effective method of enhancing Argo CD's functionality and integrating it with other programs and services. You can write Argo sync hooks in any language that is compatible with the Kubernetes API client. They can be written as Helm charts, Docker images, or even Kubernetes manifests.

Argo CD sync hooks are divided into three categories:

Prior to the start of the sync process, PreSync hooks are run. They can be employed for activities like data backup, executing database migrations, or confirming the functionality of the application.

<pre class="codeWrap"><code>metadata:
  annotations:
    argocd.argoproj.io/hook: PreSync
</code></pre>

Sync hooks are used in conjunction with the sync process. They can be employed for activities like using unique reconciliation reasoning, checking things before deployment, or sending notifications.

<pre class="codeWrap"><code>metadata:
  annotations:
    argocd.argoproj.io/hook: Sync
</code></pre>

PostSync hooks are used once the sync process is finished. They can be employed for activities like implementing unique post-deployment inspections, notifying recipients of successes or failures, and changing the dashboards for monitoring.

<pre class="codeWrap"><code>metadata:
  annotations:
    argocd.argoproj.io/hook: PostSync
</code></pre>

Benefits of using Argo CD

Argo CD is a powerful tool that makes GitOps continuous delivery (CI/CD) technology much easier in Kubernetes systems. It is a useful tool for teams handling deployments on current Kubernetes systems because of its many advantages. The fact that Argo CD automates the installation and configuration of Helm, Kubectl, and various other tools on Jenkins makes it more favorable.

‍

This way, it not only reduces the need for manual installation but also takes care of security-related issues. Argo CD makes sure that deployments always include the most recent code changes by automatically balancing the desired state specified in Git repositories with the actual state of the cluster. This lowers the possibility of human error and does away with the requirement for manual updating.

‍

Argo CD offers an audit trail for application deployments by storing all deployment manifests and reconciliation histories in Git. In the event of problems, this makes rollbacks and troubleshooting easier. Several deployment sources are supported by Argo CD, such as Helm charts, Kubernetes manifests, and Git repositories. Teams are free to choose their preferred deployment strategy due to this flexibility.

‍

Argo CD facilitates a smooth transition between the CI and CD stages by integrating with CI tools such as Jenkins and GitLab CI/CD. The process of development and deployment is streamlined as a result. Argo CD follows the concepts of GitOps, making sure that only the state that is stated as wanted in Git is distributed to the cluster.

‍

This reduces the possibility of unintentional or illegal alterations. Canary deployments, which progressively roll out new deployments to a subset of users to assess reliability before full distribution, can be implemented with Argo CD. Blue/green deployments can be implemented using Argo CD, enabling smooth rollbacks in the case of issues. In the event of an issue, Argo CD facilitates deployment rollbacks to earlier versions with ease. Argo CD facilitates troubleshooting and change tracking by offering a thorough audit trail for every deployment.

Conclusion

In a nutshell, Argo CD is a powerful tool for modern-day CI/CD pipelines. It provides a continuous delivery solution designed specifically for Kubernetes deployments. By constantly checking for inconsistencies and adjusting the Git repository to match the Kubernetes cluster, it simplifies the deployment of applications. I highly recommend looking into Argo CD if you're searching for a solution to enhance your CI/CD process for Kubernetes. It is an established open-source project that is well-maintained and has a significant user base.

‍