关于后端:GitOps-为什么成为云原生交付的事实标准

3次阅读

共计 3716 个字符，预计需要花费 10 分钟才能阅读完成。

你好，我是王炜。

这节课，我想和你分享一下 GitOps 的历史和倒退过程。

工夫回到 2017 年，一家做 Kubernetes 解决方案的初创公司 Weaveworks 首次提出了 GitOps，在那个 DevOps 流行的年代，GitOps 相对是具备创造性的。Weaveworks 对 GitOps 的定义是：利用云原生工具和云服务进行应用程序部署和治理的最佳实际，定位是 DevOps 的进一步扩大。

除了给出定义，Weaveworks 还开源了 FluxCD。没错，它就是当初和 ArgoCD 竞争的 CNCF 毕业我的项目。它们的作用都是监听 Git 仓库的变动，和集群内的对象进行比照，并主动利用有差别的局部。

不过，须要留神的是，GitOps 并不等于 FluxCD 或者 ArgoCD，它代表的是一种工程实际的办法。那么，为什么这个办法会成为利用交付的事实标准呢？到底要怎么了解 GitOps，相比拟传统的交付过程，它独特的劣势是什么？

首先，咱们须要先了解 GitOps 到底是什么？

依据 Weaveworks 的总结，咱们能够简略地把 GitOps 概括为上面两件事。

它是一种治理模型，也是一种云原生技术，负责为应用程序的部署、治理和监控提供对立的最佳实际。
它提供了一种实现开发者自助公布的门路，对立了开发团队和运维团队。

更进一步，GitOps 为开发者提供了继续部署的规范，它以开发者为核心，为开发者提供基础设施的治理和运维办法。它通过应用开发者曾经相熟的工具，例如 Git 来治理 Kubernetes 集群，实现利用交付。

Git 仓库承当了基础架构和应用程序“繁多事实起源”的职责，通过 Git 仓库，开发者能够应用他们相熟的推送、拉取和 Pull Request 流程来对基础架构和利用进行批改。

不过，任何计划都须要有一个规范，为了建设行业内的 GitOps 规范，由 CNCF 牵头，2020 年 GitOps 工作组成立了，最后的工作组由 Weaveworks、微软、GitHub 和亚马逊等公司组成。作立工作组之后的第一步，他们启动了 OpenGitOps 我的项目，它目前是 CNCF Sandbox 我的项目。

此外，GitOps 工作组还制订了 GitOps 的根本准则，它们别离是：

申明式
版本化和不可变
主动拉取
继续协调

让咱们来别离介绍一下这几个根本准则。

准则一：申明式

申明式是实现 GitOps 的外围根底。在 GitOps 中，所有工具必须是申明式的并将 Git 作为繁多起源，应用程序能够十分不便地部署到 Kubernetes 集群中，最重要的是，当呈现平台级故障时，你的利用能够随时部署到其余的规范平台上。

准则二：版本化和不可变

有了申明式的帮忙，基础设施和利用的版本能够映射为 Git 源码对应的版本，你能够通过 Git Revert 随时进行回滚操作。更重要的是 Git 仓库不会随着工夫的推移呈现版本变动。

准则三：主动拉取

一旦将申明式的状态合并到 Git 仓库中，也就意味着提交会主动利用到集群中。这种部署形式平安且高效，部署过程无需人工干预，因为整个过程是自动化的，且不存在人工运行命令的步骤，这就杜绝了人为谬误的可能性。当然，为了平安起见，你也能够在部署过程退出人工审批环节。

准则四：继续协调

“协调”过程实际上依赖于 FluxCD 或者 ArgoCD 这些控制器，它们会定期主动拉取 Git 仓库并比照它和集群的差别，而后将差别利用到集群中，这样能够确保整个零碎可能进行自我修复。

咱们晓得，当有新的内容提交到 Git 仓库的时候，GitOps 流水线会主动对基础设施和利用进行批改。但实际上，背地的机制比看起来要简单得多。GitOps 工具可能主动对基础设施的状态以及 Git 代码仓库的定义进行比照，而后当状态不统一的时候提醒并主动同步。

总结来说，GitOps 的劣势次要体现在 5 个方面：

晋升公布效率
优化开发者体验
更高的稳定性和可靠性
标准化和一致性
更强的安全性

劣势一：晋升公布效率

GitOps 显著升高了软件公布所须要的工夫。Weaveworks 预计，团队每天的公布次数晋升了 30 到 100 倍，开发效率晋升了 2-3 倍。

劣势二：优化开发者体验

GitOps 流水线蕴含 CI 构建过程，对开发者屏蔽了 Kubernetes 外部简单的工作原理，开发人员只须要相熟 Git 的应用就能够间接管制 Kubernetes 的更新。此外，GitOps 也对老手工程师十分敌对，升高了开发门槛。最初，GitOps 为开发者提供了自助式的公布体验，开发人员能够随时公布和回滚利用。

劣势三：更高的稳定性和可靠性

因为 Git 是惟一可信源，它很容易进行回滚和复原，所以当零碎呈现故障时，开发者只须要对 Git 仓库进行回滚即可，这将零碎复原工夫从几小时缩短到了几分钟。此外，因为每次变更都会产生新的提交，相当于提供了一个审计日志，它具体记录了谁在什么时候对系统进行了什么批改，有助于日后追溯操作记录。

劣势四：标准化和一致性

借助申明式和 Kubernetes，Git 仓库定义的对象都是标准化的，它人造反对不同的云厂商，当咱们须要在其余云厂商重建环境时，只须要批改部署的指标集群即可。此外，GitOps 流水线对组织的所有团队来说都是统一的，这能够防止不同的小组在实现雷同的部署需要时反复造轮子。

劣势五：更强的安全性

因为 GitOps 借助 Git 来存储规范的定义文件，而 Git 的安全性又十分好，所以 GitOps 的存储过程也是平安的。此外，在开发者侧，并不会间接接触到基础设施的凭据，所以，相比拟传统的公布过程，GitOps 具备更高的安全性。

GitOps 之所以能成为云原生利用交付的规范，除了上述 5 大劣势以外，还因为它给现有的 DevOps 利用交付模式带来了微小改革。

这里所说的变革性影响次要包含上面几个方面。

将利用交付从推模式转变为了拉模式。
补充了 Infra As Code（基础设施即代码）的有余。
逐步取代了 DevOps 的地位。

接下来咱们具体介绍一下这几个方面。

在 DevOps 主导的利用交付过程中，CD 工具往往须要在 CI 流水线执行实现之后才会启动。在这个过程中，CD 工具须要具备集群的拜访权限。而在 GitOps 的流程中，当有新的变更提交到 Git 仓库时，集群内的 GitOps 工具会主动比照差别并执行变更。

那为什么利用交付从推模式变成了拉模式就产生了如此微小的差别呢？

在推模式下，CI 或者 CD 批改集群对象时，它须要在集群内部获得集群的凭据，这是十分不平安的做法。此外，推模式下的部署过程往往是命令式的，例如通过 kubectl apply 来执行变更，因为短少“协调”的过程，在变更过程中该行为并不是原子性的。

而 GitOps 通过 Operator 在集群内实现了拉的模式，在解决凭据平安问题的同时，也退出了“协调”过程，这个过程就像是一个一直运行的监视器，一直拉取仓库变更并比照差别，这一切都是在集群内实现的。

出于安全性和原子性思考，利用交付从推模式正逐步被拉模式取代。

以 Terraform 为代表的基础设施即代码取得了微小的胜利，它将以往须要通过命令式的操作变成了 HCL 申明式的配置形式。GitOps 继承了这个思维，在 GitOps 流程中，不仅可能通过申明式的形式定义基础设施，而且还能够定义利用的交付形式，补救了基础设施即代码在定义交付形式时的有余。

尽管 DevOps 比 GitOps 反对更宽泛的应用程序模型，但随着容器化和 Kubernetes 技术的遍及，DevOps 的劣势曾经不这么显著了。

其次，随着云原生技术的倒退，DevOps 的工具链曾经逐步落后于 Kubernetes 的生态系统。GitOps 的工具链相对来说更加轻量，也更合乎云原生疾速倒退的规范。

尽管 DevOps 和 GitOps 并不是齐全独立的，它们有许多独特的指标。但随着云原生的遍及，GitOps 和 Kubernetes 的组合注定会成为新的工程实际形式。而随着 GitOps 在开发者群体中的认可度越来越高，DevOps 很可能会淡出开发者的技术选型。

最初，我来总结一下。这节课，我带你学习了 GitOps 的实践根底，例如什么是 GitOps、GitOps 的 4 个准则及其劣势，以及 GitOps 为什么会成为交付规范的几大起因。

从 GitOps 工作组制订的准则咱们能够得出结论，最罕用的 GitOps 工具 FluxCD 和 ArgoCD 都是基于雷同的理念来构建的。至于 GitOps 的劣势，通过之前的实战我置信你曾经感触到了它的弱小之处。

此外，GitOps 之所以能成为云原生交付的事实标准，我集体认为除了文中提到的三个起因以外，还有一个十分重要的起因是云原生技术特地是容器化和 Kubernetes 技术逐步成为了行业的规范。在这种状况下，旧的 CI/CD 工具也显现出了效率低和适配性不够强的问题，社区迫切需要更好的利用交付体验，这就为 GitOps 的遍及提供了更多的可能性。

总的来说，GitOps 排汇了 DevOps 的劣势，同时也借鉴了 SRE（网站可靠性）的思维，给咱们带来了颠覆式的利用交付体验。

文章起源：极客工夫《云原生架构与 GitOps 实战》

正文完