从 Ansible Automation Platform 2 中的 Python 虚拟环境迁移到自动化执行环境
从 Ansible Automation Platform 2 中的 Python 虚拟环境迁移到自动化执行环境
Red Hat Ansible Tower(包含在 Ansible Automation Platform 1.x 中)使用 Python 虚拟环境来管理依赖项并在多个 Red Hat Ansible Automation Platform 实例之间实现一致的自动化执行。这种管理依赖项的方法也存在一些局限性。
- 在多个 Ansible Tower 实例之间管理 Python 虚拟环境。
- 随着越来越多的最终用户参与,确认 Ansible Tower 实例之间的自定义依赖项变得越来越复杂。
- Python 虚拟环境与控制平面紧密耦合,导致运维团队承担了大部分维护工作。
- 没有 Red Hat 支持和维护的工具来管理 Ansible Automation Platform 部署中的自定义依赖项。
Ansible Automation Platform 2 引入了自动化执行环境。它们是容器镜像,其中包含所有自动化程序的打包和运行,包括 Ansible Core、Ansible Content Collections、Python 版本、Red Hat Enterprise Linux UBI 8 以及任何其他软件包依赖项。
为什么要升级?
Ansible Automation Platform 2,在 AnsibleFest 2021 上宣布,具有重新设计的架构,完全解耦了自动化控制平面和执行平面。新功能使您能够更容易地在全球范围内扩展自动化,并允许您在尽可能靠近源代码的位置运行自动化,而不受限于在单个数据中心中运行自动化。与 Ansible Automation Platform 1.2 相比,它更加动态、可扩展、弹性和安全。
如果您是使用 Ansible Automation Platform 1.2(Ansible Tower 3.8)的现有 Red Hat 客户,一个重要的迁移建议是将集群中的任何自定义 Python 虚拟环境转换为自动化执行环境。这项一次性工作将开启使用最新 Ansible Automation Platform 2 功能的大门,并能够以更低的长期维护成本在多个平台上执行一致的自动化。
我们现在将解释这种特定的迁移考虑因素,并提供一些有关如何迁移到自动化执行环境的最佳实践。
升级的手动流程
如本文档中所述,升级到自动化执行环境的手动流程大致如下
- 前提条件是正在运行的 Ansible Automation Platform 1.2 集群,客户在其中配置了一个或多个自定义 Python 虚拟环境,除了默认环境。
- 使用 Ansible Tower 节点上提供的
awx-manage
命令行实用程序,使用list_custom_venvs
子命令获取自定义 Python 虚拟环境的列表。 - 在每个虚拟环境上运行
awx-manage export_custom_venv
命令,以获取安装在该虚拟环境中的 Python 包的列表。 - 使用
awx-manage custom_venv_associations
命令检查虚拟环境的关联。此关联/信息列表将帮助客户在 Ansible Automation Platform 2.x 集群中建立新执行环境的关联。 - 手动过滤上述信息,并将步骤 3 中的依赖项列表提供给执行环境构建器(ansible-builder)以创建必要的自定义执行环境。
查看上述流程,可以对流程进行两项改进,这将帮助客户更快地采用自动化执行环境。
- 步骤 3 中导出的依赖项可以与已存在于自动化执行环境中的 Python 包列表进行比较,这些 Python 包将作为新创建的自动化执行环境的基础层。这将非常有用,因为基础自动化执行环境将解决一些依赖项,如果客户能够专注于在开始为其集群创建自动化执行环境时 **需要什么**,这将对他们有所帮助。
- 既然我们喜欢 Ansible,为什么不直接自动化上述过程呢?:)
升级的自动化流程
本节旨在说明如何使用 Ansible 自动化此过程。我们有一些示例 Ansible Content Collections 和角色,可用于实现这种自动化。从高层面上看,剧本将类似于以下内容。
- 从 Ansible Automation Platform 1.2 中 Ansible Tower 节点上存在的所有自定义 Python 虚拟环境中提取包列表。
- 将步骤 1 中的包列表与您决定用作基础(我们示例中的 ansible-2.9)的自动化执行环境中的包列表进行比较,以查找基础环境中不存在的包。
- 步骤 2 中的列表可以提供给 Ansible 角色,该角色可以自动执行环境创建,将基础环境保留为我们在步骤 2 中进行比较的环境。
让我们以一个现有的 Ansible Automation Platform 1.2 设置为例,该设置有两个自定义虚拟环境,分别称为 custom-venv1 和 custom-venv2,它们都有自己的 Python 包列表。
# awx-manage export_custom_venv /opt/my-envs/custom-venv1/ -q certifi==2021.10.8 charset-normalizer==2.0.10 enum34==1.1.10 future==0.18.2 idna==3.3 requests==2.27.1 solidfire-sdk-python==12.3.0.203 urllib3==1.26.8 # awx-manage export_custom_venv /opt/my-envs/custom-venv2/ -q zabbix-api==0.5.4
我们将使用打包在 redhat_cop.ee_utilities Collection 中的称为 virtualenv_migrate
的角色,该角色专门用于此目的,并针对 Ansible Tower 节点运行它。下面分别是示例剧本和清单文件。
--- - name: Review custom virtualenvs and diff packages from base EE hosts: tower become: true vars: - venv_migrate_ee_python_list: [] tasks: - name: Include venv_migrate role include_role: name: redhat_cop.ee_utilities.virtualenv_migrate
[tower] ansibletower.demoredhat.com [local] localhost [all:vars] venv_migrate_default_ee_url="registry.redhat.io/ansible-automation-platform-21/ee-29-rhel8:latest" registry_username=myRedHatID registry_password=mypassword
剧本的输出如下所示。它按预期进行了比较,并为我们提供了来自自定义 Python 虚拟环境的包列表,这些包在基础自动化执行环境中不存在。
注意:目前尚未包括 PIP 包的基于版本的比较。
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" ] } ] }
上述输出可以直接传递给同一个 redhat_cop.ee_utilities Collection 中的另一个 Ansible 角色,称为 ee_builder;它的用例是自动化执行环境创建过程。
简单总结一下
- 我们针对 Ansible Tower 节点运行了一个剧本,以收集不在基础自动化执行环境中的 Python 包(来自自定义 Python 虚拟环境)。
- 上述输出可以帮助使用自动执行环境创建的 ee_builder 角色创建自定义自动化执行环境。
主要收获
- 将此新 Ansible 角色与 ee_builder 角色结合使用可以用于自动执行从自定义虚拟环境到自动化执行环境的迁移。
- 这些角色目前是社区项目的一部分,并非由 Red Hat 正式支持。但是,它们可以提供有关迁移过程的理解细节。