5 种方法助您为迁移到红帽 Ansible 自动化平台 2 做好准备

红帽® Ansible® 自动化平台 2 为自动化团队引入了已更新的架构、新的工具，并带来了经过改进但依旧熟悉的体验。在您规划迁移策略时，请查看此检查清单中列出的注意事项，为顺利过渡到 Ansible 自动化平台 2 做好准备。

每个环境有着自身独特的配置，因此在迁移之前务必要进行详细的技术评估。

• 分析您当前的 Ansible 自动化平台 1.x 安装情况，包括当前的部署模式 、集成以及任何与迁移相关的复杂事项。
• 确定您的环境所需的更改，以满足 Ansible 自动化平台 2 的技术要求。
• 评估利益相关者对规划与执行迁移的准备情况。
• 确保合规性、安全策略实施与审计。 

Ansible 自动化平台 2 引入了新要求，这些要求将会影响您的迁移策略。如果满足这些要求需要投入巨大的精力，我们建议采取分阶段迁移。

• 自动化控制器 4（替代了 Ansible Tower）仅支持 PostgreSQL 12。不支持 PostgreSQL 10。
• 在物理和虚拟环境中进行安装时，Ansible 自动化平台 2 需要使用红帽企业 Linux® 8 (x86_64)。
• 自动化执行环境将代替 Python 虚拟环境。
• Ansible 自动化平台 2 迁移工具支持最新的 Ansible 自动化平台 1.x 版本。
• Ansible 自动化平台 2 包括 Ansible Core 2.9（用于兼容 playbook），以及通过执行环境提供的最新版本。

您的迁移规划应该考虑到对整个企业的影响。我们建议如下：

• 进行成本效益分析，概述初始迁移成本、持续节省成本以及增加的收入。
• 识别外部和内部利益相关者并确定其可用性。
• 进行风险分析以了解对业务流程与服务交付的影响。
• 确定项目时间范围、重要阶段以及可交付成果。
• 评估利益相关者所需的变更管理与培训。
• 建立迁移成功标准与所需的衡量标准。

您的迁移规划应当评估您当前的 Ansible 自动化平台内容，例如 Ansible 角色、Ansible 内容集、Ansible Playbooks 与模块，并测试它们与 Ansible 自动化平台 2 的兼容性。 此评估至少应：

• 测试并更新自动化内容，以支持 Ansible Core 2.9 或者更高版本。
• 考虑在执行环境中运行自动化时，使用“带有捆绑内容的 Ansible Core 2.9”与使用“Ansibile Core 和经认证或受支持的集合”在技术要求方面的不同。
  • 对于 Ansible Core 2.9，不必要迁移到 Ansible 内容集，但我们建议尽快迁移。
• 规划、测试 Python 虚拟环境 (venvs) 并将其移植到执行环境。
  • 根据成功执行您的 Ansible 内容所需的依赖项，确定是否需要用户构建的执行环境。
  • Ansible 自动化平台 2 提供的访问工具可帮助迁移。
  • 阅读更多关于从 Python 虚拟环境迁移到自动化执行环境的信息。
• 保留、重构或停用现有的自动化内容，例如移动到仅限集合的模型或停用不再使用的内容。

您的迁移规划应包括与现有系统的集成。它还应该评估对您当前运营模式的影响（如有）。在规划迁移时请问自己以下问题：

内容升级工作流

• 什么自动化执行环境版本适合我的模型？（如测试、阶段、最新版本和发行号。）
• 哪种自动化中心（容器镜像仓库）存储库结构最适合我的企业？（例如用于 Ansible 内容集的测试、开发和生产的单独存储库。）
• 我应该使用托管还是私有的自动化中心实例？谁将管理此实例？

平台采用

• 外部利益相关者需要哪些支持才能采用并使用该平台？
• 所有利益相关者加入都需要哪些培训和支持？
• 谁将负责管理执行环境与内容集？是集中管理还是按业务单位管理？

执行环境生命周期管理

• 我应该如何管理并分发 ansible-builder 定义文件？
• 我将如何更新我的执行环境并提供安全防护？修补通用漏洞披露 (CVEs) 并保持合规性的安全响应计划是什么？

平台生命周期管理

• 我将如何部署新集群并提供最低要求？
• 我将如何更新我的集群？我的升级节奏是什么？
• 什么是非功能性要求，这将如何影响我的设计？（示例包括备份、配置管理、灾难恢复 (DR) 与高可用性 (HA)。）

更多信息，请阅读新参考架构：部署红帽 Ansible 自动化平台 2.1。