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

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

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

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

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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