GitOps 与Devops

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

除了给出定义，Weaveworks 还开源了 FluxCD。没错，它就是现在和 ArgoCD 竞争的 CNCF 毕业项目。它们的作用都是监听 Git 仓库的变化，和集群内的对象进行对比，并自动应用有差异的部分。

不过，需要注意的是，GitOps 并不等于 FluxCD 或者 ArgoCD，它代表的是一种工程实践的方法。那么，为什么这个方法会成为应用交付的事实标准呢？到底要怎么理解 GitOps，相比较传统的交付过程，它独特的优势是什么？

首先，我们需要先理解 GitOps 到底是什么？

1 GitOps 是什么？

通过git实现版本控制和k8s集群管理
根据 Weaveworks 的总结，我们可以简单地把 GitOps 概括为下面两件事。

它是一种管理模型，也是一种云原生技术，负责为应用程序的部署、管理和监控提供统一的最佳实践。
它提供了一种实现开发者自助发布的路径，统一了开发团队和运维团队。
更进一步，GitOps 为开发者提供了持续部署的标准，它以开发者为中心，为开发者提供基础设施的管理和运维方法。它通过使用开发者已经熟悉的工具，例如 Git 来管理 Kubernetes 集群，实现应用交付。

Git 仓库承担了基础架构和应用程序“单一事实来源”的职责，通过 Git 仓库，开发者可以使用他们熟悉的推送、拉取和 Pull Request 流程来对基础架构和应用进行修改。

CI(持续集成)：目标是测试构建及推送。gitlab仓库采用gtilab CI工具；gitHub仓库采用的gitHub Action工具，

CD(持续部署)：Flux CD 及 Argo CD工具

2 GitOps 的 4 个原则

GitOps 工作组还制定了 GitOps 的基本原则，它们分别是：

声明式
版本化和不可变
自动拉取
持续协调
让我们来分别介绍一下这几个基本原则。

原则一：声明式

声明式是实现 GitOps 的核心基础。在 GitOps 中，所有工具必须是声明式的并将 Git 作为单一来源，应用程序可以非常方便地部署到 Kubernetes 集群中，最重要的是，当出现平台级故障时，你的应用可以随时部署到其他的标准平台上。

原则二：版本化和不可变

有了声明式的帮助，基础设施和应用的版本可以映射为 Git 源码对应的版本，你可以通过 Git Revert 随时进行回滚操作。更重要的是 Git 仓库不会随着时间的推移出现版本变化。

原则三：自动拉取

一旦将声明式的状态合并到 Git 仓库中，也就意味着提交会自动应用到集群中。这种部署方式安全且高效，部署过程无需人工干预，由于整个过程是自动化的，且不存在人工运行命令的步骤，这就杜绝了人为错误的可能性。当然，为了安全起见，你也可以在部署过程加入人工审批环节。

原则四：持续协调

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

GitOps 的优势
我们知道，当有新的内容提交到 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 具有更高的安全性。

3 GitOps 与DevOps 区别

（1）将应用交付从推模式转变为了拉模式。
（2）补充了 Infra As Code（基础设施即代码）的不足。
（3）逐渐取代了 DevOps 的位置。

接下来我们详细介绍一下这几个方面。

将应用交付从推模式转变为了拉模式
在 DevOps 主导的应用交付过程中，CD 工具往往需要在 CI 流水线执行完成之后才会启动。在这个过程中，CD 工具需要具有集群的访问权限。而在 GitOps 的流程中，当有新的变更提交到 Git 仓库时，集群内的 GitOps 工具会自动对比差异并执行变更。

那为什么应用交付从推模式变成了拉模式就产生了如此巨大的差异呢？

在推模式下，CI 或者 CD 修改集群对象时，它需要在集群外部取得集群的凭据，这是非常不安全的做法。此外，推模式下的部署过程往往是命令式的，例如通过 kubectl apply 来执行变更，由于缺少“协调”的过程，在变更过程中该行为并不是原子性的。

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

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

补充了基础设施即代码的不足
以 Terraform 为代表的基础设施即代码获得了巨大的成功，它将以往需要通过命令式的操作变成了 HCL 声明式的配置方式。GitOps 继承了这个思想，在 GitOps 流程中，不仅能够通过声明式的方式定义基础设施，而且还可以定义应用的交付方式，弥补了基础设施即代码在定义交付方式时的不足。

逐渐取代了 DevOps 的位置
虽然 DevOps 比 GitOps 支持更广泛的应用程序模型，但随着容器化和 Kubernetes 技术的普及，DevOps 的优势已经不这么明显了。

其次，随着云原生技术的发展，DevOps 的工具链已经逐渐落后于 Kubernetes 的生态系统。GitOps 的工具链相对来说更加轻量，也更符合云原生快速发展的标准。

虽然 DevOps 和 GitOps 并不是完全独立的，它们有许多共同的目标。但随着云原生的普及，GitOps 和 Kubernetes 的组合注定会成为新的工程实践方式。而随着 GitOps 在开发者群体中的认可度越来越高，DevOps 很可能会淡出开发者的技术选型。

4 声明式开发与命令式开发区别

幂等性及集中式配置管理

5 蓝绿发布、金丝雀发布(灰度发布)和滚动发布

滚动发布就是在灰度发布的基础上增加了指标分析，可以实现自动发布及回滚