内容简介:在过去的一年中,Weaveworks团队逐步改进了有关“GitOps是通过使用Git分布式版本控制系统(DVCS)作为声明性基础设施和应用程序的单一事实来源来实现的。团队中的每个开发人员都可以向Git存储库发出拉取请求,在合并请求时,“diff and sync”工具将检测系统的预期状态和实际状态之间的差异,然后触发工具对基础设施进行更新和同步,使其达到预期状态。Weaveworks的创始人兼首席执行官Alexis Richardson和Weaveworks的社区工程师Ilya Dmitrichenko在
在过去的一年中,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平台上,一个用于在应用程序中创建或更新新功能的 典型开发者工作流程 是这样的:
- 工程师在新的Git分支上开发新功能,并在他们准备好提交代码进行评审时发起拉取请求。
- 对代码进行评审,添加评论或由同事批准变更。在进行必要的修订之后,批准的拉取请求将被合并到主干或主线分支。
- Git合并将触发持续集成(CI)和构建管道,并运行一系列测试。成功完成这些测试后,将构建一个新的容器镜像,并上载到镜像注册表。
- Weave Cloud的“Deployment Automator”会监控镜像注册表,一旦发现新映像,就从注册表中拉取它,并更新存储库中包含配置的的相关YAML文件。
- 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
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 让开发者专注于应用开发,OpenCenter 3.0 开发者预览版发布
- 让开发者专注于应用开发,OpenCenter 3.0 开发者预览版发布
- GitHub 推出开发者赚钱新利器,100% 全给开发者!
- Google开发者大会:为中国开发者和消费者推出新的工具
- OpenCenter3.0开发者预览版发布,开发者不能错过的新特性!
- 开发者的硬核福利:专为开发者而生的免费开源安全检测工具
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。