作者：**马修·琼斯**，*红帽 Ansible 自动化首席架构师*

早在 2013 年，一支由工程师组成的团队花了一年多的时间才完成了 Ansible Tower 的第一个商业版本（在我们扩展并演变为 Ansible 自动化平台之前），在这段时间里，我们奠定了应用程序的基础，我对它感到非常自豪。

我们，Tower 的最初架构师，试图找到最佳方法来创建允许为数十万台服务器大规模运行 Ansible 的系统。我们希望有一种方法不仅可以管理这些服务器，还可以存储自动化结果，并提供可审计性和可追溯性。它需要使 Ansible 适用于大型团队，并且它成功了。

如今，我们不仅要谈论数十万，而是要谈论数百万和数千万。我们正在管理世界上一些最大的 IT 机构的自动化。而且我们不仅要管理服务器。在过去的几年里，我们一直在自动化容器、云平台、网络设备、存储、物联网设备和 PLC（以及其他事物）。我们面临的主要挑战之一是，10 年前做出的某些架构决策仍然存在。我们拥有一个功能强大的单体系统，但它很难扩展以包含新的功能。

变化的时刻

在构建 Ansible Tower 的早期，我们意识到我们需要一种分发 Ansible 内容的方法，于是 Ansible Galaxy 诞生了。多年来，每个人都要求我们提供可以本地安装的 Ansible Galaxy 版本。我们知道我们想这样做，但这花了我们好几年时间，当我们最终发布它时，我们发现我们构建了一些作为集成产品比我们意识到的能力更强的产品。能够管理自动化内容并将该内容分发到我们已经投入时间的运行时引擎对于部署和使用它的人来说非常强大，即使当时我们没有很好的方法以无缝的方式将两个系统连接在一起。

你们中的许多人可能还记得 2019 年，我们经历了与 Ansible 开源项目类似的旅程，关于重构 Ansible 项目的思考，我们现在正处于类似的转折点，要解决类似的问题，但我们也希望从那次经历以及随后发生的允许我们进行更改的变化中吸取教训。

以事件驱动的 Ansible 为例。当我们开始着手扩展 Ansible 自动化平台以接受来自外部系统的事件时，我们决定尝试一些不同的东西，我们可以预见到将这种（对我们来说是新的）模式添加到已建立的代码库中的风险。我们想要一个能够以稍微不同的方式运行 Ansible 工作负载并响应其他事件和操作的小而紧凑的系统。它需要位于这些事件源之间，做出决策，并将数据映射到与当前任务相关的 Ansible 工作负载中。该系统的扩展特性和生命周期与自动化控制器（以前称为 Ansible Tower）用于管理直接 Ansible 作业运行的特性和生命周期非常不同，即使此基于事件的系统需要能够运行相同的作业。

事件驱动的 Ansible 已经取得了巨大的成功，但我们注意到在尝试将其与新系统结合使用时，现有的架构也存在相同的局限性。我们需要作业能够以不同的方式和在不同的地方报告其状态。我们需要凭据和项目能够被该系统安全使用。如今，Ansible 的清单管理不仅仅与服务器或容器有关，还与云和服务 API 以及嵌入式和边缘功能有关。

我们的挑战和影响

在内部，作为一个团队，我们发现自己处于一个添加和维护现有应用程序架构会限制我们改变能力的点。我们已经达到了现有系统所能创新的极限，我们已经达到了尝试以正确的方式进行操作会与迄今为止我们创建的解决方案发生冲突的点。如果我们想继续前进，我们可以做些什么呢？

在过去的几年里，我们利用了容器，包括通过 Podman 的 RHEL 和 OpenShift 来解决其中一些挑战，例如，执行环境用于更好地管理 Ansible Core 中的 Python 依赖项。但是，这样做从未解决平台的核心部分，即自动化控制器，它是从 AWX 项目的下游构建的。就像我们许多客户和用户对他们的系统做的那样，我们将“遗留”应用程序迁移到了容器中，但我们没有改变它以真正利用容器所带来的优势。

虽然这些变化给我们提供了一些喘息的机会，但三年后，我们发现自己进行更改的速度仍然没有我们想要的那么快，而且旧的架构需要花费太多时间来理解和测试这些更改。

在外部，自 AWX 首次出现以来，整个行业已经发生了发展。我们的客户现在期望 AAP 作为一个云原生应用程序运行，利用自动扩展和蓝绿部署。我们现在更多的是在云超大规模提供商上和通过云超大规模提供商部署我们的产品，并且我们的客户运行着更加复杂的混合云架构。

然后，我们还需要考虑在人工智能时代，成为一个企业级自动化平台意味着什么。对于我们如何利用红帽更广泛的策略来使用经过训练的模型来增强和扩展 AAP 产品，以及 AAP 如何融入客户不断增长的管理功能方面。我们许多客户希望利用人工智能来增强他们的构建和发布系统，并改善日益复杂的运营挑战，而那些还没有这样做的人，未来也会想要这样做。

我们已经到了需要改变的点，这些改变太难以维持现状。它们很复杂，会对产品造成意外影响，而且当我们需要稳定性时，我们往往会遇到脆弱性，这也给工程师的工作带来了负担。一切都通过自动化控制器进行，以及构建它的团队。

这篇博文是我们开始审查和调整项目结构和流程的过程的开始，这样我们才能更好地满足 2024 年及以后的需求。虽然这将导致对 2013 年构思的项目进行更改，但我们、您和行业在过去 10 多年中学到了很多经验教训，我们需要将这些经验教训应用于我们构建一个为未来 10 年做准备的自动化平台的方式。这对于我们继续了解客户如何利用人工智能和自动化以及整个行业如何理解如何在企业用例中利用人工智能尤其重要。我们希望 Ansible 和 Ansible 自动化平台成为这些改进的基础，并在整个 IT 活动生命周期中继续成为一个安全、可扩展的执行平台。

我还想反思一下几周前在丹佛举行的 AnsibleFest 2024 上我们收到的反馈。在 AWX 社区会议期间，我在我们的演示中讨论了改变的必要性，以及我们将专注于增强 Ansible 的功能，做出对 Ansible 未来产生积极影响的良好设计决策，并为 Ansible 自动化平台提供稳定的基础。我和与会者进行了许多后续讨论，讨论了可能性以及我们必须考虑的问题。

因为 Ansible 对我们如此多的客户和用户非常有用，而且您设想了我们没有考虑到的用例，我们非常喜欢这一点，以及 Ansible 所产生的热情。我们过去做出的那些在当时是合理和明智的决定，通常是阻碍您和我们实现更多目标的原因。我对 Ansible 的热情现在与 2013 年一样强烈，我仍然希望在 2033 年的 AnsibleFest 上，对人们能够用我们的技术实现什么感到惊讶。如果我们不改变，我们将成为阻碍 Ansible 生态系统中下一批创新者的因素，这就是为什么我觉得我们现在必须做出这些改变，这样我们才能变得更强大、更灵活，以满足下一代自动化功能的需求，并在未来几年继续进行这些讨论。

接下来会发生什么？

在我们结束之前，我们应该清楚地了解哪些事情不会发生。

我们不会改变 Ansible 项目
我们不会调整我们的 OSS 许可证结构

最终，我们需要对我们的系统工作方式以及项目的结构进行一些更改。不是重写，而是重构和重新组织某些核心组件相互连接和通信的方式。

此时，在我们完成 Ansible 自动化平台的最新版本时，我们有很多想法。我们将开始调查选项，并将在我们确定更改区域、需要输入并做出决策时进行操作。我们将利用与贡献者之间的沟通渠道，通过持续的博客系列与他们分享这些想法和更改，我们可以在其中讨论挑战和优势。

我们意识到，这份沟通将会引发许多问题，其中很多问题我们目前还没有答案。我们请求您的时间、耐心和意见，以便我们在采取这些措施来发展我们的工作。我们希望清楚透明地向您说明我们面临的挑战以及未来的机遇，这些机遇将使 Ansible 生态系统在未来几年继续创新。