创建和恢复执行环境


Red Hat Ansible Automation Platform 2.3

为您的 Red Hat Ansible Automation Platform 创建一致且可重复生成的自动化执行环境。

Red Hat Customer Content Services

摘要

提供反馈:
如果您对本文档有任何改进建议,或发现错误,请联系技术支持 https://access.redhat.com,使用 Docs组件在 Ansible Automation PlatformJIRA 项目中创建一个问题。

前言

使用 Ansible Builder 为您的 Red Hat Ansible Automation Platform 需求创建一致且可重复生成的自动化环境。

使开源包含更多

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。有关更多详情,请参阅我们的首席技术官 Chris Wright 提供的消息

第 1 章 自动化执行环境简介

使用依赖于非默认依赖项的 Ansible 内容可能会很复杂,因为必须在每个节点上安装软件包,并与主机系统上安装的其他软件进行交互,并保持同步。

自动化执行环境有助于简化这个过程,并可使用 Ansible Builder 轻松创建。

1.1. 关于自动化执行环境

自动化执行环境是运行 Red Hat Ansible Automation Platform 中的所有自动化的容器镜像。自动化执行环境创建用于通信自动化依赖项的通用语言,并提供构建和分发自动化环境的标准方法。

自动化执行环境应该包含以下内容:

  • Ansible 2.9 或 Ansible Core 2.11-2.13
  • Python 3.8-3.10
  • Ansible Runner
  • Ansible 内容集合
  • 集合、Python 或系统依赖项

1.1.1. 为什么使用自动化执行环境?

使用自动化执行环境时,Red Hat Ansible Automation Platform 已将 control plane 与 execution plane 分开来转换为分布式架构。与 control plane 独立进行自动化执行可加快开发周期,并提高跨环境的可扩展性、可靠性和可移植性。Red Hat Ansible Automation Platform 还包括对 Ansible 内容工具的访问,方便构建和管理自动化执行环境。

除了速度、可移植性和灵活性外,自动化执行环境还提供以下好处:

  • 它们确保自动化在多个平台中持续运行,并能够纳入系统级依赖项和基于集合的内容。
  • 它们可让 Red Hat Ansible Automation Platform 管理员提供和管理自动化环境以满足不同团队的需求。
  • 它们通过提供构建和分发自动化环境的一种标准方式,在团队间轻松扩展和共享自动化。
  • 它们使自动化团队能够自行定义、构建和更新其自动化环境。 
  • 自动化执行环境提供通用语言来传达自动化依赖项。

第 2 章 使用 Ansible Builder

Ansible Builder(Ansible 构建器)是一个命令行工具,它通过使用各种 Ansible Collections 中定义的或由用户创建的元数据自动构建自动化执行环境的过程。

2.1. 为什么使用 Ansible Builder?

在开发 Ansible Builder 之前,Red Hat Ansible Automation Platform 用户可以在创建自定义虚拟环境或容器(包含所有必要的依赖项)时遇到依赖项问题和错误。

现在,使用 Ansible Builder 时,您可以轻松地创建一个可自定义的自动化执行环境定义文件,该文件指定了自动化执行环境中包含的内容,如集合、要求和系统级别软件包。这可让您满足所有必要的要求和依赖项来获取作业运行。

2.2. 安装 Ansible Builder

您可以使用 Red Hat Subscription Management (RHSM) 安装 Ansible Builder 来附加 Red Hat Ansible Automation Platform 订阅。附加 Red Hat Ansible Automation Platform 订阅 可让您访问安装 ansible-builder 所需的仅订阅资源。附加订阅后,会自动启用 ansible-builder 所需的存储库。

注意

在安装 ansible-builder 之前,您必须在主机上附加了有效的订阅。

流程

  • 在终端中,运行以下命令来安装 Ansible Builder 并激活 Ansible Automation Platform 仓库:

    # dnf install --enablerepo ansible-automation-platform-2.3-for-rhel-8-x86_64-rpms ansible-builder

2.3. 构建定义文件

安装 Ansible Builder 后,您可以创建一个定义文件,Ansible Builder 用来创建自动化执行环境镜像。构建自动化执行环境文件的高级别流程是 Ansible Builder 读取和验证您的定义文件,然后创建一个 Continerfile,最后将 Containerfile 传递给 Podman,然后打包并创建自动化执行环境文件。创建的定义文件采用 yaml 格式,包含不同的部分。如需有关定义文件内容的更多信息,请参阅定义文件内容的明细

以下是定义文件的示例:

例 2.1. 定义文件

version: 1

build_arg_defaults: 1
  ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: "-v"

dependencies: 2
  galaxy: requirements.yml
  python: requirements.txt
  system: bindep.txt

additional_build_steps: 3
  prepend: |
    RUN whoami
    RUN cat /etc/os-release
  append:
    - RUN echo This is a post-install command!
    - RUN ls -la /etc
1
列出构建参数的默认值
2
指定各种要求文件的位置
3
用于其他自定义构建步骤的命令

有关这些定义文件参数的更多信息,请参阅定义文件内容的明细

2.4. 执行构建和创建命令

先决条件

  • 您已创建了定义文件

流程

要构建自动化执行环境镜像,请运行:

$ ansible-builder build

默认情况下,Ansible Builder 将查找名为 execution-environment.yml 的定义文件,但可以通过 -f 标志将不同的文件路径指定为参数:

$ ansible-builder build -f definition-file-name.yml

其中 definition-file-name 指定您的定义文件的名称。

2.5. 定义文件内容的分类

使用 Ansible Builder 构建自动化执行环境需要定义文件,因为它指定了自动化执行环境容器镜像中包含的内容。

以下小节细分了定义文件的不同部分。

2.5.1. 构建参数和基础镜像

定义文件的 build_arg_defaults 部分是一个字典,其键可为 Ansible Builder 的参数提供默认值。下表列出了 build_arg_defaults 中可以使用的值:

描述

ANSIBLE_GALAXY_CLI_COLLECTION_OPTS

允许用户在集合安装过程中将任意参数传递给 ansible-galaxy CLI。例如,-pre 标志启用预发布集合的安装,或者 -c 禁用服务器的 SSL 证书的验证。

EE_BASE_IMAGE

指定自动化执行环境的父镜像,启用基于已存在的镜像构建的新镜像这通常是一个受支持的执行环境基础镜像,如 ee-minimal 或 ee-supported,但它也可以是之前创建的执行环境镜像,并希望进一步自定义。

默认镜像为 registry.redhat.io/ansible-automation-platform-23/ee-minimal-rhel8:latest

EE_BUILDER_IMAGE

指定用于 Python 依赖项集合和编译的中间构建器镜像;必须包含带有 EE_BASE_IMAGE 的匹配的 Python 版本,并安装了 ansible-builder。

默认镜像为 registry.redhat.io/ansible-automation-platform-23/ansible-builder-rhel8:latest

build_arg_defaults 中指定的值将硬编码到 Containerfile 中,因此这些值将在手动调用 podman build 时保留。

注意

如果在 CLI --build-arg 标志中指定相同的变量,CLI 值将具有更高的优先级。

2.5.2. Ansible 配置文件路径

ansible_config 指令允许指定到 ansible.cfg 文件的路径,在构建的 Collection 安装过程中将专用帐户的令牌和其他设置传递给自动化中心服务器。配置文件路径应相对于定义文件位置,并将复制到生成的容器构建上下文中。

ansible.cfg 文件的格式应当类似以下示例:

例 2.2. ansible.cfg 文件

[galaxy]
server_list = automation_hub

[galaxy_server.automation_hub]
url=https://cloud.redhat.com/api/automation-hub/
auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
token=my_ah_token

有关如何从自动化中心下载集合的更多信息,请参阅相关的 Ansible 文档页面。

2.5.3. 依赖项

为了避免自动化执行环境镜像出现问题,请确保 Galaxy、Python 和系统的条目指向有效的要求文件。

2.5.3.1. Galaxy

galaxy 条目指向 ansible-galaxy collection install -r …​ 命令的有效要求文件。

条目 requirements.yml 可以是对于自动化执行环境定义的文件夹目录的相对路径,也可以是绝对路径。

requirements.yml 文件的内容可能类似如下:

例 2.3. Galaxy 的 requirements.yml 文件

collections:
  - community.aws
  - kubernetes.core
2.5.3.2. Python

定义文件中的 python 条目指向 pip install -r …​ 命令的有效要求文件。

条目 requirements.txt 是一个文件,它会在集合已列出的 Python 依赖项之上安装额外的 Python 要求。它可以是对于自动化执行环境定义的文件夹目录的相对路径,也可以是绝对路径。requirements.txt 文件的内容应该类似以下示例,类似于 pip freeze 命令的标准输出:

例 2.4. Python 的 requirements.txt 文件

boto>=2.49.0
botocore>=1.12.249
pytz
python-dateutil>=2.7.0
awxkit
packaging
requests>=2.4.2
xmltodict
azure-cli-core==2.11.1
python_version >= '2.7'
collection community.vmware
google-auth
openshift>=0.6.2
requests-oauthlib
openstacksdk>=0.13
ovirt-engine-sdk-python>=4.4.10
2.5.3.3. System

定义中的 system 条目指向一个 bindep 要求文件,该文件将安装集合中已存在的系统级依赖项。它可以是对于自动化执行环境定义的文件夹目录的相对路径,也可以是绝对路径。至少,集合会为 [platform:rpm] 指定必要的要求。

要演示这一点,以下是 bindep.txt 文件示例,该文件将 libxml2subversion 软件包添加到容器中:

例 2.5. bindep.txt 文件

libxml2-devel [platform:rpm]
subversion [platform:rpm]

来自多个集合的条目合并到一个文件中。这通过 bindep 进行处理,然后传递到 dnf。镜像中仅会安装没有配置集或无运行时要求的要求。

2.5.4. 额外的自定义构建步骤

prependappend 命令可以在 additional_build_steps 部分中指定。这些将添加命令到 Containerfile,该文件将在执行主要构建步骤之前或之后运行。

additional_build_steps 的语法必须是以下之一:

  • 一个多行的字符串

    例 2.6. 一个多行的字符串条目

    prepend: |
       RUN whoami
       RUN cat /etc/os-release
  • 一个列表

    例 2.7. 一个列表条目

    append:
    - RUN echo This is a post-install command!
    - RUN ls -la /etc

2.6. 可选的 build 命令参数

-t 标志将使用特定名称标记您的自动化执行环境镜像。例如,以下命令将构建名为 my_first_ee_image 的镜像:

$ ansible-builder build -t my_first_ee_image
注意

如果您在构建中没有使用 -t,则创建名为 ansible-execution-env' 的镜像,并加载到本地容器 registry 中。

如果您有多个定义文件,您可以使用 -f 标志指定要使用的文件:

$ ansible-builder build -f another-definition-file.yml -t another_ee_image

在上例中,Ansible Builder 将使用文件 another-definition-file.yml 中提供的规格,而不是默认的 execution-environment.yml 来构建名为 another_ee_image 的自动化执行环境镜像。

有关可以与 build 命令一起使用的其他规格和标志,请输入 ansible-builder build --help 来查看附加选项列表。

2.7. Containerfile

创建定义文件后,Ansible Builder 会读取并验证它,然后创建一个 Containerfile,最后使用以下步骤将 Containerfile 传递给 Podman 以打包并创建自动化执行环境镜像:

  1. 获取基础镜像
  2. 在基础镜像的临时副本中,会下载集合,以及声明的 Python 和系统依赖项列表(若有)。
  3. 在临时构建器镜像中,用于定义文件中列出的所有 Python 依赖关系的 Python wheels 将下载并构建(根据需要),包括由定义文件中列出的集合声明的所有 Python 依赖项。
  4. 运行为来自定义文件的 additional_build_steps 的 prepend
  5. 在最后的自动化执行环境镜像中,会安装定义文件中列出的系统依赖项,包括由定义文件中列出的集合声明的所有系统依赖项。
  6. 在最后的自动化执行环境镜像中,下载的集合会被复制,并安装了之前获取的 Python 依赖项。
  7. 运行为来自定义文件的 additional_build_steps 的 prepend

2.8. 在不构建镜像的情况下创建容器文件

要创建共享的 Containerfile 而不从其中构建镜像,请运行:

$ ansible-builder create

第 3 章 发布自动化执行环境

3.1. 自定义现有自动化执行环境镜像

Ansible Controller 包含三个默认执行环境:

  • Ansible 2.9 - 不安装 Controller 模块以外的集合
  • minimal - 包含最新的 Ansible 2.13 版本以及 Ansible Runner,但不包含集合或其他额外内容
  • EE 支持 - Minimal,以及所有红帽支持的集合和依赖项

虽然这些环境涵盖了许多自动化用例,但您可以添加额外的项目来自定义这些容器,以满足您的特定需求。以下流程将 kubernetes.core 集合添加到 ee-minimal 默认镜像中:

流程

  1. 通过 Podman 登录到 registry.redhat.io

    $ podman login -u="[username]" -p="[token/hash]" registry.redhat.io
  2. 确保您可以拉取所需的自动化执行环境基础镜像

    podman pull registry.redhat.io/ansible-automation-platform-22/ee-minimal-rhel8:latest
  3. 配置 Ansible Builder 文件,以指定所需的基础镜像以及添加到新执行环境镜像的任何其他内容。

    1. 例如,要将 来自 Galaxy 的 Kubernetes Core Collection 添加到镜像中,请按如下所示填写 requirements.yml 文件:

      collections:
        - kubernetes.core
    2. 如需有关定义文件及其内容的更多信息,请参阅定义文件分类部分
  4. 在执行环境定义文件中,在 EE_BASE_IMAGE 字段中指定原始 ee-minimal 容器 URL 和标签。在这样做时,您的最终 execute-environment.yml 文件将类似如下:

    例 3.1. 自定义 execution-environment.yml 文件

    version: 1
    
    build_arg_defaults:
      EE_BASE_IMAGE: 'registry.redhat.io/ansible-automation-platform-22/ee-minimal-rhel8:latest'
    
    dependencies:
      galaxy: requirements.yml
    注意

    由于本例使用 kubernetes.core 的社区版本,而不是来自自动化中心的认证集合,因此我们不需要创建 ansible.cfg,也不在定义文件中引用。

  5. 使用以下命令构建新执行环境镜像:

    $ ansible-builder build -t registry.redhat.io/[username]/new-ee

    其中 [username] 指定您的用户名,new-ee 指定新容器镜像的名称。

注意

如果您在构建中没有使用 -t,则创建名为 ansible-execution-env' 的镜像,并加载到本地容器 registry 中。

  1. 使用 podman images 命令确认您的新容器镜像在该列表中:

    例 3.2. 使用镜像 new-eepodman images 命令的输出

    REPOSITORY          TAG     IMAGE ID      CREATED        SIZE
    localhost/new-ee    latest  f5509587efbb  3 minutes ago  769 MB
    1. 验证是否安装了集合:

      $ podman run registry.redhat.io/[username]/new-ee ansible-doc -l kubernetes.core
    2. 标记在自动化中心中使用的镜像:

      $ podman tag registry.redhat.io/[username]/new-ee [automation-hub-IP-address]/[username]/new-ee
    3. 使用 Podman 登录到您的自动化 hub:

      注意

      您必须具有 Automation hub 的 admin 或适当的容器存储库权限才能推送容器。如需更多信息,请参阅 Red Hat Ansible Automation Platform 文档中的在私有自动化中心管理容器

      $ podman login -u="[username]" -p="[token/hash]" [automation-hub-IP-address]
    4. 将镜像推送到自动化 hub 中的容器 registry 中:

      $ podman push [automation-hub-IP-address]/[username]/new-ee
    5. 将新镜像拉取(pull)到自动化控制器实例中:
  2. 进入自动化控制器。
  3. 在侧面导航栏中,点 AdministrationExecution Environments
  4. 点击 Add
  5. 输入适当的信息,然后点 Save 以拉取新镜像。

    注意

    如果您的自动化中心实例受密码或令牌保护,请确保设置了适当的容器 registry 凭证。

第 4 章 填充私有自动化中(automation hub)容器 registry

默认情况下,私有自动化中心不包括容器镜像。要填充容器 registry,您需要将容器镜像推送到其中。本节中的步骤描述了如何从红帽生态系统目录 (registry.redhat.io) 拉取镜像,标记镜像并将其推送到您的私有自动化中心容器 registry。

重要

镜像清单和文件系统 Blob 直接从 registry.redhat.ioregistry.access.redhat.com 提供。但是,从 2023 年 5 月 1 日开始,文件系统 Blob 由 quay.io 提供。为了避免拉取容器镜像出现问题,您必须启用到以下主机名的出站连接:

  • cdn.quay.io
  • cdn01.quay.io
  • cdn02.quay.io
  • cdn03.quay.io

对任何特别启用到 registry.redhat.ioregistry.access.redhat.com 的出站连接进行此更改。

在配置防火墙规则时使用主机名而不是 IP 地址。

完成此更改后,您可以继续从 registry.redhat.ioregistry.access.redhat.com 拉取镜像。要继续拉取红帽容器镜像,您不需要 quay.io 登录,或者需要以任何方式直接与 quay.io registry 交互,。

4.1. 先决条件

  • 有创建新容器并将容器推送到私有自动化中心的权限。

4.2. 获取用于自动化中心的镜像

在将容器镜像推送到私有自动化中心之前,您必须首先从现有 registry 中拉取容器镜像并标记它们以供使用。本例详细介绍了如何从红帽生态系统目录 (registry.redhat.io) 中拉取镜像。

先决条件

有从 registry.redhat.io 拉取镜像的权限

流程

  1. 使用 registry.redhat.io 凭证登录到 Podman:

    $ podman login registry.redhat.io
  2. 在提示符处输入您的用户名和密码。
  3. 拉取容器镜像:

    $ podman pull registry.redhat.io/<container_image_name>:<tag>

验证

  1. 列出本地存储中的镜像:

    $ podman images
  2. 验证您最近拉取的镜像是否包含在列表中。
  3. 验证该标签是否正确。

其他资源

4.3. 用于自动化中心的标记镜像

从 registry 中拉取镜像后,标记它们以便在私有自动化中心容器 registry 中使用。

先决条件

  • 您已从外部 registry 中提取容器镜像。
  • 有自动化中心实例的 FQDN 或 IP 地址。

流程

  • 使用自动化中心容器存储库标记本地镜像

    $ podman tag registry.redhat.io/<container_image_name>:<tag> <automation_hub_URL>/<container_image_name>

验证

  1. 列出本地存储中的镜像:

    $ podman images
  2. 验证您最近使用自动化中心信息标记的镜像是否包含在列表中。

4.4. 将容器镜像推送到私有自动化中心

您可以将标记的容器镜像推送到私有自动化中心,以创建新容器并填充容器 registry。

先决条件

  • 有创建新容器的权限。
  • 有自动化中心实例的 FQDN 或 IP 地址。

流程

  1. 使用您的自动化中心位置和凭证登录到 Podman:

    $ podman login -u=<username> -p=<password> <automation_hub_url>
  2. 将容器镜像推送到自动化中心容器 registry:

    $ podman push <automation_hub_url>/<container_image_name>
    注意

    当 registry.redhat.io 的签名镜像被推送到自动化中心容器 registry 时,需要 --remove-signatures 标志。push 操作会在上传期间重新编译镜像层,无法保证可重复生成,依赖于客户端实施。这可能会导致镜像层摘要的变化,并导致推送操作失败,Error: Copying this image requires changing layer representation, which is not possible (image is signed or the destination specifies a digest)

验证

  1. 登录到您的自动化中心。
  2. 进入 Container Registry
  3. 在 container 存储库列表中找到容器。

第 5 章 设置容器存储库

您可以设置容器存储库来添加描述,包括 README,添加可以访问存储库的组,以及标记镜像。

5.1. 先决条件

  • 您使用权限登录到私有 Automation Hub,以更改存储库。

5.2. 将 README 添加到容器存储库中

将 README 添加到容器存储库,以向用户提供如何使用容器的说明。自动化中心容器存储库支持 Markdown 创建 README。默认情况下,README 将为空。

先决条件

  • 有更改容器的权限。

流程

  1. 进入 Execution Environments
  2. 选择您的容器存储库。
  3. Details 标签页中,点 Add
  4. Raw Markdown 文本字段中,使用 Markdown 格式输入您的 README 文本。
  5. 完成后点 Save

添加 README 后,您可以随时通过点 Edit 并重复步骤 4 和 5 对其进行编辑。

5.3. 提供对容器存储库的访问

为需要使用镜像的用户提供容器存储库的访问权限。通过添加组,您可以修改组对容器存储库的权限。您可以使用这个选项根据组分配的内容来扩展或限制权限。

先决条件

  • 您具有改变容器命名空间的权限。

流程

  1. 进入 Execution Environments
  2. 选择您的容器存储库。
  3. 点击窗口右上角的 Edit
  4. Groups with access 中选择要分配访问权限的一个或多个组。

    • 可选:使用该组名称下的下拉菜单为特定组添加或删除权限。
  5. 点击 Save

5.4. 标记容器镜像

标记镜像,为存储在自动化中心容器存储库中的镜像添加额外名称。如果没有向镜像添加任何标签,则自动化中心名称默认为 latest

先决条件

  • 您有更改镜像标签的权限。

流程

  1. 进入 Execution Environments
  2. 选择您的容器存储库。
  3. Images 选项卡。
  4. more actions ,然后点 Manage tags
  5. 在文本字段中添加新标签,然后点 Add

    • 可选:通过点该镜像的任何标签上的 x 来删除当前标签
  6. 点击 Save

验证

  • Activity 选项卡,再检查最新的变化。

5.5. 在自动化控制器中创建凭证

在以前的版本中,您需要部署 registry 来存储执行环境镜像。在 Ansible Automation Platform 2.0 及更新的版本中,假设您已经启动并运行了容器 registry。因此,您只需要添加您选择的容器 registry 凭证来存储执行环境镜像。

要从密码或令牌保护的 registry 中拉取容器镜像,请在自动化控制器中创建凭证:

流程

  1. 进入自动化控制器。
  2. 在侧边栏中,点 ResourcesCredentials
  3. Add 以创建新凭据。
  4. 输入授权 NameDescriptionOrganization
  5. 选择凭据类型
  6. 输入身份验证 URL。这是容器 registry 地址。
  7. 输入登录到容器 registry 所需的 UsernamePassword or Token
  8. (可选)选择 Verify SSL 来启用 SSL 验证。
  9. 点击 Save

第 6 章 从容器存储库中拉取镜像

从自动化中心容器 registry 中拉取镜像,以便将镜像复制到本地机器。自动化中心为容器存储库中的每个 latest 镜像提供 podman pull 命令。您可以将此命令复制并粘贴到终端中,或者使用 podman pull 根据镜像标签复制镜像。

6.1. 先决条件

您需要有从私有容器存储库查看和拉取的权限。

6.2. 拉取镜像

您可以从自动化中心容器 registry 中拉取镜像,以在本地机器中创建副本。自动化中心为容器存储库中的每个 latest 镜像提供 podman pull 命令。

注意

如果需要从密码保护的 registry 中拉取容器镜像,您必须在拉取镜像前在自动化控制器中创建凭证

流程

  1. 进入 Execution Environments
  2. 选择您的容器存储库。
  3. Pull this image 条目中,点 Copy to clipboard
  4. 在终端中粘贴并运行命令。

验证

  • 运行 podman images 以查看本地机器上的镜像。

6.3. 从容器存储库同步镜像

您可以从自动化中心容器 registry 拉取镜像,将镜像同步到本地机器。

先决条件

您需要有从私有容器存储库查看和拉取的权限。

流程

要从远程容器 registry 同步镜像,您需要配置远程 registry。

  1. 进入到 Execution EnvironmentsRemote Registries
  2. https://registry.redhat.io 添加到 registry。
  3. 添加所需的任何凭证进行验证。
注意

有些容器 registry 有速率限制。建议您在 Advanced Options 下设置速率限制。

  1. 进入到 Execution EnvironmentsExecution Environments
  2. 在页面标头中点 Add execution environment
  3. 选择您要从中拉取的 registry。"name"字段显示本地 registry 上显示的镜像的名称。
注意

"Upstream name"字段是远程服务器上的镜像名称。例如,如果上游名称被设置为 "alpine",并且 "name" 字段设置为 "local/alpine",则 alpine 镜像将从远程下载,并重命名为 local/alpine。

建议设置要包含或排除的标签列表。将镜像与大量标签同步会非常耗时,并将使用大量磁盘空间。

其他资源

6.4. 其他资源

附录 A. 自动化执行环境优先级

默认情况下,项目更新始终使用 control plane 自动化执行环境,但作业将使用第一个可用的自动化执行环境,如下所示:

  1. 创建了该作业的模板(作业模板或清单源)上定义的 execution_environment
  2. 作业使用的项目上定义的 default_environment
  3. 在作业的组织上定义的 default_environment
  4. 在作业使用的清单的组织上定义的 default_environment
  5. 当前 DEFAULT_EXECUTION_ENVIRONMENT 设置(可在 api/v2/settings/jobs/中进行配置)
  6. 来自 GLOBAL_JOB_EXECUTION_ENVIRONMENTS 设置的任何镜像。
  7. 任何其它全局执行环境。
注意

如果多个执行环境符合条件(适用于 6 和 7),则会使用最近创建的执行环境。

法律通告

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.