Documentation

14. Execution Environments

为自动化构建和部署 Python 虚拟环境的功能已被 Ansible 执行环境替代。与旧的虚拟环境不同，执行环境是容器镜像，从而可以包含系统级别的依赖项和基于集合的内容。每个执行环境都允许您具有自定义镜像来运行作业，每个环境都只包含运行作业时所需的内容。

14.1. 构建一个 Execution Environment

使用依赖于非默认依赖项（自定义虚拟环境）的 Ansible 内容可能会比较棘手。软件包必须在每个节点上安装，并需要可以与主机系统上安装的其他软件一同正常操作，并保持同步。以前，在默认情况下，作业会在 /var/lib/awx/venv/ansible 的一个虚拟环境中运行，它会预加载 ansible-runner 的依赖项，以及 Ansible 控制机器使用的某些 Ansible 内容类型。

为了简化这个过程，容器镜像可以通过 Ansible 构建 control nodes。这些容器镜像称为自动化 execution environments，您可以使用 ansible-builder 创建，然后 ansible-runner 可以利用这些镜像。

14.1.1. 安装 ansible-builder

要构建镜像，需要安装 podman 或 docker，以及 ansible-builder Python 软件包。--container-runtime 选项需要与您要使用的 Podman/Docker 可执行文件对应。

从 PyPi 安装：

$ pip install ansible-builder

从主线的开发分支中安装：

$ pip install https://github.com/ansible/ansible-builder/archive/devel.zip

要从特定的标签或分支安装，请替换以下示例中的 <ref>：

$ pip install https://github.com/ansible/ansible-builder/archive/<ref>.zip

14.1.2. 构建一个 execution environment

ansible-builder 用于创建 execution environment。

execution environment 应该包含：

  • Ansible

  • Ansible Runner

  • Ansible Collections

  • Python 和/或系统依赖项：

    • 集合中的模块/插件

    • ansible-base 中的内容

    • 自定义用户需要

Building a new execution environment involves a definition (a .yml file) that specifies which content you would like to include in your execution environment, such as collections, Python requirements, and system-level packages. The content from the output generated from migrating to execution environments has some of the required data that can be piped to a file or pasted into this definition file. See 将旧的 venv 迁移到 execution environments for more detail. If you did not migrate from a virtual environment, you can create a definition file with the required data outlined in Execution environment 定义.

集合开发人员可以通过提供适当的元数据来声明其内容要求。如需更多信息，请参阅 集合级元数据。

14.1.3. 运行构建器

创建定义后，使用此流程构建 execution environment。

ansible-builder build 命令将 execution environment 定义用作输入。它输出构建 execution environment 镜像所需的构建上下文，并继续进行构建该镜像。镜像可以使用其他构建上下文重新构建，并生成相同的结果。默认情况下，它会在当前目录中查找名为 execution-environment.yml 的文件。

为了说明这一点，可以使用以下示例 execution-environment.yml 文件作为一个起点：

---
version: 1
dependencies:
  galaxy: requirements.yml

requirements.yml 的内容：

---
collections:
  - name: awx.awx

要使用上述文件构建 execution environment，请运行：

$ ansible-builder build
...
STEP 7: COMMIT my-awx-ee
--> 09c930f5f6a
09c930f5f6ac329b7ddb321b144a029dbbfcc83bdfc77103968b7f6cdfc7bea2
Complete! The build context can be found at: context

除了生成随时可用的容器镜像外，构建上下文也会保留，它可以通过您选择的工具在不同的时间和/或位置进行重建，如 docker build 或 podman build。

14.2. 在作业中使用 execution environment

根据 execution environment 已被设置为全局使用，还是只与某个机构关联，您需要具有适当的管理员权限级别才能在作业中使用 execution environment。与机构相关联的 Execution environments 需要机构管理员权限才可以使用这些 execution environments 运行作业。

要在作业中使用 execution environment，您必须已使用 ansible-builder 创建了一个。详情请查看 构建一个 execution environment。当一个 execution environment 被创建后，您可以使用它来运行作业。使用 automation controller 用户界面指定作业模板中使用的 execution environment。

  1. 从左侧导航栏中点 Execution Environments。

  2. 选择 Add 按钮来添加 execution environment。

  3. 在以下字段中输入相关信息：

  • Name：为 execution environment 输入一个名称（必需）。

  • Image：输入镜像名称（必需）。镜像名称需要其完整位置（存储库）、registry、镜像名称和版本标签，其示例格式为 quay.io/ansible/awx-ee:latestrepo/project/image-name:tag。

  • Job Type：（可选）在运行作业时选择拉取类型：

  • Always pull container before running：为容器拉取最新的镜像文件。

  • No pull option has been selected：没有指定拉取。

  • Never pull container before running：永不拉取容器镜像的最新版本。

  • Description：可选。

  • Organization：可选地分配机构来特定地使用这个 execution environment。要使 execution environment 可用于多个机构，请将此字段留空。

  • Registry credential：如果镜像有一个受保护的容器 registry，提供访问它的凭证。

_images/ee-new-ee-form-filled.png

  1. 点 Save。

现在，您新添加的 execution environment 已准备好在作业模板中使用。 要将 execution environment 添加到作业模板中，在作业模板的 Execution Environment 字段中指定它，如下例所示。 有关设置作业模板的详情，请参考 Automation Controller User Guide 中的 作业模板。

_images/job-template-with-example-ee-selected.png

将 execution environment 添加到作业模板后，您可以看到在 execution environment 的 Templates 标签页中列出的模板：

_images/ee-details-templates-list.png

14.3. Execution Environment mount options

Rebuilding an execution environment is one way to add certs, but inheriting certs from the host provides a more convenient solution. For VM-based installs, the controller automatically mounts the system trust store in the execution environment when jobs run.

Additionally, you may customize execution environment mount options and mount paths in the Paths to expose to isolated jobs field of the Job Settings page, where it supports podman-style volume mount syntax. Refer to the Podman documentation for detail.

In some cases where the /etc/ssh/* files were added to the execution environment image due to customization of an execution environment, an SSH error may occur. For example, exposing the /etc/ssh/ssh_config.d:/etc/ssh/ssh_config.d:O path allows the container to be mounted, but the ownership permissions are not mapped correctly.

If you encounter this error, or have upgraded from an older version of the controller (e.g. 3.8.x), perform the following steps:

  1. Change the container ownership on the mounted volume to root.

  2. In the Paths to expose to isolated jobs field of the Job Settings page, using the current example, expose the path as such:

_images/settings-paths2expose-iso-jobs.png

注解

The :O option is only supported for directories. It is highly recommended that you be as specific as possible, especially when specifying system paths. Mounting /etc or /usr directly have impact that make it difficult to troubleshoot.

This informs podman to run a command similar to the example below, where the configuration is mounted and the ssh command works as expected.

podman run -v /ssh_config:/etc/ssh/ssh_config.d/:O ...