GitOps 是什么？¶

你可能听说过 DevOps，或者 AIOps、ChatOps 等，那么 GitOps 又是什么呢？

GitOps 是 Weaveworks 提出的一种持续交付方式，它的核心思想是将应用系统的声明性基础架构和应用程序存放在 Git 版本库中。将 Git 作为交付流水线的核心，每个开发人员都可以提交拉取请求（Pull Request）并使用 Git 来加速和简化 Kubernetes 的应用程序部署和运维任务。通过使用像 Git 这样的简单工具，开发人员可以更高效地将注意力集中在创建新功能而不是运维相关任务上（例如，应用系统安装、配置、迁移等）。

主要优点¶

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

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

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

安全的云原生 CI/CD 流水线模型
更快的部署时间和恢复时间
稳定且可重现的回滚（例如，根据 Git 恢复/回滚/fork）
与监控和可视化工具相结合，对已经部署的应用进行全方位的监控

应用场景¶

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

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

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

不可变基础设施¶

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

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

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

声明性容器编排¶

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

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

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.7.9
          ports:
            - containerPort: 80

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

基本原则¶

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

任何能够被描述的内容都必须存储在 Git 库中：通过使用 Git 作为存储声明性基础架构和应用程序代码的存储仓库，可以方便地监控集群，以及检查比较实际环境的状态与代码库上的状态是否一致。所以，我们的目标是描述系统相关的所有内容：策略，代码，配置，甚至监控事件和版本控制等，并且将这些内容全部存储在版本库中，在通过版本库中的内容构建系统的基础架构或者应用程序的时候，如果没有成功，则可以迅速的回滚，并且重新来过。
不应直接使用 kubectl 命令：一般不提倡在命令行中直接使用 kubectl 命令操作执行部署基础架构或应用程序到集群中。还有一些开发者使用 CI 工具驱动应用程序的部署，但如果这样做，可能会给生产环境带来潜在不可预测的风险。
调用 Kubernetes 的 API 接口或者控制器应该遵循 Operator 模式：集群的状态和 Git 库中的配置文件等要保持一致，并且查看分析它们之间的状态差异。

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

将变更部署到集群¶

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

如下图所示是一条典型的 push 模式的 CI/CD 流水线，CI 工具负责运行测试、构建镜像、检查 CVE 并将新镜像重新部署至集群当中。

push 流水线（图片来源：Weaveworks）

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

pull流水线（图片来源：Weaveworks）

GitOps 流水线¶

GitOps 流水线

上图中我们可以看到部署的相关操作都是围绕 Git 仓库工作的，在“拉式流水线”中提到过，开发人员将更新的代码推送到 Git 代码仓库，CI 工具获取变更并最终构建成 Docker 镜像，GitOps 的 Config Updater 检测到有镜像更新，从存储库中提取新镜像，然后在 Git 配置仓库中更新其 YAML。然后，GitOps 的 Deploy Operator 会检测到集群中应用已过期，并从配置库中提取已更改的清单，并将新镜像部署到集群中。

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

状态同步¶

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

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

git sync

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

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

只部署容器和配置¶

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

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

GitOps 的可观察性¶

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

状态监测¶

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

GitOps 可观测性

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

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

验证当前线上系统的状态是否和 Git 库中描述的状态一致，例如，我上一次发布是否符合期望？
提醒开发人员不一致状态，以及相应的明细信息。

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

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

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

GitOps Workflow

合规性和安全性¶

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

角色和权限控制¶

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

工具¶

上面我们提到在实现 GitOps 中有两个重要的概念：Config Updater 和 Deploy Operator，这在 Kubernetes 中通常也是使用 Operator 来实现的，目前比较热门的用于实现 GitOps 的工具有 Flux、ArgoCD、Jenkins X。

关于 3 者直接的对比可以参考文章 https://blog.container-solutions.com/fluxcd-argocd-jenkins-x-gitops-tools 了解，接下来我们的重点将是通过 ArgoCD 来实现 GitOps 流水线。