Red Hat Ansible Automation Platform 升级和迁移指南

Red Hat Ansible Automation Platform 2.1

升级到最新版本的 Ansible Automation Platform，并将旧虚拟环境迁移到自动化执行环境

Red Hat Customer Content Services

摘要

提供反馈：
如果您对本文档有任何改进建议，或发现错误，请联系技术支持 https://access.redhat.com，使用 Docs组件在 Ansible Automation PlatformJIRA 项目中创建一个问题。

使开源包含更多

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始：master、slave、黑名单和白名单。由于此项工作十分艰巨，这些更改将在即将推出的几个发行版本中逐步实施。有关更多详情，请参阅我们的首席技术官 Chris Wright 提供的消息。

第 1 章 将隔离节点升级到执行节点

从版本 1.x 升级到 Red Hat Ansible Automation Platform 的最新版本，需要平台管理将数据从隔离的旧节点迁移到执行节点。这个迁移是部署自动化网格所必需的。

本指南介绍了如何对外迁移进行并排迁移。这样可确保在迁移过程中不会修改原始自动化环境中的数据。

迁移过程涉及以下步骤：

  1. 验证升级配置。
  2. 备份原始实例。
  3. 为并行升级部署新实例。
  4. 使用 ansible 控制器在新实例中重新创建实例组。
  5. 将原始备份恢复到新实例。
  6. 设置执行节点，并将实例升级到 Red Hat Ansible Automation Platform 2.1。
  7. 配置升级的控制器实例。

1.1. 升级 Ansible Automation Platform 的先决条件

在开始升级 Ansible Automation Platform 前，请确保您的环境满足以下要求。

1.1.1. 节点要求

Ansible Automation Platform 升级过程涉及的节点需要以下规格：

  • 16 GB RAM，控制器节点、数据库节点、执行节点和跃点 (hop) 节点。
  • 4 个 CPU，用于控制器节点、数据库节点、执行节点和跃点节点。
  • 数据库节点有 150 GB+ 磁盘空间。
  • 非数据库节点有 40 GB+ 磁盘空间。
  • DHCP 保留使用无限租期来部署集群使用静态 IP 地址。
  • 所有节点的 DNS 记录。
  • 为所有节点安装 Red Hat Enterprise Linux 8 或更高的 64 位版本(x86)。
  • 为所有节点配置 chrony。
  • Python 3.8 或更高版本，用于所有内容依赖项。

1.1.2. 自动化控制器配置要求

在进行 Ansible Automation Platform 升级过程前，需要以下自动化控制器配置：

使用 Chrony 配置 NTP 服务器

集群中的每个 Ansible Automation Platform 节点都必须有权访问 NTP 服务器。使用 chronyd 将系统时钟与 NTP 服务器同步。这样可确保如果节点间的日期和时间没有同步，则使用需要验证的 SSL 证书的集群节点不会失败。

这对升级的 Ansible Automation Platform 集群中使用的所有节点都需要：

  1. 安装 chrony ： 

    # dnf install chrony --assumeyes
  2. 使用文本编辑器打开 /etc/chrony.conf。

  3. 找到公共服务器池部分，并将其修改为包含相应的 NTP 服务器地址。只需要一个服务器，但建议使用三个服务器。添加 iburst 选项以加快与服务器正确同步所需的时间： 

    # Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server <ntp-server-address> iburst
  4. 在 /etc/chrony.conf 文件中保存更改。

  5. 启动主机并启用 chronyd 守护进程： 

    # systemctl --now enable chronyd.service

  6. 验证 chronyd 守护进程状态： 

    # systemctl status chronyd.service

在所有节点上附加红帽订阅

Red Hat Ansible Automation Platform 要求您将有效的订阅附加到所有节点。您可以运行以下命令来验证当前节点是否具有红帽订阅： 

# subscription-manager list --consumed

如果没有附加到该节点的红帽订阅，请参阅附加 Ansible Automation Platform 订阅以了解更多信息。

创建具有 sudo 权限的非 root 用户

在升级 Ansible Automation Platform 前，建议为部署过程创建一个具有 sudo 权限的非 root 用户。此用户用于：

  • SSH 连接。
  • 在安装过程中进行免密码身份验证。
  • 权限升级(sudo)权限。

以下示例使用 ansible 命名此用户。在升级的 Ansible Automation Platform 集群的所有节点上，创建一个名为 ansible 的非 root 用户，并生成 ssh 密钥：

  1. 创建非 root 用户： 

    # useradd ansible

  2. 为您的用户设置密码： 

    # passwd ansible 1
Changing password for ansible.
Old Password:
New Password:
Retype New Password:
    1
    如果使用其他名称，将 ansible 替换为第 1 步中的非 root 用户

  3. 以用户身份生成 ssh 密钥： 

    $ ssh-keygen -t rsa

  4. 进行以下操作，以使用户在使用 sudo 时无需输入密码： 

    # echo "ansible ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers.d/ansible

将 SSH 密钥复制到所有节点

创建 ansible 用户后，将 ssh 密钥复制到升级 Ansible Automation Platform 集群中使用的所有节点上。这样可确保 Ansible Automation Platform 安装运行时，它可以在没有密码的情况下 ssh 到所有节点： 

$ ssh-copy-id ansible@node-1.example.com
注意

如果在云供应商中运行，您可能需要创建一个 ~/.ssh/authorized_keys 文件，其中包含所有节点上的 ansible 用户的公钥，并将权限设置为 authorized_keys 文件，使只有所有者（ansible）具有读写权限（权限 600）。

配置防火墙设置

在升级的 Ansible Automation Platform 集群的所有节点上配置防火墙设置，以允许访问成功的 Ansible Automation Platform 升级的适当服务和端口。对于 Red Hat Enterprise Linux 8 或更高版本，启用 firewalld 守护进程以启用所有节点所需的访问权限：

  1. 安装 firewalld 软件包： 

    # dnf install firewalld --assumeyes

  2. 启动 firewalld 服务： 

    # systemctl start firewalld

  3. 启用 firewalld 服务： 

    # systemctl enable --now firewalld

1.1.3. Ansible Automation Platform 配置要求

在进行 Ansible Automation Platform 升级过程前，需要以下 Ansible Automation Platform 配置：

配置执行和跃点节点的防火墙设置

升级 Red Hat Ansible Automation Platform 实例后，在网格节点上添加自动化网格端口（execution 和 hop 节点）以启用自动化网格功能。用于所有节点上的网格网络的默认端口为 27199/tcp。您可以将网格网络配置为使用不同的端口，方法是将 recptor_listener_port 指定为清单文件中每个节点的变量。

在跃点和执行节点中，设置用于安装的 firewalld 端口。

  1. 确保 firewalld 正在运行： 

    $ sudo systemctl status firewalld

  2. 将 firewalld 端口添加到控制器数据库节点（例如，端口 27199）： 

    $ sudo firewall-cmd --permanent --zone=public --add-port=27199/tcp

  3. 重新加载 firewalld ： 

    $ sudo firewall-cmd --reload

  4. 确认端口已打开： 

    $ sudo firewall-cmd --list-ports

1.2. 备份 Ansible Automation Platform 实例

使用 backup_dir 标志运行 .setup.sh 脚本备份现有 Ansible Automation Platform 实例，它会保存当前环境的内容和配置：

  1. 进入 ansible-tower-setup-latest 目录。

  2. 按照以下示例运行 ./setup.sh 脚本： 

    $ ./setup.sh -e ‘backup_dir=/ansible/mybackup’ -e ‘use_compression=True’ @credentials.yml -b 12
    1
    backup_dir 指定将备份保存到的目录。
    2
    @credentials.yml 传递密码变量及其值通过 ansible-vault 加密。

通过成功备份，会在 /ansible/mybackup/tower-backup-latest.tar.gz 处创建一个备份文件。

之后，需要进行这个备份，将内容从您的旧实例迁移到新实例。

1.3. 为并行（side-by-side）升级部署新实例

要进行并行升级过程，请部署第二个 Ansible Tower 3.8.x 实例，并使用相同的实例组配置。此新实例将收到来自您原始实例的内容和配置，之后再升级到 Red Hat Ansible Automation Platform 2.1。

1.3.1. 部署 Ansible Tower 的新实例

要部署新的 Ansible Tower 实例，请执行以下操作：

  1. 进入 Ansible Tower 安装程序页面，下载与您的原始 Tower 实例匹配的 Tower 安装程序版本。

  2. 进入安装程序，使用一个文本编辑器打开 inventory 文件，为 Tower 安装配置 inventory 文件 ：

    1. 除了 Tower 配置外，删除包含 isolated_group 或 instance_group 的任何字段。

      注意

      有关使用 Ansible Automation Platform 安装程序安装 Tower 的更多信息，请参阅 Ansible Automation Platform 安装指南。

  3. 运行 setup.sh 脚本来开始安装。

安装了新实例后，配置 Tower 设置以匹配来自原始 Tower 实例的实例组。

1.3.2. 在新实例中重新创建实例组

要在新实例中重新创建您的实例组，请执行以下操作：

注意

记录来自您原始 Tower 实例的所有实例组。您需要在新实例中重新创建这些组。

  1. 登录到 Tower 的新实例。
  2. 在导航窗格中，选择 Administration → Instance groups。
  3. 点 Create instance group。
  4. 输入与原始实例的实例组匹配的 Name，然后点 Save
  5. 重复上述实例中的所有实例组。

1.4. 将备份恢复到新实例

使用 restore_backup_file 标志运行 ./setup.sh 脚本，将内容从原始 1.x 实例的备份文件迁移到新实例。这会有效地迁移所有作业历史记录、模板和其他 Ansible Automation Platform 相关内容。

流程

  1. 运行以下命令： 

    $ ./setup.sh -r -e ‘restore_backup_file=/ansible/mybackup/tower-backup-latest.tar.gz’ -e ‘use_compression=True’ -e @credentials.yml -r -- --ask-vault-pass 123
    1
    restore_backup_file 指定 Ansible Automation Platform 备份数据库的位置
    2
    use_compression 设置为 True，因为备份过程中使用要使用压缩功能
    3
    -r 将 restore 数据库选项设置为 True

  2. 登录到新的 RHEL 8 Tower 3.8 实例，验证来自您原始实例的内容是否已恢复：

    1. 进入 Administration → Instance Groups。重新创建的实例组现在应包含来自原始实例的 Total Jobs。
    2. 使用侧导航面板，检查您的内容是否已从您的原始实例导入，包括作业、模板、清单、凭证和用户。

现在，您有一个新的 Ansible Tower 实例，其中包含来自您原始实例的所有 Ansible 内容。

您将把这个新实例升级到 Ansible Automation Platform 2.1，以便保留所有之前的数据，而无需覆盖原始实例。

1.5. 升级到 Ansible Automation Platform 2.1

要将 Ansible Tower 实例升级到 Ansible Automation Platform 2.1，请将您的原始 Tower 实例中的 inventory 文件复制到您的新 Tower 实例，并运行安装程序。Red Hat Ansible Automation Platform 安装程序检测到 pre-2.1 清单文件，并提供升级的清单文件以继续升级过程：

  1. 从红帽客户门户网站下载 Red Hat Ansible Automation Platform 的最新安装程序。

  2. 解压文件： 

    $ tar xvzf ansible-automation-platform-setup-<latest-version>.tar.gz

  3. 进入 Ansible Automation Platform 安装目录： 

    $ cd ansible-automation-platform-setup-<latest-version>/

  4. 将原始实例中的 inventory 文件复制到最新安装程序的目录中： 

    $ cp ansible-tower-setup-3.8.x.x/inventory ansible-automation-platform-setup-<latest-version>

  5. 运行 setup.sh 脚本： 

    $ ./setup.sh

    设置脚本将暂停并表明检测到了"pre-2.x"清单文件，但提供了名为 inventory.new.ini 的新文件，允许您继续升级您的原始实例。

  6. 编辑使用文本编辑器打开 inventory.new.ini。

    注意

    通过运行设置脚本，安装程序修改了原始清单文件中的几个字段，如将 [tower] 重命名为 [automationcontroller]。

  7. 通过分配相关变量、节点和相关节点对等连接来修改新生成的 inventory.new.ini 文件来配置自动化网格：

    注意

    自动化网格拓扑的设计取决于您的环境自动化需求。以下示例为自动化网格设计提供了可能的场景，以及自动化网格拓扑的设计取决于您的环境自动化需求。有关设计以满足您的需要的信息，请参阅完整的 Ansible Automation Platform 自动化网格指南。

    包含三个使用跃点节点的标准 control plane 的清单文件示例：

    [automationcontroller]
control-plane-1.example.com
control-plane-2.example.com
control-plane-3.example.com

[automationcontroller:vars]
node_type=control 1
peers=execution_nodes 2


[execution_nodes]
execution-node-1.example.com peers=execution-node-2.example.com
execution-node-2.example.com peers=execution-node-3.example.com
execution-node-3.example.com peers=execution-node-4.example.com
execution-node-4.example.com peers=execution-node-5.example.com node_type=hop
execution-node-5.example.com peers=execution-node-6.example.com node_type=hop 3
execution-node-6.example.com peers=execution-node-7.example.com
execution-node-7.example.com

[execution_nodes:vars]
node_type=execution

    1
    指定运行项目和清单更新和系统作业的控制节点，但不运行常规作业。这些节点上禁用了执行功能。
    2
    在 [execution_nodes] 组中为节点连接指定对等关系。
    3
    指定将流量路由到其他执行节点的跃点节点。hop 节点无法执行自动化。

  8. 为自动化网格配置 inventory.new.ini 后，使用 inventory.new.ini 运行设置脚本： 

    $ ./setup.sh -i inventory.new.ini -e @credentials.yml -- --ask-vault-pass
  9. 安装完成后，通过在所有自动化控制器节点中登录 Ansible Automation Platform 控制面板 UI 来验证 Ansible Automation Platform 是否已成功安装。

其他资源

1.6. 配置升级的 Ansible Automation Platform

1.6.1. 配置自动化控制器实例组

升级 Red Hat Ansible Automation Platform 实例后，通过在自动化控制器 UI 中配置设置将原始实例关联到对应的实例组：

  1. 登录新的 Controller 实例。
  2. 来自旧实例的内容，如凭证、作业和清单，现在在控制器实例上可见。
  3. 进入 Administration → Instance Groups。
  4. 点实例组来关联执行节点，然后点实例选项卡。
  5. 点关联。选择要关联此实例组的节点，然后点 Save。
  6. 您还可以修改默认实例来解除新的执行节点。

第 2 章 迁移到自动化执行环境

2.1. 为什么需要升级到自动化执行环境？

Red Hat Ansible Automation Platform 2.1 引入了自动化执行环境。自动化执行环境是容器镜像，可以通过包括在单一容器内运行 Ansible 自动化所需的所有内容来更轻松地管理 Ansible。自动化执行环境包括：

  • RHEL UBI 8
  • Ansible 2.9 或 Ansible Core 2.11
  • Python 3.8 或更高版本。
  • 任何 Ansible 内容集合
  • 集合 python 或二进制依赖项

通过包含这些元素，Ansible 为平台管理员提供标准化的方法来定义、构建和分发自动化运行环境。

由于新的自动化执行环境，管理员不再需要创建自定义插件和自动化内容。管理员现在只需较少的时间即可启动较小的自动化执行环境，以创建其内容。

现在，所有自定义依赖项都在开发阶段定义，而不是在管理和部署阶段定义。与 control plane 分离，可加快跨环境的开发周期、可扩展性、可靠性和可移动性。借助自动化执行环境，Ansible Automation Platform 可以移至分布式架构，允许管理员在组织内扩展自动化。

2.2. 关于将旧的 venvs 迁移到自动化执行环境

当从旧版本的自动化控制器升级到 4.0 或更高版本时，控制器可以检测之前与机构、清单和作业模板关联的虚拟环境版本，并告知您迁移到新的自动化执行环境模型。新的自动化控制器安装在安装过程中创建两个 virtualenv；一个运行控制器，另一个运行 Ansible。与传统虚拟环境一样，自动化执行环境允许控制器在稳定的环境中运行，同时允许您根据需要在自动化执行环境中添加或更新模块，以运行 playbook。

通过将设置迁移到新的自动化执行环境，您可以将设置复制到以前的自定义虚拟环境中。使用本节中的 awx-manage 命令：

  • 所有当前自定义虚拟环境及其路径列表（list_custom_venvs）
  • 查看依赖特定自定义虚拟环境的资源（custom_venv_associations）
  • 将特定的自定义虚拟环境导出到可用于迁移到自动化执行环境（export_custom_venv）的格式

以下工作流描述了如何使用 awx-manage 命令从旧的 venvs 迁移到自动化执行环境。

2.3. 将虚拟环境迁移到自动化执行环境

升级到 Red Hat Ansible Automation Platform 2.0 和自动化控制器 4.0 后，请使用以下部分协助迁移过程中的其他步骤。

2.3.1. 列出自定义虚拟环境

您可以使用 awx-manage 命令列出自动化控制器实例上的虚拟环境。

流程

  1. SSH 到自动化控制器实例并运行： 

    $ awx-manage list_custom_venvs

这时将显示已发现的虚拟环境列表。 

# Discovered virtual environments:
/var/lib/awx/venv/testing
/var/lib/venv/new_env

To export the contents of a virtual environment, re-run while supplying the path as an argument:
awx-manage export_custom_venv /path/to/venv

2.3.2. 查看与自定义虚拟环境关联的对象

使用 awx-manage 命令，查看与自定义虚拟环境关联的组织、作业和清单源。

流程

  1. SSH 到自动化控制器实例并运行： 

    $ awx-manage custom_venv_associations /path/to/venv

这时将显示相关对象的列表。 

inventory_sources:
- id: 15
  name: celery
job_templates:
- id: 9
  name: Demo Job Template @ 2:40:47 PM
- id: 13
  name: elephant
organizations
- id: 3
  name: alternating_bongo_meow
- id: 1
  name: Default
projects: []

2.3.3. 选择要导出的自定义虚拟环境

选择您要使用 awx-manage export_custom_venv 命令导出的自定义虚拟环境。

流程

  1. SSH 到自动化控制器实例并运行： 

    $ awx-manage export_custom_venv /path/to/venv

此命令的输出将显示在指定虚拟环境中的 pip freeze 状态。此信息可复制到 Ansible Builder 的 requirements.txt 文件中，用于创建新的自动化执行环境镜像 

numpy==1.20.2
pandas==1.2.4
python-dateutil==2.8.1
pytz==2021.1
six==1.16.0

To list all available custom virtual environments run:
awx-manage list_custom_venvs
注意

在运行 awx-manage list_custom_venvs 时传递 -q 标志来减少输出。

2.4. 其他资源

第 3 章 Ansible 内容迁移

如果您要从 ansible-core 版本迁移到 ansible-core 2.12+，请考虑检查 Ansible Core 移植指南，以熟悉每个版本之间的更改和更新。在查看 Ansible 核心端口指南时，请确保选择最新版本的 ansible-core 或 devel，它位于指南的左上方。

有关完全支持和经认证的 Ansible 内容集合列表，请参阅 console.redhat.com 上的 Ansible Automation hub。

3.1. 将 Ansible playbook 和角色迁移到 Core 2.12

当您从基于集合的内容迁移到基于集合的内容时，您应该在 playbook 和角色中使用 Fully Qualified Collection Names(FQCN)以避免意外行为。

带有 FQCN 的 playbook 示例： 

- name: get some info
  amazon.aws.ec2_vpc_net_info:
    region: "{{ec2_region}}"
  register: all_the_info
  delegate_to: localhost
  run_once: true

如果您使用 ansible-core 模块，且没有从不同的集合调用模块，您应该使用 FQCN ansible.builtin.copy。

带有 FQCN 的模块示例： 

- name: copy file with owner and permissions
  ansible.builtin.copy:
  src: /srv/myfiles/foo.conf
  dest: /etc/foo.conf
  owner: foo
  group: foo
  mode: '0644'

法律通告

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.