创建和使用执行环境


Red Hat Ansible Automation Platform 2.4

使用 Ansible Builder 创建和使用执行环境

Red Hat Customer Content Services

摘要

本指南演示了如何为 Red Hat Ansible Automation Platform 创建一致且可重复生成的自动化执行环境。
本文档包括上游 docs.ansible.com 文档中的内容,该文档由 Apache 2.0 许可证涵盖。

前言

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

对红帽文档提供反馈

如果您对本文档有任何改进建议,或发现错误,请通过 https://access.redhat.com 联系技术支持来创建一个请求。

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

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

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

1.1. 关于自动化执行环境

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

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

  • Ansible Core 2.15 或更高版本
  • Python 3.8-3.11
  • Ansible Runner
  • Ansible 内容集合及其依赖项
  • 系统依赖项

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 时,您可以轻松地创建一个可自定义的自动化执行环境定义文件,该文件指定自动化执行环境中包含的内容,如 Ansible Core、Python、Collections、第三方 Python 要求和系统级别软件包。这可让您满足所有必要的要求和依赖项来获取作业运行。

2.2. 安装 Ansible Builder

先决条件

流程

  1. 在终端中,运行以下命令来激活 Ansible Automation Platform 仓库:

    #  dnf install --enablerepo=ansible-automation-platform-2.4-for-rhel-9-x86_64-rpms ansible-builder

2.3. 构建定义文件

安装 Ansible Builder 后,您可以创建一个定义文件,Ansible Builder 用来创建自动化执行环境镜像。Ansible Builder 通过读取和验证定义文件来创建自动化执行环境镜像,然后创建一个 Containerfile,最后将 Containerfile 传递给 Podman,然后打包并创建自动化执行环境镜像。您创建的定义文件必须采用 yaml 格式,并包含不同的部分。默认定义文件名(如果未提供)是 execution-environment.yml。有关定义文件的部分的更多信息,请参阅 定义文件内容的明细

以下是版本 3 定义文件的示例。每个定义文件必须指定其使用的 Ansible Builder 功能集的主版本号。如果没有指定,Ansible Builder 默认为版本 1,使大多数新功能和定义关键字不可用。

例 2.1. 定义文件示例

version: 3

build_arg_defaults: 1
  ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: '--pre'

dependencies: 2
  galaxy: requirements.yml
  python:
    - six
    - psutil
  system: bindep.txt

images: 3
  base_image:
    name: registry.redhat.io/ansible-automation-platform-24/ee-minimal-rhel9:latest

# Custom package manager path for the RHEL based images
 options: 4
 package_manager_path: /usr/bin/microdnf

additional_build_steps: 5
  prepend_base:
    - RUN echo This is a prepend base command!

  prepend_galaxy:
    # Environment variables used for Galaxy client configurations
    - ENV ANSIBLE_GALAXY_SERVER_LIST=automation_hub
    - ENV ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_URL=https://console.redhat.com/api/automation-hub/content/xxxxxxx-synclist/
    - ENV ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_AUTH_URL=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
    # define a custom build arg env passthru - we still also have to pass
    # `--build-arg ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_TOKEN` to get it to pick it up from the env
    - ARG ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_TOKEN

  prepend_final: |
    RUN whoami
    RUN cat /etc/os-release
  append_final:
    - RUN echo This is a post-install command!
    - RUN ls -la /etc
1
列出构建参数的默认值。
2
指定各种要求文件的位置。
3
指定要使用的基础镜像。红帽支持仅针对 redhat.registry.io 基础镜像提供。
4
指定可能会影响构建器运行时功能的选项。
5
用于其他自定义构建步骤的命令。

其他资源

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 中可以使用的值:

Description

ANSIBLE_GALAXY_CLI_COLLECTION_OPTS

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

ANSIBLE_GALAXY_CLI_ROLE_OPTS

允许用户将任何标志(如 -no-deps)传递给角色安装。

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

注意

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

您可以在定义文件的 dependencies 部分包含必须安装到最终镜像的依赖项。

为了避免自动化执行环境镜像出现问题,请确保 Galaxy、Python 和系统的条目指向有效的要求文件,或者是其相应的文件类型的有效内容。

2.5.1.1. Galaxy

galaxy 条目指向有效的要求文件,或者包括 ansible-galaxy collection install -r …​ 命令的内联内容。

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

内容可能类似如下:

例 2.2. Galaxy 条目

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

定义文件中的 python 条目指向有效的要求文件,或者指向 pip install -r …​ 命令格式的 PEP508 格式的 Python 要求列表。

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

例 2.3. Python 条目

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
openshift>=0.6.2
requests-oauthlib
openstacksdk>=0.13
ovirt-engine-sdk-python>=4.4.10
2.5.1.3. System

定义中的 system 条目指向 bindep 要求文件,或指向 bindep 条目的内联列表,该条目安装集合已包含为依赖项的系统级依赖项。它可以是来自自动化执行环境定义的文件夹目录的相对路径,也可以列为绝对路径。至少,集合必须为 [platform:rpm] 指定必要的要求。

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

例 2.4. 系统条目

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

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

2.5.2. 镜像

定义文件的 images 部分标识基础镜像。podman 容器运行时支持验证签名的容器镜像。

下表列出了您可以在 镜像 中使用的值:

valueDescription

base_image

指定自动化执行环境的父镜像,它允许基于现有镜像构建新镜像。这通常是一个受支持的执行环境基础镜像,如 ee-minimalee-supported,但它也可以是您创建的执行环境镜像,并希望进一步自定义。

容器镜像需要使用 name 键。如果镜像在存储库中镜像,则指定 签名 _original_name 密钥,但使用镜像的原始签名密钥签名。镜像名称必须包含标签,如 :latest

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

注意

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

2.5.3. 其他构建文件

您可以将任何外部文件添加到构建上下文目录中,方法是将它们引用或复制到定义文件的 additional_build_steps 部分。格式是字典值的列表,每个值都有一个 srcdest 键和值。

每个列表项都必须是包含以下所需键的字典:

src
指定要复制到构建上下文目录中的源文件。这可以是绝对路径(例如 /home/user/.ansible.cfg),也可以是相对于执行环境文件的路径。相对路径可以是 glob 表达式与一个或多个文件匹配(例如,fileAttr. cfg)。
注意

绝对路径不能包含正则表达式。如果 src 是目录,则该目录的整个内容都会复制到 dest

dest
指定构建上下文目录的 _build 子目录下的子目录路径,其中包含源文件(如 files/configs)。这不能是绝对路径,也可以是在 路径中包含 ..。如果不存在,Ansible Builder 会为您创建此目录。

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

您可以在定义文件的 additional_build_steps 部分中为任何构建阶段指定自定义构建命令。这允许对构建阶段进行精细控制。

使用 prepend_append_ 命令将指令添加到在执行主构建步骤之前或之后运行的 Containerfile。命令必须符合运行时系统所需的任何规则。

下表列出了 additional_build_steps 中使用的值:

Description

prepend_base

允许您在构建基础镜像前插入命令。

append_base

允许您在构建基础镜像后插入命令。

prepend_galaxy

允许您在构建 galaxy 镜像前插入。

append_galaxy

允许您在构建 galaxy 镜像后插入。

prepend_builder

允许您在构建 Python 构建器镜像前插入命令。

append_builder

允许您在构建 Python 构建器镜像后插入命令。

prepend_final

允许您在构建最终镜像前插入。

append_final

允许您在构建最终镜像后插入。

additional_build_steps 的语法支持多行字符串和列表。请参见以下示例:

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

prepend_final: |
   RUN whoami
   RUN cat /etc/os-release

例 2.6. 一个列表条目

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

2.5.5. 其他资源

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 和容器构建上下文,并选择性地将它们传递给 Podman 以构建自动化执行环境镜像。容器构建以几个不同的阶段发生: basegalaxybuilder最终。镜像构建步骤(以及 additional_build_steps中定义的任何对应的自定义 prepend_append_ 步骤)包括:

  1. 基础 构建阶段,指定的基础镜像是(可选)由其他构建阶段自定义的组件,包括 Python、pipansible-coreansible-runner。然后,生成的镜像会被验证以确保所需的组件可用(因为它们可能已在基础镜像中存在)。生成的 自定义基础镜像 的临时副本用作所有其他构建阶段的基础。
  2. galaxy 构建阶段,由定义文件指定的集合会在 最终 构建阶段下载并供以后安装。还会收集集合声明的 Python 和系统依赖项(若有),以便稍后进行分析。
  3. 构建器 构建阶段,集合声明的 Python 依赖项与定义文件中列出的 Python 依赖项合并。最后的 Python 依赖项被下载并构建为 Python wheels,并在 最终 构建阶段存储下来。
  4. 最终 构建阶段,会安装之前下载的集合,以及系统软件包以及之前由集合声明为依赖项或定义文件中列出的依赖项的、以前构建的 Python 软件包。

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

出于安全原因,您需要使用在沙盒环境中构建的共享容器镜像,您可以创建一个可共享 Containerfile

$ ansible-builder create

第 3 章 常见自动化执行环境场景

使用以下示例定义文件来解决常见配置场景。

3.1. 更新自动化中心 CA 证书

使用本示例自定义默认定义文件,将 CA 证书包含到 additional-build-files 部分,将该文件移到适当的目录中,最后运行 命令来更新 CA 证书的动态配置,以允许系统信任此 CA 证书。

先决条件

  • 自定义 CA 证书,如 rootCA.crt
注意

使用 prepend_base 自定义 CA 证书意味着生成的 CA 配置出现在所有其他构建阶段和最终镜像中,因为所有其他构建阶段都继承自基础镜像。

additional_build_files:
  # copy the CA public key into the build context, we will copy and use it in the base image later
  - src: files/rootCA.crt
    dest: configs

additional_build_steps:
  prepend_base:
    # copy a custom CA cert into the base image and recompute the trust database
    # because this is in "base", all stages will inherit (including the final EE)
    - COPY _build/configs/rootCA.crt /usr/share/pki/ca-trust-source/anchors
    - RUN update-ca-trust

options:
  package_manager_path: /usr/bin/microdnf  # downstream images use non-standard package manager

[galaxy]
server_list = automation_hub

3.2. 在构建自动化执行环境时使用自动化中心身份验证详情

使用以下示例自定义默认定义文件,将自动化中心身份验证详情传递给自动化执行环境构建,而无需在最终的自动化执行环境镜像中公开它们。

先决条件

export ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_TOKEN=$(cat <token.txt>)
additional_build_steps:
  prepend_galaxy:
    # define a custom build arg env passthru- we still also have to pass
    # `--build-arg ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_TOKEN` to get it to pick it up from the host env
    - ARG ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_TOKEN
    - ENV ANSIBLE_GALAXY_SERVER_LIST=automation_hub
    - ENV ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_URL=https://console.redhat.com/api/automation-hub/content/<yourhuburl>-synclist/
    - ENV ANSIBLE_GALAXY_SERVER_AUTOMATION_HUB_AUTH_URL=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token

3.3. 其他资源

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

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

Ansible Controller 包括以下默认执行环境:

  • minimal - 包括最新的 Ansible-core 2.15 发行版本以及 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-24/ee-minimal-rhel8:latest
  3. 配置 Ansible Builder 文件,以指定所需的基础镜像以及添加到新执行环境镜像的任何其他内容。

    1. 例如,要将 来自 Galaxy 的 Kubernetes Core Collection 添加到镜像中,请使用 Galaxy 条目:

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

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

    version: 3
    
    images:
      base_image: 'registry.redhat.io/ansible-automation-platform-24/ee-minimal-rhel9:latest'
    
    dependencies:
      galaxy:
        collections:
          - kubernetes.core
    注意

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

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

    $ ansible-builder build -t [username]/new-ee

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

    注意

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

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

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

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

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

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

    注意

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

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

    $ podman push [automation-hub-IP-address]/[username]/new-ee
  10. 将新镜像拉取(pull)到自动化控制器实例中:

    1. 进入自动化控制器。
    2. 在导航面板中,选择 AdministrationExecution Environments
    3. Add
    4. 输入适当的信息,然后点 Save 以拉取新镜像。

      注意

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

4.2. 其他资源(或后续步骤)

有关基于常见场景自定义执行环境的更多详细信息,请参阅 Ansible Builder 文档中的以下主题:

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

默认情况下,私有自动化中心不包括容器镜像。要填充容器 registry,您需要将容器镜像推送到其中。

您必须遵循特定的工作流来填充私有自动化中心容器 registry:

  • 从红帽生态系统目录 (registry.redhat.io) 中拉取镜像
  • 标记它们
  • 将它们推送到您的私有自动化中心容器 registry
重要

2025 年 4 月 1 日起, quay.io 正在添加三个额外的端点。因此,客户必须调整防火墙系统列表中的允许/块列表,使其包含以下端点:

  • cdn04.quay.io
  • cdn05.quay.io
  • cdn06.quay.io

为了避免拉取容器镜像出现问题,客户必须将出站 TCP 连接(端口 80 和 443)到以下主机名:

  • cdn.quay.io
  • cdn01.quay.io
  • cdn02.quay.io
  • cdn03.quay.io
  • cdn04.quay.io
  • cdn05.quay.io
  • cdn06.quay.io

此更改应针对用于启用到 registry.redhat.ioregistry.access.redhat.com 的出站连接的任何防火墙配置进行修改。

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

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

如需更多信息,请参阅容器镜像防火墙更改 2024/2025

确保 Table 6.4 中列出的 网络端口和协议。执行环境(EE) 可用于避免拉取容器镜像的问题。

5.1. 拉取 (pull) 用于自动化中心的镜像

在将容器镜像推送到私有自动化中心之前,您必须首先从现有 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. 检查镜像名称,并验证标签是否正确。

其他资源

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

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

前提条件

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

流程

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

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

验证

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

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

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

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

前提条件

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

流程

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

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

    $ podman push <automation_hub_url>/<container_image_name>

故障排除

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 存储库列表中找到容器。

第 6 章 设置容器存储库

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

6.1. 设置容器 registry 的先决条件

  • 已登陆到一个私有自动化中心。
  • 您有更改存储库的权限。

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

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

前提条件

  • 有更改容器的权限。

流程

  1. 登录到自动化中心。
  2. 在导航面板中,选择 Execution EnvironmentsExecution Environments
  3. 选择您的容器存储库。
  4. Details 标签页中,点 Add
  5. Raw Markdown 文本字段中,使用 Markdown 格式输入您的 README 文本。
  6. 完成后点 Save

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

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

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

前提条件

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

流程

  1. 登录到自动化中心。
  2. 在导航面板中,选择 Execution EnvironmentsExecution Environments
  3. 选择您的容器存储库。
  4. Access 选项卡中,点 Select a group
  5. 选择您要授予访问权限的组,然后点 Next
  6. 选择您要添加到此执行环境的角色,然后点 Next
  7. Add

6.4. 标记容器镜像

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

前提条件

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

流程

  1. 在导航面板中,选择 Execution EnvironmentsExecution Environments
  2. 选择您的容器存储库。
  3. Images 选项卡。
  4. More Actions 图标 ,点 Manage tags
  5. 在文本字段中添加新标签,然后点 Add
  6. 可选:通过点该镜像的任何标签上的 x 来删除当前标签
  7. 点击 Save

验证

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

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

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

在早期版本的 Ansible Automation Platform 中,您需要部署 registry 来存储执行环境镜像。在 Ansible Automation Platform 2.0 及更新的版本中,系统会象您已启动并运行容器 registry 一样运行。要存储执行环境镜像,请仅添加所选容器 registry 的凭证。

流程

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

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

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

7.1. 拉取镜像

您可以从自动化中心容器 registry 中拉取镜像,以在本地机器中创建副本。

前提条件

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

流程

  1. 如果您要从密码保护的 registry 中拉取容器镜像,请在拉取镜像前 在自动化控制器中创建凭证
  2. 在导航面板中,选择 Execution EnvironmentsExecution Environments
  3. 选择您的容器存储库。
  4. Pull this image 条目中,点 Copy to clipboard
  5. 在终端中粘贴并运行命令。

验证

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

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

您可以从自动化中心容器 registry 拉取镜像,将镜像同步到本地机器。要从远程容器注册表同步镜像,您必须首先配置远程 registry。

前提条件

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

流程

  1. 在导航面板中,选择 Execution EnvironmentsExecution Environments
  2. https://registry.redhat.io 添加到 registry。
  3. 添加所需的任何凭证进行验证。

    注意

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

  4. 在导航面板中,选择 Execution EnvironmentsExecution Environments
  5. 在页面标头中点 Add execution environment
  6. 选择您要从中拉取的 registry。Name 字段显示本地 registry 中显示的镜像名称。

    注意

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

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

其他资源

部分 I. 开源许可证

Apache License

版本 2.0,2004 年 1 月

http://www.apache.org/licenses/

使用、重新生产环境和发行版本的条款和条件

1.定义。

"许可" 应意味着使用、重新生产环境以及由本文档第 1 节到第 9 部分定义的条款和条件。

"licensor" 应表示版权所有者或由许可许可的版权所有者或实体授权。

"图实体" 应意味着参与实体的联合,以及控制、由其控制或与其实体共同控制的其他实体。就此定义而言,"控制" 表示(i)电源、直接或间接导致此类实体的方向或管理,无论是根据合同还是以其他方式管理此类实体,还是(ii)所有权(50%)或更多未完成共享,或者(iii)有益于此类实体的所有权。

"您 " (或 "您的")应表示许可证授予的个人或法务实体法案权限。

"源" 格式应意味着进行修改的首选形式,包括但不限于软件源代码、文档源和配置文件。

"对象" 格式应表示由源代码转换或转换形式生成的任何形式,包括但不限于编译的对象代码、生成的文档,以及转换为其他介质类型。

"工作" 应表示,无论是在许可证下提供的 Source 或 Object 表单,无论是在许可证下提供,如以下附录中包括或附加到工作的版权声明(以下示例在下方附录中提供)。

"derivative Works" 应该意味着任何工作,无论是在 Source 或 Object 表单中,它基于(或来自)工作,以及编辑修订、标注、电子协作或其他修改代表,作为一个整体是原始的作者。出于此许可证的目的,Derivative Works 不应包括保持从中分离的工作,或者将 (或按名称绑定)链接到 Work 和 Derivative Works 的接口。

"贡献"应表示任何编写版本的工作,包括工作者的最初版本,以及对该工作的修改或补充,以代表版权所有者提交给个人或法 务实体。就此定义而言,"提交" 表示任何形式的电子、操作操作或写入通信,这些通信都发送到 Licensor 或其代表,包括但不仅限于电子邮件列表、源代码控制系统和由管理的问题跟踪系统或代表,用于讨论和改进工作的目的,但排除那些被版权所有者 写为"不 Contribution"的写入或指定的通信

"贡献者" 应该代表代表代表某个 Contribution 收到 Contribution 的任何个人或法务实体,并在工作中纳入了随后在工作中。

2.授权版权许可证.根据此许可证的条款和条件,每个 Contributor hereby 都授予您在全球范围内、非独占、非计费、免收、免版、免版的版权许可证来复制、准备 Derivative Works、公开显示、公开执行、子许可以及分发工作中的 Work 和 such Derivative Works。

3.授予 Patent 许可证。根据本许可证的条款和条件,每个 Contributor 都会授予您全球性、非独占、非计费、免收、免版、免版、不可取的、不可撤销(除本小节中声明除外)进行贡献、非独占性、使用、销售、无法销售的许可证。导入并转让工作,其中此类许可证只应用于那些需要单独出版的贡献或其贡献者的贡献方许可的披露。如果您认为对任何实体(包括法律的跨声明或反权声明)承担任何实体(包括跨声明或反权声明)除除在工作中包括工作或贡献的贡献方的义务会构成直接或贡献者不侵权,那么为这一工作许可证授予的任何有力的隐性许可证将终止给您。

4.再发布.您可以在任何介质(带有或不修改的情况下)在 Work 或 Derivative Works 中复制并分发副本,前提是您满足以下条件:

  1. 您必须为 Work 或 Derivative Works 赋予任何其他接收方,并为其提供此许可证的副本。
  2. 您必须使任何修改的文件具有重要通知,表示您更改了文件;以及
  3. 您必须保留以任何 Derivative Works 形式的 Source 表单,分发、所有版权、质量、商标和发布通知,不包括与 Derivative Works 的任何部分无关的声明,以及
  4. 如果工作中包含一个 "NOTICE" 文本文件作为其分发的一部分,则分发的 Derivative Works 都必须包含在此类 NOTICE 文本文件中所含的不涉及的 Derivative Works 的读取副本,不包括与 Derivative Works 的任何部分无关的这些通知,且至少在以下某个位置: NOTICE 文本文件中分发为 Derivative Works 的一部分; 在 Source 表单或文档中,如果与 Derivative Works 一起提供,或者在 Derivative Works 生成的显示中(如果和通常出现此类第三方通知)。NOTICE 文件的内容仅用于信息,不修改许可证。您可以在 Derivative Works 内添加您自己的tribution 通知,您一起分发、或作为工作中 NOTICE 文本的附录,只要此类在tribution 通知中被认为是修改许可证的情况。

您可以将自己的版权声明添加到您的修改中,并可能还会提供其他或不同的许可证条款和条件以供使用、重新生产或发布您的修改,或针对整个此类 Derivative Works 作为一个整体、提供您的用途、再生产和发布,否则可能满足本许可证中规定的条件。

5.提交贡献.除非另有明确的状态,否则您特意提交的任何贡献需要您本许可的条款和条件应遵循此许可证的条款和条件,而无需任何其他条款或条件。对于以上内容,这里什么都不能取代或修改您可能通过有关此类贡献的许可协议所执行的单独许可条款。

6.商标。此许可证不授予使用 Licensor 的交易名称、商标、服务标记或产品名称的权限,除了在描述工作来源和生成 NOTICE 文件内容的需要外。

7.免责声明.除非适用法律或同意编写,Licensor 会为"AS IS" BASIS、WITHOUT WARRANTIES 或 CONDITIONS OF ANY KIND 提供工作(每个 Contributor 提供) 没有限制,TITLE、NON-INFRINGEMENT、MERCHANTABILITY 或 FITNESS FOR A PARTICULAR PURPOSE 的任何保证或条件。您只负责确定使用或重新分发工作中的相应性,并假定与您在许可证下权限行行相关的任何风险。

8.责任限制.在任何事件或没有法律要求的情况下,无论是在书写中(包括 negligence)、合同,或以其他方式要求,除非适用法律的要求(如人体和自信行为)或同意书写,则应对您造成损坏,包括任何直接的、包括任何直接的责任。由于此许可证导致,间接、特殊、事件或违反任何字符的破坏,或者无法使用或不当使用或无法利用(包括但不限于损害损害、工作停止页面、计算机故障或有潜在其他商业破坏或损害),即使此类行为已被认为是此类损害的损失,也建议此类损害。

9.接受 Warranty 或 Additional Liability。虽然重新分发工作或 Derivative Works,但您可以选择提供费用,并收取支持、接受支持、保证、伪造或其他责任义务和/或与此许可证一致的费用费用。但是,在接受此类义务时,您可能只代表您的责任,不代表您的责任,不代表其他贡献,并且只有在您同意遵守遵守、国防和国防措施,并保证每个义务,不承担任何责任,或根据您接受此类保证或任何责任而承担任何责任。

条款和条件结束

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

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

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

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

法律通告

Copyright © 2025 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.