2018 年 7 月 9 日
第 16 卷，第 3 期

 

GitOps：通往更多自助式 IT 的道路

IaC + PR = GitOps

Thomas A. Limoncelli

您编写了一个新的 Web 应用程序，并希望将其添加到您组织的 Web 负载均衡器中。负载均衡器非常复杂；其配置由网络运营团队中训练有素的专家维护。您向团队提交工单，等待，等待，等待，与专家讨论，等待，等待，等待，最终您的请求完成。假设他们第一次就做对了，您的应用程序现在可以使用了。

在其他公司，流程更像是这样：

1. 找到 Git 仓库，其中存储了将负载均衡器连接到各种 Web 应用程序服务器的管道的逻辑描述。

2. 编辑该文件以添加您的新应用程序。

3. 建议的修订以 PR（拉取请求）的形式提交给 Web 团队，就像开发人员为软件项目提交 PR 一样。

4. 在人工审查 PR 的同时，您的 CI（持续集成）系统（即 Jenkins 或类似系统）正在对您对负载均衡器配置的更改进行 linting 和单元测试（可能在容器或 VM 中）。

5. 一旦 PR 获得批准并且“构建变为绿色”，CD（持续部署）管道（通常是另一个 Jenkins 作业或类似作业）将负责为生产负载均衡器生成新的配置文件并部署它，通常借助 Puppet 或 Chef 等配置管理系统。

这种类型的工作流程被称为 GitOps：授权用户通过 PR 执行自己的 IT 运维。

GitOps 降低了创建常见 IT（或站点可靠性工程，或 DevOps）流程的自助服务版本的门槛。随着门槛降低，就更容易达到投资回报率 (ROI) 计算中的回报。GitOps 不仅实现了这一点，而且还鼓励了 IT 系统中期望的行为：更好的测试、减少“巴士系数”（https://en.wikipedia.org/wiki/Bus_factor）、缩短等待时间、更多基础设施逻辑通过 IaC（基础设施即代码）以编程方式处理，并将时间从手动苦工转移到创建和维护自动化。

GitOps 使 IT 组织能够轻松提供自助式 IT 运维。它在做到这一切的同时，还减少了需要编写和维护的代码量。它鼓励采用自动化的渐进式方法：审批在开始时主要是手动的，但随着时间的推移变得更加自动化。唯一编写的代码是已被证明需要的代码。

最重要的是，GitOps 提高了安全运行系统的能力，即使新用户需要进行重大更改也是如此。这种安全性随着更多测试的自动化而迭代改进。它通过启用补偿原则来克服剩余原则（参见 https://queue.org.cn/detail.cfm?id=2841313 和 https://queue.org.cn/detail.cfm?id=3197520 或主要来源 John Allspaw 的文章“自动化的成熟角色”。http://www.kitchensoap.com/2012/09/21/a-mature-role-for-automation-part-i）。

GitOps 简述

GitOps 工作流程具有以下特点：

• 配置存储在 Git 或其他 VCS（版本控制系统）中。配置文件采用声明性语言，或者允许幂等更新。

• 团队外部人员（客户）被授权以 PR 的形式发送变更请求。用户文档可用于指导他们完成整个过程。

• CI 系统运行自动化测试以验证文件，并在批准后再次运行。

• 人工批准 PR，这将启动 CI/CD 系统。一些测试是手动完成的，但会随着时间的推移实现自动化。

• 当 PR 获得批准并且所有测试都通过时，CD 系统会将更改部署到生产环境。

其中很多内容并不新鲜。早在 Git 发明之前的几十年，人们就已将配置文件存储在 VCS 中。IaC 倡导者多年来一直在赞扬使用声明性语言进行配置文件的优势。

新的内容是允许 IT 团队外部人员提交 PR、广泛使用自动化测试以及使用 CI 系统来集成所有这些。

进化式进步

前面我描述了用户发出请求的体验。从提供者角度来看，体验更有趣，因为它会随着时间的推移而演变。在这个例子中，我将追溯 DNSControl（https://github.com/StackExchange/dnscontrol）使用的一些虚构的演变。这是一种 DSL（领域特定语言），用于描述 DNS（域名系统）域配置（区域数据）以及一个编译器，该编译器处理该配置，然后更新各种 DNS 服务提供商，例如 AWS（亚马逊网络服务）Route 53、Google Cloud DNS、ISC BIND 等。

最初，DNSControl 配置文件 (dnsconfig.js) 存储在 Git 中。配置了一个 CI 系统，以便更改触发 DNSControl 的测试和推送周期，并且对文件的更新会导致更改传播到 DNS 提供商。这是一种典型的 IaC 模式。当需要更改时，IT 团队的某人会更新文件并将其提交到 Git。

要将其转变为 GitOps，只需添加文档即可。团队的 Wiki 已更新，以将人们指向正确的 Git 仓库。文件格式非常明显：找到您要修改的域并添加记录。命令 dnscontrol check 会执行一些基本检查。发送 PR，您就可以开始了。

PR 由 IT 团队审查。审查包括技术问题（如语法和字符串长度），以及机构政策（如排序、大写和禁止粗言秽语）。最初，这些检查是手动完成的。一旦 PR 获得批准，CI 系统就会接管并触发测试和推送周期。

重要的是，IT 团队执行的手动检查在用户文档中列出。这提高了 PR 首次尝试即获得批准的可能性（而且，强制执行未公开的规则相当不道德）。以书面形式列出检查也有助于 IT 团队在政策执行方面保持一致。它也可以作为一种培训机制：新的 IT 团队成员可以像其他任何人一样执行操作。

这通常就足够了。该系统满足基本要求：它是自助服务，工作分配给请求者，自动化完成枯燥的部分。所有或大部分清单都是手动执行的；但在 PR 率较低的情况下，这是可以接受的。

如果 PR 率增加，可能是时候通过自动化一些手动检查来改进系统了。也许某个检查经常被遗忘或经常做错。也许额外的边界检查可以防止停机，并且可以实施新的输入验证。事实上，在每次与部署相关的停机之后，您都应该停下来问问是否可以通过验证或其他检查来防止它。

语法检查和文件格式验证通常很容易添加，并且可以减少挫败感。特别是 JSON（JavaScript 对象表示法）文件，其语法很容易通过代码检查，但不容易通过肉眼检查。如果没有基本的自动化检查，您会看到一个常见的模式，即提交 PR，然后很快跟进一个带有令人沮丧的评论的 PR，例如“该死的 JSON！该死的逗号规则！”

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

随着清单中更多内容的自动化，团队可以处理更大数量的 PR。

我喜欢这种演变，因为它将编码项目指向最需要它们的地方。与其试图自动化每个测试并且永远不发布，不如尽早发布
并经常发布，随着您了解哪些错误最常见，添加解决实际问题的测试。

通过从许多手动检查开始，并且仅在需求指导您的注意力时自动化问题，低价值工作会受到抑制。正如《目标》（Eliyahu M. Goldratt，1984 年）和《凤凰项目》（Gene Kim、Kevin Behr 和 George Stafford，2013 年）等书中指出的那样，最好只在瓶颈处直接付出努力：瓶颈上游的改进只会造成更大的积压；瓶颈下游的改进是过早的优化。

如果所有验证、检查和测试都可以自动化，则系统可以自动批准 PR。虽然这种情况很少发生，但当发生时，结果是用户可以 24/7 全天候无延迟地满足他们的需求，即使 IT 团队正在睡觉、生病或度假。

总而言之，GitOps 系统像这样演变：

1. 基本 — 仓库中的配置作为存储或备份机制。

2. IaC — 团队内部的 PR 仅触发基于 CI 的部署。

3. GitOps — 团队外部的 PR、预先审查的 PR、合并后测试。

4. 自动 — 完全消除人工检查。

用户受益

用户从 GitOps 中以多种方式受益。主要好处是请求完成得更快。等待批准比等待会议讨论请求、等待 IT 团队完成所需工作以及验证所有工作是否正确完成要快得多。即使 PR 需要几次迭代和改进，该过程也更快，或者至少更令人愉快，因为它更具协作性。

GitOps 提供更高的透明度。用户可以看到请求的所有详细信息，从而避免潜在的错误、拼写错误以及信息在翻译过程中丢失的常见问题。

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

GitOps 提升了请求处理的尊严。理想情况下，环境变更请求应根据它们是否符合架构和工程原则来批准，而与来源无关。在传统的组织中，请求的实现通常是政治和官僚成功的因素，以及个性的力量。GitOps 将我们推向更好的方式。

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

缺点是 Git 具有陡峭的学习曲线。对于已经使用 Git 的开发人员来说，这并不是什么大问题，他们可能会将 GitOps 视为他们可以提交 PR 的更多内容。然而，对于其他人来说，这是一个负担，特别是对于非技术用户，以及对于尚未​​使用 Git 的技术人员，例如网络运营中心、帮助台或其他纯粹运营角色的人员。幸运的是，Git 令人沮丧地难以理解，以至于它催生了一个 GUI 系统和编辑器插件的家庭手工业，它们位于 Git 之上并使其更易于使用。一些流行的 GUI 包括 GitHub Desktop 和 TortoiseGit。Emacs、vim 和 VSCode 都具有出色的 Git 集成。

IT 受益

GitOps 具有 IaC 的所有优势。当描述基础设施的文件存储在 VCS 中时，使用 VCS 的所有优势都会显现出来：版本历史记录、谁做了什么更改的日志、回滚等等。

GitOps 的优势远远超出 IaC。它使工作民主化和委派。通过让用户创建自己的 PR，它可以创建一种劳动分工，即精通请求细节的用户创建 PR，而精通系统的团队批准 PR。它可以更好地扩展 IT 团队，因为批准 PR 相对容易。它还可以让 IT 团队专注于质量保证和提高系统安全性，这更好地利用了他们的时间。

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

GitOps 也具有安全优势。拥有所有更改的 VCS 日志使安全审计更容易。这使通常被视为阻碍者的组织转变为盟友。如果您的 VCS 是 Git 或另一个加密哈希系统，则静默更改文件变得非常困难。可以对提交进行加密签名以获得额外的保证。

最后，GitOps 使管理者能够成为更好的管理者。中层管理者可以从 PR 系统或配置文件本身收集指标。直线经理可以通过跟踪 PR 而不是唠叨他们的直接下属来了解他们的团队正在做什么。

我喜欢将我们的 GitOps 系统配置为抄送我任何 PR 更新。因此，我变得无处不在，并且很少需要唠叨状态更新。当我发现自己微观管理一个项目时（因为有人抱怨），通常是针对一个没有订阅 GitOps 工作方式的项目。另一个在处理绩效不佳者时有帮助的 GitOps 管理技巧：审查此人的 PR 历史记录可以启发人心，并可以用作证据，在您指导他或她解决特定问题时向员工展示。

投资回报率 (ROI)

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

传统上，自助服务 IT 系统涉及创建一个基于 Web 的门户，允许用户在无需人工审批的情况下执行定义明确的事务性请求。然而，此类系统难以创建，需要 Web UI 设计技能，而这些技能通常超出典型系统管理员的技能范围。工作流程非常复杂，以至于需要高级 UX（用户体验）研究和测试才能创建一个比仅打开工单更不容易混淆的系统。可悲的是，大多数公司没有 UX 研究人员，而那些有 UX 研究人员的公司也不会将他们分配给内部 IT 项目。

此类系统是脆弱的，因为它们与它们控制的系统紧密耦合。我见过一些门户，当底层系统发生更改时，它们被放弃了，因为返回手动更新比更新门户所需的工作量更少。这通常不是因为更改很复杂，而是因为有关如何更新门户的知识随着最初创建它的人一起离开了。通常，门户由与负责控制它们的系统的人员不同的人员制作。

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

 

提示

我对于入门的建议是使用您组织中现有的 VCS、PR 和 CI 系统。人们已经熟悉它们，这降低了学习曲线。它们通常具有许多不错的功能，例如管理等待批准的 PR 队列的方式、与工单系统集成等等。我喜欢可以在我团队的聊天室中宣布新 PR 到达的系统。您甚至可以将 PR 批准变得像向聊天机器人发送消息一样容易。

用例

寻找使用 GitOps 的机会。DNS 是一个明显的起点，VM 创建、容器维护和编排、防火墙规则、网站更新、博客文章、电子邮件别名和邮件列表以及几乎任何虚拟基础设施或具有配置文件或 API 的基础设施也是如此。

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

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

一家公司维护着全球计算机机架中设备位置的清单，作为一组 YAML（YAML 不是标记语言）文件。技术人员通过触发自动计算以检测过载电源系统并验证其他系统约束的 PR 来保持文件更新。CI 系统还生成带有机架图的 HTML 页面。当请求基于 Web 的 GUI 时，他们创建了一个系统，该系统在后台更新其 VCS 中的 YAML 文件。

 

结论

GitOps 降低了创建自助服务 IT 系统的成本，从而在以前无法证明其合理性的情况下实现了自助服务操作。它提高了安全运行系统的能力，允许普通用户进行重大更改。随着更多测试的添加，安全性得到提高。随着每次更改都被跟踪，安全审计变得更容易。

GitOps 并非完美无缺。并非每个 IT 系统或服务都可以以这种方式配置，并且它需要承诺编写用户文档，这可能需要一些时间来适应。它还需要围绕您的 VCS 进行更高的安全控制，因为它现在是一个生产攻击向量。

然而，当 GitOps 嵌入到公司的技术文化中时，新的系统在构建时会考虑到 GitOps，并且我们朝着一个操作协作、共享和安全的世界迈进了一步。

致谢

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

 

相关文章

您的负载均衡是否使用错误？
Thomas A. Limoncelli
任何人都可以使用负载均衡器。正确使用它们要困难得多。
https://queue.org.cn/detail.cfm?id=3028689

理解版本控制系统
Bryan O'Sullivan
无论是分布式还是集中式，所有版本控制系统都带有一系列复杂的权衡。您如何找到工具和团队之间的最佳匹配？
https://queue.org.cn/detail.cfm?id=1595636

容器不会修复您破碎的文化
Bridget Kromhout
复杂的社会技术系统很难；晚间 11 点播出。
https://queue.org.cn/detail.cfm?id=3185224

Thomas A. Limoncelli 是纽约市 Stack Overflow Inc. 的 SRE 经理。他的著作包括《系统和网络管理实践》（http://the-sysadmin-book.com）、《云系统管理实践》（http://the-cloud-book.com）和《系统管理员的时间管理》（http://shop.oreilly.com/product/9780596007836.do）。他的博客是 EverythingSysadmin.com，推特是 @YesThatTom。他拥有德鲁大学计算机科学学士学位。

版权 © 2018 归所有者/作者所有。出版权已授权给 。

最初发表于 Queue vol. 16, no. 3—
在 数字图书馆 中评论本文

---

更多相关文章

虽然加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。出于各种安全要求的考虑，加密哈希函数存在许多标准，但在非加密方面，存在一定的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对现实世界数据集的均匀分布在很大程度上是有意义的，但当面对具有特定模式的数据集时，这可能是一个挑战。

DevEx（开发者体验）在许多软件组织中越来越受到关注，因为领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付。直观地，技术领导者普遍接受良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改进 DevEx 的拟议举措和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。

本文旨在通过展示使用基于代码、低代码和极端低代码技术进行的实验室实验结果来研究生产力差异，从而为该主题提供新的见解。低代码技术已清晰地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。

虽然软件行业是一个快节奏且令人兴奋的世界，新的工具、技术和技巧不断被开发出来以服务于商业和社会，但它也很健忘。在其快速前进的步伐中，它容易受到时尚的支配，并且可能会忘记或忽略针对其面临的一些永恒问题的行之有效的解决方案。用例于 1986 年首次引入，并在后来得到普及，它们是这些行之有效的解决方案之一。

---

---

© 保留所有权利。