原文地址：https://www.weave.works/technologies/gitops

什么是GitOps？

GitOps是一种进行Kubernetes集群管理和应用程序交付的方法。通过使用Git作为声明性基础设施和应用程序的单一真实来源。由于Git是交付流水线的中心，开发人员可以向Kubernetes发出pull请求，以加速和简化应用程序部署和操作任务。

构建云原生应用程序的操作模型
GitOps可以概括为2点：

1. Kubernetes和其他云原生技术的操作模型，提供了一组最佳实践，统一了对容器化集群和应用程序的部署、管理和监控。
2. 开发人员管理应用程序的经验;其中端到端CICD流水线和Git工作流应用于操作和开发。

主要优点

当对Git进行变更时，自动交付流水线将对你的基础设施进行更改。但是GitOps的思想远不止于此——它使用工具将整个应用程序的实际生产状态与源代码控制下的状态进行比较，然后告诉你何时你的集群与现实世界不匹配。

通过应用GitOps最佳实践，你的基础结构和应用程序代码都有了“真实的来源”，允许开发团队提高速度并提高系统可靠性。

应用GitOps最佳实践的好处是深远的:

提高了生产率

具有集成反馈控制循环的持续部署自动化加速了平均部署时间。你的团队每天可以交付30-100倍的变更，从而将整体开发产出提高2-3倍。

加强开发人员的经验

推动代码而不是容器。开发人员可以使用熟悉的工具(如Git)来更快地管理Kubernetes的更新和特性，而不必了解Kubernetes的内部结构。新加入的开发人员可以很快跟上进度，并且在几天内而不是几个月内就能提高生产力。

提高稳定性

当你使用Git工作流管理你的集群时，你将自动获得一个方便的审计日志，其中记录了Kubernetes之外的所有集群更改。对谁做了什么以及何时对你的集群进行审计的跟踪可用于满足SOC 2遵从性并确保稳定性。

更高的可靠性

使用Git的revert、rollback和fork功能，你可以获得稳定的、可重复的回滚。因为你的整个系统是用Git描述的，所以你也有一个单一的事实来源，可以根据它在系统崩溃后进行恢复，从而将恢复(MTTR)的时间从几小时减少到几分钟。

一致性和标准化

因为GitOps为基础设施、应用程序和Kubernetes插件的变更提供了一个模型，所以你在整个组织中拥有一致的端到端工作流。不仅你的持续集成和持续部署流水线都是由pull request驱动的，而且你的操作任务也可以通过Git完全复制。

强大的安全保障

Git强大的正确性和安全性保证，加上用于跟踪和管理更改的强大加密技术，以及对变更进行签名以证明作者和来源的能力，这些都是安全定义集群所需状态的关键。

GitOps是持续交付与Cloud Native的碰撞

GitOps构建和迭代来自DevOps和站点可靠性工程的思想，这些思想始于Martin Fowler在2006年的全面持续集成概述。

自由选择所需的工具
作为CI/CD流水线的工作流程，GitOps被描述为开发过程中的圣杯。因为没有一种工具可以完成CICD流水线中所需的所有工作，所以GitOps允许你自由地为不同的部分选择最好的工具。你可以从开源代码生态系统或闭源代码中选择一组工具，或者根据你的用例，你甚至可以组合它们。创建CICD流水线最困难的部分是将所有部分结合在一起。

无论你为你的交付流水线选择什么，应用GitOps与Git(或任何版本控制)的最佳实践都应该是你的流程中必不可少的一部分。这样做将使向持续交付的过渡更加容易。这不仅从技术角度是正确的，而且从文化角度也是正确的。

GitOps的原则

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

以声明方式描述的整个系统

Kubernetes只是许多现代云原生工具中的一个例子，这些工具是“声明性的”，可以当作代码来对待。声明性意味着由一组事实而不是一组指令来保证配置。在Git中对应用程序的声明进行了版本控制之后，你就有了一个单一的事实来源。你的应用程序可以很容易的在Kubernetes中部署和回滚。更重要的是，当灾难发生时，集群的基础设施也可以可靠且快速地复制。

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

通过将系统声明存储在版本控制系统中，并将其作为权威的真相来源，你就有了一个单独的地方，所有的东西都是从这里派生和驱动的。这使回滚变得微不足道； 你可以在其中使用“Git revert”功能返回到先前的应用程序状态。 借助Git出色的安全性保证，你还可以使用SSH密钥来签署提交，从而对代码的作者和出处实施强有力的安全性保证。

批准的变更可以自动应用于系统中

一旦声明的状态保存在Git中，下一步就是允许对该状态的任何变更自动应用到系统中。重要的是，你不需要集群凭据来更改系统。有了GitOps，就有了一个隔离的环境，其中状态定义位于外部。这样你就可以把你要做的事情和你要怎么做它们区分开来。

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

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

Git支持基础架构即代码（IAC）

Kubernetes只是许多现代云原生工具的一个例子，这些工具是“声明式的”，可以当作代码来对待。声明性意味着配置由一组事实而不是一组指令来保证，例如，“有10台redis服务器”，而不是“启动10台redis服务器，然后告诉我它是否工作”。

使用声明式工具，可以在Git中对整个配置文件集进行版本控制。通过使用Git作为真相的来源，你的应用程序更容易在Kubernetes中部署和回滚。更重要的是，当灾难发生时，集群的基础设施可以可靠且快速地从Git复制所有内容。

IAC tools vs GitOps

基础设施作为能够按需提供服务器的代码工具已经存在很长一段时间了。这些工具提出了保持基础设施配置版本化、备份和可从源代码控制复制的概念。

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

管理和比较你的基础设施和应用程序的当前状态的能力，以便你可以测试、部署、回滚、前滚，并使用完整的审计跟踪(全部来自Git)，这正是GitOps哲学及其最佳实践的核心所在。这是可能的，因为Kubernetes几乎完全通过声明式配置进行管理，而且容器是不可变的。

如果我的系统偏离了真理来源呢?

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

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

这里有现有技术。IAC工具，例如Chef，Puppet和Ansible支持的功能，例如“差异警报”。这些帮助运维人员了解何时需要采取措施将实时系统“收敛”到预期状态（由配置脚本定义）。 最近，最佳实践是部署不可变的镜像（例如容器），以免发生分歧。
在“ GitOps”模型中，我们使用Git来解决发散和收敛问题，并借助一组“差异”和“同步”工具（kubediff，以及terradiff和ansiblediff），将预期状态与实际状态进行比较。

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

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

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

与IAC工具一起使用
当你将GitOps原理应用于“一切”时，包括机器配置，应用程序和服务以及告警规则和仪表板，所有这些都将受到源代码控制。

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

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

GitOps核心机器位于其CI / CD工具中，关键部分是支持Git群集同步的连续部署（CD）。 Weave Cloud专为版本控制系统和声明性应用程序栈而设计。 你团队中的每个开发人员都可能熟悉Git，并且可以提出pull request。 现在，他们还可以使用Git来加速和简化对Kubernetes的应用程序部署。

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

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

用Operator pattern实现的Kubernetes控制器

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

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

Pull vs Push 流水线

Push流水线
目前提供的大多数CI/CD工具都使用基于push的模式。基于push的流水线意味着代码从CI系统开始，并可以通过一系列编码脚本继续其路径，或者手动使用“kubectl”将任何更改推送到Kubernetes集群。
不想将CI系统用作部署推动力或在命令行上手动执行此操作的原因是，可能会在集群外部公开凭据。虽然可以保护你的CI/CD脚本和命令行，但你正在集群的信任域之外工作。这通常不是好的实践，这就是为什么CI系统可以被称为生产攻击向量的原因。

具有集群外部读写权限的典型推送流水线

在Weave Cloud中，镜像是拉取的并将凭据保留在群集中

Weave Cloud拉取流水线

Weave Cloud使用的拉动策略包括两个关键组件：一个监视镜像注册表的“Deployment Automator”和一个位于群集中以维护其状态的“Deployment Synchronizer”。
拉取流水线模式的中心是清单（或配置存储库）的单一事实来源。开发人员将更新后的代码推送到代码库中。CI工具在其中进行变更，并最终构建Docker镜像。Weave Cloud“Deployment Automator”会注意到该镜像，从存储库中提取新镜像，然后在配置库中更新其YAML。然后“Deployment Synchronizer”检测到集群已过期，然后从配置库中提取变更的清单，并将新镜像部署到集群。

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

使用群集内部的“Deployment synchronizer”，您的群集凭据不会在生产环境之外公开。 一旦将Weave Cloud代理安装到您的集群并连接了Git存储库后，生产环境中的任何变更都将通过具有完整回滚的Git pull requests以及所有由Git提供的便捷审计日志来完成。

可观察性是部署的催化剂

借助Kubernetes，GitOps可以通过pull requests管理基础架构和应用程序部署。 但是GitOps工作流程和可观察性如何一起工作？
通过将GitOps工作流程与实时可观察性相结合，您的开发团队可以在部署任何新功能之前做出关键决策。 因为在发布之前可以在正在运行的群集中实时观察即将发布的服务，所以这意味着您可以放心部署并更快地交付质量更高的功能。
可观察性可以被视为Kubernetes持续交付周期的主要驱动力之一，因为它描述了在任何给定时间的系统实际运行状态。 观察正在运行的系统是为了理解和控制它。 将新功能和修复推送到git并触发部署流水线，并且可以在运行中的集群上实时观察何时准备发布。 此时，开发人员可以根据此反馈返回到流水线的开头，或者将镜像部署并发布到生产集群。

GitOps的好处

发展更快

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

更好的行动

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

更有力的安全保障

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

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

简化合规和审核

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