基于云原生交付的模型——GitOps

翻译：https://www.weave.works/technologies/gitops/

概述

您是否听说过GitOps，并想知道它的全部含义？在此页面中，我们将描述GitOps工作流程的原理和模式，以及如何实现它们以在生产中和大规模运行Kubernetes。我们还将描述GitOps与基础架构代码（IAC）配置管理工具之间的区别，当然还会向您展示如何在自己的开发环境中采用GitOps最佳实践。

什么是GitOps？

GitOps是执行Kubernetes集群管理和应用程序交付的一种方式。它通过将Git用作声明性基础结构和应用程序的单一事实来源来工作。通过将Git置于交付管道的中心，开发人员可以发出拉取请求（Pull Request），以加速和简化Kubernetes的应用程序部署和操作任务。

用于构建云本机应用程序的操作模型

GitOps可以归纳为以下两点：

1. Kubernetes和其他云原生技术的运行模型，提供了一组最佳实践，这些最佳实践统一了容器化集群和应用程序的部署，管理和监视。
2. 通往开发人员管理应用程序体验的途径；将端到端CICD管道和git工作流应用于操作和开发。

GitOps的主要优点

当对Git进行更改时，自动交付管道会将更改发布到您的基础架构中。但是GitOps的想法远不止于此–它使用工具将整个应用程序的实际生产状态与源代码控制下的内容进行比较，然后告诉您何时群集与现实世界不符。

通过应用GitOps最佳实践，您的基础架构和应用程序代码都有“真理之源”，从而使开发团队可以提高速度并提高系统可靠性。

应用GitOps最佳实践的好处是深远的，并提供：

1. 提高生产率
   带有集成反馈控制回路的持续部署自动化可加快平均部署时间。您的团队每天可以发送30-100倍的变更，从而将整体开发输出提高2-3倍。
2. 增强的开发人员体验
   推送代码，而不是容器。开发人员可以使用熟悉的工具（如Git）更快地管理Kubernetes的更新和功能，而无需了解Kubernetes的内部。新入职的开发人员可以在几天（而不是几个月）内迅速掌握并提高工作效率。
3. 改进的稳定性
   使用Git工作流管理集群时，您会自动获得一个便捷的审核日志，其中包含Kubernetes以外的所有集群更改。谁执行了什么操作以及何时对群集执行了审核跟踪可用于满足SOC 2合规性并确保稳定性。
4. 更高的可靠性
   借助Git的还原/回滚和分叉功能，您可以获得稳定且可复制的回滚。因为您的整个系统都在Git中进行了描述，所以您也只有一个真相，崩溃后可以从中恢复，从而将恢复的平均时间（MTTR）从数小时缩短到了数分钟。
5. 一致性和标准化
   由于GitOps提供了一种用于进行基础架构，应用程序和Kubernetes附加更改的模型，因此您在整个组织中拥有一致的端到端工作流。不仅持续的集成和持续的部署流水线都由请求请求驱动，而且您的操作任务也可以通过Git完全重现。
6. 更高的安全性保证
   Git强大的正确性和安全性保证，以用于跟踪和管理更改的强大加密技术为后盾，以及对更改进行签名以证明作者和来源的能力，是安全定义集群所需状态的关键

GitOps是持续交付与Cloud Native相遇

GitOps建立并迭代了从DevOps和Site Reliability Engineering汲取的思想，这些思想始于 2006年Martin Fowler的全面持续集成概述。

自由选择所需的工具

作为CI / CD管道的工作流，GitOps被 描述为开发过程的圣杯。 由于没有单一的工具可以完成CICD管道中所需的所有工作，因此GitOps可以让您自由选择适用于不同零件的最佳工具。您可以从开源生态系统或封闭源中选择一组工具，或者根据您的用例，甚至可以将它们组合在一起。创建CICD管道最困难的部分是将所有部分粘合在一起。

无论您为交付渠道选择什么，将GitOps最佳实践与Git（或任何版本控制）一起应用都应作为流程的组成部分。这样做将使向连续交付的过渡更加容易。不仅从技术角度来看，而且从文化角度来看，都是如此。

---

GitOps：在声明性基础架构之上的CI / CD版本。停止脚本并开始发货。 https://t.co/SgUlHgNrnY-Kelsey Hightower（@kelseyhightower）2018年1月17日

GitOps原理

要开始使用GitOps工作流程管理集群，必须具备以下条件：

＃1 整个系统以声明方式进行描述。

Kubernetes只是许多“声明性”的现代云原生工具的一个示例，可以将其视为代码。声明式意味着配置是由一组事实而不是一组指令来保证的。在Git中对应用程序的声明进行版本控制后，您就有了一个真实的来源。然后，您的应用程序可以轻松部署并在Kubernetes之间回滚。更重要的是，当灾难来袭时，还可以可靠，快速地复制群集的基础架构。

＃2。在Git中规范化了所需的规范系统状态。

将系统声明存储在版本控制系统中，并作为真理的规范来源，您可以在一个地方获取和驱动所有内容。这使回滚变得微不足道；您可以在其中使用“ Git恢复”返回到之前的应用程序状态。借助Git出色的安全性保证，您还可以使用SSH密钥对提交进行签名，以对代码的作者和出处实施强有力的安全性保证。

＃3。批准的更改可以自动应用于系统。

将声明的状态保存在Git中之后，下一步就是允许对该状态的任何更改自动应用于您的系统。重要的是，您不需要群集凭据即可对系统进行更改。使用GitOps，存在一个隔离的环境，状态定义位于外部。这样，您就可以将自己的工作以及如何做分开。

＃4。软件代理可确保正确性并警告差异。

一旦声明了系统状态并将其保持在版本控制之下，只要现实不符合您的期望，软件代理就会通知您。代理的使用还可以确保您的整个系统都能自我修复。通过自我修复，我们不仅意味着节点或容器发生故障（它们由Kubernetes处理），而且从更广泛的意义上讲，例如人为错误。在这种情况下，软件代理将充当您操作的反馈和控制回路。

链接：

• GitOps：通过请求请求进行操作
• GitOps管道-第2部分
• GitOps：所有东西都“ Git Push”（新堆栈）
• Kubernetes的最佳CI / CD工具不存在

Git启用基础架构即代码（IAC）工具

Kubernetes只是许多“声明性”的现代云原生工具的一个示例，可以将其视为代码。声明式意味着配置是由一组事实而不是一组指令来保证的，例如，“有十个Redis服务器”，而不是“启动十个Redis服务器，并告诉我它是否有效”。

使用声明性工具，可以在Git中控制整个配置文件集。通过将Git用作事实来源，您的应用程序可以更轻松地在Kubernetes上部署和回滚。更重要的是，当灾难来袭时，可以从Git可靠，快速地复制群集的基础架构。

IAC工具与GitOps

可以按需配置服务器的基础结构即代码工具已经存在了很长时间。这些工具起源于保持基础结构配置版本化，备份和可从源代码控制复制的概念。

但是现在，随着Kubernetes几乎完全是声明性的，再加上不可变的容器，可以将其中一些概念扩展到管理应用程序及其操作系统。

管理和比较基础架构和应用程序当前状态的能力，使您可以通过Git进行完整的审计跟踪来测试，部署，回滚，前滚，这包含了GitOps的理念及其最佳实践。之所以可能这样做是因为Kubernetes几乎完全通过声明性配置进行管理，并且容器是不可变的。

在Weaveworks，我们使用Terraform和Ansible来配置服务器。我们还将保留这些配置文件的备份并在Git中进行版本控制。如果灾难在Weaveworks发生，IAC工具及其相关的配置文件构成了我们GitOps工作流程的中心部分，可用于近乎即时的群集恢复。在GitOps常见问题解答中了解有关基础结构即代码工具与GitOps有何不同的更多信息 。

如果我的系统与真理的来源背道而驰怎么办？

声明式配置工具可让您在Git中描述所需的真实状态。但是他们遭受的问题是实时系统中现在“真正的真实”，并且可能与源代码控制中描述的有所不同。

• 您如何知道实时系统是否已收敛到所需状态？
• 不同时，您会收到通知吗？
• 当您遇到麻烦时，通知您的“煤矿中的金丝雀”是什么？
• 如何触发群集和源代码控制之间的融合？

这里有现有技术。

IAC工具，例如Chef，Puppet和Ansible支持功能，例如“差异警报”。这些帮助操作员了解何时需要采取措施将实时系统“收敛”到预期状态（由配置脚本定义）。最近，最佳实践是部署不可变的映像（例如容器），以免发生分歧。

在“ GitOps”模型中，我们使用Git来解决发散和收敛问题，并借助一组“差异”和“同步”工具（kubediff， 以及terradiff和ansiblediff）将目标状态与实际状态进行比较。

GitOps建立在不可变的基础架构上

GitOps充分利用了向不变的基础架构和声明性容器编排的转变。我们每天在Weaveworks管理多个部署。为了最大程度地减少部署后变更的风险，无论是有意还是因“配置漂移”而导致的意外事故，至关重要的是，我们必须保持可重复且可靠的部署过程。

我们整个系统的期望状态（又称“真理之源”）在Git中进行了描述。我们使用容器来实现不变性，并使用不同的云原生工具（例如Terraform和Ansible）来自动化和管理我们的配置。这些工具以及容器和Kubernetes的声明性为我们提供了在整个崩溃的情况下进行完全恢复所需的工具。

链接：

• 适用于Kubernetes的GitOps：专注于声明性基础架构的DevOps迭代
• 为什么我们使用Terraform而不使用Chef，Puppet，Ansible，SaltStack或CloudFormation
• 真正的GitOps是什么？

与IAC工具一起使用

当您将GitOps原理应用于“一切”时，包括机器配置，应用程序和服务以及警报规则和仪表板，所有这些都将保持在源代码控制之下。

除了通过Git之外，不需要访问正在运行的系统。可以原子地应用任何更改组，并相应地进行更改。这样，Git记录不仅是审核日志，而且是事务日志，您可以使用它来回滚到任何快照。

链接：

• Weaveworks和AWS；我们如何管理Kubernetes集群
• 生产就绪的Kubernetes集群的供应和生命周期
• GitOps常见问题

Weave Cloud中的持续交付和GitOps工作流程

在我们的产品 Weave Cloud中，GitOps核心机器位于其CI / CD工具中，关键部分是支持Git集群同步的持续部署（CD） 。

Weave Cloud专为版本控制系统和声明性应用程序堆栈而设计。您团队中的每个开发人员都可能熟悉Git，并且可以提出请求。现在，他们还可以使用Git来加速和简化对Kubernetes的应用程序部署。

这是用于创建或更新新功能的典型开发人员工作流程：

1. 对新功能的请求请求已推送到GitHub进行审查。
2. 该守则由同事审查和批准。修改并重新批准代码后，将其合并到Git中。
3. Git合并触发CI和构建管道，运行一系列测试，然后最终构建一个新映像，并将新映像存放到注册表中。
4. Weave Cloud“ Deployment Automator”监视映像注册表，注意到映像，从注册表中提取新映像并在配置库中更新其YAML。
5. Weave Cloud“部署同步器”（已安装到群集）检测到群集已过时。它从配置库中提取更改的清单，并将新功能部署到生产环境。

启用GitOps的CICD管道：

用操作员模式实现的Kubernetes控制器

Weave Cloud实现了一个自定义控制器，以侦听部署并将其同步到您的Kubernetes集群。控制器是使用在两个层次上都很重要的操作员模式实现的。首先，它更安全；以及 其次，它可以自动执行复杂的易于出错的任务，例如必须手动更新YAML清单。

通过使用操作员模式，代理程序可以代表集群来侦听与自定义资源更改有关的事件，以便可以应用它们。该代理负责将Git中的内容与集群中正在运行的内容进行同步，并为您的团队提供了一种实现连续部署的简单方法。

链接：

• Kubernetes运营商模式与替代方案的比较
• 操作员简介：将操作知识纳入软件
• Kubernetes的CI / CD：您需要知道的

拉与推管道

推管道

当今大多数可用的CI / CD工具都使用基于推送的模型。基于推式的管道意味着代码从CI系统开始，并且可以通过一系列编码脚本继续其路径，或者手动使用’kubectl’将任何更改推向Kubernetes集群。

您不想将CI系统用作部署动力或不想在命令行上手动执行此操作的原因是因为可能会将凭据公开到群集之外。虽然可以同时保护CI / CD脚本和命令行，但您在群集的信任域之外工作。这通常不是一个好习惯，这就是为什么CI系统可以称为生产攻击向量的原因。

具有集群外部读写权限的典型推送管道：

在Weave Cloud中，将提取映像并将凭据保留在群集中：

Weave Cloud拉管道

Weave Cloud使用拉动策略，该策略由两个关键组件组成：监视映像注册表的“ Deployment Automator”和位于群集中以维护其状态的“ Deployment Synchronizer”。

拉式管道模式的中心是清单（或配置存储库）的单一事实来源。开发人员将更新后的代码推送到代码库中。CI工具在其中进行更改，并最终构建Docker映像。Weave Cloud“ Deployment Automator”会注意到该映像，从存储库中提取新映像，然后在配置库中更新其YAML。部署同步器，然后检测到集群已过期，然后从配置库中提取更改的清单，并将新映像部署到集群。

将Weave Cloud部署代理安装到您的集群

使用群集内部的部署同步器，您的群集凭据不会在生产环境之外公开。一旦将Weave Cloud代理安装到您的集群并连接了Git存储库后，生产环境中的任何更改都将通过具有完整回滚的Git拉取请求以及Git提供的便捷审核日志来完成。

链接：

• 您的管道有多安全？

可观察性是部署的催化剂

借助Kubernetes，GitOps可以通过请求请求管理基础架构和应用程序部署。但是GitOps工作流程和可观察性如何一起工作？

通过将GitOps工作流程与实时可观察性相结合，您的开发团队可以在部署任何新功能之前做出关键决策。因为在发布之前可以在正在运行的群集中实时观察即将发布的服务，所以这意味着您可以放心部署并更快地交付质量更高的功能。

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

GitOps是一个面向操作和功能的发布模型。您向客户交付新功能的速度有多快，部分取决于您的团队在此周期中能走多快。

一起使用GitOps工作流程和可观察性的开发人员需要回答以下问题：

1. 如果更改自动发布，我们如何知道它确实有效？
2. 我们如何确定我们的变更实际上在推动改进？
3. 在复杂的分布式系统中，我们如何理解问题，诊断问题并处理事件？

借助Weave Cloud，可观察性工作负载仪表板已集成到部署和发布过程中。您一眼就可以看到部署是否成功，然后再将其发布到阶段或生产。这不仅可以帮助您更快地发现问题，而且由于可观察性工作负载仪表板是实时的，并且直接内置在部署过程中，因此您每天可以放心地多次部署服务，并且可以确信部署中没有重大缺陷。

链接：

• GitOps的可观察性
• 使用Prometheus监控Kubernetes

GitOps的好处

发展更快

通过采用GitOps最佳实践，开发人员可以使用Git等熟悉的工具来更快地管理Kubernetes的更新和功能。通过不断推动功能更新，企业将变得更加敏捷，可以更快地响应客户需求，并在市场上更具竞争力。

更好的行动

使用GitOps，您可以获得完整的端到端管道。不仅持续的集成和持续的部署流水线都由请求请求驱动，而且您的操作任务也可以通过Git完全重现。

如果您使用的是Weave Cloud，则还可以安全地对正在运行的群集进行部署，而不会将敏感凭据泄漏到群集之外。

更有力的安全保障

Git强大的正确性和安全性保证，再加上用于跟踪和管理更改的强大加密技术以及对更改进行签名以证明作者和来源的能力，是正确，安全地定义集群所需状态的关键。如果确实发生了安全漏洞，则可以使用不可更改且可审核的真相源来独立于受到破坏的系统来重新创建新系统，从而减少停机时间并提供更好的事件响应。

打包软件之间的责任分离和将其发布到生产环境中还体现了最小特权的安全原理，从而减少了危害的影响并提供了较小的攻击面。

简化合规和审核

由于以安全的方式跟踪和记录更改，因此合规性和审核变得微不足道。使用比较工具（如kubediff，terradiff和ansiblediff）还可以使您将群集状态的可信定义与实际运行的群集进行比较，以确保跟踪的和可审核的更改与实际情况相匹配。

自己试试吧。

链接：

• GitOps：Kubernetes的高速CICD
• 带有Weave Cloud的GitOps工作流程-教程