红帽® Ansible® 自动化平台 2 为自动化团队引入了已更新的架构、新的工具，并带来了经过改进但依旧熟悉的体验。在您规划迁移策略时，请查看此检查清单中列出的注意事项，为顺利过渡到 Ansible 自动化平台 2 做好准备。
1 评估您当前的环境
每个环境有着自身独特的配置，因此在迁移之前务必要进行详细的技术评估。
- 分析您当前的 Ansible 自动化平台 1.x 安装情况，包括当前的部署模式 、集成以及任何与迁移相关的复杂事项。
- 确定您的环境所需的更改，以满足 Ansible 自动化平台 2 的技术要求。
- 评估利益相关者对规划与执行迁移的准备情况。
- 确保合规性、安全策略实施与审计。
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），以及通过执行环境提供的最新版本。
3 让团队做好准备
您的迁移规划应该考虑到对整个企业的影响。我们建议如下：
- 进行成本效益分析，概述初始迁移成本、持续节省成本以及增加的收入。
- 识别外部和内部利益相关者并确定其可用性。
- 进行风险分析以了解对业务流程与服务交付的影响。
- 确定项目时间范围、重要阶段以及可交付成果。
- 评估利益相关者所需的变更管理与培训。
- 建立迁移成功标准与所需的衡量标准。
4 为您的自动化内容做好迁移准备
您的迁移规划应当评估您当前的 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 虚拟环境迁移到自动化执行环境的信息。
- 保留、重构或停用现有的自动化内容，例如移动到仅限集合的模型或停用不再使用的内容。
5 集成到现有的工作流中
您的迁移规划应包括与现有系统的集成。它还应该评估对您当前运营模式的影响（如有）。在规划迁移时请问自己以下问题：
内容升级工作流
- 什么自动化执行环境版本适合我的模型？（如测试、阶段、最新版本和发行号。）
- 哪种自动化中心（容器镜像仓库）存储库结构最适合我的企业？（例如用于 Ansible 内容集的测试、开发和生产的单独存储库。）
- 我应该使用托管还是私有的自动化中心实例？谁将管理此实例？
平台采用
- 外部利益相关者需要哪些支持才能采用并使用该平台？
- 所有利益相关者加入都需要哪些培训和支持？
- 谁将负责管理执行环境与内容集？是集中管理还是按业务单位管理？
执行环境生命周期管理
- 我应该如何管理并分发 ansible-builder 定义文件？
- 我将如何更新我的执行环境并提供安全防护？修补通用漏洞披露 (CVEs) 并保持合规性的安全响应计划是什么？
平台生命周期管理
- 我将如何部署新集群并提供最低要求？
- 我将如何更新我的集群？我的升级节奏是什么？
- 什么是非功能性要求，这将如何影响我的设计？（示例包括备份、配置管理、灾难恢复 (DR) 与高可用性 (HA)。）
更多信息，请阅读新参考架构：部署红帽 Ansible 自动化平台 2.1。
