第 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。

为实现完整性,手动过程包括:

  1. 带有自定义 Python 虚拟环境的 Ansible Automation Platform 1.2 环境
  2. 使用 awx-manage 命令行工具获取自定义 Python 虚拟环境列表
  3. 在每个 Python 虚拟环境上运行 awx-manage export_custom_venv 命令,以获取已安装的 Python 软件包列表
  4. 使用 awx-manage custom_venv_associations 命令检查 Python 虚拟环境的关联
  5. 使用 ansible-builder 工具过滤以上信息以创建执行环境

自动过程包括:

  1. 从 Ansible Automation Platform 1.2 环境中每个自定义 Python 虚拟环境中拉取软件包列表
  2. 将上一步中的软件包列表与 Ansible-2.9 的软件包列表进行比较[1] 查找基础 Ansible-2.9 执行环境中不存在的软件包
  3. 创建一个新的自定义执行环境,它使用 Ansible-2.9 执行环境作为基础,并包含上一步中列表中缺少的依赖项

要运行可能如下所示的情况,我们来看以下示例。

在我们现有的 Ansible Automation Platform 1.2 中,有两个自定义 Python 虚拟环境标记为 custom-venv1custom-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 凭证:

  1. 选择 Resources→Credentials
  2. 凭据 中,选择蓝色 添加按钮
  3. Create New Credentials 窗口中,

    1. 提供 名称,如 My 私有自动化 hub 凭证
    2. Credential Type 下选择下拉菜单并选择 Container Registry
    3. 类型详情下

      1. 提供身份验证 URL,如 pah.example.com
      2. Username 字段中提供您的私有自动化中心用户名
      3. Password 或 Token 字段中提供您的私有自动化中心密码或令牌
      4. 如果您的私有自动化中心环境支持 SSL,请选择 Verify SSL
  4. Save

要使执行环境在自动化控制器中可用,请创建一个新的执行环境,它将从您的私有自动化中心拉取镜像。

在自动化控制器中,

  1. 选择 Administration→Execution Environments
  2. 执行环境 中,选择蓝色 添加按钮
  3. Create new execution environment 窗口中,

    1. 提供一个名称,如 我的执行环境
    2. 提供执行环境的镜像位置,如 repo/project/image-name:tag
    3. 选择 Registry 凭证 放大镜

      1. 点私有自动化中心凭证的单选按钮,如我的私有自动化中心凭证

现在,在自动化控制器中提供执行环境时,它们可用于任何现有作业模板或新创建的作业模板。

提示

在创建新用户构建的执行环境时,不要受到向后兼容性,建议使用 ee-minimal 执行环境作为您的基本执行环境,以针对其构建新镜像。



[1] 此参考架构使用 ansible-2.9 执行环境来最佳模拟 Ansible Automation Platform 1.2 的执行平面环境。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.