Argo CD (part of the Argo project) is a deployment solution for Kubernetes that follows the GitOps paradigm.

Deploying to Kubernetes with Argo CD

In the most basic scenario, Argo CD continuously monitors a Git repository with Kubernetes manifests (Helm and Kustomize are also supported) and listens for commit events.

When a commit happens (usually one that updates the versions of the image artifacts), Argo CD starts a “synchronization” process that is responsible for bringing the cluster configuration in the same state as described in Git.

When the sync process is complete we know that the application configuration is exactly the same as the Git manifests.

The Argo CD deployment process is the embodiment of the central ideas behind GitOps:

• All application configuration is stored in Git (usually in a separate repository than the source code)
• Deployments are happening in a “pull” manner where the cluster is fetching manifests from Git (instead of traditional solutions where updates are “pushed” to the cluster)
• A deployment is a reconciliation process between the two states (what is described in Git versus what is deployed in the cluster)

Even though the sync process is vital for performing the initial deployment of the application, one of the true strengths of Argo CD is the continuous monitoring of both states (cluster and Git) *after* the deployment takes place. This continuous monitoring is very important for solving configuration drift which is a very common issue in organizations with a large number of deployment targets.

Configuration drift between different Kubernetes clusters

Configuration drift is a problem that existed even with traditional Virtual Machines and it has plagued production deployments long before Kubernetes appeared on the scene. The problem manifests itself when the CI/CD platform performs a deployment to multiple targets and it fails because a set of machines that were supposed to be similar are in fact differently configured.

In several organizations, developers use a “staging” environment to test their application right before it is deployed in production. Ideally, the staging environment should match the configuration of the production one, so that developers are confident that any testing they perform in staging will closely match the production environment.

Specifically with Kubernetes clusters, it is very common for teams to use ad-hoc commands (i.e. via `kubectl`) to perform changes on a cluster that are completely outside of the CI/CD process.

These ad hoc changes are a major issue for application deployments. Differences in configuration are one of the most common causes of failed deployments. An application that is passing all tests with flying colors in a staging environment, results in a broken state in production because the required settings were not present or in the expected format.

Another hidden problem that stems from configuration drift is the gradual loss of knowledge on what exactly is deployed on a machine/Node and when exactly was the last change. Argo CD solves this problem by using Git as the source of truth for the present deployment and all past ones.

After a failed deployment, operators and developers are trying to understand the causes of the incident and one of the first questions they ask is “what was the last thing that changed in this cluster”. This question is very hard to answer if uncontrolled changes can happen to the cluster outside of the approved CI/CD process.

How Argo CD detects configuration drift issues

Argo CD takes a completely different approach to deployments (the “pull from Git” paradigm). Because all deployments can be traced back to Git commits, the Git commit history is also the cluster deployment history.

Developers can use their favorite Git tools to answer questions like “What was deployed on the cluster last Thursday?” or “What changed between Monday and Thursday this week?”

Let’s say however that a person from the team completely bypasses Argo CD and performs a manual change straight to the cluster using kubectl. Other CI/CD solutions will be completely oblivious to this change, paving the way for a configuration drift issue.

Argo CD will understand instead that something was changed on the cluster and the two states (cluster configuration and Git manifests) are no longer the same. The deployment will instantly be marked as “out-of-sync”.

Argo CD will also dig deeper and even present a nice diff overview of what was changed:

In the example above, Argo CD detected that the port configuration of a service is no longer the same between the cluster and Git.

Once you detect a discrepancy like this you can either manually bring the application to the same state as the Git (performing the sync process again) or instruct Argo CD to automatically sync on its own when it detects configuration changes.

This means that with Argo CD configuration drift (at least for Kubernetes applications) is completely eliminated, especially if the auto-sync behavior is enabled.

Teams that use Argo CD can deploy with confidence because they know that the cluster is in the state it is supposed to be (and that state is also fully described in the Git manifests). Configuration drift is not an issue anymore and keeping staging and production as close as possible is a very easy process.

Combining Argo with a Devops Platform

Apart from the main Argo CD project,  you might also find Argo Rollouts interesting. Argo Rollouts is another Argo project for performing progressive (blue/green/canary) deployments to Kubernetes.

Argo CD and Argo Rollouts are great for handling application deployments but they need to be coupled with a full automation solution that will also handle all other aspects of the software lifecycle such as application builds, unit tests, secret management, and pull request handling, etc.

Argo CD works great for taking care of the actual deployment, but it assumes that the artifact is already created by another solution. This is why we have been working hard to integrate Codefresh and Argo together in order to cover the full software lifecycle and even cover the scenario of pushing automatically a change to the manifest Git repository monitored by Argo (i.e. performing automatic commits and thus practicing Continuous Deployment).

Visit the main Argo Website for more information.

Kostis Kapelonis is a developer advocate at Codefresh, a continuous delivery platform build for Kubernetes and containers. Formerly a Software Engineer, Kostis has years of experience containerizing applications, building CI/CD pipelines, and developing Java applications. He lives in Greece and loves roller skating.

Source: CNCF Blog by Kostis Kapelonis