GitOps介绍

GitOps的来源

GitOps的概念最早起源于Weavworks的一篇博客 GitOps - Operations by Pull Request。这篇博客描述了Weavworks如何运行完整的基于Kubernetes的SaaS并开发了一套针对云原生部署，管理和监控的最佳实践。

随后，Weavworks又发表了一系列文章来介绍GitOps应用案例和最佳实践，对GitOps进行推广，并且发表一篇新的博客 What’s GitOps Really 重新介绍了 GitOps 的相关概念。

GitOps的概念

GitOps 是一种针对 Kubernetes 集群管理和应用交付的方式。在这种工作模式中，将 Git 作为声明式基础设施和应用的唯一事实来源。通过将 Git 作为交付 Pipeline 的中心，开发者们可以通过创建 pull request 来加速和简化Kubernetes中的应用部署和运维任务。

简单来说，GitOps 是创建云原生应用的 操作模型（Operating model) 。

GitOps 可以被总结成两个方面

1. 是 Kubernetes 和其他云原生应用的操作模型，提供了一组最佳实践，这些最佳实践统一了容器化集群和应用程序的部署，管理和监控。

2. 是一条通向以开发者为中心的管理应用程序之路。GitOps 不仅将 Git 工作流程应用到运维中，也运用到了开发之中。

GitOps的作用

GitOps 为基于 Kubernetes 的应用提供了一个持续部署(Continuous Deployment)机制，使其无需任何单独的部署管理系统，因为 Kubernetes 已经能够替你做好这些工作。

在 GitOps 模式中，对应用进行更新，需要对 Git 仓库进行更新。当 Git 仓库更新后，GitOps Operator 会在集群中触发一个事务性的更新，使集群状态趋近于目标状态。因为Kubernetes 的特性，这些更新是收敛的，这就提供了一种持续部署的机制，并且在其中所有的更新都是原子性的。

GitOps Operator

上面提到，当 Git 仓库更新后，GitOps Operator 会触发集群中的后续操作。我们可以得到，GitOps Operator 是 GitOps 模式实践的关键。

GitOps Operator 会一直监视目标仓库。当目标仓库出现更新时，Operator 就会根据 Git 仓库中的数据对集群进行状态更新，并且会保证这个更新是原子性的，也就是说，如果该状态更新最后不能达到理想状态的话，Operator 会对集群进行回滚至最近的理想状态，这样就保证了我们应用的稳定性。

目前，Weaveworks 官方提供了一个开源的 GitOps Operator, 叫做 Flux.

CI 与 CD 之间是有区别的

现代的 CI 工具是一个编排工具，它能够编排一个 Pipeline，其中包括应用的 build, test, merge 等过程，所以CI 工具可以将复杂的多步骤 Pipeline 自动化。然而，目前关于CD，一个常见的做法就是用脚本编写一系列的 Kubernetes 更新命令，并且把执行这个脚本作为 Pipeline 中的一个 step，从而对集群状态进行更新。事实上很多人这么做，但是其实这么做是不太好的，在 GitOps 模式中，我们推行的是 No kubectl, no script，所有的状态信息都保存在 Git 仓库中，对集群状态的更新只需要由 GitOps Operator来操作。

之所以不建议直接使用脚本在 CI 工具中对集群状态进行更新，有以下几个原因：

• 更新脚本很难保证是正确的，我们可能会犯错误。

• 更新脚本的执行不能保证是原子性的，也就是说执行过程中可能会在某一步失败，使应用达到一个未知的状态。

• 幂等性无法保证。如果脚本中途执行失败，无论是退回到最近的desire state，还是继续更新到新的desire state，都需要运维者深入地去理解目前的状态，花费大量的精力和时间。

基于以上原因，我们说 GitOps 是在 Kubernetes 上进行持续部署(Continuous Deployment) 最好的方式。

Reference

What is GitOps really?

Flux