从 Python 虚拟环境迁移到 Ansible 自动化平台 2 中的自动化执行环境
Red Hat Ansible Tower(包含在 Ansible 自动化平台 1.x 中)使用 Python 虚拟环境来管理依赖项并在多个 Red Hat Ansible 自动化平台实例中实施一致的自动化执行。这种管理依赖项的方法有其自身的局限性
- 在多个 Ansible Tower 实例中管理 Python 虚拟环境。
- 随着更多最终用户与其交互,确认 Ansible Tower 实例中的自定义依赖项变得越来越复杂。
- Python 虚拟环境与控制平面紧密耦合,导致运营团队承担了大部分维护工作。
- 没有 Red Hat 支持和维护的工具来管理 Ansible 自动化平台部署中的自定义依赖项。
Ansible 自动化平台 2 引入了自动化执行环境。这些是所有自动化都打包并在其中运行的容器镜像,其中包括 Ansible Core、Ansible 内容集合、Python 版本、Red Hat Enterprise Linux UBI 8 以及任何其他软件包依赖项。
为什么要升级?
Ansible 自动化平台 2,在 AnsibleFest 2021 上宣布,它具有重新设计的架构,完全解耦了自动化控制平面和执行平面。新功能使跨全球更容易扩展自动化,并允许您在尽可能靠近源代码的位置运行自动化,而无需绑定到在单个数据中心中运行自动化。与 Ansible 自动化平台 1.2 相比,它更加动态、可扩展、弹性和安全。
如果您是使用 Ansible 自动化平台 1.2(Ansible Tower 3.8)的现有 Red Hat 客户,一项重要的迁移建议是将集群中的任何自定义 Python 虚拟环境转换为自动化执行环境。这项一次性工作为利用最新的 Ansible 自动化平台 2 功能以及在多个平台上执行一致的自动化以降低长期维护成本打开了大门。
现在我们将解释这种具体的迁移考虑因素,并向您提供有关如何迁移到自动化执行环境的一些最佳实践。
手动升级过程
如这 文档 中所述,升级到自动化执行环境的手动过程将类似于以下步骤
- 前提是运行一个 Ansible 自动化平台 1.2 集群,客户除了默认虚拟环境外还在其中配置了一个或多个自定义 Python 虚拟环境。
- 使用 Ansible Tower 节点上存在的
awx-manage
命令行实用程序,使用 list_custom_venvs
子命令获取自定义 Python 虚拟环境列表。
- 在每个虚拟环境上运行
awx-manage export_custom_venv
命令以获取该虚拟环境中安装的 Python 软件包列表。
- 使用
awx-manage custom_venv_associations
命令检查虚拟环境的关联。此关联/信息列表将帮助客户在 Ansible 自动化平台 2.x 集群中建立新执行环境的关联。
- 手动过滤上述信息,并将步骤 3 中的要求列表提供给执行环境构建器(ansible-builder)以创建必要的自定义执行环境。
查看上述流程,可以对该流程进行两个改进,这将帮助客户更快地采用自动化执行环境
- 可以将步骤 3 中导出的要求与将用作新创建环境的基础层的自动化执行环境中已存在的 Python 软件包列表进行比较。这将很有帮助,因为基础自动化执行环境将解决某些依赖项,如果客户在开始为其集群创建自动化执行环境时能够关注 **需要什么**,这将对他们有所帮助。
- 既然我们喜欢 Ansible,为什么不直接将上述过程自动化呢?:)
自动升级过程
本节的目的是解释如何使用 Ansible 自动化此过程。我们有一些示例 Ansible 内容集合和角色可用于实现这种自动化。从高层面上看,剧本将类似于以下步骤
- 从 Ansible 自动化平台 1.2 中 Ansible Tower 节点上存在的所有自定义 Python 虚拟环境中提取软件包列表。
- 将步骤 1 中的软件包列表与您决定用作基础的自动化执行环境(在本例中为 ansible-2.9)中的软件包列表进行比较,以查找基础环境中不存在的软件包。
- 将步骤 2 中的列表提供给一个 Ansible 角色,该角色可以自动化执行环境创建,将基础环境保持为我们在步骤 2 中进行比较的环境。
让我们来看一个现有的 Ansible 自动化平台 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 集合 中打包的一个名为 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 集合 中的另一个 Ansible 角色,名为 ee_builder;它的用例是自动化执行环境创建过程。
简要总结
- 我们在 Ansible Tower 节点上运行了一个剧本,以收集不在基础自动化执行环境中的 Python 软件包(来自自定义 Python 虚拟环境)。
- 上述输出可以帮助使用 ee_builder 角色创建自定义自动化执行环境,该角色可以自动化执行环境创建。
关键要点
- 将此新 Ansible 角色与 ee_builder 角色结合使用可以用来自动化从自定义虚拟环境到自动化执行环境的迁移。
- 这些角色目前是社区项目的一部分,未得到 Red Hat 的正式支持。但是,它们可以提供有关迁移过程的理解方面的详细信息。