Geekly articles weekly

什么是GitOps？

注意事项 佩雷夫 ：最近发布了有关GitOps中的推拉方法的材料之后，我们整体上对这种模型很感兴趣，但是，关于该主题的俄文出版物很少（他们根本不在中心）。 因此，我们很高兴引起您的注意，尽管差不多一年前，但另一篇文章的翻译！ -来自Weaveworks公司，该公司的负责人创造了“ GitOps”一词。 文本解释了该方法的本质以及与现有方法的主要区别。



一年前，我们发布了GitOps简介 。 然后，我们讨论了Weaveworks团队如何启动基于Kubernetes的SaaS，并开发了一套规范性的最佳实践，用于在云原生环境中进行部署，管理和监视。

这篇文章很受欢迎。 其他人开始谈论GitOps，开始发布用于git push ， 开发 ， 秘密 ， 功能 ， 持续集成等的新工具。 GitOps的大量出版物和用例已经出现在我们的网站上。 但是有些人仍然有疑问。 该模型与传统基础架构在代码和连续交付方面有何不同？ 使用Kubernetes是强制性的吗？

很快，我们意识到需要一个新的描述，其中包括：

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

在本文中，我们试图涵盖所有这些主题。 在其中，您将找到有关GitOps的更新介绍，并从开发人员和CI / CD的角度对其进行研究。 尽管该模型可以推广，但我们主要关注Kubernetes。

认识GitOps


想象一下爱丽丝。 她经营家庭保险公司（Family Insurance），该公司为忙于无法独自理解合同细微差别的人们提供医疗，汽车，房地产和旅行保险。 当爱丽丝（Alice）在该银行担任数据科学家时，她的业务始于一项附属项目。 一旦她意识到可以使用高级计算机算法来更有效地分析数据并形成保险包。 投资者为该项目提供了资金，现在她的公司每年带来超过2000万美元的收入，并且发展迅速。 目前，有180人在其中担任不同职务。 其中，一个技术团队负责开发，维护站点，数据库并分析客户群。 该公司的技术总监Bob领导一个60人的团队。

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

家庭保险公司不打算使用容器，但是感染了对Docker的热情。 不久，公司专家发现GKE使部署集群以测试新功能变得容易。 添加了用于CI和Quay的Jenkins以组织容器注册表，并编写了用于Jenkins的脚本，这些脚本在GKE中推送或新的容器和配置。

一段时间过去了。 爱丽丝和鲍勃对所选方法的效果及其对业务的影响感到失望。 引入容器并没有像团队希望的那样提高生产率。 有时部署会中断，目前尚不清楚是否应归咎于代码更改。 事实证明，跟踪配置更改也很困难。 通常，有必要创建一个新集群并将应用程序移入其中，因为这是消除系统陷入困境的最简单方法。 Alice担心随着应用程序的开发，情况会恶化（此外，正在酝酿一个基于机器学习的新项目）。 鲍勃将大部分工作自动化了，却不明白为什么管道仍然不稳定，伸缩性不好并且需要时常进行人工干预？

然后他们了解了GitOps。 事实证明，这一决定正是他们自信地前进的必要条件。

多年来，Alice和Bob听说过基于Git，DevOps和基础架构作为代码的工作流。 GitOps的独特之处在于，它带来了许多最佳实践（分类和规范），以在Kubernetes的背景下实现这些想法。 这个话题已经被反复提出 ，包括在Weaveworks博客上 。

家庭保险决定实施GitOps。 该公司现在拥​​有与Kubernetes兼容的自动化操作模型，该模型结合了速度和稳定性 ，因为它们：

  • 发现团队的工作效率提高了一倍，没有人发疯；
  • 停止服务脚本。 相反，他们现在可以专注于新功能并改进工程方法-例如，引入金​​丝雀推出并改善测试；
  • 改进了部署过程-现在很少中断；
  • 有机会在部分故障后无需手动干预即可恢复部署；
  • 对供应系统有了更大的信心。 爱丽丝（Alice）和鲍勃（Bob）发现，该团队可以分为在微服务中工作和并行工作的小组。
  • 在每个小组的努力下，每天可以对项目进行30-50次更改，并尝试新技术；
  • 他们很容易被新开发人员吸引到项目中，他们能够在几个小时内使用拉取请求对生产进行更新。
  • 可以轻松地在SOC2中进行审核（以确保服务提供商符合对安全数据管理的要求；例如， 在此处了解更多-大约翻译） 。

发生什么事了


GitOps有两件事：

  1. Kubernetes和Cloud Native的运营模型。 它提供了一组用于部署，管理和监视容器化集群和应用程序的最佳实践。 Luis Faceira的一张幻灯片中的优雅定义：

  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的工作原理。

让我们回到与微服务有关的家庭保险团队。 他们通常需要做什么？ 请查看下面的列表（如果其中有任何问题似乎很陌生或不熟悉，请推迟批评并与我们在一起）。 这些只是基于Jenkins的工作流的示例。 使用其他工具时，还有许多其他过程。

最主要的是，我们看到每次更新都以对配置文件和Git存储库的更改结束。 Git中的这些更改导致“ GitOps语句”更新集群：

1.工作流程：“ Jenkins Build-master分支 ”。
任务清单：

  • 詹金斯（Jenkins）将标记的图片推送到码头；
  • Jenkins将“ it”配置和Helm图表推入主存储桶；
  • 云功能将配置和图表从主存储桶复制到主git存储库；
  • GitOps语句更新集群。

2. Jenkins build-release或hotfix分支 ：

  • 詹金斯（Jenkins）将“未加标签的图像”推入码头；
  • Jenkins将config和Helm图表推到暂存存储区。
  • 云功能将配置和图表从分段存储的存储桶复制到Git存储库分段；
  • GitOps语句更新集群。

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

  • 詹金斯（Jenkins）将“未加标签的图像”推入码头；
  • 詹金斯（Jenkins）将config和Helm图推到开发存储桶中。
  • 云功能将配置和图表从开发存储桶复制到开发git存储库；
  • GitOps语句更新集群。

4. 添加一个新客户端 ：

  • 经理或管理员（LCM / ops）呼叫Gradle最初部署和配置网络负载平衡器（NLB）；
  • LCM / ops提交新的配置以准备部署更新。
  • GitOps语句更新集群。

GitOps的简短说明


  1. 使用每种环境的声明性规范描述整个系统的期望状态（在我们的历史中，Bob团队在Git中定义了整个系统配置）。

    • git存储库是有关整个系统所需状态的唯一事实来源。
    • 对所需状态的所有更改都是通过Git中的提交进行的。
    • 所有所需的群集参数也可以在群集本身中观察到。 因此，我们可以确定期望状态和观察状态是否重合（converge， converge ）或相异 （ diverge ， diverge ）。
  2. 如果期望状态和观察到的状态不同，则：

    • 有一种收敛机制，迟早会自动同步目标状态和观察到的状态。 在集群内部，Kubernetes会执行此操作。
    • 该过程立即以“更改已提交”通知开始。
    • 经过一段可配置的时间后，如果状态不同，则可以发送差异警报。
  3. 因此，Git中的所有提交都会触发集群中可验证的幂等更新。

    • 回滚是收敛到先前期望的状态。
  4. 收敛是最终的。 关于其发病证明：

    • 一段时间内缺乏“差异”警报。
    • 聚合警报（例如，webhook，Git写回事件）。

什么是分歧？


我们再次重复： 群集的所有所需属性应在群集本身中可见 。

分歧的一些例子：

  • 由于在Git中合并了分支，因此配置文件中的更改。
  • 由于GUI客户端在Git中进行的提交，导致配置文件中的更改。
  • 由于Git中的PR以及后续容器图像的组装以及对配置的更改，期望状态发生了多次更改。
  • 由于错误，导致“不良行为”的资源冲突或只是与原始状态的意外偏离而导致的群集状态更改。

什么是收敛机制？


一些例子：

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

GitOps将Git与Kubernetes的出色收敛引擎结合在一起，提供了操作模型。

GitOps允许我们声明只有可以描述和观察的系统才可以自动化和控制 。

GitOps适用于整个云本机堆栈（例如Terraform等）


GitOps不仅是Kubernetes。 我们希望对整个系统进行声明式管理并使用收敛。 对于整个系统，我们指的是一组与Kubernetes一起使用的环境，例如“开发集群1”，“生产”等。每个环境都包括机器，集群，应用程序以及用于提供数据，监控和维护的外部服务的接口。等

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

人们非常关注将GitOps概念应用于Kubernetes上的各个层。 当前，有针对Istio，Helm，Ksonnet，OpenFaaS和Kubeflow以及例如Pulumi的GitOps类型的解决方案，这些解决方案创建了一个层来开发用于云原生的应用程序。

Kubernetes CI / CD：将GitOps与其他方法进行比较


如前所述，GitOps有两件事：

  1. 上述Kubernetes和Cloud Native的运营模型。
  2. 组织以开发人员为中心的应用程序管理环境的路​​径。

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

GitOps为Kubernetes提供持续部署（CD）


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

  • 更新应用程序需要在Git中进行更新。 这是到所需状态的事务性升级。 然后，Kubernetes会根据更新的说明在集群内执行“部署”。
  • 由于Kubernetes的特性，这些更新是收敛的。 这提供了一种连续部署的机制，其中所有更新都是原子的。
  • 注意： Weave Cloud提供了一个GitOps运算符，该运算符集成了Git和Kubernetes，并允许您通过匹配集群的期望状态和当前状态来运行CD。

没有kubectl和脚本


避免使用Kubectl升级群集，尤其是使用脚本对kubectl命令进行分组。 相反，使用GitOps管道，用户可以通过Git升级其Kubernetes集群。

好处包括：

  1. 正确性 。 可以应用，融合并最终验证一组更新，这使我们更接近原子部署的目标。 相反，脚本的使用并不能保证任何收敛性（更多内容请参见下文）。
  2. 安全性 引用 Kelsey Hightower的话：“将Kubernetes集群的访问权限限制为负责调试或维护它的自动化工具和管理员。” 另请参阅我关于安全性和合规性的出版物 ，以及有关通过从粗心的Jenkins脚本中窃取凭据来破解Homebrew的文章 。
  3. 用户体验 。 Kubectl揭示了非常复杂的Kubernetes对象模型的机制。 理想情况下，用户应在更高的抽象级别上与系统进行交互。 在这里，我将再次提及Kelsey，并建议您查看这样的简历 。

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' , . - push' , - ; --.

, CI- CD:

  • ; .
  • CI- .
  • . .
  • .

Helm'e: Helm, GitOps-, Flux-Helm . . Helm , .

GitOps Continuous Delivery Kubernetes


GitOps , , . , , . , , GitOps .

Kubernetes


. Git :

  • , Git .
  • Runtime GitOps, . Git .



?


  1. : , , Git . , CI runtime-. « » (immutability firewall) , . 72-87 .
  2. CI- Git- : GitOps . CI- Git-, . Continuous Delivery CI-/Git- . cloud native. GitOps .
  3. : Git , Weave Flux ( Weave Cloud) runtime. , Kubernetes , Git . GitOps, .



结论


GitOps , CI/CD:

  • ;
  • ;
  • ;
  • .

, cloud native.

  • , runbook' ( — . .) , deployment'.
  • cloud native- , .

, . GitOps - .

译者的PS


另请参阅我们的博客：

Source: https://habr.com/ru/post/zh-CN458878/

More articles:


All Articles