如果从旧版本的 automation controller 升级到 4.0 或更高版本,控制器可以检测到与机构、清单和作业模板关联的虚拟环境的以前版本,并通知您需要将它们迁移到新的 execution environment 模型。automation controller 的一个全新安装会在安装过程中创建两个 virtualenv:一个用于运行控制器本身,另一个用于运行 Ansible。与旧的虚拟环境一样,execution environments 允许控制器在一个稳定的环境中运行,同时允许您根据需要在 execution environment 中添加或更新模块以运行 playbook。如需更多信息,请参阅 Automation Controller User Guide 中的 Execution Environments。
重要
升级时,强烈建议您始终在与您使用的平台版本对应的基本 execution environment 上重建。如需更多信息,请参阅 构建一个 Execution Environment。
通过将之前自定义虚拟环境中的设置迁移到新的 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 中的 构建一个 Execution Environment。
从隔离实例组转为执行节点可启用入站或出站连接。这与版本 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
|
如果配置了 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。
If you have already deployed a mesh topology and want to view node type, node health, and specific details about each node, see Topology Viewer in the Automation Controller Administration Guide.