Ansible 内容交付的未来

Ansible 内容交付的未来

每天，我都对 Ansible 的发展感到惊叹。社区的惊人增长和技术的病毒式传播导致了项目的内容管理挑战。

我不想重复我们亲爱的朋友 Jan-Piet Mens 或我们出色的社区团队所说的话，但请允许我尝试一下。

我们面临的主要挑战在于可扩展性。我们每天看到的拉取请求和问题数量远远超过 Ansible 社区跟上这种变化速度的能力。

因此，我们正在踏上旅程。我们知道社区，包括我们的内容创建者和内容消费者，都将对这段旅程感兴趣。

正如我们一直所称，这种“新世界秩序”（戏谑地说），是一种模式，将使我们能够赋予 Ansible 内容贡献者（阅读：模块、插件和角色）社区权力，让他们以自己的速度提供内容。

为此，我们对 Ansible 如何利用与其一起“发布”的内容进行了一些更改。简而言之，Ansible 内容不必成为引擎本身的里程碑核心版本的一部分。我们将利用一个交付流程和内容结构/格式，帮助缓解当前由于将插件绑定到核心引擎而导致的大量模糊性和痛苦。

这段旅程的基石是您可能在互联网上听到过的一些传言。它被称为 Ansible 内容集合，简称为集合。

为了创建 Ansible 内容集合，我们查看了许多已经实践的方案。我们研究了其他工具、其他打包格式、交付引擎、存储库，以及最终的自身。在所有这些调查中，我们认为我们已经制定了一个相当可靠的规范。下面我们将介绍一些细节。

集合是 Ansible 内容的严格项目/目录结构。与角色目录结构类似；我们现在强调对 Ansible 剧本执行至关重要的内容。以下是我的队友 Tim Appnel 创建的该规范的图形。

如您所见，该结构看起来非常类似于角色。不过也有一些细微的差别。请注意，角色目录不再包含库文件夹？这里的想法是，集合本身是与之相关的每一段内容，以及执行该内容的剧本的真正封装。因此，我们将各种角色中的库（可能存在于集合中）移到了顶层的插件目录中。在那里，所有类型的插件（是的，模块也在那里，因为模块实际上是插件）都可供角色以及最终可能调用它们的剧本使用。因为此内容将“安装”在引擎知道的、并知道在剧本中调用时查找内容的位置。

此外，通过这些更改，我们还将一些命名空间概念引入到剧本中。以下是 Tim 创建的另一个图形，它是剧本中突出显示命名空间的片段。

所以，这里我们有一个非常简单的剧本。在这个剧本中，我们重点介绍了我们感兴趣使用的集合列表。对于每个任务，我们都使用模块的 FQCN（完全限定的集合命名空间）路径。当然，我们仍然希望简化这一过程。因此，剧本创建者不必始终完全限定其内容路径。如您在第四个任务中所见，创建者仍然可以使用模块的简写名称。Ansible 将按照 Ansible 配置或剧本本身中定义的顺序，以先到先得的方式搜索集合路径。

关于集合，我就说这么多。

祝大家自动化愉快！