第 5 章 将虚拟环境迁移到执行环境
Ansible Automation Platform 2 附带一个 re-imagined 架构,完全分离自动化 control plane 和执行平面。新功能可以更轻松地在全球范围内扩展自动化,并可让您尽可能地运行自动化,而无需绑定到在单个数据中心中运行自动化。与 Ansible Automation Platform 1.2 相比,它更为动态、可扩展、弹性和灵活性。
随着自动化执行环境的引入,这些容器镜像允许打包并运行所有自动化,包括 Ansible Core、Ansible 内容集合、Python 依赖项、Red Hat Enterprise Linux UBI 8 以及任何其他软件包依赖项。
本章重点介绍将 Ansible Automation Platform 1.2 集群中的自定义 Python 虚拟环境迁移到用户构建的自动化执行环境。
这种一次性工作将开来者利用最新的 Ansible Automation Platform 2 功能,并能够在低长期维护的多个平台上执行一致的自动化。
要访问用户构建的执行环境,需要在私有自动化中心或容器 registry 中托管它们。有关如何安装私有自动化中心的更多信息,请访问 部署 Ansible Automation Platform 2.1 参考架构。
5.1. 自动将虚拟环境迁移到执行环境
为简单起见,我们包括通过运行 Ansible 命令自动化流程的补充 Ansible Playbook。
为实现完整性,手动过程包括:
- 带有自定义 Python 虚拟环境的 Ansible Automation Platform 1.2 环境
-
使用
awx-manage
命令行工具获取自定义 Python 虚拟环境列表 -
在每个 Python 虚拟环境上运行
awx-manage export_custom_venv
命令,以获取已安装的 Python 软件包列表 -
使用
awx-manage custom_venv_associations
命令检查 Python 虚拟环境的关联 -
使用
ansible-builder
工具过滤以上信息以创建执行环境
自动过程包括:
- 从 Ansible Automation Platform 1.2 环境中每个自定义 Python 虚拟环境中拉取软件包列表
- 将上一步中的软件包列表与 Ansible-2.9 的软件包列表进行比较[1] 查找基础 Ansible-2.9 执行环境中不存在的软件包
- 创建一个新的自定义执行环境,它使用 Ansible-2.9 执行环境作为基础,并包含上一步中列表中缺少的依赖项
要运行可能如下所示的情况,我们来看以下示例。
在我们现有的 Ansible Automation Platform 1.2 中,有两个自定义 Python 虚拟环境标记为 custom-venv1 和 custom-venv2。
使用打包在 redhat_cop.ee_utilities 集合中的 角色 virtualenv_migrate
,我们将通过 ssh
访问 Ansible Tower 节点来提取软件包及其当前没有与基础执行环境(Ansible 2.9 执行环境进行比较)中的软件包及其版本。
redhat_cop.ee_utilities 集合是一个社区项目,不受红帽的正式支持。
下面分别找到环境的 playbook 和清单文件示例:
playbook.yml
--- - name: Review custom virtualenvs and pull requirements hosts: enva_tower become: true tasks: - name: Include venv role include_role: name: redhat_cop.ee_utilities.virtualenv_migrate
清单(Inventory)
[tower] ansibletower.example.com ansible_ssh_private_key_file=/path/to/example.pem [all:vars] ############################################################################### # Required configuration variables for migration from venv -> EE # ############################################################################### # The default URL location to the execution environment (Default Ansible 2.9) # If you want to use the newest Ansible base, change to: ee-minimal-rhel8:latest venv_migrate_default_ee_url="registry.redhat.io/ansible-automation-platform-21/ee-29-rhel8:latest" # User credential for access to venv_migrate_default_ee_url registry_username='myusername'
-
根据
ssh
到 Ansible Tower 节点所需的用户,添加 ansible_user=<ANSIBLE_USER>。 -
此参考环境利用了加密凭证,且不以纯文本形式包含密码。附录 C, 创建加密的 credentials.yml 文件 中的详情请查看如何使用
ansible-vault
加密 registry 凭证。加密的 credentials.yml 文件用于提供registry_password
此角色需要 sudo 特权才能运行 podman
命令。
Ansible playbook 的示例输出显示每个自定义 Python 虚拟环境所需的附加软件包列表。在这种情况下,custom-venv1 Python 虚拟环境还需要以下软件包,而其他软件包已是 Ansible 2.9 执行环境的一部分:
- certifi
- charset-normalizer
- enum34
- future
- solidfire-sdk-python
虽然 custom-venv2 Python 虚拟环境除了已经属于标准 Ansible-2.9 执行环境的一部分外,还需要 zabbix-api
。
Ansible 2.9 执行环境用于与自定义 Python 虚拟环境进行比较,因为大多数 Ansible Automation Platform 1.2 环境都使用 Ansible 2.9。这样可确保因为向后兼容而更容易迁移。
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" ] } ] }
在为每个自定义 Python 虚拟环境捕获软件包后,Ansible playbook 将使用作为 redhat_cop.ee_utilities 集合一部分的 ee_
builder 角色,该角色可在本地用户环境中自动创建执行环境。
在运行提供的 Ansible playbook 之前,在 localhost 机器上安装 ansible-builder,playbook 运行会根据自定义 Python 虚拟环境和提供的基本执行环境的软件包 delta 创建执行环境。
$ podman images REPOSITORY TAG IMAGE ID localhost/custom-venv2 latest c017418d1919 localhost/custom-venv1 latest 7cbe3b49974d localhost/custom-venv latest 9d5d809f38b0
5.1.1. 推送到私有自动化中心
使用本地执行环境,您可以使用以下方法将其推送到私有自动化中心:
在这个参考架构中,我们将自动化执行环境的名称保留为自定义 Python 虚拟环境的名称,以便简化。如果需要更改名称,请在将执行环境推送到私有自动化中心或所选容器 registry 前使用 podman tag 命令。
$ podman login [automation-hub-url] # Enter the username and password to access Private Automation Hub. $ podman tag [image-id] [automation-hub-url]/[container image name] $ podman push [automation-hub-url]/[container image name]
如需更多信息,请访问: 在私有自动化中心中管理容器
然后,通过在控制器用户界面中为私有自动化中心创建 registry 凭证,将执行环境同步到自动化控制器。
在自动化控制器中创建 registry 凭证:
- 选择 Resources→Credentials
- 在 凭据 中,选择蓝色 添加按钮
在 Create New Credentials 窗口中,
- 提供 名称,如 My 私有自动化 hub 凭证
- 在 Credential Type 下选择下拉菜单并选择 Container Registry
在 类型详情下
- 提供身份验证 URL,如 pah.example.com
- 在 Username 字段中提供您的私有自动化中心用户名
- 在 Password 或 Token 字段中提供您的私有自动化中心密码或令牌
- 如果您的私有自动化中心环境支持 SSL,请选择 Verify SSL
- 点 Save
要使执行环境在自动化控制器中可用,请创建一个新的执行环境,它将从您的私有自动化中心拉取镜像。
在自动化控制器中,
- 选择 Administration→Execution Environments
- 在 执行环境 中,选择蓝色 添加按钮
在 Create new execution environment 窗口中,
- 提供一个名称,如 我的执行环境
- 提供执行环境的镜像位置,如 repo/project/image-name:tag
选择 Registry 凭证 放大镜
- 点私有自动化中心凭证的单选按钮,如我的私有自动化中心凭证
现在,在自动化控制器中提供执行环境时,它们可用于任何现有作业模板或新创建的作业模板。
在创建新用户构建的执行环境时,不要受到向后兼容性,建议使用 ee-minimal
执行环境作为您的基本执行环境,以针对其构建新镜像。