ACM通信

实践

GitOps:通向更多自助IT服务的路径

托马斯·a·利蒙切利著
ACM通信，2018年9月，Vol. 61 No. 9, page 38-42
10.1145 / 3233241
评论

您已经编写了一个新的Web应用程序，并希望将其添加到组织的Web负载平衡器中。负载均衡器很复杂;网络运营团队中训练有素的专家维护其配置。你和团队提交一张票，等待，等待，等待，和专家讨论，等待，等待，最后你的请求完成了。您的应用程序现在可以使用了，假设他们第一次尝试就获得了正确的结果。

在其他公司，这个过程看起来更像这样:

1. 找到存储连接负载均衡器到各种Web应用程序服务器的管道的逻辑描述的Git repo。
2. 编辑该文件以添加新的应用程序。
3. 建议的修订作为一个拉式请求(PR)提交给Web团队，就像开发人员提交软件项目的PRs一样。
4. 在人们审查PR的同时，你的持续集成(CI)系统(如Jenkins或类似的)正在检测和单元测试你对负载均衡器配置的更改(可能在容器或VM中)。
5. 一旦PR被批准并且“构建是绿色的”，持续部署(CD)管道(通常是另一个Jenkins工作或类似的工作)将负责为生产负载平衡器生成新的配置文件并进行部署，通常是在配置管理系统(如Puppet或Chef)的帮助下。

这种工作流程被称为GitOps:通过PRs授权用户做他们自己的IT操作。

GitOps降低了创建通用IT(或站点可靠性工程，或DevOps)流程的自助版本的门槛。随着门槛的降低，在计算投资回报率(ROI)时更容易达到回报。GitOps不仅实现了这一点，而且还鼓励IT系统中所需的行为:更好的测试，减少“总线因素”，^一个减少了等待时间，更多的基础架构逻辑通过基础架构作为代码(IaC)以编程方式处理，并将时间从手工劳动转移到创建和维护自动化上。

GitOps为it组织提供自助it运营提供了便利。它在完成所有这些工作的同时，减少了必须编写和维护的代码量。它鼓励一种增量的自动化方法:最初的审批大部分是手动的，但随着时间的推移会变得更加自动化。唯一需要编写的代码是已经证明需要的代码。

最重要的是，GitOps提高了安全操作系统的能力，即使新用户需要进行大的更改。随着更多的测试被自动化，这种安全性不断改进。它通过使补偿原则生效来击败剩余原则。^b

回到顶部

GitOps In a Nutshell

GitOps工作流具有以下特点:

• 配置存储在Git或其他VCS(版本控制系统)中。配置文件使用声明式语言，或者允许幂等更新;
• 团队之外的人(客户)被授权发送变更请求作为PRs。可以使用面向用户的文档指导他们完成整个过程;
• CI系统运行自动化测试来验证文件，并在获得批准后进行验证;
• 一个人批准了PR，这就启动了CI/CD系统。有些测试是手动完成的，但随着时间的推移会自动完成;而且
• 当PR获得批准且测试全部通过时，CD系统将更改部署到生产环境中。

这在很大程度上并不新鲜。在Git发明之前几十年，人们就已经在VCS中存储配置文件了。多年来，IaC的支持者一直在赞扬在配置文件中使用声明性语言的好处。

IT团队之外的人可以提交PRs，大量使用自动化测试，并使用CI系统集成所有这些。

回到顶部

进化的进展

前面我描述了用户发出请求的体验。提供者端的经验更有趣，因为它会随着时间的推移而发展。在这个例子中，我将追溯DNSControl使用的一个有点虚构的演变过程。^c这是一种域特定语言(DSL)，描述域名系统(DNS)配置(区域数据)和一个编译器，它处理它，然后更新各种DNS服务提供商，如AWS (Amazon Web服务)Route 53、谷歌云DNS、ISC BIND等。

DNSControl配置文件保存在Git中。配置一个CI系统，以便更改触发DNSControl的测试-推送周期，对文件的更新将导致更改传播到DNS提供者。这是典型的IaC模式。当需要更改时，IT团队的某个人会更新文件并将其提交到Git。

要将其转换为GitOps，只需添加文档。团队的wiki得到了更新，可以将人们指向正确的Git存储库。文件格式非常明显:找到您想要修改的域并添加记录。命令dnscontrolCheck做一些基本的检查。把公关发了，你就可以去比赛了。

产品责任表由资讯科技小组审阅。此次审查包括语法和字符串长度等技术问题，以及排序、大写和禁止粗话等制度政策。最初，这些检查是手动完成的。一旦PR得到批准，CI系统就会接管并启动测试和推进周期。

It团队执行的手动检查在面向用户的文档中列出是很重要的。这将提高PR在第一次尝试时便获得批准的可能性(另外，强制执行未被宣传的规则是非常不道德的)。以书面形式枚举检查还允许IT团队在策略执行中保持一致。它还可以作为一种培训机制:新的It团队成员可以像其他人一样执行相同的任务。

这通常已经足够好了。该系统满足基本需求:它是自助服务的，工作分发给请求者，自动化完成无聊的部分。所有或大部分检查清单都是手动执行的;但如果PRs的比率很低，那就没问题了。

如果PRs的比率增加，也许是时候通过自动化一些手动检查来改进系统了。也许有一个经常被忘记或经常做错。也许可以通过额外的边界检查来避免停机，并且可以实现新的输入验证。实际上，在每次与部署相关的停机之后，您都应该暂停，询问验证或其他检查是否可以防止这种情况发生。

语法检查和文件格式验证通常很容易添加并减少挫折。特别是JSON (JavaScript对象表示法)文件，它的语法很容易用代码检查，但不容易用肉眼检查。如果没有基本的自动检查，你将会看到一个常见的PR提交模式，然后是一个带有愤怒评论的PR，如“该死的JSON!该死的逗号规则!”

这些检查可以在CI管道的许多阶段添加。Git有预提交检查，在提交者的客户端运行，如果提交失败就会阻塞Git提交，但这可以被禁用，或者如果它们依赖于特定的操作系统或服务，它们可能会完全失败。我更喜欢将PR系统配置为运行测试。可以对CI系统进行配置，以便在任何新的PRs发送给团队审批之前对其进行测试。这确保了检查不会被跳过，并且可以包括比提交前检查更深入的测试，而提交前检查可能很难以操作系统无关的方式编写。预先审查的PRs减少了IT团队的工作量。

随着更多的检查清单被自动化，团队可以处理更多的PRs。

我喜欢这种演进的原因是，它将编码项目指向了最需要它们的地方。与其尝试自动化每一个测试，却从不发布，您可以更早、更频繁地发布，在您了解到哪些错误是最常见的时，添加解决实际问题的测试。

当需求引导您的注意力时，通过许多手动检查和自动化问题开始，低价值的工作是不受鼓励的。如书中所述我们的目标(E.M. Goldratt, 1984)和凤凰城项目(G. Kim等人，2013)，最好只在瓶颈处直接花费精力:瓶颈上游的改进只会造成更大的积压;瓶颈下游的改进是过早的优化。

如果所有的验证、检查和测试都可以自动化，系统就可以自动审批PRs。尽管这种情况很少发生，但结果是用户可以24/7地不延迟地满足他们的需求，即使IT团队在睡觉、生病或度假。

总结一下，GitOps系统的发展是这样的:

1. 基本:将repo配置为存储或备份机制。
2. IaC:团队内部的PRs触发基于ci的部署。
3. GitOps:来自团队之外的PRs，预审查PRs，合并后测试。
4. 自动:完全消除人工检查。

回到顶部

用户利益

用户可以从很多方面受益于GitOps。它的主要好处是更快地完成请求。等待批准比等待满足和讨论请求、等待IT团队完成所需的工作并验证所有工作都正确完成要快得多。即使PR需要一些迭代和优化，这个过程也会更快或至少更有趣，因为它更具有合作性。

GitOps提供了更多的透明度。用户可以看到请求的所有细节，从而避免潜在的错误、打字错误和翻译过程中丢失信息的常见问题。

技术人员重视学习的机会。技术用户喜欢学习系统，因为文档会引导他们完成整个过程。处理PR、检查错误和部署结果的代码对用户来说通常是可见的，好奇的用户可以探索它。对附加功能和错误检查的请求经常被推送给用户，他们可能喜欢协作改进系统。这可以成为IT团队的招聘工具。

GitOps增强了处理请求的尊严。理想情况下，环境更改的请求应该根据它们是否符合架构和工程原则而获得批准，而不管其来源如何。在传统的组织中，要求往往是作为政治和官僚成功的因素，以及个性的力量来实现的。GitOps让我们朝着更好的方向前进。

---

GitOps为it组织提供自助it运营提供了便利。它在完成所有这些工作的同时，减少了必须编写和维护的代码量。

---

用户也会受益，因为当it团队更容易创建自助服务工具时，就会创建更多此类工具。GitOps降低了创建这些工具的门槛。

缺点是Git的学习曲线很陡峭。对于已经在使用GitOps的开发者来说，这并不是什么大问题，他们可能会将GitOps视为他们可以提交PRs的更多内容。然而，它对其他人来说是一种负担，尤其是非技术用户，但也包括那些尚未使用Git的技术人员，比如那些在网络操作中心、帮助台或其他纯操作角色中的人员。幸运的是，Git是如此令人沮丧地难以理解，以至于它催生了一个基于Git并使其更容易使用的GUI系统和编辑器插件的家庭工业。一些流行的gui包括GitHub Desktop和turtle - git。Emacs、vim和VSCode都有出色的Git集成。

回到顶部

它的好处

GitOps拥有IaC的所有优点。当描述基础架构的文件存储在VCS中时，使用VCS的所有好处就显现出来了:版本历史记录、谁做了什么更改的日志、回滚，等等。

GitOps的好处远不止IaC。它使工作民主化和委派工作。通过让用户创建他们自己的PRs，这就形成了一种劳动分工，即由精通请求细节的用户创建PR，而拥有系统专业知识的团队批准PRs。它能更好地扩展It团队，因为批准pr相对容易。它还让It团队专注于质量保证和提高系统安全性，这是他们更好地利用时间。

虽然可能需要高级工程师来建立初始系统，但自动化测试是初级工程师积累经验的好方法。因此，GitOps创造了指导和成长机会。

GitOps也有安全方面的好处。拥有包含所有更改的VCS日志使安全审计更容易。这使一个经常被视为阻碍者的组织变成了盟友。如果您的VCS是Git或其他加密散列系统，那么悄无声息地修改文件将变得非常困难。可以对提交进行加密签名，以获得额外的保证。

最后，GitOps让管理者成为更好的管理者。中层管理人员可以从公关系统或配置文件中收集指标。直线经理可以通过遵循客户关系报告来跟踪他们的团队在做什么，而不是唠叨他们的直接下属的状态更新。

我喜欢把我们的GitOps系统配置成密传给我任何公关更新。因此，我变得无所不在，很少需要唠叨着更新状态。当我发现自己在微观管理一个项目时，通常是针对一个没有遵循GitOps做事方式的项目。在处理表现不佳的员工时，另一个有用的GitOps管理技巧是:当你在指导员工解决具体问题时，回顾这个人的公关履历可以起到启发作用，并作为证据向他/她展示。

回到顶部

ROI

然而，最大的好处来自于GitOps提高自动化ROI的能力。事实是我们没有时间自动化所有的请求，并且并不是所有的请求都有足够的ROI来实现自动化。GitOps减少了I，使其更容易实现R。

传统上，自助IT系统涉及创建基于web的门户，该门户允许用户执行定义良好的事务性请求，而无需人工审批者的参与。然而，这样的系统很难创建，需要的Web UI设计技能通常超出了典型的系统管理员的能力。工作流程非常复杂，需要进行高级用户体验(UX)研究和测试，才能创建一个比开罚单更容易理解的系统。遗憾的是，大多数公司没有UX研究人员，而那些有研究人员的公司也不会将他们分配给内部IT项目。

这样的系统是脆弱的，因为它们与它们控制的系统紧密耦合。我看到过一些门户在底层系统更改时被放弃，因为返回手动更新的工作量比更新门户要少。这通常并不是因为更改复杂，而是因为如何更新门户的知识留给了最初创建门户的人。制作门户的人员通常与负责他们控制的系统的人员不同。

GitOps降低了创建自助系统的门槛，因为UI是公司已经拥有的现有PR系统。

回到顶部

提示

我对开始的建议是使用组织中现有的VCS、PR和CI系统。人们已经熟悉它们，这减少了学习曲线。它们通常有许多不错的功能，例如管理等待批准的PRs队列的方法，与票务系统的集成，等等。我喜欢能够在我团队的聊天室里宣布新pr到来的系统。你甚至可以像向聊天机器人发送消息一样简单地进行公关审批。

回到顶部

用例

寻找使用GitOps的机会。DNS显然是一个开始的地方，就像VM创建、容器维护和编制、防火墙规则、网站更新、博客文章、电子邮件别名和邮件列表，以及几乎任何虚拟基础设施或一个配置文件或API一样。

GitOps在我们的行业中无处不在。在OpenStack中，整个基础设施都是通过GitOps控制的，包括GitOps基础设施本身。GitHub Inc.的员工报告说，GitOps的使用非常普遍，甚至非技术人员也接受过如何使用Git的培训。

流行的开源仪表板应用程序Grafana正在向仪表板的GitOps工作流转变。认识到这些仪表板中编码了多少业务逻辑，Grafana现在提供了从JSON仪表板定义中提供仪表板的选项，这些仪表板被放置在文件系统的特定位置。通过GitOps方法，仪表板创建者可以使用任何对他们的特定工作流程有意义的工具和流程，包括在存储仪表板的Git repo上使用PRs。

一家公司以一组YAML (YAML Ain’t Markup Language)文件的形式维护了全球计算机机架中设备放置位置的库存。技术人员通过PRs实时更新文件，触发自动计算，以检测过载的电力系统，并验证其他系统约束。CI系统还生成了带有机架图的HTML页面。当请求基于web的GUI时，他们创建了一个系统，该系统在底层更新VCS中的YAML文件。

回到顶部

结论

GitOps降低了创建自助IT系统的成本，实现了以前无法实现的自助操作。它提高了安全操作系统的能力，允许普通用户进行大的改变。安全性随着测试的增加而提高。随着对每个更改的跟踪，安全审计变得更加容易。

GitOps并不完美。并不是每个IT系统或服务都可以这样配置，它需要编写面向用户的文档，这可能需要一些时间来适应。它还需要对VCS进行更高的安全控制，因为它现在是一个生产攻击向量。

然而，当GitOps融入到公司的技术文化中时，新系统的构建就会考虑到GitOps，我们离实现协作、共享和安全运营的世界又近了一步。

回到顶部

致谢

本文受益于Alice Goldfuss, SRE, GitHub Inc.的反馈和建议;Elizabeth K. Joseph, Mesosphere的开发者倡导者;Chris Hunt, SRE, Stack Overflow Inc.;Eric Shamow, StanCorp首席平台工程师;Jonathan Kratter, SRE, Uber Technologies LLC;Stack Overflow Inc.的Mark Henderson。

相关文章
在queue.acm.org

你的负载平衡错误吗?
托马斯·a·Limoncelli
https://queue.acm.org/detail.cfm?id=3028689

理解修正控制系统
布莱恩·奥沙利文
https://queue.acm.org/detail.cfm?id=1595636

容器不能修复你破碎的文化
布丽姬特Kromhout
https://queue.acm.org/detail.cfm?id=3185224

回到顶部

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2018 ACM, Inc。

---

没有发现记录