如何立即充分利用 GitOps

您可能遇到过著名的云软件工程师 Kelsey Hightower 分享的关于 GitOps 的简短介绍

GitOps：基于声明式基础设施的版本化 CI/CD。停止编写脚本，开始交付。https://#/SgUlHgNrnY

— Kelsey Hightower (@kelseyhightower) 2018 年 1 月 17 日

在 基础设施即代码 的世界中，GitOps 是一种流行的管理自动化部署的方式，通过持续集成/持续开发 (CI/CD) 和微服务架构，因为我们的大部分基础设施本质上是在今天的配置文件中定义的（例如，YAML、JSON、HCL）。这不仅限于 Kubernetes (K8s)，但它通常与 K8s 集群高度相关。（我稍后会解释原因。）这基本上意味着更改生产基础设施中的任何内容就像更改一行代码一样简单。

GitOps 与 K8s 如此紧密相关的原因是 K8s 完全在声明式 YAML 中配置，因此，您可以快速实现使用 GitOps 的好处，因为它实际上只是软件定义的基础设施。当涉及到在您的工程组织中正确应用 GitOps 时，您需要注意的主要事项是如何强制对您的集群或基础设施进行更改。

当您选择 GitOps 路径时，您只能通过单一的事实来源来完成：您的源代码管理 (SCM) 存储库（例如，GitLab、GitHub、Bitbucket 或您自己的托管解决方案），该存储库为您的整个组织强制执行版本控制策略。这意味着更改基础设施的唯一方法是通过存储库中的拉取请求。这就是在使用 GitOps 的大型工程组织中大规模维护版本控制的方式。

现实世界部署的状态

GitOps 原则声称是实现 CI/CD 的一种新的更简单的方法，但 CI/CD 的 CD 部分比 GitOps 实践让您相信的要复杂得多。使用 GitOps，CD 部分分解为一种非常二元的工程环境方法。您要么处于暂存环境，要么处于生产环境，您只需拨动开关，您的代码就会进入生产环境。在我多年的工程师经验中，我还没有参与过如此简单的重大代码更改、功能发布或其他重大部署。

在暂存或生产版本控制中封装了更多的后续工作，这些工作完全从 GitOps 的 CD 过程中抽象出来。这意味着任何认真对待质量的工程流程都将在重大部署的 CI 和 CD 阶段之间设置几个阶段。这些阶段包括测试、验证结果、验证更改是否已传播、重新测试，以及通常进行部分发布（金丝雀等）。这些只是工程组织中如何管理 CD 的一些示例。

更好地进行部署的 GitOps 技巧

当涉及到 GitOps 时，无需重新发明 CI/CD（尤其是 CD）的轮子。如果您像大多数人一样，通过在部署前后使用一些自定义脚本来勉强完成 CD 流程以使其完成，那么要知道有更好的方法可以使用 GitOps 促进器来完成此操作。使用 GitOps 促进器，例如开源的、云原生计算基金会 (CNCF) 托管的 Argo CD，使用户能够在一个地方大规模管理所有这些自定义脚本。这确保了在 CI/CD 流程中使用脚本时的最佳实践，使它们在每次运行时都具有规范性和可重复性。

更重要的是，由于有一个代理持续同步状态，因此它通过强制执行提交状态来减少人为错误。

使用 GitOps 管理跨存储库的混乱

对于复杂的部署架构，例如 K8s，甚至只是普通的旧微服务，即使是对代码的微小更改通常也会影响其他相互依赖的服务。使用 GitOps 映射这些依赖关系往往会变成一场噩梦。通常使用共享存储库和文件，您需要同步状态。然而，您经常会发现，错误、配置错误甚至只是错误都可能产生 蝴蝶效应，从而引发一连串的故障，在 GitOps 中变得极其难以跟踪和理解。

使用 GitOps 解决此挑战的一种常见方法是创建一个“超级存储库”，它本质上是一个集中式的单体存储库，其中包含指向所有相关依赖项、文件、资源等的指针。然而，这很快就变成了一个混乱的垃圾袋“包罗万象”的存储库，在那里，理解、跟踪和记录更改极其困难。

当您有许多依赖项时，为了使 GitOps 能够工作，这些依赖项需要以 Git 形式表示。这要求您的组织是“Git 原生”的。这意味着您需要做大量的临时自动化工作来创建模块和子模块，以连接和关联您的超级存储库和相关的子存储库。很多时候，这会带来大量的维护开销，随着时间的推移，维护起来会变得极其困难。

如果您不这样做，您就无法获得 GitOps 的好处，而您主要只是陷入了缺点之中。您可以通过一个 YAML 文件来实现类似的功能，该文件封装了所有版本和依赖项，类似于 Helm umbrella chart。如果不完全采用 Git 原生，您基本上可以做任何其他事情——而不是 GitOps。

虽然在 GitOps 世界中，存储库代表环境的单一事实来源，但在实践中，任何给定的部署中都有许多第三方集成。这些集成可以是任何东西，从您的身份验证和授权（例如，Auth0）到您的数据库，这些集成在大多数情况下都是在您的存储库外部更新的。这些对外部资源的更改可能会严重影响您的生产和部署，但它们在您的单一事实来源存储库中根本没有表示。这可能是您整个部署中的一个严重的盲点。

更好地管理混乱的 GitOps 技巧

当使用 GitOps 时，像对待代码一样对待您的配置。不要吝啬验证管道，确保适当的拉取请求卫生，并维护您在规模化管理代码时应用的任何其他实践，以避免这种混乱。不要惊慌！如果推送了不正确的内容，并且您担心它会传播到所有服务器、集群和存储库，您只需运行 git revert，即可撤消上次提交。

此外，与我关于同步状态的建议类似，使用 GitOps 促进器可以帮助管理 Git 实践、成为 Git 原生以及处理 Kubernetes 部署（以及成为 Kubernetes 原生）。

最后，为了避免任何混乱或复杂性，请确保您的 Git 存储库的状态尽可能接近您的生产环境，以避免您的环境偏离 GitOps 操作。

使用 GitOps 的 3 个技巧

以下是我充分利用 GitOps 的技巧

1. 确保尽早构建对 GitOps 自动化的可见性，这样您就不会在众多存储库中盲目运行。当涉及到使 GitOps 最佳运行时，您应该为每个应用程序使用单个存储库。当这些存储库开始增加时，可见性可能会成为一个真正的痛点。考虑依赖项以及如何设计足够的系统可见性，这样如果出现问题，您将知道如何跟踪到其源头并修复它。
2. 做到这一点的一种方法是为每种故障场景制定计划。当依赖项崩溃时会发生什么？当涉及到 GitOps 时，合并冲突是一种生活方式。您如何管理可能使 GitOps 系统不堪重负的高速部署和生产环境升级？考虑许多潜在的挑战、故障和冲突，并为每个挑战、故障和冲突制定剧本。此外，根据第一点，确保有足够的可见性以便快速排除故障。当然，如果发生故障，请不要忘记 git revert 命令。
3. 使用单体存储库。是的，我说出来了。关于单体存储库与多存储库的古老争论。当涉及到 GitOps 时，毫无疑问哪种是更好的选择。虽然集中式单体存储库有缺点（例如，它可能会变得混乱，成为理解构建过程的噩梦等等），但它也可以帮助解决与跨存储库依赖项相关的大部分麻烦。

作为一名工程师，我直接感受到了这种痛苦。我意识到迫切需要某种东西来关联我在 GitOps 生活的每一天都感受到的这些依赖关系和可见性挑战。

我想要一个更好的解决方案来跟踪复杂微服务设置中的级联故障，并将其追溯到根本原因或代码更改。我迄今为止尝试过的所有方法，包括 GitOps，都只提供了部分信息、很少的关联，并且几乎没有因果关系。

GitOps 工具（如 Argo CD）有助于解决 DIY GitOps 出现的许多问题。当走 GitOps 路线时，考虑使用此类工具可能是一件好事，因为它们

• 是为 Kubernetes 原生设计的
• 适用于使用 image-puller 的小型团队
• 拥有强大的社区支持（例如，通过 CNCF 的 Argo CD，它也易于与其他 Argo 工具一起使用）
• 通过良好的应用程序用户界面提供改进的开发人员体验
• 与 Git 原生集成，这有助于最大限度地减少混乱和复杂性

底线

部署过程，尤其是新版本的部署过程，是一项复杂的工程壮举。为了正确地完成这些工作，您需要投入精力来研究技术和流程设计。例如，在生产环境中部署和验证我的应用程序的最佳方法是什么？

GitOps 是了解生产环境中运行内容的一个非常好的起点。请记住，它可能还需要使用其他工具和 DIY 自动化进行一些增强，才能使其恰到好处地为您的工程团队工作。这样，GitOps 的光芒对于您的组织来说是 24K 纯金，而不是 愚人金。