3. 升级至执行环境¶
如果从旧版本的 automation controller 升级到 4.0 或更高版本，控制器可以检测到与机构、清单和作业模板关联的虚拟环境的以前版本，并通知您需要将它们迁移到新的 execution environment 模型。automation controller 的一个全新安装会在安装过程中创建两个 virtualenv：一个用于运行控制器本身，另一个用于运行 Ansible。与旧的虚拟环境一样，execution environments 允许控制器在一个稳定的环境中运行，同时允许您根据需要在 execution environment 中添加或更新模块以运行 playbook。如需更多信息，请参阅 Automation Controller User Guide 中的 执行环境。
重要
升级时，强烈建议您始终在与您使用的平台版本对应的基本 execution environment 上重建。如需更多信息，请参阅 构建一个执行环境。
3.1. 将旧的 venvs 迁移到执行环境¶
通过将之前自定义虚拟环境中的设置迁移到新的 execution environment，您在 execution environment 中会有一个和以前一样的设置。使用本节中的 awx-manage 命令：
所有当前自定义虚拟环境及其路径列表（
list_custom_venvs）查看依赖特定自定义虚拟环境的资源（
custom_venv_associations）将特定的自定义虚拟环境导出为可用于迁移到 execution environment 的格式（
export_custom_venv）
在迁移前，建议您使用
awx-manage list命令查看所有当前运行的自定义虚拟环境：
$ awx-manage list_custom_venvs
以下是运行这个命令时的输出示例：
以上输出显示了三个自定义虚拟环境及其路径。如果您有一个没有位于默认 /var/lib/awx/venv/ 目录路径中的自定义虚拟环境，则它不会包含在这个输出中。
使用
_associations命令查看自定义虚拟环境关联的机构、作业和清单源，以确定哪些资源依赖它们：
$ awx-manage custom_venv_associations /this/is/the/path/
以下是运行这个命令时的输出示例：
为您要迁移的虚拟环境选择一个路径，并在
awx-manage export命令中指定：
$ awx-manage export_custom_venv /this/is/the/path/
生成的输出实际上就是执行 pip freeze 命令的结果。示例显示了所选自定义虚拟环境的内容：
注解
这些命令都可使用 -q 选项运行，该选项会删除每个输出中提供的指导性内容。
现在，您已拥有这个 pip freeze 数据的输出，您可以将这些数据粘贴到一个定义文件中，该文件可以使用 ansible-builder 来启动您的新 execution environment。任何人（包括普通用户和管理员）都可以使用 ansible-builder 创建一个 execution environment。详情请查看 Automation Controller User Guide 中的 构建一个执行环境。
3.2. 将隔离实例迁移到执行节点¶
从隔离实例组转为执行节点可启用入站或出站连接。这与版本 3.8 及更早版本不同，在以前的版本中，只有控制器节点到隔离节点的出站连接被允许。
将旧的隔离实例组迁移到执行节点以便在 4.1 中的 automation controller 网格架构中正常工作，是安装程序的 preflight 功能，它根据旧文件创建清单文件。虽然 .ini 和 .yml 文件仍然被接受，但生成的文件输出目前仅为 .ini 文件。
preflight 会检查对 Ansible 的使用；Ansible 扁平化子概念，这意味着，并非每一个清单文件都可以被完全准确复制，但非常接近。它虽然看上去可能有所不同，但从功能上讲与 Ansible 相同，但可能与您不同。 自动进行的 preflight 处理会“智能地”创建子关系，但请注意，该工具可能无法象人一样完全准确地创建。因此，创建文件后，**不要**在没有进行检查的情况下原样使用该文件。请检查生成的文件，并将它作为模板使用，以确保它们适用于您和 Ansible 引擎。
以下是 preflight 检查前后的一个示例，演示了 Ansible 如何扁平化清单文件，以及安装程序如何重建新的清单文件。对于 Ansible，这些文件基本上都是相同的。
旧格式（来自 Ansible 文档） |
新样式（由安装程序生成） |
|---|---|
[tower]
localhost ansible_connection=local
[database]
[all:vars]
admin_password='******'
pg_host=''
pg_port=''
pg_database='awx'
pg_username='awx'
pg_password='******'
rabbitmq_port=5672
rabbitmq_vhost=tower
rabbitmq_username=tower
rabbitmq_password='******'
rabbitmq_cookie=cookiemonster
# Needs to be true for fqdns and ip addresses
rabbitmq_use_long_name=false
[isolated_group_restrictedzone]
isolated-node.c.towertest-188910.internal
[isolated_group_restrictedzone:vars]
controller=tower
|
[all:vars]
admin_password='******'
pg_host=''
pg_port=''
pg_database='awx'
pg_username='awx'
pg_password='******'
rabbitmq_port=5672
rabbitmq_vhost='tower'
rabbitmq_username='tower'
rabbitmq_password='******'
rabbitmq_cookie='cookiemonster'
rabbitmq_use_long_name='false'
# In AAP 2.X [tower] has been renamed to [automationcontroller]
# Nodes in [automationcontroller] will be hybrid by default, capable of executing user jobs.
# To specify that any of these nodes should be control-only instead, give them a host var of `node_type=control`
[automationcontroller]
localhost
[automationcontroller:vars]
# in AAP 2.X the controller variable has been replaced with `peers`
# which allows finer grained control over node communication.
# `peers` can be set on individual hosts, to a combination of multiple groups and hosts.
peers='instance_group_restrictedzone'
ansible_connection='local'
# in AAP 2.X isolated groups are no longer a special type, and should be renamed to be instance groups
[instance_group_restrictedzone]
isolated-node.c.towertest-188910.internal
[instance_group_restrictedzone:vars]
# in AAP 2.X Isolated Nodes are converted into Execution Nodes using node_state=iso_migrate
node_state='iso_migrate'
# In AAP 2.X Execution Nodes have replaced isolated nodes. All of these nodes will be by default
# `node_type=execution`. You can specify new nodes that cannot execute jobs and are intermediaries
# between your control and execution nodes by adding them to [execution_nodes] and setting a host var
# `node_type=hop` on them.
[execution_nodes]
[execution_nodes:children]
instance_group_restrictedzone
|
3.3. 查看网格拓扑¶
如果配置了 mesh 拓扑，安装程序可以通过生成的图形渲染工具以图形方式验证网格配置。相关的图会根据清单文件的内容生成。如需更多详情，请参阅 Red Hat Ansible Automation Platform automation mesh guide <https://access.redhat.com/documentation/en-us/red_hat_ansible_automation_platform/2.1/html/red_hat_ansible_automation_platform_automation_mesh_guide/index>。
任何给定清单文件都必须包含某种执行能力，这些执行能力由至少一个控制 node 管理。 也就是说，不能生成一个仅包含控制节点、或仅包含执行节点、或仅包含跃点的点的清单文件。 控制节点和执行节点之间紧密耦合的关系必须始终保持。 如果未正确定义清单文件，安装程序将失败。 此规则的唯一例外是单个混合节点，因为它能够满足控制和执行限制。
要在执行节点上运行作业，安装程序需要预注册该节点，或者用户需要向 /api/v2/instances/N/ 发出 PATCH 请求，以将已启用的字段更改为 true。
如果您已经部署了网格拓扑，并希望查看节点类型、节点健康状况以及每个节点的具体详情，请参阅 Automation Controller Administration Guide 中的 拓扑视图。