红帽 Ansible 自动化平台 2.6 的发布标志着一个关键里程碑。在开始升级之前，您需要了解以下三个重要事项，以便更顺利地完成过渡：
- 这是最后一个包含 RPM 安装程序的版本。采用 RPM 安装方法的红帽 Ansible 自动化平台 2.6 仅适用于红帽企业 Linux（RHEL）9，且 RPM 安装程序将在此版本后停用。Ansible 自动化平台 2.7 将仅支持容器化安装方法、红帽 OpenShift Operator 或我们的云服务，因此建议现在就开始准备过渡。
- Ansible 自动化平台 2.6 是一个基石版本。该平台未来版本的每个升级路径都必须通过 2.6 完成，这是无法绕过的必经之路。
- RHEL 8 支持已终止。如果您仍在使用 RHEL 8，则需要先迁移到 RHEL 9（或 RHEL 10），然后再升级到 Ansible 自动化平台 2.6。
规划升级
在规划过渡到 Ansible 自动化平台 2.6 时，应考虑两个重要因素来制定升级计划：
一次只能变更一项内容。 无论是底层操作系统（OS）、安装方法还是产品版本，安装程序每次运行仅处理一项变更。这意味着您可能需要多次运行安装程序。有关其工作原理的详细信息，请查看官方文档。
大多数情况下需要进行全新安装。 除少数特定场景外（例如在同一架构上从 2.5 升级至 2.6，或在某些红帽 OpenShift Operator 部署中），您都需要部署新的 Ansible 自动化平台 2.6 实例，然后将您的配置迁移到其中。
这就引出了关键问题：如何将现有配置迁移到新实例？要回答这个问题，首先要理解一个事实：Ansible 自动化平台配置存储在 PostgreSQL 数据库中。升级策略的核心就在于如何将这些数据迁移到更新的环境。
升级方法
迁移到 Ansible 自动化平台 2.6 有两条路径：以数据库为中心的迁移，或以 API 为中心的迁移。要做出正确选择，取决于您的环境、具体需求以及您愿意做出的权衡。
以数据库为中心的方法将 Ansible 自动化平台视为有状态系统，其中数据是事实来源。以 API 为中心的方法则将该平台视为配置即代码（CaC），其事实来源位于配置文件中。请参阅下表，评估每种方法的技术注意事项：
以数据库为中心 | 以 API 为中心 | |
理念 | 数据库是事实来源 | 配置即代码是事实来源 |
主要工具 | ansible.containerized_installer 集合与设置脚本（备份、恢复、升级） | ansible.controller 集合、REST API |
基础架构需求 | 如需多次迁移，可能需要中间环境 | 仅需源平台和目标平台 |
迁移内容 | 所有内容，包括作业历史记录、用户、密码、日志等 | 仅配置定义（不包括作业历史记录或日志） |
起始版本 | 必须基于 Ansible 自动化平台 2.4 或更高版本。旧版本需要先升级到 2.4 | 可从任意版本的 Ansible 自动化平台或 Tower 导出（但架构差异可能需要额外处理） |
目标选项 | 任何自助管理式 Ansible 自动化平台（容器化或红帽 OpenShift Operator） | 任何 Ansible 自动化平台，包括托管式云服务产品 |
密钥 | 数据库 SECRET_KEY 自动迁移，保留所有密钥 | 需额外处理（见下文备注） |
技术债务 | 完全继承，包括孤立对象、旧日志等一切内容 | 基于文本的中间状态允许您在导入之前清理、重组或删除对象 |
数据格式 | 自动处理 | 配置文件可能需要在导出和导入格式之间进行编辑 |
以数据库为中心的迁移
以数据库为中心的迁移是经过文档记录且享有全面支持的路径，可在升级过程中保留并迁移整个数据库。其挑战在于需要执行复杂的组合步骤，才能完成这支“升级之舞”。您可能需要从 RHEL 8 迁移到 RHEL 9，从 RPM 迁移到容器化，并从 Ansible 自动化平台 2.4/2.5 迁移到 2.6——其中的每项变更都是一个单独步骤，需要配备各自的基础架构。
在这个过程中，可能需要置备和管理大量中间环境。此外，根据迁移工作的起点与终点目标、环境规模以及所对应的数据库的大小，这项任务可能会非常耗时。
重要提示：如果这种复杂性促使您考虑使用 Ansible 自动化平台的托管式云服务产品，请注意，需要提交支持工单才能将数据库上传到托管服务。相关流程已记录在此处。若要自行完成迁移操作，需要采用以 API 为中心的方法。
以 API 为中心的迁移
这种方法不受红帽正式支持（但实现该迁移技术的各个独立组件受支持）。也就是说，它的速度可能会显著加快，尤其是在大型环境中。由于是直接一步迁移到目标平台，因此无需中间安装。
采用此方法时，需要通过 API 调用导出 Ansible 自动化平台的配置，并将其存储在本地（例如存储在配置文件或临时数据库中）。存储后，可以根据需要修改这些文件，之后也可以通过 API 将配置恢复到另一个平台上。此方法还有一个额外优势：它将配置即代码（CaC）引入您的工作流中，为您今后采用 CaC 方法管理平台奠定了基础。
此方法有哪些需要权衡的方面？您将丢失作业历史记录（可通过外部日志聚合器缓解），并且需要谨慎处理密钥（可通过外部密钥管理器缓解）。您可能还需要编辑导出的配置文件，确保其格式正确以供导入，尤其是私有自动化中心和事件驱动的 Ansible 对象。
关于密钥的备注
凭据和通知密钥存储在配置数据库中，并由数据库 SECRET_KEY 加密。由于这些数据已加密，其值完全无法通过 API 导出。因此，要获取配置中的密钥，必须具备数据库服务器的 root 访问权限。鉴于此操作会以纯文本形式暴露密钥，因此需要极其谨慎地进行处理，例如将密钥重新加密到 Ansible 密钥库中。
但是，如果您使用的是外部密钥管理器（如 HashiCorp Vault），则不会存在此问题，因为这些密钥不会存储在 Ansible 自动化平台中。或者，如果需要管理的密钥较少，也可以直接将密钥填充到新平台中。
两种方法的注意事项
无论您选择哪条路径，都请注意：外部集成和 API 令牌可能需要重点关注。
Ansible 自动化平台 2.5 引入了自动化网关，这是一个统一前端，可将自动化控制器、Ansible 自动化中心和事件驱动的 Ansible 控制器连接到单个接口中。这将许多 API 端点转移到了新路径。虽然 2.6 版本已对这些集成端点保持向后兼容，但在未来版本中，需要对这些端点进行更新。此外，平台发出的大多数令牌将需要重新生成并重新分发，可能需要置备额外服务器，并且负载平衡器也需要更新为新的网关服务。
外部托管的数据库
对于使用外部托管数据库的客户，还有一些注意事项。 首先，Ansible 自动化平台 2.4 使用 Postgres 13，2.5 版本升级为 Postgres 15，2.6 版本则升级为 PostgreSQL 15。此外，Ansible 自动化平台 2.6 还支持客户提供的 PostgreSQL 16 和 17 数据库。此数据库升级流程是迁移和“更新之舞”中的关键考量因素，也是客户必须经历此更新流程才能复用现有数据库的关键原因。 具体而言，对于 Ansible 自动化平台 2.5 及更高版本，客户提供的数据库中必须启用 Unicode 国际组件（ICU）。大多数主流数据库提供商（如 EDB、 Amazon Web Services Relational Database Service（AWS RDS）和 Azure SQL 数据库）虽提供此功能，但默认处于未启用状态。正是这种数据库兼容性问题，导致我们不能只更新现有数据库中的架构。
Playbook 兼容性
升级 Ansible 自动化平台时，默认执行环境中附带的 ansible-core 版本也会随之升级。好消息是，您始终可以在新版本平台上运行旧版执行环境。虽然可以保持向后兼容性，但强烈建议进行升级，以便利用新功能和安全修复。
如果升级执行环境，意味着升级至新版本的 Ansible 核心，这可能会带来一些变化， 具体如下：
从 Ansible 自动化平台 2.4 升级至 2.6（从 ansible-core 2.15 升级至 2.16）
这是次要升级。最显著的变化是，条件语句中的一些警告现已被视为错误。除此之外，影响微乎其微。
升级至 ansible-core 2.18（Ansible 自动化平台 2.6 中的可选执行环境）这是 Ansible 自动化平台 2.6 的一个可选受支持执行环境，此升级会带来更多显著变化。具体包括：
- 目标节点上的 Python 2.7 和 3.6 版本不再受支持。这意味着您无法再使用此执行环境对 RHEL 6 主机进行操作。对于 RHEL 7 主机，需要安装 Python 3.8（可通过红帽软件集合获取），才能使用 Ansible 自动化平台进行自动化。
- 您的执行环境中现在包含的 Python 版本是 Python 3.11。自定义和第三方 Python 库需要更新至兼容 3.11 的库。
- Python 正在推进“废弃电池”清理计划。 在未来几个 Python 版本中，PEP 594 将从标准库中删除无人维护、存在安全隐患和已过时的库。Python 3.11 开始发出弃用警告，版本 3.12 中删除了部分库，版本 3.13 中则删除了大量库。
对于绝大多数客户而言，这并非迫在眉睫的问题，但不妨现在就关注弃用警告，以便您做好应对准备。
有关受支持的 ansible-core 版本的完整详情，请参阅红帽官方支持政策。
过渡到 Ansible 自动化平台 2.6 不仅仅是一次版本更新，更是一项战略举措，为下一代自动化奠定了基础。通过选择最适合您当前基础架构的迁移路径，您可以实现富有弹性的自动化、确保安全防护，并为未来发展做好准备。
其他资源
- 文章： 通过 Python、AsyncIO 和批量操作自动进行 Ansible 自动化平台 2.6 升级
- Ansible 自动化平台发行说明和文档。
- Ansible 自动化平台的新增功能
关于作者
Ryan Bontreger is a Services Architect with Red Hat Consulting. He has been delivering automation solutions for public sector customers with Red Hat since 2015. As a leader on the Americas Automation Platform Services team, Ryan has been designing and delivering Ansible solutions for customers across the globe, with a focus and dedication on the automation developer experience and automation at scale.
