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

从 Ansible Automation Platform 2.1 或更高版本升级到 2.4 版本涉及下载安装软件包，然后执行以下步骤：

从 Ansible Automation Platform 2.0 或更早版本升级到 2.4 版本需要您迁移 Ansible 内容以获得兼容性。

以下步骤提供旧的升级过程概述：

在开始升级过程前，请查看以下注意事项，以计划并准备 Ansible Automation Platform 部署：

自动化控制器

Automation hub

Event-Driven Ansible 控制器

根据您的 Red Hat Enterprise Linux 环境互联网连接，选择您需要的 Red Hat Ansible Automation Platform 安装程序。查看以下场景，并决定哪个 Red Hat Ansible Automation Platform 安装程序满足您的需要。

Tarball 安装

RPM 安装

使用 RPM 安装程序时，文件位于 /opt/ansible-automation-platform/installer 目录下。

在升级 Red Hat Ansible Automation Platform 安装前，请编辑 inventory 文件，使其与您的所需配置匹配。您可以从现有 Ansible Automation Platform 部署中保留相同的参数，或者修改参数以匹配环境的任何更改。

在更新了 inventory 文件后，您可以运行设置脚本。

安装将开始。

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

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

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

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

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

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

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

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

# 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

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: []

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

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

# subscription-manager list --consumed

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

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

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

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

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

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

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

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

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

作为从较早 Ansible 版本迁移到更新的版本的一部分，您需要查找并下载包含您使用的模块的集合。找到该集合列表后，您可以使用以下选项之一在本地包含集合：

当您从基于集合的内容迁移到基于集合的内容时，您应该在 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'

您将以 aape1.local 执行节点为目标来运行此作业，因为底层主机已经有这个问题。

[awx@aape1 ~]$ ls -la /mydata/
total 4
drwxr-xr-x.  2 awx  awx   41 Apr 28 09:27 .
dr-xr-xr-x. 19 root root 258 Apr 11 15:16 ..
-rw-r--r--.  1 awx  awx   33 Apr 11 12:34 file_read
-rw-r--r--.  1 awx  awx    0 Apr 28 09:27 file_write

您将使用简单的 playbook 启动自动化，并定义 sleep 来供您访问，并了解进程，并演示读取和写入文件。

# vim:ft=ansible:

- hosts: all
  gather_facts: false
  ignore_errors: yes
  vars:
    period: 120
    myfile: /mydata/file
  tasks:
    - name: Collect only selected facts
      ansible.builtin.setup:
        filter:
          - 'ansible_distribution'
          - 'ansible_machine_id'
          - 'ansible_memtotal_mb'
          - 'ansible_memfree_mb'
    - name: "I'm feeling real sleepy..."
      ansible.builtin.wait_for:
        timeout: "{{ period }}"
      delegate_to: localhost
    - ansible.builtin.debug:
        msg: "Isolated paths mounted into execution node: {{ AWX_ISOLATIONS_PATHS }}"
    - name: "Read pre-existing file..."
      ansible.builtin.debug:
        msg: "{{ lookup('file', '{{ myfile }}_read'
    - name: "Write to a new file..."
      ansible.builtin.copy:
        dest: "{{ myfile }}_write"
        content: |
          This is the file I've just written to.

    - name: "Read written out file..."
      ansible.builtin.debug:
        msg: "{{ lookup('file', '{{ myfile }}_write') }}"

在 Ansible Automation Platform 2 导航面板中，选择 Settings。然后从 Jobs 选项中选择 Job settings。

公开隔离任务的路径：

[
"/mydata:/mydata:rw"
]

卷挂载在容器中使用相同的名称进行映射，并具有读写功能。这将在启动作业模板时使用。

prompt on launch 应该为 extra_vars 设置，以便您可以调整每次运行的 sleep 持续时间，默认为 30 秒。

启动后，会调用 wait_for 模块作为睡眠状态，您可以进入执行节点并查看正在运行的内容。

要验证运行是否已成功完成，请运行以下命令以获得作业的输出：

$ podman exec -it 'podman ps -q' /bin/bash
bash-4.4#

您现在位于运行的执行环境容器中。

查看权限，您会看到 awx 已变为 'root'，但这并不像在超级用户中一样真正是 root 用户，因为您使用无根 Podman，这会将用户映射到与沙盒类似的内核命名空间中。了解更多有关 rootless Podman 工作方式的信息，适用于 shadow-utils。

bash-4.4# ls -la /mydata/
Total 4
drwxr-xr-x. 2 root root 41 Apr 28 09:27 .
dr-xr-xr-x. 1 root root 77 Apr 28 09:40 ..
-rw-r—--r–. 1 root root 33 Apr 11 12:34 file_read
-rw-r—--r–. 1 root root  0 Apr 28 09:27 file_write

根据结果，此作业会失败。为了了解原因，需要检查剩余的输出。

TASK [Read pre-existing file…]******************************* 10:50:12
ok: [localhost] =>  {
    “Msg”: “This is the file I am reading in.”

TASK {Write to a new file...}********************************* 10:50:12
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: PermissionError: [Errno 13] Permission denied: b'/mydata/.ansible_tmpazyqyqdrfile_write' -> b' /mydata/file_write'
Fatal: [localhost]: FAILED! => {"changed": false, :checksum": "9f576o85d584287a3516ee8b3385cc6f69bf9ce", "msg": "Unable to make b'/root/.ansible/tmp/anisible-tim-1651139412.9808054-40-91081834383738/source' into /mydata/file_write, failed final rename from b'/mydata/.ansible_tmpazyqyqdrfile_write': [Errno 13] Permission denied: b'/mydata/.ansible_tmpazyqyqdrfile_write' -> b'/mydata/file_write}
...ignoring

TASK [Read written out file...] ****************************** 10:50:13
Fatal: [localhost]: FAILED: => {"msg": "An unhandled exception occurred while running the lookup plugin 'file'. Error was a <class 'ansible.errors.AnsibleError;>, original message: could not locate file in lookup: /mydate/file_write. Vould not locate file in lookup: /mydate/file_write"}
...ignoring

作业失败，即使设置了 :rw，因此它应具有写入功能。进程能够读取现有的文件，但不能写出。这是因为 SELinux 保护要求将正确的标签放在挂载到容器中的卷内容上。如果缺少标签，SELinux 可能会阻止进程在容器内运行。Podman 不会更改操作系统设置的标签。如需更多信息，请参阅 Podman 文档。

这可以是常见的错误解释器。我们已将默认值设置为 :z，它会告知 Podman 在共享卷上重新标记文件对象。

因此，我们可以添加 :z 或将其关闭。

公开隔离任务的路径：

[
   "/mydata:/mydata"
]

playbook 现在可以正常工作：

PLAY [all] **************************************************** 11:05:52
TASK [I'm feeling real sleepy. . .] *************************** 11:05:52
ok: [localhost]
TASK [Read pre-existing file...] ****************************** 11:05:57
ok: [localhost] =>  {
	"Msg": "This is the file I'm reading in."
}
TASK [Write to a new file…] ********************************** 11:05:57
ok: [localhost]
TASK [Read written out file…] ******************************** 11:05:58
ok: [localhost] =>  {
      “Msg”: “This is the file I’ve just written to.”

返回到底层执行节点主机，我们有新写入的内容。

启用后，这将将其注入用于执行的 pod 规格中的 volumeMounts 和卷。它类似如下：

apiVersion: v1
kind: Pod
Spec:
   containers:
   - image: registry.redhat.io/ansible-automation-platform-24/ee-minimal-rhel8
  args:
    - ansible runner
    - worker
    - –private-data-dir=/runner
  volumeMounts:
mountPath: /mnt2
name: volume-0
readOnly: true
mountPath: /mnt3
name: volume-1
readOnly: true
mountPath: /mnt4
name: volume-2
readOnly: true
volumes:
hostPath:
  path: /mnt2
  type: “”
name: volume-0
hostPath:
  path: /mnt3
  type: “”
name: volume-1
hostPath:
  path: /mnt4
  type: “”
name: volume-2

运行的容器内的存储使用覆盖文件系统。运行的容器中的任何修改都会在作业完成后销毁，就像被卸载的 tmpfs 一样。

将本地自动化控制器文件系统视为计数器产品，因为这会将数据绑定到该主机。如果您有多节点集群，那么您可以在每次联系不同的主机，如果创建依赖于其他和创建的目录的工作流，则会导致问题。例如，如果在另一个节点运行 playbook 时只在一个节点中创建目录，则结果将不一致。

该解决方案是使用某种形式的共享存储解决方案，如 Amazon S3、Gist 或您的数据端点的 rsync 数据的角色。

选项存在在运行时将数据或配置注入容器中。这可以通过使用自动化控制器的隔离作业路径选项来实现。

这提供了在运行时将目录和文件挂载到执行环境的方法。这可以通过自动化网格来实现，使用 ansible-runner 将它们注入 Podman 容器以启动自动化。以下是使用隔离作业路径的一些用例：

使用率有一些注意事项：

需要仔细观察到注意事项。强烈建议您对无根 Podman 和 Podman 卷挂载选项、隔离作业路径的 [:OPTIONS] 部分进行读取，因为这是 Ansible Automation Platform 2 中使用的内容。

[awx@aape1 ~]$ ls -la /mydata/
total 4
drwxr-xr-x.  2 awx  awx   41 Apr 28 09:27 .
dr-xr-xr-x. 19 root root 258 Apr 11 15:16 ..
-rw-r--r--.  1 awx  awx   33 Apr 11 12:34 file_read
-rw-r--r--.  1 awx  awx    0 Apr 28 09:27 file_write

# vim:ft=ansible:

- hosts: all
  gather_facts: false
  ignore_errors: yes
  vars:
    period: 120
    myfile: /mydata/file
  tasks:
    - name: Collect only selected facts
      ansible.builtin.setup:
        filter:
          - 'ansible_distribution'
          - 'ansible_machine_id'
          - 'ansible_memtotal_mb'
          - 'ansible_memfree_mb'
    - name: "I'm feeling real sleepy..."
      ansible.builtin.wait_for:
        timeout: "{{ period }}"
      delegate_to: localhost
    - ansible.builtin.debug:
        msg: "Isolated paths mounted into execution node: {{ AWX_ISOLATIONS_PATHS }}"
    - name: "Read pre-existing file..."
      ansible.builtin.debug:
        msg: "{{ lookup('file', '{{ myfile }}_read'
    - name: "Write to a new file..."
      ansible.builtin.copy:
        dest: "{{ myfile }}_write"
        content: |
          This is the file I've just written to.

    - name: "Read written out file..."
      ansible.builtin.debug:
        msg: "{{ lookup('file', '{{ myfile }}_write') }}"

[
"/mydata:/mydata:rw"
]

$ podman exec -it 'podman ps -q' /bin/bash
bash-4.4#

bash-4.4# ls -la /mydata/
Total 4
drwxr-xr-x. 2 root root 41 Apr 28 09:27 .
dr-xr-xr-x. 1 root root 77 Apr 28 09:40 ..
-rw-r—--r–. 1 root root 33 Apr 11 12:34 file_read
-rw-r—--r–. 1 root root  0 Apr 28 09:27 file_write

TASK [Read pre-existing file…]******************************* 10:50:12
ok: [localhost] =>  {
    “Msg”: “This is the file I am reading in.”

TASK {Write to a new file...}********************************* 10:50:12
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: PermissionError: [Errno 13] Permission denied: b'/mydata/.ansible_tmpazyqyqdrfile_write' -> b' /mydata/file_write'
Fatal: [localhost]: FAILED! => {"changed": false, :checksum": "9f576o85d584287a3516ee8b3385cc6f69bf9ce", "msg": "Unable to make b'/root/.ansible/tmp/anisible-tim-1651139412.9808054-40-91081834383738/source' into /mydata/file_write, failed final rename from b'/mydata/.ansible_tmpazyqyqdrfile_write': [Errno 13] Permission denied: b'/mydata/.ansible_tmpazyqyqdrfile_write' -> b'/mydata/file_write}
...ignoring

TASK [Read written out file...] ****************************** 10:50:13
Fatal: [localhost]: FAILED: => {"msg": "An unhandled exception occurred while running the lookup plugin 'file'. Error was a <class 'ansible.errors.AnsibleError;>, original message: could not locate file in lookup: /mydate/file_write. Vould not locate file in lookup: /mydate/file_write"}
...ignoring

[
   "/mydata:/mydata"
]

PLAY [all] **************************************************** 11:05:52
TASK [I'm feeling real sleepy. . .] *************************** 11:05:52
ok: [localhost]
TASK [Read pre-existing file...] ****************************** 11:05:57
ok: [localhost] =>  {
	"Msg": "This is the file I'm reading in."
}
TASK [Write to a new file…] ********************************** 11:05:57
ok: [localhost]
TASK [Read written out file…] ******************************** 11:05:58
ok: [localhost] =>  {
      “Msg”: “This is the file I’ve just written to.”

apiVersion: v1
kind: Pod
Spec:
   containers:
   - image: registry.redhat.io/ansible-automation-platform-24/ee-minimal-rhel8
  args:
    - ansible runner
    - worker
    - –private-data-dir=/runner
  volumeMounts:
mountPath: /mnt2
name: volume-0
readOnly: true
mountPath: /mnt3
name: volume-1
readOnly: true
mountPath: /mnt4
name: volume-2
readOnly: true
volumes:
hostPath:
  path: /mnt2
  type: “”
name: volume-0
hostPath:
  path: /mnt3
  type: “”
name: volume-1
hostPath:
  path: /mnt4
  type: “”
name: volume-2