主持人 > 博客 > 管理 > 什么是 GitOps？

什么是 GitOps？

笔记。 翻译。: 最近发表后 材料 关于 GitOps 中的拉和推方法，我们普遍看到了对这个模型的兴趣，但是关于这个主题的俄语出版物很少（关于 Habré 根本没有）。 因此，我们很高兴向您提供另一篇文章的翻译，尽管是一年前的事了！ ——来自 Weaveworks，该公司的负责人创造了术语“GitOps”。 文本解释了该方法的本质以及与现有方法的主要区别。

一年前我们发表了 GitOps 简介。 当时，我们分享了 Weaveworks 团队如何推出完全基于 Kubernetes 的 SaaS，并开发了一套用于在云原生环境中部署、管理和监控的规范性最佳实践。

这篇文章很受欢迎。 其他人开始谈论 GitOps 并开始发布新工具 git推, 发展, 秘密, 功能, 持续集成 等等。 出现在我们的网站上 大量的 出版物和 GitOps 用例。 但有些人仍有疑问。 该模型与传统模型有何不同？ 基础架构即代码 和持续交付（持续交货）？ 有必要使用Kubernetes吗？

我们很快意识到需要一个新的描述，提供：

  1. 大量的例子和故事；
  2. GitOps的具体定义；
  3. 与传统持续交付的比较。

在本文中，我们试图涵盖所有这些主题。 它提供了 GitOps 的最新介绍以及开发人员和 CI/CD 视角。 尽管该模型可以推广，但我们主要关注 Kubernetes。

认识 GitOps

想象一下爱丽丝。 她经营家庭保险，为那些太忙而无法自己弄清楚合同细节的人们提供健康、汽车、家庭和旅行保险。 当爱丽丝在一家银行担任数据科学家时，她的生意开始于一个业余项目。 有一天，她意识到她可以使用先进的计算机算法来更有效地分析数据并制定保险方案。 投资者为该项目提供了资金，现在她的公司每年收入超过 20 万美元，并且发展迅速。 目前，该公司拥有不同岗位的员工180人。 这包括开发、维护网站、数据库和分析客户群的技术团队。 这个 60 人的团队由公司技术总监 Bob 领导。

Bob 的团队在云中部署生产系统。 他们的核心应用程序在 GKE 上运行，利用 Google Cloud 上的 Kubernetes。 此外，他们在工作中使用各种数据和分析工具。

Family Insurance 并没有打算使用容器，而是被 Docker 的热情所吸引。 该公司很快发现 GKE 可以轻松部署集群来测试新功能。 添加了 Jenkins for CI 和 Quay 来组织容器注册表，为 Jenkins 编写了脚本，将新容器和配置推送到 GKE。

一段时间过去了。 Alice 和 Bob 对他们选择的方法的性能及其对业务的影响感到失望。 容器的引入并没有像团队希望的那样提高生产力。 有时部署会中断，并且不清楚代码更改是否是罪魁祸首。 事实证明，跟踪配置更改也很困难。 通常有必要创建一个新的集群并将应用程序移至其中，因为这是消除系统混乱的最简单方法。 Alice 担心随着应用程序的开发情况会变得更糟（此外，一个基于机器学习的新项目正在酝酿中）。 Bob 已经自动化了大部分工作，但不明白为什么管道仍然不稳定，无法很好地扩展，并且需要定期手动干预？

然后他们了解了 GitOps。 事实证明，这个决定正是他们自信地前进所需要的。

Alice 和 Bob 多年来一直听说 Git、DevOps 和基础设施即代码工作流程。 GitOps 的独特之处在于，它带来了一组最佳实践（既明确又规范），用于在 Kubernetes 环境中实现这些想法。 这个主题 反复上涨包括在内 Weaveworks 博客.

Family Insurance 决定实施 GitOps。 公司现已拥有兼容 Kubernetes 并结合自动化运营模式 速度 同 稳定因为他们：

  • 发现团队的生产力翻了一番，而没有人发疯；
  • 停止提供脚本。 相反，他们现在可以专注于新功能并改进工程方法 - 例如，引入金​​丝雀部署和改进测试；
  • 我们改进了部署流程，使其很少出现故障；
  • 有机会在部分故障后恢复部署，无需人工干预；
  • 购买二手的о对交付系统更有信心。 Alice 和 Bob 发现他们可以将团队分成并行工作的微服务团队；
  • 通过每个小组的努力，每天可以对项目进行30-50次修改并尝试新技术；
  • 很容易吸引新的开发人员加入该项目，他们有机会在几个小时内使用拉取请求将更新推出到生产环境；
  • 轻松通过SOC2框架内的审核 （使服务提供商遵守安全数据管理的要求；了解更多信息，例如， 这里 - 大约。 译）.

发生什么事了吗？

GitOps 有两件事：

  1. Kubernetes 和云原生的运营模型。 它提供了一组用于部署、管理和监控容器化集群和应用程序的最佳实践。 优雅的形式定义 一张幻灯片 从 路易斯·费塞拉:
  2. 创建以开发人员为中心的应用程序管理环境的途径。 我们将Git工作流程应用到运营和开发中。 请注意，这不仅仅是关于 Git 推送，而是关于组织整套 CI/CD 和 UI/UX 工具。

关于 Git 的几句话

如果您不熟悉版本控制系统和基于 Git 的工作流程，我们强烈建议您了解它们。 使用分支和拉取请求乍一看似乎像是黑魔法，但其好处是值得付出努力的。 这里 好文章 一开始。

Kubernetes 的工作原理

在我们的故事中，Alice 和 Bob 在使用 Kubernetes 一段时间后转向了 GitOps。 事实上，GitOps 与 Kubernetes 密切相关——它是基于 Kubernetes 的基础设施和应用程序的运营模型。

Kubernetes 给用户带来了什么？

以下是一些主要特点：

  1. 在 Kubernetes 模型中，一切都可以用声明式的形式描述。
  2. Kubernetes API 服务器将此声明作为输入，然后不断尝试使集群进入声明中描述的状态。
  3. 声明足以描述和管理各种工作负载——“应用程序”。
  4. 因此，应用程序和集群会因以下原因发生更改：
    • 容器镜像的变化；
    • 声明性规范的更改；
    • 环境中的错误 - 例如容器崩溃。

Kubernetes 强大的融合能力

当管理员进行配置更改时，Kubernetes Orchestrator 会将它们应用到集群，只要其状态为 不会接近新配置。 该模型适用于任何 Kubernetes 资源，并且可通过自定义资源定义 (CRD) 进行扩展。 因此，Kubernetes 部署具有以下奇妙的特性：

  • 自动化：Kubernetes 更新提供了一种机制，可以自动、优雅地、及时地应用更改的过程。
  • 收敛：Kubernetes 将继续尝试更新，直到成功。
  • 幂等性：重复应用收敛会导致相同的结果。
  • 决定论：当资源充足时，更新后的集群状态仅取决于期望的状态。

GitOps 的工作原理

我们已经了解了足够多的 Kubernetes 知识来解释 GitOps 的工作原理。

让我们回到 Family Insurance 的微服务团队。 他们通常需要做什么？ 请看下面的列表（如果其中有任何项目看起来很奇怪或不熟悉，请不要批评并继续关注我们）。 这些只是基于 Jenkins 的工作流程的示例。 使用其他工具时还有许多其他流程。

最主要的是我们看到每次更新都会对配置文件和 Git 存储库进行更改。 对 Git 的这些更改会导致“GitOps 操作员”更新集群：

1.工作流程：》Jenkins 构建 - 主分支“。
任务列表：

  • Jenkins 将标记的图像推送到 Quay；
  • Jenkins将配置和Helm图表推送到主存储桶；
  • 云功能将主存储桶中的配置和图表复制到主Git存储库中；
  • GitOps 操作员更新集群。

2. Jenkins 构建 - 发布或修补程序分支:

  • Jenkins 将未标记的图像推送到 Quay；
  • Jenkins 将配置和 Helm 图表推送到暂存存储桶；
  • 云功能将配置和图表从暂存存储桶复制到暂存 Git 存储库；
  • GitOps 操作员更新集群。

3. Jenkins 构建 - 开发或功能分支:

  • Jenkins 将未标记的图像推送到 Quay；
  • Jenkins 将配置和 Helm 图表推送到开发存储桶中；
  • 云功能将开发存储桶中的配置和图表复制到开发Git存储库中；
  • GitOps 操作员更新集群。

4. 添加新客户:

  • 经理或管理员 (LCM/ops) 调用 Gradle 来初始部署和配置网络负载均衡器 (NLB)；
  • LCM/ops 提交新配置以准备更新部署；
  • GitOps 操作员更新集群。

GitOps 简要描述

  1. 使用每个环境的声明性规范来描述整个系统的所需状态（在我们的故事中，Bob 的团队在 Git 中定义了整个系统配置）。
    • Git 存储库是有关整个系统所需状态的唯一事实来源。
    • 对所需状态的所有更改都是通过 Git 中的提交进行的。
    • 所有所需的集群参数也可以在集群本身中观察到。 这样我们就可以判断它们是否重合（收敛， 汇集）或不同（发散， 偏离）期望的和观察到的状态。
  2. 如果期望的状态和观察到的状态不同，则：
    • 有一种收敛机制迟早会自动同步目标状态和观察到的状态。 在集群内部，Kubernetes 执行此操作。
    • 该过程立即开始，并发出“更改已提交”警报。
    • 经过一段可配置的时间后，如果状态不同，则可以发送“差异”警报。
  3. 这样，Git 中的所有提交都会导致对集群进行可验证且幂等的更新。
    • 回滚是收敛到先前期望的状态。
  4. 收敛是最终的。 其发生由以下情况表示：
    • 在一段时间内没有差异警报。
    • “聚合”警报（例如 webhook、Git 写回事件）。

什么是背离？

让我们再重复一遍： 所有所需的集群属性必须在集群本身中是可观察的.

一些背离的例子：

  • 由于合并 Git 中的分支而导致配置文件发生更改。
  • 由于 GUI 客户端进行的 Git 提交而导致配置文件发生更改。
  • 由于 Git 中的 PR，随后构建容器映像并更改配置，对所需状态进行了多次更改。
  • 由于错误、导致“不良行为”的资源冲突或简单地随机偏离原始状态而导致集群状态发生变化。

收敛机制是什么？

几个例子：

  • 对于容器和集群来说，收敛机制是由Kubernetes提供的。
  • 相同的机制可用于管理基于 Kubernetes 的应用程序和设计（例如 Istio 和 Kubeflow）。
  • 提供了管理 Kubernetes、镜像存储库和 Git 之间操作交互的机制 GitOps 操作员 Weave Flux，这是一部分 织云.
  • 对于基础机器，收敛机制必须是声明性的和自治的。 根据我们自己的经验，我们可以说 Terraform 最接近这个定义，但仍然需要人类控制。 从这个意义上说，GitOps 扩展了基础设施即代码的传统。

GitOps 将 Git 与 Kubernetes 优秀的融合引擎结合起来，提供了一种利用模型。

GitOps 允许我们说： 只有那些可以描述和观察的系统才能实现自动化和控制.

GitOps 适用于整个云原生堆栈（例如 Terraform 等）

GitOps 不仅仅是 Kubernetes。 我们希望整个系统以声明方式驱动并使用收敛性。 整个系统是指使用 Kubernetes 的环境集合，例如“开发集群 1”、“生产环境”等。每个环境包括机器、集群、应用程序以及提供数据、监控的外部服务的接口等等。

请注意，在这种情况下，Terraform 对于引导问题有多么重要。 Kubernetes 必须部署在某个地方，使用 Terraform 意味着我们可以应用相同的 GitOps 工作流程来创建支撑 Kubernetes 和应用程序的控制层。 这是一个有用的最佳实践。

人们非常关注将 GitOps 概念应用到 Kubernetes 之上的层。 目前，有针对 Istio、Helm、Ksonnet、OpenFaaS 和 Kubeflow 的 GitOps 类型解决方案，以及 Pulumi 等，它们创建了一个用于开发云原生应用程序的层。

Kubernetes CI/CD：GitOps 与其他方法的比较

如前所述，GitOps 包含两件事：

  1. 上面描述的 Kubernetes 和云原生的操作模型。
  2. 通往以开发人员为中心的应用程序管理环境的道路。

对于许多人来说，GitOps 主要是基于 Git 推送的工作流程。 我们也喜欢他。 但这还不是全部：现在让我们看看 CI/CD 管道。

GitOps 为 Kubernetes 提供持续部署 (CD)

GitOps 提供了一种持续部署机制，无需单独的“部署管理系统”。 Kubernetes 会为您完成所有工作。

  • 更新应用程序需要在 Git 中更新。 这是对所需状态的事务更新。 然后，Kubernetes 本身根据更新的描述在集群内完成“部署”。
  • 由于 Kubernetes 工作方式的本质，这些更新是收敛的。 这提供了一种持续部署的机制，其中所有更新都是原子的。
  • 注： 织云 提供集成了 Git 和 Kubernetes 的 GitOps Operator，并允许通过协调集群的所需状态和当前状态来执行 CD。

没有 kubectl 和脚本

您应该避免使用 Kubectl 更新集群，尤其是避免使用脚本对 kubectl 命令进行分组。 相反，借助 GitOps 管道，用户可以通过 Git 更新其 Kubernetes 集群。

好处包括：

  1. 正确的。 一组更新可以被应用、聚合并最终验证，使我们更接近原子部署的目标。 相反，使用脚本并不能提供任何收敛保证（更多内容见下文）。
  2. 安全. 引用 Kelsey Hightower：“将 Kubernetes 集群的访问权限限制为自动化工具和负责调试或维护集群的管理员。” 也可以看看 我的出版物 关于安全和遵守技术规范，以及 关于黑客 Homebrew 的文章 通过从粗心编写的 Jenkins 脚本中窃取凭证。
  3. 用户体验。 Kubectl 公开了相当复杂的 Kubernetes 对象模型的机制。 理想情况下，用户应该在更高的抽象级别与系统交互。 在这里我再次提到凯尔西并推荐观看 这样的简历.

CI 和 CD 的区别

GitOps 改进了现有的 CI/CD 模型。

现代 CI 服务器是一种编排工具。 特别是，它是一个用于编排 CI 管道的工具。 其中包括构建、测试、合并到主干等。CI 服务器自动管理复杂的多步骤管道。 一种常见的诱惑是编写一组 Kubernetes 更新脚本，并将其作为管道的一部分运行，以将更改推送到集群。 事实上，许多专家都是这样做的。 然而，这并不是最佳的，原因如下。

应该使用 CI 将更新推送到主干，并且 Kubernetes 集群应该根据这些更新进行自身更改以在内部管理 CD。 我们称之为 CD 的拉模型，与 CI 推送模型不同。 CD是一部分 运行时编排.

为什么 CI 服务器不应该通过 Kubernetes 中的直接更新进行 CD

不要使用 CI 服务器将 Kubernetes 的直接更新编排为一组 CI 作业。 这就是我们正在讨论的反模式 已经告诉过 在你的博客上。

让我们回到爱丽丝和鲍勃。

他们遇到了什么问题？ Bob 的 CI 服务器将更改应用到集群，但如果在此过程中崩溃，Bob 将不知道集群处于（或应该）处于什么状态，也不知道如何修复它。 成功的情况也是如此。

我们假设 Bob 的团队构建了一个新映像，然后修补了他们的部署以部署该映像（全部来自 CI 管道）。

如果图像构建正常，但管道失败，团队将必须弄清楚：

  • 更新已经推出了吗？
  • 我们要推出新版本吗？ 这是否会导致不必要的副作用——可能会产生同一个不可变图像的两个版本？
  • 我们应该在运行构建之前等待下一次更新吗？
  • 究竟出了什么问题？ 哪些步骤需要重复（哪些步骤可以安全重复）？

建立基于 Git 的工作流程并不能保证 Bob 的团队不会遇到这些问题。 他们仍然可能在提交推送、标签或其他一些参数方面犯错误； 然而，这种方法仍然更接近于明确的“全有或全无”方法。

总而言之，这就是 CI 服务器不应该处理 CD 的原因：

  • 更新脚本并不总是确定性的； 他们很容易犯错误。
  • CI 服务器不收敛于声明式集群模型。
  • 很难保证幂等性。 用户必须理解系统的深层语义。
  • 从部分故障中恢复更加困难。

关于 Helm 的注意事项：如果您想使用 Helm，我们建议将其与 GitOps 操作符结合使用，例如 通量头盔。 这将有助于确保收敛。 Helm 本身既不是确定性的也不是原子性的。

GitOps 是实现 Kubernetes 持续交付的最佳方式

Alice 和 Bob 的团队实施了 GitOps，发现使用软件产品、保持高性能和稳定性变得更加容易。 让我们用一张插图来结束这篇文章，展示他们的新方法是什么样子的。 请记住，我们主要讨论的是应用程序和服务，但 GitOps 可用于管理整个平台。

Kubernetes 的运营模型

看下图。 它将 Git 和容器镜像存储库呈现为两个精心安排的生命周期的共享资源：

  • 一个持续集成管道，用于读取文件并将其写入 Git，并可以更新容器映像存储库。
  • 将部署与管理和可观察性相结合的运行时 GitOps 管道。 它可以读取文件并将其写入 Git，并且可以下载容器映像。

主要发现是什么？

  1. 关注点分离：请注意，两个管道只能通过更新 Git 或镜像存储库进行通信。 换句话说，CI和运行时环境之间有一道防火墙。 我们称之为“不变性防火墙” （不变性防火墙），因为所有存储库更新都会创建新版本。 有关此主题的更多信息，请参阅幻灯片 72-87 这个演示文稿.
  2. 您可以使用任何 CI 和 Git 服务器：GitOps 可与任何组件配合使用。 您可以继续使用您最喜欢的 CI 和 Git 服务器、图像存储库和测试套件。 市场上几乎所有其他持续交付工具都需要自己的 CI/Git 服务器或图像存储库。 这或许会成为云原生发展的限制因素。 通过 GitOps，您可以使用熟悉的工具。
  3. 事件作为集成工具：一旦 Git 中的数据更新，Weave Flux（或 Weave Cloud 运算符）就会通知运行时。 每当 Kubernetes 接受更改集时，Git 就会更新。 这提供了一个简单的集成模型来组织 GitOps 的工作流程，如下所示。

结论

GitOps 提供任何现代 CI/CD 工具所需的强大更新保证：

  • 自动化;
  • 收敛;
  • 幂等性；
  • 决定论。

这很重要，因为它为云原生开发人员提供了一个操作模型。

  • 用于管理和监控系统的传统工具与在运行手册中操作的运营团队相关​​联 （一组例行程序和操作 - 大约翻译），与特定部署相关。
  • 在云原生管理中，可观察性工具是衡量部署结果的最佳方式，以便开发团队能够快速响应。

想象一下，许多集群分散在不同的云中，并且许多服务都有自己的团队和部署计划。 GitOps 提供了一个规模不变的模型来管理所有这些丰富的内容。

译者PS

另请阅读我们的博客：

只有注册用户才能参与调查。 登录拜托

在这两个翻译出现在 Habré 之前，您了解 GitOps 吗？

  • 是的，我知道一切

  • 只是表面上

  • 没有

35 位用户投票。 10 名用户弃权。

来源： habr.com

添加评论