如何使用Argo CD和GitOps解决配置漂移问题

这篇文章将为大家详细讲解有关如何使用Argo CD和GitOps解决配置漂移问题，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

Argo CD（Argo项目的一部分）是一个为Kubernetes而设的部署解决方案，遵循GitOps模式。

使用Argo CD部署到Kubernetes

在最基本的场景中，Argo CD使用Kubernetes清单持续监视Git仓库（也支持Helm和Kustomize）并监听提交事件。

当发生提交（通常是更新镜像工件版本的提交）时，Argo CD会启动一个"同步（synchronization）"进程，该进程负责使集群配置处于与Git中描述的相同的状态。

当同步过程完成时，我们知道应用程序配置与Git清单完全相同。

Argo CD的部署过程体现了GitOps背后的核心理念：

• 所有应用程序配置都存储在Git中（通常在与源代码不同的存储库中）

• 部署以一种"拉"方式进行，即集群从Git获取清单（而不是将更新"推"到集群的传统解决方案）。

• 部署是两种状态之间的协调过程（Git中描述的状态与集群中部署的状态）

尽管同步过程对于执行应用程序的初始部署是至关重要的，但Argo CD真正的优势之一是在部署完成后能够持续监控两个状态（集群和Git）。这种持续的监视对于解决配置漂移非常重要，配置漂移在具有大量部署目标的组织中是一个非常常见的问题。

不同Kubernetes集群之间的配置漂移

配置漂移是一个即使在传统虚拟机中也存在的问题，而且早在Kubernetes出现之前，它就一直困扰着生产部署。当CI/CD平台执行到多个目标的部署并失败时，问题就会显现出来，因为一组本应相似的机器实际上配置不同。

在一些组织中，开发人员在应用程序部署到生产环境之前使用"登台（staging）"环境来测试其应用程序。理想情况下，登台环境应该与生产环境的配置相匹配，这样开发人员就可以确信他们在登台中执行的任何测试都将与生产环境紧密匹配。

特别是在Kubernetes集群中，团队经常使用特别的命令（例如，通过kubectl）在一个完全不在CI/CD进程之外的集群上执行更改。

这些特别的更改是应用程序部署的一个主要问题。配置上的差异是导致部署失败的最常见原因之一。在登台环境中成功通过所有测试的应用程序在生产中会出现中断状态，因为没有提供所需的设置或采用预期的格式。

另一个由配置漂移引起的隐藏问题是，逐渐丢失了在机器/节点上部署了什么以及最后一次更改的确切时间的知识。Argo CD解决了这个问题，它将Git作为当前部署和过去所有部署的真实来源。

在部署失败后，运营者和开发人员试图了解事故的原因，他们问的第一个问题是"这个集群最后发生的变化是什么"。如果集群在批准的CI/CD进程之外发生了未控制的更改，那么这个问题很难回答。

Argo CD如何检测配置漂移问题

Argo CD采用了一种完全不同的部署方法（"pull from Git"范式）。因为所有部署都可以追溯到Git提交，所以Git提交历史记录也是集群部署历史记录。

开发人员可以使用他们喜欢的Git工具来回答诸如"上周四集群上部署了什么？"或者"这周周一到周四之间发生了什么变化？"

让我们假设团队中的一个人完全绕过了Argo CD，并使用kubectl直接对集群进行手动更改。其他CI/CD解决方案将完全忽略此更改，这为配置漂移问题提供了环境。

Argo CD会理解集群上发生了变化，这两种状态（集群配置和Git清单）不再相同。部署将立即标记为"不同步（out-of-sync）"。

Argo CD也将挖掘得更深入，甚至提供了一个很好的差异概述，改变了什么：

在上面的例子中，Argo CD检测到集群和Git之间服务的端口配置不再相同。

当你检测到这样的差异，你可以手动使应用程序处于与Git相同的状态（再次执行同步过程），或者指示Argo CD在检测到配置更改时自动进行自身的同步。

这意味着Argo CD配置的漂移（至少对Kubernetes应用程序而言）完全消除了，特别是在启用了自动同步行为的情况下。

使用Argo CD的团队可以放心地进行部署，因为他们知道集群处于它应该处于的状态（该状态在Git清单中也有完整的描述）。配置漂移不再是一个问题，保持登台和生产过程尽可能接近是一个非常简单的过程。

Argo与Devops平台的结合

除了Argo CD的主要项目，你可能也会发现Argo Rollouts项目很有趣。Argo Rollouts是Argo的另一个项目，用于对Kubernetes进行渐进式（蓝/绿/灰度）部署。

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

Argo CD和Argo Rollouts对于处理应用程序部署来说是非常好的，但是它们需要与一个完整的自动化解决方案相结合，这个解决方案也将处理软件生命周期的所有其他方面，比如应用程序构建、单元测试、秘密管理和拉取请求处理等。

Argo CD非常适合实际部署，但它假设工件已经由另一个解决方案创建。这就是为什么我们一直努力将Codefresh和Argo集成在一起，以覆盖整个软件生命周期，甚至覆盖自动将变更推送到Argo监控manifest的Git仓库的场景（即执行自动提交，从而实践持续部署）。

关于如何使用Argo CD和GitOps解决配置漂移问题就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。