GitOps：Weaveworks 通过开发者工具实现 CI/CD

在过去的一年中，Weaveworks 团队逐步改进了有关“ GitOps ”实践的想法。“GitOps”是指他们通过开发者工具来推动运营和实现持续交付。

GitOps 是通过使用 Git 分布式版本控制系统（DVCS）作为声明性基础设施和应用程序的单一事实来源来实现的。团队中的每个开发人员都可以向 Git 存储库发出拉取请求，在合并请求时，“diff and sync”工具将检测系统的预期状态和实际状态之间的差异，然后触发工具对基础设施进行更新和同步，使其达到预期状态。

Weaveworks 的创始人兼首席执行官 Alexis Richardson 和 Weaveworks 的社区工程师 Ilya Dmitrichenko 在他们的公司博客上撰写了一系列文章，解释了 GitOps 的概念。在进行 GitOps 实践时，一旦有变更被提交到 Git，自动构建 / 交付管道就会使用“拉模型”来检测和发布对基础设施做出的变更。GitOps 实践并不强制使用特定的工具或产品，它只需要所选工具提供的某些功能（例如“diff and sync”）。

Weaveworks 团队声称，GitOps 可以帮助开发团队提高效率并提高系统的可靠性。他们讨论了如何在团队内部实现 GitOps 来帮助交付他们的产品，以及如何通过他们的 Weave Cloud SaaS 产品为这种方法提供构建模块。Weave Cloud 提供“容器和微服务的部署、监控和管理”，并支持 Git 集群同步。

目前，Weaveworks 使用容器和 Kubernetes 进行部署来实现 GitOps，包括：

• 软件系统中可以被描述为代码的内容都必须存储在 Git 中：通过使用 Git 作为事实的来源，可以观察一个集群的变化，并将其与预期的状态进行比较。目标是描述和对所有内容进行版本控制：策略、代码、配置，甚至是监控事件和仪表盘定义。

• 不应直接使用 Kubernetes CLI 工具（kubectl）：作为一般规则，使用 kubectl 直接部署到集群不是一个好习惯。Weaveworks 团队认为，很多人通过 CI 工具来推动部署，但这样做会阻碍他们实现良好的关注点分离，并且“提供了某种臭名昭著的可以访问生产环境的方式”。

• 使用遵循“操作员模式”的Kubernetes 控制器：通过扩展Kubernetes 提供的功能以及使用遵循操作员模式的自定义控制器，群集可以被配置成始终与基于Git 的“真实来源”保持同步。Weaveworks 团队使用“diff”和“sync”工具（如开源的 kubediff ，内部工具“terradiff”和“ansiblediff”，分别用于 Terraform 和 Ansible）对预期状态与实际状态进行对比。

“拥抱 GitOps 理念和最佳实践”就是通过比较和管理基础设施和应用程序的当前状态，让团队可以使用 Git 日志中的完整审计路径进行测试、部署和回滚。与旧技术相比，现代平台组件让这种方法更加可行，例如，Kubernetes 几乎完全可以通过声明性配置进行管理，并且容器可以相对容易地变为不可变的。

例如，在 Weave Cloud SaaS 平台上，一个用于在应用程序中创建或更新新功能的典型开发者工作流程是这样的：

1. 工程师在新的 Git 分支上开发新功能，并在他们准备好提交代码进行评审时发起拉取请求。
2. 对代码进行评审，添加评论或由同事批准变更。在进行必要的修订之后，批准的拉取请求将被合并到主干或主线分支。
3. Git 合并将触发持续集成（CI）和构建管道，并运行一系列测试。成功完成这些测试后，将构建一个新的容器镜像，并上载到镜像注册表。
4. Weave Cloud 的“Deployment Automator”会监控镜像注册表，一旦发现新映像，就从注册表中拉取它，并更新存储库中包含配置的的相关 YAML 文件。
5. Weave Cloud 的“Deployment Synchronizer”（安装在群集中）会检测到群集状态“已过期”，并从配置存储库中拉取已发生变更的清单，并将新功能部署到生产环境中。

GitOps 管道示例（图像来自 Weaveworks 博客）

Weaveworks 团队表示，GitOps 是一种“面向发布的模型”，用于实现和管理运营和功能。通过增加良好的可观察性实践和工具，完成假设驱动开发的反馈循环，团队为客户提供新功能的速度将部分取决于他们在 OODA 循环中经历各个阶段的速度：

GitOps SDLC，受 OODA 循环的启发（图片来自 Weaveworks 博客）

对于有兴趣了解 GitOps 的读者，可以阅读 Weavework 网站上的一系列博客。第一篇文章解释了“拉取请求运营”模型，并提供了该概念的动机和高级概述。第二篇文章讨论了 GitOps 交付管道的核心阶段。本系列的第三部分探讨了可观察性在这种实践中的作用。来自软件交付社区的反应相当鼓舞人心，包括 Kelsey Hightower 在内的行业杰出人士对这种方法给予了积极的评价。

还有一篇独立文章探讨了 GitOps 与“CIOps”的关系，并认为使用 CI 工具可能不是协调持续交付软件部署的最佳方法。并不是每个人都对这篇文章中选择的术语感到满意，例如，Conflux Digital 咨询主管 Matthew Skelton 认为，“CIOps”一词可能会导致一些工程师得出错误的结论，即 GitOps 在某种程度上是 CI 的替代方案。

有关 GitOps 的更多信息，请访问 Weaveworks 博客。

查看英文原文："GitOps": Weaveworks Explain Their Model for Using Developer Tooling to Implement CI/CD