Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to use Argo CD and GitOps to solve the problem of configuration drift. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

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

Deploy to Kubernetes using Argo CD

In the most basic scenario, Argo CD uses the Kubernetes manifest to continuously monitor the Git repository (which also supports Helm and Kustomize) and listens for submission events.

When a commit occurs (usually a commit to update the version of the mirrored artifact), Argo CD starts a "synchronization" process, which is responsible for keeping the cluster configuration in the same state as described in Git.

When the synchronization process is complete, we know that the application configuration is exactly the same as the Git manifest.

The deployment process of Argo CD embodies the core philosophy behind GitOps:

All application configurations are stored in Git (usually in a different repository than the source code)

Deployment is done in a "pull" manner, where the cluster takes the inventory from the Git (rather than the traditional solution that pushes updates to the cluster).

Deployment is a coordination process between two states (the state described in Git and the state of deployment in the cluster)

Although the synchronization process is critical to performing the initial deployment of the application, one of the real advantages of Argo CD is the ability to continuously monitor two states (cluster and Git) after deployment. This continuous monitoring is important to address configuration drift, which is a very common problem in organizations with a large number of deployment targets.

Configuration drift between different Kubernetes clusters

Configuration drift is a problem even in traditional virtual machines, and it has plagued production deployments long before Kubernetes. Problems arise when the CI/CD platform performs deployment to multiple targets and fails, because a set of machines that are supposed to be similar are actually configured differently.

In some organizations, developers use the staging environment to test their applications before they are deployed to a production environment. Ideally, the staging environment should match the configuration of the production environment so that developers can be sure that any tests they perform during the staging will closely match the production environment.

Especially in Kubernetes clusters, teams often use special commands (for example, through kubectl) to perform changes on a cluster that is not outside the CI/CD process at all.

These particular changes are a major issue in application deployment. Differences in configuration are one of the most common reasons for deployment failures. Applications that successfully pass all tests in the staging environment will experience a state of interruption in production because the required settings are not provided or the expected format is adopted.

Another hidden problem caused by configuration drift is the gradual loss of knowledge of what was deployed on the machine / node and the exact time of the last change. Argo CD solves this problem by using Git as the true source of current and past deployments.

After the deployment failed, operators and developers tried to understand the cause of the accident, and the first question they asked was "what was the last change in this cluster?" If the cluster makes uncontrolled changes outside the approved CI/CD process, this question is difficult to answer.

How to detect configuration drift by Argo CD

Argo CD takes a completely different deployment approach (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 such as "what was deployed on the cluster last Thursday?" Or "what has changed between Monday and Thursday this week?"

Let's assume that one person on the team completely bypasses Argo CD and uses kubectl to make manual changes to the cluster directly. Other CI/CD solutions will completely ignore this change, which provides an environment for configuration drift issues.

Argo CD will understand that changes have taken place on the cluster, and the two states (cluster configuration and Git manifest) are no longer the same. The deployment is immediately marked as out of sync (out-of-sync).

Argo CD will also dig deeper and even provide a good overview of the differences and what has changed:

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

When you detect such a difference, you can manually put the application in the same state as Git (perform the synchronization process again), or instruct Argo CD to automatically synchronize itself when a configuration change is detected.

This means that the drift of the Argo CD configuration, at least for Kubernetes applications, is completely eliminated, especially if automatic synchronization behavior is enabled.

Teams using Argo CD can safely deploy because they know that the cluster is in the state it should be in (which is also fully described in the Git list). Configuration drift is no longer a problem, and it is a very simple process to keep the stage and production process as close as possible.

The combination of Argo and Devops platform

In addition to Argo CD's main projects, you may also find the Argo Rollouts project interesting. Argo Rollouts is another Argo project for progressive (blue / green / grayscale) deployment of Kubernetes.

Https://argoproj.github.io/argo-rollouts/

Argo CD and Argo Rollouts are great for handling application deployment, but they need to be combined with a complete automation solution that will also address all other aspects of the software life cycle, such as application building, unit testing, secret management, and pull request processing.

Argo CD is ideal for actual deployment, but it assumes that the artifact has been created by another solution. This is why we have been trying to integrate Codefresh and Argo together to cover the entire software lifecycle and even cover scenarios where changes are automatically pushed to the Git repository of Argo monitoring manifest (that is, automatic commit is performed to practice continuous deployment).

On how to use Argo CD and GitOps to solve the configuration drift problem is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.