关于重构 Ansible 项目的想法

关于重构 Ansible 项目的想法

Ansible 能够流行很大程度上是因为我们在早期就采用了一些关键原则，并且坚持这些原则。

第一个关键原则是简单性：易于安装、易于使用、易于查找文档和示例、易于编写剧本，以及易于进行贡献。

第二个关键原则是模块化：Ansible 功能可以通过编写模块轻松扩展，任何人都可以编写模块并将其贡献回 Ansible。

第三个关键原则是“电池包含”：所有 Ansible 模块都将内置，因此你不必弄清楚从哪里获取它们。它们就存在那里。

遵循这些原则，我们已经取得了长足的进步，我们打算继续坚持这些原则。

不过，最近我们一直在重新评估如何更好地构建 Ansible 来支持这些原则。我们现在发现自己正在处理规模问题，这些问题越来越难以解决。Jan-Piet Mens 从很早开始就一直是 Ansible 的亲密朋友，他最近从长期贡献者的角度 简洁地描述了这些问题，我认为他对我们面临的问题的分析非常准确。简而言之，我们已经成为了自身成功的受害者。

成功意味着增长，增长意味着更多用户、更多客户、更多贡献者以及更多责任，这些都带来了复杂性的增加。我们一直在继续构建像 Ansibot 这样的工具来帮助我们管理这种复杂性，但是当我们继续走向超大规模时，即使我们合并了越来越多的社区代码，我们也看到越来越多的拉取请求和问题被遗漏了。

请考虑以下对 Ansible 项目贡献演变的视觉表示

我们目前面临的大多数挑战都源于 **我们简单的模型无法处理的复杂性增加**。如果我们想突破当前的限制，我们将需要构建一个新的组织模型来做到这一点。

这正是我们一直在努力的，而且这需要一些时间，因为这是一系列复杂的挑战，但我们正在取得进展。

所以让我们讨论一些关键的挑战。

首先，有 **不断增长的支持挑战**。

最初，Ansible 有一项简单的政策：如果我们发布了它，我们就支持它。在最初，这项政策非常有意义；我们有相对较少的模块，而且我们也有相对较少的客户。Ansible 支持团队非常了解所有模块，能够为所有愿意为该支持付费的人提供所有模块的支持。

然而，实际上，自己支持模块可能是一个棘手的命题，而且我们规模越大，它就变得越棘手。我们大多数模块都是 社区维护的。我们显然非常了解 Ansible 本身，但我们并不像贡献者那样了解社区维护的模块。在某些情况下，我们甚至可能无法访问模块与之交互的底层软件或硬件；在这种情况下，我们完全依赖于社区来保持模块正常运行。

我们的一些社区维护者反应异常迅速。有些人反应较慢。这就是社区开发软件的本质。但是，由于所有模块都位于同一个位置，并且是我们“电池包含”模型的一部分，因此许多人（包括付费客户）没有意识到这种区别的存在。

对我们来说，将企业支持负担强加于志愿贡献者是不公平的。同样重要的是，我们要尽可能清楚地向客户说明哪些内容完全包含在他们的订阅中，哪些内容不包含在他们的订阅中。

接下来，有 **生命周期挑战**。

随着 Ansible 本身变得越来越成熟并被更多企业客户使用，Ansible 的生命周期正在放缓。即使直到最近，我们每四个月就会发布一个主要版本的 Ansible，但我们最新的发布周期是八个月，而且这种较慢的发布周期将成为常态。

这是一个挑战，因为它意味着随着时间的推移，新代码需要更长时间才能到达用户。这对我们的合作伙伴来说尤其具有约束力；在当前的结构下，他们只能按照我们的时间表更新他们的模块和插件。我们已经从许多合作伙伴那里收到反馈，他们希望能够独立于我们的发布周期发布自己的模块和插件，并且随着我们的发布周期继续放缓，我们预计这些呼声会越来越高。

然后，有 **不断提高的标准的挑战**。

合作伙伴和社区每个人都希望模块越来越好：编写得更好、测试得更好、更安全。随着每个版本的发布，我们都会尝试提高质量标准。

例如，对于即将发布的 Ansible 2.9 版本，我们预计很快就会要求贡献者 为每个模块提供基本的集成测试。

不断提高的标准带来了自己的挑战。我们如何处理以前足够好的但不再符合新标准的贡献？我们如何处理那些不一定能够或不愿意做必要的工作来达到这些标准的贡献者？对于那些没有跟上我们不断提高的质量标准的现有模块，我们该怎么办？我们是否要以某种方式标记它们，或者是否要完全将它们从 Ansible 中剔除，即使它们是许多人依赖的相对稳定的模块？我们一直在努力解决这些问题。

这让我们想到了 **新的模块贡献者挑战**。

PR 的平均合并时间。新模块（蓝色）与其他所有模块（红色）。请注意，在过去一年中，平均而言，80% 的非新模块 PR 在 22.4 天内合并。

随着质量标准的提高，我们招募新贡献者的能力下降了——或者至少放缓了。与以前相比，贡献者需要更多的时间和精力才能让他们的新模块被接受。

将 PR 引入现有模块相对容易，因为这些模块通常有维护者，他们已经获得了我们集体的信任。我们对现有模块的 PR 合并数量实际上相当不错（当然，我们始终可以改进）。

但是，新模块需要更高程度的审查，因为我们不仅在审查代码，而且还在隐式地审查该代码的贡献者对维护该代码的兴趣和能力。

鉴于我们目前的结构，这是一个不幸但必要的障碍。我们的支持挑战让我们更加不愿意合并没有强有力保证其维护者愿意且能够根据日益严格的要求维护这些模块的新模块。

所有这些挑战的核心在于，我们有一个代码库，它支持两类具有不同主要利益的参与者。

企业用户和合作伙伴最需要的是一个稳定且得到良好支持的平台，他们可以信赖它来自动化其 IT 基础设施。

但是，我们的社区用户和贡献者需要其他东西，而 Ansible 过去一直提供的就是：一种简单的方法来安装 Ansible，以及简单的方法来为 Ansible 做贡献。

对于那些经历过 Red Hat 老时代的人来说，这些问题与我们在原始 Red Hat Linux 产品中遇到的问题非常相似——这些问题导致了 Fedora 项目和 Red Hat Enterprise Linux 的创建。我们的问题并不完全相同，但类似。

这就是为什么我们认为解决方案不应该完全相同，而是类似的。

所以让我们谈谈 **我们解决这些挑战的提议**。

从 **开发的角度来看**，Ansible 将 **被分解成不同的组件**

• **核心引擎**，它本质上将是运行所有其他内容的平台。保持此引擎稳定、更安全和经过良好测试对于每个人来说都至关重要。核心团队将负责维护此引擎。社区贡献政策将与目前的政策相同。

• **核心模块和插件**，即 Ansible 团队直接支持的模块和插件。这些将是最常用的模块和插件（例如模板、复制、lineinfile 等）。社区贡献政策将与目前的政策相同，但不会引入任何新模块。

• **社区模块和插件**，大多数非核心模块和插件都将驻留在那里。社区贡献政策将在一定程度上放宽，以帮助引入新内容和新贡献者，但我们仍将保持质量标准，以帮助确保社区内容具有功能、文档齐全且可用。单独的结构将允许社区更有效地参与策展过程。

• 各种受支持的 **合作伙伴模块和插件**，这些模块和插件将被分解并由合作伙伴更直接地管理。社区贡献政策将由各个合作伙伴自行决定。

所有这些不同的组件都将以 **Ansible 内容集合** 的形式构建，我们首次在 Ansible 2.8 中引入了这些集合。

从 **部署的角度来看**，Ansible 将以两种基本方式之一提供

• **电池包含方法**，这与目前 Ansible 的交付方式非常相似：通过集合捆绑核心引擎、所有核心模块和插件、所有社区模块和插件以及选定的合作伙伴模块和插件。这种方法不会提供任何官方的 Red Hat 支持。

• 一种受支持的企业方法，它只包含该内容的完全受支持的子集：核心模块和插件，以及选定的合作伙伴模块和插件，所有这些都通过集合实现。这将是 Red Hat 作为 Red Hat Ansible Automation 产品的一部分所支持的方法。客户可以自行决定安装和使用任何其他内容，但 Red Hat 支持的内容与非 Red Hat 支持的内容之间的区别将更加明确。

这两种方法都将高度依赖 Ansible Galaxy 作为事实上的交付机制，我们计划大幅改进 Ansible Galaxy 以应对不断增长的流量负载。

有些人可能会注意到，这种新的提议结构与我们几年前迁移到的 Ansible Extras 结构，以及之后 放弃的 结构之间存在相似之处。确实如此；两者之间存在明显的相似之处，许多优点和潜在缺点也是一样的。我们希望并打算从之前的尝试中吸取教训，以获得优势，同时减轻潜在的缺点。

我们相信，这些结构性变化将有助于 Ansible 保持我们强大的社区重点，同时还提供必要的结构来支持我们不断增长的合作伙伴和客户群。我们认识到，这些都是重大的变化，这就是我们计划非常谨慎地朝着这些变化迈进的原因。我们希望确保在做出改变之前，我们能够理解这些改变的影响。这些改变并非迫在眉睫，但我们认为我们已经到了可以讨论这些可能性的时候。

还有许多问题有待解答：基础设施问题、许可问题、发布策略问题等等。我们将在即将到来的网络研讨会上讨论其中的一些问题。

我们还将在 9 月份举行的 AnsibleFest Atlanta 社区贡献者大会上深入探讨这些问题。我们希望在那里亲自见到我们的贡献者，但一如既往，我们也努力实现 完全远程参与。请以任何方式加入我们。

在 Ansible 的早期，我们只能梦想着这种成功。在我们七年的发展历程中，我们已经建立了 全球最顶尖的开源项目之一，并拥有一个致力于推动我们并从一开始就支持我们的社区。如果我们当时就预想到了今天所面临的挑战，我们肯定会把它们归类为“好问题”。

但“好问题”仍然是问题，如果我们不能解决它们，它们就不会一直是“好问题”。现在是我们迈出下一步的时候了，这样我们才能继续成为所有用户、客户和贡献者的可靠合作伙伴。如果没有你们所有人，我们就永远不可能走得这么远。