Ansible Automation Platform 1.2 到 2 迁移指南

本节重点介绍了两个环境的架构详情，它们通过并行迁移过程。

第一个环境 环境 A 包括：

此环境的 pictorial 表示如下：

图 1.1. 环境架构概述

第二个环境环境 B 是一个新的和空的 Ansible Automation Platform 1.2 环境，它将用于在升级到 Ansible Automation Platform 2 之前使用 Ansible Automation Platform 1.2 安装程序从 Environment A 导入所有数据。

最初 ，环境 B 包括：

初始 环境 B 占用空间的可疑表示如下：

图 1.2. 初始环境 B 架构概述

当数据从 环境 A 迁移到 环境 B 成功后，我们在升级过程中扩展了 环境 B 架构，包括：

扩展 Ansible Automation Platform 2 环境 B 的全局 视图如下所示：

图 1.3. 环境 B 世界视图

扩展 Ansible Automation Platform 2 环境 B 架构占用空间的详细表示如下：

图 1.4. 扩展环境 B 架构概述

Ansible Automation Platform 1.2 和 Ansible Automation Platform 2 之间的一个关键变化是删除隔离的节点，而是使用跃点节点以及使用自动化网格执行节点。自动化网格是一个覆盖网络，它提供了一种简单、灵活且可靠的方式，可在不同网络拓扑、平台和区域间扩展大型清单的自动化。自动化网格提供灵活的设计选项，可构建弹性和容错架构，同时提供增强安全性，以便在整个 IT estate 标准化和规范自动化。

在本参考环境中，我们捕获迁移使用隔离节点和第三方工具（如 SSH 代理和跳过主机）的 Ansible Automation Platform 1.2 的步骤，以使用自动化网格跃点和执行节点升级到 Ansible Automation Platform 2。

使用自动化网格和执行节点需要在防火墙中打开额外的端口。

另一个重要的考虑因素是数据库可支持性。随着自动化控制器的引入，引入 Postgres 12 数据库的要求。如果您的现有 Postgres 10 数据库由 Ansible Automation Platform 1.2 安装/管理，则 Ansible Automation Platform 2 的升级过程会处理 Postgres 数据库升级到新版本 12。

如果您管理自己的 Postgres 10 数据库，则需要：

除了隔离节点和数据库可支持性的关键考虑外，还有 Ansible Automation Platform 2 中删除的功能列表。列表包括：

当您评估将环境迁移到 Ansible Automation Platform 1.2 的过程到 Ansible Automation Platform 2 时，在 Ansible 内容（收集、模块、角色、插件等）时可能会有额外的注意事项。

这些注意事项不仅限于此列表，而是包括以下内容：

采用新的 Ansible Automation Platform 架构后，务必要计划如何集成新设计的 Ansible Automation Platform 环境。

有答案的关键问题包括：

虽然这些只是几个示例，但关键问题需要回答以确保为您的组织提供成功策略。

Ansible Automation Platform 2 需要分配给运行 control plane 作业的自动化控制器实例和网格 worker 节点之间直接网络连接。

要访问 Ansible Automation Platform 仪表板，需要一个可以访问 control plane 节点所在的网络的浏览器。如果要从外部访问 Ansible Automation Platform 仪表板，请确保在 control plane 节点中添加公共 IP 地址。

建议网络管理员为所有节点和适当的 DNS 记录提供专用 IP 地址。网络管理员可以为节点分配静态 IP 地址，并将 DHCP 服务器配置为使用无限租期保留 IP，或者网络管理员应确保分配的 IP 地址是排除范围的一部分。这样可确保在没有 DHCP 服务器时每个节点的 IP 地址保持恒定状态。注意：为此参考架构、DHCP 服务器的设置、设置 DNS 记录和设置负载均衡器超出范围。

网络管理员应至少保留以下 IP 地址数，包括：

此参考环境为每个站点保留 13 个 IP 地址。

下表提供了参考环境的 Environment B 示例。

以下是所有要求的概述：

此参考架构侧重于将 Ansible Automation Platform 1.2 迁移到 Ansible Automation Platform 2。该配置旨在提供一个全面的 Ansible Automation Platform 解决方案，涵盖 isde-side migration scenarios。本参考构架中涵盖的关键解决方案组件包括：

# subscription-manager register --username [User] --password '[Password]'
The system has been registered with id: abcd1234-ab12-ab12-ab12-481ba8187f60

# subscription-manager list --available | grep -A8 "Red Hat Ansible Automation Platform"
---
Subscription Name:   Red Hat Ansible Automation Platform, Premium (5000 Managed Nodes)
Provides:            Red Hat Ansible Engine
                     Red Hat Single Sign-On
                     Red Hat Ansible Automation Platform
SKU:                 MCT3695
Contract:            <contract>
Pool ID:             <pool_id>
Provides Management: No
Available:           9990
Suggested:           1
Service Type:        L1-L3
Roles:

# subscription-manager attach --pool <pool_id>
Successfully attached a subscription for: Red Hat Ansible Automation Platform, Premium (5000 Managed Nodes)

# subscription-manager repos --enable=ansible-automation-platform-2.1-for-rhel-8-x86_64-rpms

$ ssh-copy-id ansible@hostname.example.com

当环境 A 中的 Ansible Automation Platform 1.2 环境 包含我们的所有数据时，以下命令会在 环境 A 上使用 Ansible Automation Platform 安装程序创建备份。

在 环境 A 中，

在 环境 A 创建并可用时，以下使用环境 B 上的 Ansible Automation Platform 安装程序导入备份的 Ansible Automation Platform 数据库。

在 环境 B 中，

成功导入 Ansible Automation Platform 数据库后，迁移过程中的最后一步是将 环境 B Ansible Automation Platform 1.2 环境升级到 Ansible Automation Platform 2，并扩展环境 B 的架构，如 图 1.4 “扩展环境 B 架构概述” 所示。

在 环境 B 中，

完成升级过程后，您需要将您的实例关联到对应的实例组，例如 sacramento 和 new-delhi。

对 new-delhi 实例组重复该过程，并将以下实例与 new-delhi 实例组关联：

完成后，在 default 组中取消关联这些实例。

默认 实例组应该只包含以下实例：

完成基础架构迁移后，重点是将 Python 虚拟环境迁移到用户构建的执行环境。

为简单起见，我们包括通过运行 Ansible 命令自动化流程的补充 Ansible Playbook。

为实现完整性，手动过程包括：

自动过程包括：

要运行可能如下所示的情况，我们来看以下示例。

在我们现有的 Ansible Automation Platform 1.2 中，有两个自定义 Python 虚拟环境标记为 custom-venv1 和 custom-venv2。

使用打包在 redhat_cop.ee_utilities 集合中的 角色 virtualenv_migrate，我们将通过 ssh 访问 Ansible Tower 节点来提取软件包及其当前没有与基础执行环境(Ansible 2.9 执行环境进行比较)中的软件包及其版本。

下面分别找到环境的 playbook 和清单文件示例：

---
- name: Review custom virtualenvs and pull requirements
  hosts: enva_tower
  become: true
  tasks:
    - name: Include venv role
      include_role:
        name: redhat_cop.ee_utilities.virtualenv_migrate

[tower]
ansibletower.example.com
ansible_ssh_private_key_file=/path/to/example.pem


[all:vars]
###############################################################################
# Required configuration variables for migration from venv -> EE              #
###############################################################################

# The default URL location to the execution environment (Default Ansible 2.9)
# If you want to use the newest Ansible base, change to: ee-minimal-rhel8:latest
venv_migrate_default_ee_url="registry.redhat.io/ansible-automation-platform-21/ee-29-rhel8:latest"

# User credential for access to venv_migrate_default_ee_url
registry_username='myusername'

Ansible playbook 的示例输出显示每个自定义 Python 虚拟环境所需的附加软件包列表。在这种情况下，custom-venv1 Python 虚拟环境还需要以下软件包，而其他软件包已是 Ansible 2.9 执行环境的一部分：

虽然 custom-venv2 Python 虚拟环境除了已经属于标准 Ansible-2.9 执行环境的一部分外，还需要 zabbix-api。

TASK [redhat_cop.tower_utilities.virtualenv_migrate : diff | Show the packages that are extra from default EEs in custom venvs.] ******************************************************************************
ok: [3.228.23.40 -> localhost] => {
    "msg": [
        {
            "/opt/my-envs/custom-venv1/": [
                "certifi",
                "charset-normalizer",
                "enum34",
                "future",
                "solidfire-sdk-python"
            ]
        },
        {
            "/opt/my-envs/custom-venv2/": [
                "zabbix-api"
            ]
        }
    ]
}

在为每个自定义 Python 虚拟环境捕获软件包后，Ansible playbook 将使用作为 redhat_cop.ee_utilities 集合一部分的 ee_ builder 角色，该角色可在本地用户环境中自动创建执行环境。

在运行提供的 Ansible playbook 之前，在 localhost 机器上安装 ansible-builder，playbook 运行会根据自定义 Python 虚拟环境和提供的基本执行环境的软件包 delta 创建执行环境。

$ podman images

REPOSITORY                           TAG                IMAGE ID
localhost/custom-venv2               latest             c017418d1919
localhost/custom-venv1               latest             7cbe3b49974d
localhost/custom-venv                latest             9d5d809f38b0

$ podman login [automation-hub-url]
# Enter the username and password to access Private Automation Hub.
$ podman tag [image-id] [automation-hub-url]/[container image name]
$ podman push [automation-hub-url]/[container image name]