在此之前您可能听说过“GitOps”，但并不知道它到底是什么，除了 GitOps，您可能还听说过 DevOps，或者 AIOps、GOps 等，是的，现在是“Ops”盛行的时代。

GitOps 是一种实现持续交付的模型，它的核心思想是将应用系统的声明性基础架构和应用程序存放在 Git 的版本控制库中。Choerodon 猪齿鱼在构建持续交付流水线时参考了 GitOps，并进行了实践，俗话说“兵马未动，理论先行”，在本文中，将重点阐述 GitOps 工作流程的原理和模式，以及将它们应用在生产和大规模运行 Kubernetes 中的一些实践经验。在下一篇文章中，将介绍 Choerodon 猪齿鱼是如何实践和落地 GitOps，从而构建了一个可重复且可靠的交付过程。

GitOps，90%的最佳实践，10%有意思的新东西需要我们去构建。 —— 《GitOps - Operations by Pull Request》

来自：https://www.weave.works

这篇文章是根据 Weave Cloud 的几篇关于 GitOps 的文章翻译整理而来：

• GitOps: Operations by Pull Request

• The GitOps Pipeline - Part 2

• GitOps - Part 3: Observability

• GitOps - Part 4: Application Delivery Compliance and Secure CICD

 主要内容

• 什么是 GitOps？

• GitOps 的主要优点

• GitOps 的应用场景——适合云原生的持续交付

• GitOps 的基本原则

• 最佳实践

• 拉式流水线——Pull Request 操作

• GitOps 工作流

• 可视化

• 应用交付的合规性和安全的 CI/CD

• GitOps 带来的价值

什么是 GitOps？

GitOps 是一种持续交付的方式。它的核心思想是将应用系统的声明性基础架构和应用程序存放在 Git 版本库中。

将 Git 作为交付流水线的核心，每个开发人员都可以提交拉取请求（Pull Request）并使用 Git 来加速和简化 Kubernetes 的应用程序部署和运维任务。通过使用像 Git 这样的简单熟悉工具，开发人员可以更高效地将注意力集中在创建新功能而不是运维相关任务上（例如，应用系统安装、配置、迁移等）。

GitOps: versioned CI/CD on top of declarative infrastructure. Stop scripting and start shipping. https://t.co/SgUlHgNrnY — Kelsey Hightower (@kelseyhightower) January 17, 2018

GitOps 的主要优点 

通过 GitOps，当使用 Git 提交基础架构代码更改时，自动化的交付流水线会将这些更改应用到应用程序的实际基础架构上。但是 GitOps 的想法远不止于此——它还会使用工具将整个应用程序的实际生产状态与基础架构源代码进行比较，然后它会告诉集群哪些基础架构源代码与实际环境不匹配。

通过应用 GitOps 最佳实践，应用系统的基础架构和应用程序代码都有“真实来源”——其实是将基础架构和应用程序代码都存放在 gitlab、或者 github 等版本控制系统上。这使开发团队可以提高开发和部署速度并提高应用系统可靠性。

将 GitOps 理论方法应用在持续交付流水线上，有诸多优势和特点：

• 安全的云原生 CI/CD 管道模型 

• 更快的平均部署时间和平均恢复时间 

• 稳定且可重现的回滚（例如，根据 Git 恢复/回滚/ fork）

• 与监控和可视化工具相结合，对已经部署的应用进行全方位的监控

GitOps 应用场景——满足云原生环境下的持续交付

作为 CI / CD 流水线的方案，GitOps 被描述为软件开发过程的“圣杯”。 由于没有单一工具可以完成流水线中所需的所有工作，因此可以自由地为流水线的不同部分选择最佳工具。可以从开源生态系统中选择一组工具，也可以从封闭源中选择一组工具，或者根据使用情况，甚至可以将它们组合在一起，其实，创建流水线最困难的部分是将所有部件粘合在一起。

不管如何选择构造自己的交付流水线，将基于 Git（或者其他版本控制工具）的 GitOps 最佳实践应用在交付流水线中都是一个不二选择，这将使构建持续交付流水线，以及后续的推广变得更加容易，这不仅从技术角度而且从文化角度来看都是如此。

当然，GitOps 也不是万能的，它也有相应的应用场景。

不可变基础设施 

应用都需要运行在多台机器上，它们被组织成不同的环境，例如开发环境、测试环境和生产环境等等。需要将相同的应用部署到不同的机器上。通常需要系统管理员确保所有的机器都处于相同的状态。接着所有的修改、补丁、升级需要在所有的机器中进行。随着时间的推移，很难再确保所有的机器处于相同的状态，同时越来越容易出错。这就是传统的可变架构中经常出现的问题。这时我们有了不可变架构，它将整个机器环境打包成一个单一的不可变单元，而不是传统方式仅仅打包应用。这个单元包含了之前所说的整个环境栈和应用所有的修改、补丁和升级，这就解决了前面的问题。 —— 摘自 InfoQ 的《关于不可变架构以及为什么需要不可变架构》作者 百占辉

“不可变基础设施”这一概念不是刚刚冒出来的，它也不是必须需要容器技术。然而，通过容器，它变得更易于理解，更加实用，并引起了业内广泛注意。“不可变基础设施”让我们以全新的方式理解和面对应用系统，尤其是使以微服务为代表的分布式系统在部署、运营等方面变得不那么复杂，而有很好的可控性。

那么，如何比较方便地在实际的生产过程中应用“不可变基础设施”，这给业界也提出了另外一个问题。GitOps 是在具体 Kubernetes 的应用实践中出现的，GitOps 需要依托于“不可变基础架构”才能发挥其作用。在一定程度上说，“不可变基础架构”为 GitOps 的出现创造了必要的条件，反过来 GitOps 应用 Kubernetes 的容器编排能力，能够迅速的使用镜像搭建出应用系统所需的组件。

声明性容器编排 

Kubermetes 作为一个云原生的工具，可以把它的“声明性”看作是“代码”，声明意味着配置由一组事实而不是一组指令组成，例如，“有十个 redis 服务器”，而不是“启动十个 redis 服务器，告诉我它是否有效”。

借助 Kubermetes 的声明性特点，应用系统的整个配置文件集可以在 Git 库中进行版本控制。通过使用 Git 库，应用程序更容易部署到 Kubernetes 中，以及进行版本回滚。更重要的是，当灾难发生时，群集的基础架构可以从 Git 库中可靠且快速地恢复。

Kubernetes 等云原生工具的声明性体现在可以对实例、容器、网络、存储、CPU 等配置通过一组代码方便的表达出来，Kubernetes 等云原生工具可以利用这些配置代码运行出来一套基于容器的应用系统，例如 YMAL，

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

 name: nginx-deployment

spec:

 replicas: 1

 template:

   metadata:

     labels:

       app: nginx

   spec:

     containers:

     - name: nginx

  image: registry.choerodon.com.cn/operation-choerodon-dev/nginx-demo:1.13.5-alpine

       ports:

       - containerPort: 80

GitOps 充分利用了不可变基础设施和声明性容器编排，通过 GitOps 可以轻松地管理多个部署。为了最大限度地降低部署后的变更风险，无论是有意还是偶然的“配置偏差”，GitOps 构建了一个可重复且可靠的部署过程，在整个应用系统宕机或者损坏情况下，为快速且完全恢复提供了所需条件。

GitOps 的基本原则

以下是几条在云原生环境中，GitOps 的原则：

● 任何能够被描述的内容都必须存储在 Git 库中

通过使用 Git 作为存储声明性基础架构和应用程序代码的存储仓库，可以方便地监控集群，以及检查比较实际环境的状态与代码库上的状态是否一致。所以，我们的目标是描述系统相关的所有内容：策略，代码，配置，甚至监控事件和版本控制等，并且将这些内容全部存储在版本库中，在通过版本库中的内容构建系统的基础架构或者应用程序的时候，如果没有成功，则可以迅速的回滚，并且重新来过。

● 不应直接使用 Kubectl

作为一般规则，不提倡在命令行中直接使用 kubectl 命令操作执行部署基础架构或应用程序到集群中。还有一些开发者使用 CI 工具驱动应用程序的部署，但如果这样做，可能会给生产环境带来潜在不可预测的风险。

● 调用 Kubernetes 的 API 的接口或者控制器应该遵循 Operator 模式

调用 Kubernetes 的 API 的接口或者控制器应该遵循 Operator 模式（什么是 Operator 模式？），集群的状态和 Git 库中的配置文件等要保持一致，并且查看分析它们之间的状态差异。

最佳实践

以 Git 作为事实的唯一真实来源 

Git 是每个开发人员工具包的一部分。学习起来感觉自然而且不那么令人生畏，而且工具本身也非常简单。 通过使用 Git 作为应用系统的事实来源，几乎可以操作所有东西。例如，版本控制，历史记录，评审和回滚都是通过 Git 进行的，而无需使用像 kubectl 这样的工具。

所以，Git 是 GitOps 形成的最基础的内容，就像第一条原则“任何能够被描述的内容都必须存储在 Git 库中 ”描述的那样：通过使用 Git 作为存储声明性基础架构和应用程序代码的存储仓库，可以方便地监控集群，以及检查比较实际环境的状态与代码库上的状态是否一致。所以，我们的目标是描述系统相关的所有内容：策略，代码，配置，甚至监控事件和版本控制等，并且将这些内容全部存储在版本库中，在通过版本库中的内容构建系统的基础架构或者应用程序的时候，如果没有成功，则可以迅速的回滚，并且重新来过。

拉式流水线——Pull Request 操作 

▌推送流水线  

目前大多数 CI / CD 工具都使用基于推送的模型。基于推送的流水线意味着代码从 CI 系统开始，通过一系列构建测试等最终生成镜像，最后手动使用“kubectl”将任何更改推送到 Kubernetes 集群。

很多开发人员不愿意在 CI 中启动 CD 部署流程，或者使用命令行工具操作启动 CD 部署流程的原因可能是这样做会将集群的用户和密码等公布出去。虽然可以有措施保护 CI / CD 脚本和命令行，但是这些操作毕竟还是在集群外部非可信区工作的。所以，类似做法是不可取的，会给系统安全带来潜在的风险。

具有集群外读/写（R/W）权限的典型推送流水线：





• CI 运行测试，输出传递到容器映像存储库。

• CD 系统自动部署容器（或根据请求，即手动）。

▌拉式流水线

在 GitOps 中，镜像被拉出并且凭证保留在集群中：



Git 库是拉式流水线模式的核心，它存储应用程序和配置文件集。开发人员将更新的代码推送到 Git 代码库; CI 工具获取更改并最终构建 Docker 镜像。GitOps 检测到有镜像，从存储库中提取新镜像，然后在 Git 配置仓库中更新其 YAML。然后，GitOps 会检测到群集已过期，并从配置库中提取已更改的清单，并将新镜像部署到群集。

GitOps 的流水线 

在上节中介绍了 GitOps 采用拉式模式构建交付流水线，本节将详细地介绍在构建 GitOps 流水时需要注意哪些事情，有哪些最佳实践。

▌GitOps 流水线



这是一个新图，显示部署上游的所有内容都围绕 Git 库工作的。在“拉式流水线”中讲过，开发人员将更新的代码推送到 Git 代码库，CI 工具获取更改并最终构建 Docker 镜像。GitOps 的 Config Update 检测到有镜像，从存储库中提取新镜像，然后在 Git 配置仓库中更新其 YAML。然后，GitOps 的 Deploy Operator 会检测到群集已过期，并从配置库中提取已更改的清单，并将新镜像部署到群集。

使用群集内部的 Deploy Operator，群集凭据不会在生产环境之外公开。一旦将 Deploy Operator 安装到集群与 Git 仓库建立连接，线上环境中的任何更改都将通过具有完全回滚的 Git pull 请求以及 Git 提供的方便审计日志完成。

▌自动 git→集群同步

由于没有单一工具可以完成流水线中所需的所有工作，可以从开源生态系统中选择一组工具，也可以从封闭源中选择一组工具，或者根据使用情况，甚至可以将它们组合在一起，其实，创建流水线最困难的部分是将所有部件粘合在一起。要实现 GitOps，必须要开发出新的组件，用于粘合这些工具，实现拉式交付流水线。

部署和发布自动化是应用落实 GitOps，并使交付流水线工作的基础。GitOps 不仅要保证，当开发人员通过 Git 更新配置文件集的时候，GitOps 流水线要自动根据最新的配置文件状态更新线上环境，而且 GitOps 还要能够实时比对 Git 库中配置文件集最新的状态与线上环境最新的状态保持一致。





在上节中提到了两个名词：Config Update 和 Deploy Operator，根据 GitOps 的实践，Config Update 和 Deploy Operator 是需要进行设计开发的，它们是实现 GitOps 流水线必须的关键组件。GitOps 赋予了它们神奇的魔法，它们既是自动化容器升级和发布到线上环境的工具，可能也要负责服务、部署、网络策略甚至路由规则等任务。因此，Config Update 和 Deploy Operator 是映射代码，服务和运行集群之间所有关系的“粘合剂”。

当然，您可以根据具体的设计，赋予各种其他的功能，但是自动同步是一定需要的，确保如果对存储库进行任何更改，这些更改将自动部署到线上环境中。

▌仅部署容器和配置

GitOps 建议不直接将应用程序部署到线上环境中，而是将应用程序和相关配置打包成镜像，并存储到镜像库中，最后，通过镜像的方式生成容器，并部署到线上环境中。

容器为什么如此重要？在 GitOps 模型中，我们使用不可变基础架构模式。一旦代码在 Git 中提交，GitOps 就不希望任何其他内容发生变化，这样可以最大限度地降低系统潜在不确定性、不一致性风险。例如，需要将相同的应用部署到不同的机器上。通常需要系统管理员确保所有的机器都处于相同的状态。接着所有的修改、补丁、升级需要在所有的机器中进行。随着时间的推移，很难再确保所有的机器处于相同的状态，同时越来越容易出错。然而，容器是比较完美地解决了这个问题，当然，使用虚拟机是可以的，显然使用容器更加方便。

GitOps 的可观察性 

“可观察性就像生产中的驱动测试一样。如果你不知道如何确定它是否正常工作，请勿接受 pull request。@mipsytipsy “ - Adriano Bastos

在 GitOps 中，使用 Git 库来存储应用系统的配置文集和应用程序，它确保开发人员将所有对于应用系统的配置和程序的新增、修改等都通过 Git 库进行版本控制，使 Git 成为配置和程序的唯一真实来源。而 GitOps 的可观察性则是确保线上环境的真实状态与 Git 库中的保持一致性。本章节将给大家介绍 GitOps 的可观察性。

▌可观察性是另一个真理来源

在 GitOps 中，我们使用 Git 作为系统所需状态的真实来源。例如，如果应用系统宕机，GitOps 可以回滚到之前正确状态。而可观察性是系统实际运行状态的真实来源，系统开发人员或者运维人员可以监控系统的状态。这是一张显示流程的图片。





▌通过观察需寻找问题的答案

如果大家使用 Kubernetes 作为云原生环境和容器编排工具，相信大家会有这样的感触，虽然 Kubernetes 是一个非常棒的编排容器平台，但是随之而来的缺乏友好的可视化管理界面给开发人员或者运维人员带来诸多不便。例如：

• 我的部署成功了吗？我的系统现在处于工作的状态，我现在可以回家吗？

• 我的系统与以前有什么不同？我可以使用 Git 或我们的系统历史记录来检查吗？

• 我的改变是否改善了整体用户体验？（与系统正确性相对）

• 我在信息中心找不到我的新服务（例如 RED 指标）

• 这个故障是否与我上次的服务更新事件有关，还是和其他操作有关系？

大家可能会想到通过监控服务器的 CPU、内存、网络等，以及应用的日志，甚至微服务的调用链等来解决问题。是的，这个没有错，能够得到一些反馈信息，但是使用过类似监控的开发人员或者运维人员也会感觉，这些监控仪表盘给我们大量冗繁的信息，需要认真地甄别，而且有很多信息在这些仪表盘中是获得不到的。这意味着需要创建新的仪表盘，用于监控新的指标和内容。

▌GitOps 的可观察性

可观察性可被视为 Kubernetes 持续交付周期的主要驱动因素之一，因为它描述了在任何给定时间系统的实际运行状态。观察运行系统以便理解和控制它。新功能和修复程序被推送到 git 并触发部署管道，当准备好发布时，可以实时查看正在运行的集群。此时，开发人员可以根据此反馈返回到管道的开头，或者将映像部署并释放到生产集群。

在这里 GitOps 引入一个新的工具：Diffs，用来监控对比系统状态。即：

• 验证当前线上系统的状态是否和 Git 库中描述的状态一致，例如，我上一次发布是否符合期望？

• 提醒开发人员不一致状态，以及相应的明细信息。

在文章前面讲过，在 Git 库中存储的实际上是“声明性基础设施”，例如 Kubernetes 的 YAML 文件，用以构建应用系统所需的各种组件、域名、网络等配置信息。Diffs 需要读取 Git 库中配置信息，同时，通过 API 等读取集群的相应信息，并进行比对。

例如，Kubernetes 集群：所需的 Kubernetes 状态可能是“有 4 个 redis 服务器”。Diffs 定期检查群集，并在数量从 4 变化时发出警报。一般而言，Diffs 将 YAML 文件转换为运行状态查询。

GitOps 是面向发布的操作模型，请参见下图。交付速度取决于团队在此周期中绕过各个阶段的速度。



应用交付合规性和安全性 

由于以安全的方式跟踪和记录更改，因此合规性和审计变得微不足道。使用 Diffs 等比较工具还可以将 Git 库中定义的集群状态与实际运行的集群进行比较，从而确保更改与实际情况相符。

▌在 Git 中记录所有的操作日志

通过上面文章的叙述，开发人员或者运维人员通过 Git 操作系统配置和应用程序的新建和更新等。通过 Git 客户端 git commit /git merge 的所有操作都会 Git 库记录下来，审计员可以查看 Git，看看谁做了任何更改，何时以及为何以及如何影响正在运行的系统部署。当然，可以根据自身的需求定制不同的交付合规性。相较于直接进入服务器操作或者通过 Kubctl 操作集群，Git 记录了每一个操作步骤，这些可以为合规性和审计提供完整的操作日志。

▌角色和权限控制

几乎所有的 Git 库都提供角色和权限控制，与开发和运维无关的人员没有权限操作 Git 库。而不是直接把服务器或者集群的操作权限散发出去，这样特别容易引起安全泄露。

GitOps 带来的好处

▌更加快速地开发

借助 GitOps 的最佳实践，开发人员可以使用熟悉的 Git 工具，便捷地将应用程序和其对应的配置文件集持续部署到 Kubernetes 等云原生环境，提高业务的敏捷度，快速地相应用户的需求，有助于增加企业市场的竞争力。

▌更好地进行运维

借助 GitOps，可以实现一个完整的端到端的交付流水线。不仅可以实现拉式的持续集成流水线和持续部署流水线，而且系统的运维操作可以通过 Git 来完成。

▌更强大的安全保证

几乎所有的 Git 库都提供角色和权限控制，与开发和运维无关的人员没有权限操作 Git 库。而不是直接把服务器或者集群的操作权限散发出去，这样特别容易引起安全泄露。

▌更容易合规的审计

由于以安全的方式跟踪和记录更改，因此合规性和审计变得微不足道。使用 Diffs 等比较工具还可以将集群状态的可信定义与实际运行的集群进行比较，从而确保跟踪和可审计的更改与实际情况相符。