本文永久链接: https://www.xtplayer.cn/git/top-11-reasons-to-use-gitops/

Kubernetes 允许我们单纯地使用声明性的配置文件来管理我们的应用部署和其他基础设施组件（例如，我们现在都是 YAML 开发者）。这使我们能够把所有这些文件放到 Git 仓库中，然后把它挂到流水线上（Jenkins、GitLab 等），流水线会把这些变化应用到集群上，然后就有了 GitOps。如果你还不了解 GitOps 是什么，可以查看我们之前发布过的文章：GitOps 初阶指南：将 DevOps 扩展至 K8S

为了使工作正常进行，我们必须确保改变集群的唯一方法是在 Git 仓库上提交。GitOps 并不是专门针对 Kubernetes 的，同样的原理也可以应用于任何其他声明式配置管理的环境。

可以说，很多企业已经开始采用 GitOps 了，但现在是业界开始充分认识到其潜力的时候。所以，让我们深入了解一下它如此出色的原因吧！

  1. 存储环境变更历史记录

    只有通过更新相应 Git 仓库中的配置，才能改变应用环境。这将创建一个完整的状态变化的历史记录，包括谁做了更改和为什么更改的记录。你可以通过正在使用的 Git 用户界面来读取历史记录。

  2. 轻松回滚到之前的状态

    一旦我们所有的变更都被存储为 Git 历史记录，就可以很容易地将一个环境回滚到之前的任何状态。通过还原一些 commit，我们可以回到以前的工作状态。

  3. 保障部署安全

    一旦对集群的所有更改都通过 GitOps repo，用户和持续集成(CI)流程就不需要再访问集群了。这大大降低了攻击面，尤其是还可以减少对 Kubernetes API 的网络访问。

    部署过程无论如何实现，都可以在集群内部运行，并从 Git 中拉取配置。其对 API 的访问使用基于角色的访问控制（RBAC）进行限制。这极大地提高了集群的安全性，防止任何恶意的远程更改在 API 服务器上。

  4. 轻量化审批程序

    在修改生产环境时，开发人员总是不受信任。因此在许多公司中都建立了四眼审批流程（four-eyes approval processes），不论是出于什么原因建立的审批流程，GitOps 都提供了一个简单的方法来实现它们。

    具体实现方式取决于你使用的 Git 服务器，但重点是给开发人员在 Git repo 上创建拉取请求的权利，同时给另一组人审查和合并的权利。大多数 Git 服务器都有一个很好的 UI 来检查修改和批准拉取请求——所以这个解决方案不仅便宜，而且对用户也相当友好。

  5. 模块化架构

    GitOps 有 3 个部分：Git repo、部署流程以及一个在 Git repo 中自动更新版本的过程。这三者可以相互独立演化或替换。

    一边是一个组件在 Git repo 写入，另一边是一个组件在读取。Git repo 的结构成为这些组件之间的桥梁。由于这是一个相当松散的耦合，两边可以用不同的方式甚至不同的技术栈来实现。

  6. 独立于工具的架构

    第 5 点中提到的模块化可以看出 GitOps 架构是一个可以灵活组装最佳工具的架构。当然，任何流行的 Git 服务器都可以完成 Git 部分的工作，FluxCD 或 ArgoCD 可以负责将 repo 同步到集群。JenkinsX 是一个处理这个过程所有部分的工具，包括创建 Git repos，并在构建新的 Docker 镜像时用新版本更新它们。

  7. 复用现有知识

    将 Git 置于部署流程的核心，可以充分利用大多数开发人员和运维人员已经掌握的 Git 知识。不需要新的工具来浏览部署历史或实施审批流程。所有的流程都是用大家都熟悉的工具来完成的。

  8. 比较不同的环境

    当你有一个从开发到用户接受度测试（UAT）再到生产的环境链时，跟踪这些环境之间的差异是一件很麻烦的事情。多亏了存储在 Git repos 中的声明式配置，它使得处理环境间差异就像比较一组 YAML 文件一样简单。

    我们有非常棒的工具来做这件事，所以这将不再是一个问题。更重要的是，从头开始创建一个新的环境，就像复制和粘贴这些文件到一个新的 repo 中一样简单。

  9. 开箱即用的备份

    由于你的环境状态存储在 Git 中，如果 Kubernetes 上的 etcd 发生了什么事情，你也永远不会丢失数据。因为它是你集群状态的自然备份。

  10. 像应用程序代码一样测试你的更改

    你可以用测试应用程序代码的方式来测试环境中可能出现的破坏性变化。将更改放在一个分支上，然后在其上运行 CI 流水线。你的 CI 工具将能够运行测试，并根据测试结果将 Git 中的 pull-request 状态设置为绿色或红色。一旦所有的东西都经过测试和审查，你就可以合并到 master。

    这听起来非常简单，但自动化测试是基础设施管理中经常被忽视的任务。虽然 GitOps 并没有让它变得更容易，但至少它为你提供了与你在其他地方使用的相同的熟悉工作流程。

  11. 高可用部署基础设施

    部署基础设施保持一致很重要。Git repo 服务器通常已经以复制、高可用的方式进行了设置。源代码是所有开发人员在大多数时间都需要访问的东西，所以使用 Git 作为部署的源码并不会给 Git 本身增加额外的负担。