作者：李晓辉

微信联系：Lxh_Chat

联系邮箱: 939958092@qq.com

为什么要构建⾃定义的自动化执行环境？

构建自己的Ansible自动化执行环境有几个显著的优势，这使得它在某些情况下比使用官方执行环境更为合理：

1. 定制化需求： 官方环境虽然提供了很多功能，但无法满足每个组织的特定需求。构建自己的执行环境可以根据具体需求进行个性化配置，从而提高效率和灵活性。

2. 安全性： 自己的执行环境可以实施更严格的安全措施，确保数据和系统的安全。你可以选择最适合自己的安全策略和工具，而不是依赖官方环境的通用方案。

3. 性能优化： 可以根据自身的硬件和软件环境进行优化，以提高性能和效率。例如，你可以选择最适合自己工作负载的硬件和操作系统，从而提升执行速度。

4. 兼容性： 构建自己的执行环境可以确保与现有系统和工具的高度兼容，避免由于官方环境更新或更改而导致的兼容性问题。

5. 成本控制： 通过选择开源工具和自有资源，可以更好地控制成本。自建环境可以避免依赖第三方服务，减少长期的运行费用。

总之，构建自己的Ansible自动化执行环境能够提供更高的灵活性、安全性和优化性能，满足独特的业务需求，同时也能有效控制成本。

构建的准备工作

如果你想给你的自动化执行环境创建个专属容器镜像，可以用 ansible-builder 命令。其实，ansible-builder 是个超级实用的小工具，专门用来帮助你构建自己的容器镜像。而且，如果你用的是 RPM 包管理器，它已经打包好了这个命令，直接安装就能用，省了不少麻烦。简单、快捷又不失灵活性，想要定制镜像的朋友一定会喜欢！

安装ansible-builder

ansible-builder 命令来创建⽤于⾃动化执⾏环境的容器镜像

1	[student@workstation ~]$ sudo dnf install ansible-builder

准备配置文件

想要自己整一个自动化执行环境的容器镜像，首先得建个工作目录，把所有需要的文件都放进去。ansible-builder 会在这个目录里找 execution-environment.yml 这个配置文件，它可是关键角色，决定了你的容器镜像该怎么构建。

这里有个 execution-environment.yml 的示例，方便你上手：

---
version: 1

build_arg_defaults:
  EE_BASE_IMAGE: registry.redhat.io/ansible-automation-platform-22/ee-minimal-rhel8:latest
  EE_BUILDER_IMAGE: registry.redhat.io/ansible-automation-platform-22/ansible-builder-rhel8:latest

ansible_config: ansible.cfg

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

简单拆解一下：

EE_BASE_IMAGE 和 EE_BUILDER_IMAGE：指定了基础镜像，直接用 Red Hat 官方的，稳得很。
EE_BASE_IMAGE：
这个是你的执行环境（EE，Execution Environment）基础镜像，相当于容器的底层系统。
- 在这里，它用的是 ee-minimal-rhel8:latest，这是个精简版 RHEL 8 镜像，带有基本的 Ansible 运行环境，适合轻量级执行任务。
- 你可以换成其他 Ansible 官方 EE 镜像，比如 ee-supported-rhel8（带更多工具和支持）。
EE_BUILDER_IMAGE：
这个是用来构建执行环境的工具镜像，相当于“工地上的施工队”。
- 这里用的是 ansible-builder-rhel8:latest，它包含了 ansible-builder 需要的一些工具，可以帮你编译、打包和安装各种依赖，最终生成一个定制化的执行环境镜像。
ansible_config：告诉 ansible-builder 你的 ansible.cfg 配置文件在哪。
dependencies：这里列出了各种依赖文件：
- requirements.yml：Ansible Galaxy 依赖，装角色和集合的。
- requirements.txt：Python 依赖，装各种库。
- bindep.txt：系统级依赖，像 yum install 之类的东东。

如果你用 红帽 Ansible 自动化平台 提供的基础镜像（比如 registry.redhat.io/...），那生成的镜像不能公开发布，比如传到 Quay.io 这种公共仓库。
想公开分享的话，有两个办法：
换成公共镜像：比如 quay.io/ansible/ansible-runner:stable-2.12-latest 这个基础镜像，它是开源的，可以自由分发。
只发布 execution-environment.yml 配置：这样别人可以自己拉取适合的基础镜像，再本地构建，不涉及镜像的直接分发，合规又省事。

声明内容集合

requirements.yml 这个文件的作用，就是告诉 ansible-builder 需要安装哪些 Ansible 内容集合（collections）

--
collections:
  - community.aws
  - community.general

也可以写的全一些

---
collections:
  - name: redhat.insights
    version: 1.0.5
    source: https://console.redhat.com/api/automation-hub/

  - name: ansible.posix
    source: https://hub.example.com/api/galaxy/content/rh-certified/

如果你的 Ansible 集合（collections）来自 私有自动化中心，那 requirements.yml 只是第一步，你 还需要在 ansible.cfg 里配置认证信息，让 Ansible 知道如何访问这些私有资源。

怎么配置 ansible.cfg？

在 ansible.cfg 里，添加 automationhub 认证信息，像这样：

[galaxy]
server_list = ansible_automation_hub, my_hub, galaxy

[galaxy_server.ansible_automation_hub]
url = https://console.redhat.com/api/automation-hub/
auth_url = https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
token = eyJh...0Nwk

[galaxy_server.my_hub]
url = https://hub.example.com/api/galaxy/content/rh-certified/
token = e8e4...b0c2

[galaxy_server.galaxy]
url = https://galaxy.ansible.com/

声明 Python 软件包

requirements.txt 这个文件用于列出 ansible-builder 在自动化执行环境里 必须安装的 Python 软件包。

sh==1.13.1
jsonschema>=3.2.0,<4.0.1
textfsm
ttp
xmltodict
dnspython

几点建议：

指定版本 → 避免因软件包更新导致的兼容性问题。
检查依赖 → 确保 requirements.yml 里的 Ansible 集合不会引入额外的 Python 依赖，避免冲突。
测试环境 → 在本地 venv 里跑 pip install -r requirements.txt 先试试看，确保没问题再用 ansible-builder 打包。

声明 RPM 软件包

bindep.txt 这个文件用于列出 ansible-builder 在自动化执行环境内需要安装的 RPM 软件包，确保运行 Ansible 任务时所需的系统级依赖都准备就绪。

[platform:rpm] 适用于所有基于 RPM 的 Linux 发行版（如 RHEL、CentOS、Fedora）

[platform:rpm]
git
gcc
gcc-c++
make
python3-devel
libffi-devel
openssl-devel

构建新的⾃动化执⾏环境

仓库身份验证

如果你的 本地镜像 或 构建器镜像 不可用，ansible-builder 会自动尝试从远程拉取这些镜像。这是默认的行为，可以确保你始终能够获取到最新的镜像，避免构建中断。

但，如果你使用的镜像来自需要 身份验证的容器仓库（比如私有的 Docker 仓库或 Red Hat 注册系统），你需要在开始构建之前完成 身份验证。否则，ansible-builder 可能会因为没有权限拉取镜像而失败。

如何进行身份验证？

如果使用 Docker Hub 或 私有 Docker 仓库，可以通过以下命令进行登录：

1	podman login quay.io

简单构建

当你准备好所有的配置文件并完成身份验证后，就可以使用 ansible-builder build 命令来构建 自动化执行环境容器镜像。这是构建镜像的核心步骤！

构建命令格式：

1	ansible-builder build --tag <image_name>:<tag>

构建完成后，你会看到新的容器镜像被创建，并可以在本地或推送到容器仓库。
如果构建成功，镜像就会在你的本地仓库中出现，准备好使用或者部署。
使用 podman images 命令，你可以查看 本地容器镜像，列出当前系统中所有的镜像信息。

自定义构建

如果你需要对 自动化执行环境的构建流程 进行更高级的自定义配置，特别是在 使用私有自动化中心 或 企业证书颁发机构（CA）签名的 TLS 证书 的情况下，ansible-builder 提供了一个自定义构建流程的机制。

阶段一：创建构建上下文（ansible-builder create）

在这个阶段，ansible-builder create 命令会做以下几件事：

创建一个新的 context/ 目录，在该目录下生成 Containerfile 文件（类似于 Dockerfile，但用于 Podman）。
在 context/ 中创建一个 _build/ 子目录，将需要的构建文件（如 requirements.yml、ansible.cfg、requirements.txt 和 bindep.txt）复制到该子目录中，确保构建流程能够访问这些文件。

这样，你就有了构建所需的所有文件和目录结构，准备好进行 自定义构建。

1	ansible-builder create

命令作用：

ansible-builder create 会根据你的配置文件（例如 requirements.yml、bindep.txt）和所需要的构建设置，自动创建一个 构建上下文。
它生成的 Containerfile 会包含 Podman 构建命令的指令。

可以进行个性化修改（比如添加企业证书、定制的配置等）

1 2	COPY my_ca.crt /etc/pki/ca-trust/source/anchors/ RUN update-ca-trust

ansible-builder create 命令每次运行时，都会重新生成 context/Containerfile 文件，这意味着你对该文件所做的任何修改都会被覆盖。

阶段二：构建容器镜像

这一步会使用 Containerfile 指令，通过 podman 构建最终的自动化执行环境容器镜像。

在创建好构建上下文之后，下一步是实际构建容器镜像：

1	podman build -f context/Containerfile -t your_custom_image:latest context

总结：

使用 ansible-builder create 创建构建上下文，以便为自定义构建流程做好准备。
在构建过程中，你可以定制化一些高级配置（比如证书安装）来确保安全连接。
一旦准备好上下文，就可以使用 podman build 来构建最终的容器镜像。

运⾏测试 Playbook

如果新⾃动化执⾏环境使⽤了⾃定义集合，则可创建⼀个 playbook 来测试这些中的⼀个或多个集
合。测试可以使⽤⼀个简单 playbook 来测试集合中包含的⻆⾊或模块。

–execution-environment-image（或 –eei）选项来指定⾃动化执⾏环境容器镜像

–pull-policy always 拉取镜像

将镜像推送到镜像仓库

tag
push