Ansible 与 Terraform 的区别

还可以查看 RedHat.com 上的文章 Ansible vs. Terraform，以了解更多信息。

Ansible 和 Terraform 是两个非常强大但独特的开源 IT 工具，在竞争性讨论中经常被比较。我们经常看到对这两个工具的比较 - 但很多时候，这些比较纯粹是从“规格表”的角度进行的。这种类型的比较虽然很有趣，但没有考虑到大规模使用产品，或者比较是否现实，因为它采用了二元非此即彼的方法。Red Hat 20 多年来一直致力于帮助企业，并且非常了解大多数 IT 管理员如何在生产环境中使用这两个工具。尽管这两个工具通常可以完成大多数事情，但我们通常会看到它们分别利用各自最大的优势，而不是必须二选一。

剧透：这两个工具结合使用效果更好，可以协同工作，为开发和运维团队创造更好的体验。

Ansible 和 Terraform 都是具有庞大用户群的开源工具，由于经典的“锤子”方法，往往会形成追随者。也就是说，如果我的唯一工具是锤子，那么每个问题都会开始看起来像钉子。这最终会导致我只能用我所知道的方式解决新问题，而不是尝试可能更有效的其他工具。只了解一种工具及其方法和理念从来都不是一个好主意。相反，您应该敞开心扉，了解为什么存在不同的工具和平台，以及为什么成功的组织可能会同时使用两者。在本篇博文中，我们将介绍 Ansible 和 Terraform 之间的差异和相似之处，以及这些开源项目及其下游的企业产品。请记住，这是一篇博文，请查看日期以确保相关性，因为产品和项目在不断变化和发展。

Terraform

Terraform 是一个开源项目，由 HashiCorp 公司赞助。Terraform 是 HashiCorp 推出的众多开源项目之一，其他项目包括 Vagrant、Packer、Consul 和 Vault。HashiCorp 专门有一种名为 HashiCorp 道 的设计理念，他们希望自己的项目和产品简单、模块化和可组合。在这种情况下，每个项目和产品的配对都有明确的范围，对于更大的工作流，您将组合多个项目和产品。他们用以下目的来定义 Terraform

Terraform 是 HashiCorp 提供的基础设施即代码产品。它是一个用于以安全、可重复的方式构建、更改和管理基础设施的工具。运营和基础设施团队可以使用 Terraform 通过名为 HashiCorp 配置语言 (HCL) 的配置语言来管理环境，以便进行人性化的自动化部署。 来源

Terraform 主要只支持命令行，但与一组流行的公共云很好地集成。Terraform 非常擅长配置固定的云基础设施集并在之后将其拆除。HashiCorp 为客户提供了两种 Terraform 产品化方法，他们可以使用 Terraform Enterprise 自行管理自定义部署，或者可以使用其托管服务 Terraform Cloud。他们的商业版提供了漂移检测、SSO 审计日志、自托管代理和自定义并发。

Ansible

Ansible 是一种 IT 自动化工具。它可以配置系统、部署软件以及编排更高级的 IT 任务，例如持续部署或零停机滚动更新。大多数人熟悉社区版 Ansible，它是一个用于运行 Ansible Playbook 的命令行工具。与 Terraform 一样，Ansible 侧重于简单易用。Ansible 使用 YAML 语法 来编写 Ansible playbook。我们使用 YAML 是因为它比其他常见的数据格式（如 XML 或 JSON）更容易让人类阅读和编写。

Red Hat Ansible Automation Platform 是提供给客户的产品。它建立在 Ansible 的基础之上，具有众多企业级功能，将十多个上游项目整合到一个集成的、简化的产品中。每个产品组件也都有一个特定的用途，并具有明确的范围，类似于 HashiCorp 的设计理念。例如，自动化控制器是 Ansible 自动化的 Web UI 和 API，它基于上游项目 AWX。此组件捆绑到平台中以管理自动化。Ansible Automation Platform 可以 在本地运行，并按节点（而非按用户）收费，或者您可以使用 Microsoft Azure 上的托管服务。

总而言之，Ansible 和 Terraform 都有仅限命令行的开源版本。它们都提供了具有企业级功能（如 Web UI 或 SSO）的产品。其社区版本的首要区别在于 Ansible 是一种多用途自动化工具，而 Terraform 是一种基础设施即代码工具。混乱的出现是因为有许多用例可能由这两种工具解决，并且 Ansible 和 Terraform 都有插件可以相互调用。例如，许多 Ansible 专家只是使用 Ansible Playbook 配置 AWS 资源，可能不明白为什么其他人使用完全不同的工具。同样，Terraform 专家甚至可能为最小的配置更改创建和销毁整个实例（请参阅下一节关于不变性的内容）。

不变基础设施：杀手级应用？

Terraform 采用了一种不变的基础设施方法。如果您不熟悉不变基础设施，则将其定义为不会随时间变化或无法更改的实例。为了简化，IT 运营人员可以创建一个声明性文件（Terraform HCL 文件），该文件以结构化数据表示他们希望其最终状态的云足迹是什么样子，并使用 Terraform 部署它。这种方法的优势之一是它创建了一个单一的事实来源（该 HCL 文件），可以一遍又一遍地部署它，而无需了解它是如何到达最终状态的。对于快速上手的个人来说，这种方法可能很简单且优雅，但根据基础设施的规模，它可能会变得 复杂且难以管理。不变方法的另一个优点是拆除（取消配置）云资源同样容易。这允许开发人员快速启动资源、测试某些内容，然后将其拆除。

Ansible 在设计上采用了一种命令式的方法进行自动化。您只需有一个任务列表，迭代每个资源。您将告诉它配置此 VPC、此子网，然后是此 VM。这种方法的优点是它非常易于理解，没有隐藏的魔法，这有助于它易于故障排除。缺点是通常在不知道正确顺序的情况下执行拆除和取消配置会比较麻烦。我必须删除实例，然后是安全组，依此类推。但是，Ansible 支持调用 AWS CloudFormation（AWS 的另一种不变和声明性方法）和 Terraform。事实上，Ansible Automation Platform 对所有主要的公共云都这样做，并鼓励人们使用他们首选的配置和取消配置方法。这是一个很好的例子，说明 Terraform 和 Ansible 结合使用效果更好。

重要提示：尽管 Ansible 并非普遍不变，但根据您实现各个任务的方式，一些 Ansible 任务可以是不可变的。

举个例子：您可以使用 Ansible Playbook 在公共云中配置 Linux 虚拟机，方法是使用 CloudFormation 模板，然后通过 dnf Ansible 模块 安装应用程序。此活动将完全不受 Ansible 影响。大多数 Ansible 模块都设计为 幂等，以便它们仅在需要时进行更改。Ansible 非常灵活，并且很容易自动化非幂等的 shell 命令，这些命令在每次运行 playbook 时都会发生变化。这展示了 Ansible 作为多用途自动化工具与离散基础设施即代码工具之间的区别。

用例对比

如果您阅读了所有关于 Terraform 的文章，您会发现它们都侧重于公共云。这是不可变基础设施运作良好且 Terraform 在为 AWS、Azure、Docker、GCP 和 OCI 配置云资源和应用程序方面非常出色的地方。但是，IT 运营不仅仅是自动化的基础设施配置，这就是 Ansible 也非常受欢迎的原因。这并不是对 Terraform 的贬低，它是一个具有特定目的和理念的特定工具，旨在专门用于基础设施即代码。但是，此基础设施即代码完全取决于您如何定义您的基础设施。我的关键 Cisco IOS 网络交换机不是基础设施吗？IT 基础设施对不同的 IT 管理员来说可能意味着很多不同的东西，这取决于他们是网络工程师、云运营工程师、系统管理员还是拥有其他职位或角色。

Ansible 专注于具有各种用例的自动化，这些用例通常由于其遗留孤岛而被划分为不同的领域。

• 基础设施自动化 - 包括 Linux 和 Microsoft Windows 以及 NetApp、PureStorage 和 HPE 等存储供应商的自动化。
• 网络自动化 - 包括来自 Arista、Cisco、F5 和 Juniper 等知名供应商的物理交换机、路由器、负载均衡器和 SDN 控制器。
• 安全自动化 - 集成来自 IBM、Checkpoint 等供应商的 SIEM、IDPS 和防火墙，以及 ServiceNow 等 ITSM 工具。
• 边缘和混合云足迹。

转向事件驱动的 IT 策略

与 Terraform 相反，Ansible 更多地关注整个 IT 工作流。例如，考虑以下工作流

1. 将 Web 应用程序部署到 AWS。
2. 使用 Web 应用程序信息更新您的 ServiceNow ITSM。
3. 运行计划以每小时检查一次 Web 应用程序是否在正确的端口上响应或使用事件流监视端口和应用程序以进行进一步的自动化。
4. 如果 Web 应用程序停止响应，则更新/创建 ServiceNow 工单并尝试进行自动化修复。

在以上示例中，仅仅将 Web 应用程序配置到公共云是不够的。在此自动化工作流中，还需要执行其他步骤。我们需要自动化与客户的 ITSM 工具同步，并包含 Web 应用程序的事件驱动检查，以确保其正常运行（我们称之为持续 IT 合规性）。有状态自动化甚至可以保证此服务在人工操作员在您的自动化之外进行更改时保持运行。

更好：Ansible 编排 Terraform

Terraform 是一个出色的用于基础设施即代码的云配置和取消配置工具。Ansible 是一款出色的通用跨域自动化解决方案。两者都拥有令人惊叹的开源社区和良好的下游付费产品支持。我们在社区、客户甚至我们自己的 IT 工作流中看到的是，您可以将这些工具和解决方案结合起来创建更出色的 IT 工作流。如果您已经投资了 Terraform，Ansible 只是允许您将这些 HCL 模板包装到更全面的自动化工作流中。Ansible 进一步扩展了您的自动化，允许您将配置管理和应用程序部署等任务添加到 Terraform IaC 部署中。

人们如何使用 Ansible？

我们注意到，许多 IT 管理员更倾向于参考特定的“云部署和停用”用例，而不是查看其他云运营用例，例如第 2 天运营。为了激发一些想法，让我们重点介绍一些当今 Ansible 云自动化用例，而不仅仅是配置和取消配置云资源。

• 基础设施可见性 - 这只是简单地使用 Ansible 从您的公共云中检索信息以了解您的云足迹。对于存在大量 IT 管理员在彼此之外配置资源的棕地环境，这非常有用。当没有强制性 IT 流程时，这是一个很好的入门用例，因为它只读并且不需要进行生产更改。
• 合规性 - 我们不仅需要将云基础设施视为代码，还需要将云视为代码。例如，我们可以执行 IAM 策略并确保在公共云中提供一致的体验。另一个示例是在您的实例中强制执行标签策略以进行计费和审计以及关闭不合规的实例。Ansible 的优点在于它可以在可变和不可变的基础设施上运行和执行这些策略。
• 业务连续性 - Ansible 可以帮助保持系统正常运行。将资源移出云并复制，创建和管理备份策略，并构建自动化以管理中断和故障。
• 云运营 - Ansible 可以自动化第 2 天活动。这包括应用程序部署和 CI/CD 管道、生命周期管理和执行以及操作系统修补和维护。
• 云迁移 - Ansible 可以帮助将工作负载迁移到您需要的位置。例如，对本地基础设施采用自动化可以帮助运营商采用公共云。确保您的真相来源是自动化而不是盒内配置是云迁移的第一步。Ansible 自动化还可以减少迁移到云原生的摩擦，允许开发人员从遗留基础设施迁移。通过使用 Ansible 自动化，IT 小组可以帮助统一跨遗留和云原生的自动化架构。
• 基础设施优化 - 采用云可以帮助 IT 运营商节省时间和金钱，但最初很难预测成本并了解您的计费要求如何变化。拥有自动化策略可以帮助您通过关闭未使用的资源、调整云资源大小并结合基础设施可见性等用例来控制成本，您可以轻松地恢复孤立的资源并确保没有意外成本。
• 基础设施编排 - 我们之前讨论过这一点，但是您如何集成公共云之外的所有内容？编排只是我们如何打破孤岛并与云外部的基础设施集成的过程。这使 IT 运营商能够编排业务成果而不是技术孤岛，并在所有基础设施中应用一致的合规性。
• 自动化故障排除 - 随着您的 IT 团队对自动化的信心增强，我们可以转向事件驱动的架构。这使 IT 团队能够更快地响应事件，加快平均解决时间并与组织的 ITSM 解决方案集成。

人们是否取得了成功？

简短的回答？是的！甚至使用 Ansible 自动化 Terraform！但是，整体自动化不仅仅是在云中做好一件事。Ansible 可以自动化和编排物理、虚拟和云资源。它可以自动化网络设备、Windows 服务器、存储以及当然还有 Linux 的配置、配置管理和管理第 2 天运营。但是，无论人们决定使用什么来解决问题，我们发现真正的问题不在于从技术角度来看问题是如何解决的，而更多地是关于在技术领域之间进行标准化，同时发展壮大并扩展到整个 IT 组织。

使用 Ansible Automation Platform 在云中获得的最令人印象深刻且最近的成功案例之一是亚洲开发银行。发布的 案例研究 详细介绍了他们如何在实现基础设施现代化的同时实现员工队伍的现代化，使他们有更多时间专注于更重要的事情，例如创新项目和新的服务产品。他们在第 0 天标准化使用 Terraform，而在第 1 天和第 2 天运营中标准化使用 Ansible Automation Platform。在嵌入的 视频 中查看他们的故事！

最后的想法

Ansible 和 Terraform 之间的混淆已经存在了一段时间，这可能是由于不准确（或过时）的源材料或使用任一/两种技术缺乏经验造成的。这篇博文（虽然有点偏颇）应该至少能够开启关于 Ansible 和 Terraform 之间更深层次联系的讨论。每个情况、用例和实施解决方案的人员都可能有所不同，但由于这些因素，我们认为 Ansible 是自动化最佳解决方案。

自动化执行环境的构成

Red Hat Ansible Automation Platform 2 引入了诸如自动化网格和自动化执行环境等主要的架构更改，这些更改有助于以灵活的方式扩展 Ansible 自动化到您的整个组织，为所有组织和混合云自动化需求提供单一解决方案。

自动化执行环境是充当 Ansible 运行时的容器镜像，用于自动化控制器作业。Ansible Automation Platform 还包括一个名为 ansible-builder（执行环境构建器）的命令行工具，它允许您通过指定 Ansible 内容集合和 Python 依赖项来创建自动化执行环境。

通常，自动化执行环境包括

• Python 版本。
• ansible-core 版本。
• Python 模块/依赖项。
• Ansible 内容集合（可选）。

在本博文中，我将带您了解 ansible-builder 的内部工作原理以及如何将上述所有要求打包到自动化执行环境中并在 Ansible Automation Platform 中交付。

两个 ansible-builder 包的故事

与 Red Hat 的所有项目一样，ansible-builder 遵循开放开发模型和上游优先的方法。 ansible-builder 的上游项目作为 Python 包分发，然后打包到 Ansible Automation Platform 下游的 RPM 中。这也意味着有不同的方法来安装上游包和下游 ansible-builder。

注意：要获取下游包，您必须订阅来自 Red Hat 的 Ansible Automation Platform 存储库。

上游

pip3 install ansible-builder

下游：

dnf install ansible-builder

这有时会导致用户之间产生混淆，因为 Ansible Automation Platform 的客户也可以免费安装 Python 包。上游和下游包之间存在细微差别，在深入构建自动化执行环境之前，您应该了解这些差别。

如前所述，自动化执行环境是充当 Ansible 运行时的容器镜像，而 ansible-builder 与 Podman 和 Docker 等通用容器引擎非常相似。因此，与任何其他容器引擎一样，构建镜像的概念从基础镜像开始；这就是 ansible-builder 的上游和下游包的不同之处。上游 ansible-builder（Python 包）中使用的基础镜像作为预定义常量如下所示

EE_BASE_IMAGE='quay.io/ansible/ansible-runner:latest'
EE_BUILDER_IMAGE='quay.io/ansible/ansible-builder:latest'

下游包中的基础镜像如下所示

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'

上游基础镜像可通过 Red Hat Quay.io 获取，而下游镜像来自 Red Hat 生态系统目录 (registry.redhat.io)，这需要使用 Red Hat 帐户进行身份验证。这些镜像的另一个区别在于，上游镜像使用 CentOS 镜像作为基础镜像，而下游镜像使用 Red Hat 通用基础镜像 (UBI)。与 CentOS 镜像相比，UBI 为官方 Red Hat 容器镜像提供了更高的可靠性、安全性以及性能。

上游和下游软件包的一个共同点是，它们都允许通过一个名为 execution-environment.yml 的自动化执行环境规范文件进行镜像配置。

无论您是 Ansible Automation Platform 客户还是 ansible-builder 的社区用户，您都可以根据软件包或通过传递不同的基础镜像集到您的自动化执行环境规范文件中，将 UBI 镜像或 CentOS 镜像用作您的自动化执行环境的基础镜像。

为什么 ansible-builder 软件包有两个基础镜像？

承接上一节介绍 ansible-builder 的上游和下游基础镜像，有两个参数指定要使用的镜像。

• EE_BASE_IMAGE 构建参数指定自动化执行环境的父镜像。
• EE_BUILDER_IMAGE 构建参数指定用于编译类型任务的镜像。

对于大多数容器镜像，您通常只需要一个基础镜像，然后在其上添加不同的指令（也称为构建步骤）来创建最终的容器镜像。

但是，基础自动化执行环境 (ee-minimal) 是使用容器的多阶段构建概念构建的。EE_BUILDER_IMAGE 构建参数用作中间步骤，用于安装集合和构建依赖项，以尽可能降低基础镜像的大小。

让我们举个例子：假设您的 Ansible 内容集合依赖于一个需要使用 python-dev 软件包（例如 NumPy）编译的 Python 软件包。由于 python-dev 是编译时依赖项，因此您不一定需要它在最终软件包中（您只需要 NumPy 软件包即可）。您不希望在最终镜像中包含 python-dev，以尽可能降低镜像大小。为此，EE_BUILDER_IMAGE 用于构建依赖项，然后仅复制最终自动化执行环境所需的软件包 wheel。

如果我想构建自定义自动化执行环境，这是否重要？

在大多数情况下，这并不重要。当您使用 ansible-builder 构建自动化执行环境时，您只需要 EE_BASE_IMAGE 而不需要 EE_BUILDER_IMAGE。但是，您应该了解如何在名为 bindep.txt 的执行环境定义文件中应用编译时二进制依赖项。对于上述示例，如果您需要将 NumPy Python 软件包作为集合的依赖项安装到 UBI8 上，则需要按如下所示指定 bindep.txt 和 requirements.txt

# bindep.txt
python38-devel [compile platform:rhel-8] #compile time dependency

# requirements.txt
NumPy

在某些情况下，当您构建自动化执行环境时，自动化执行环境规范中的配置不会反映出来或会出现错误。在这些情况下，了解 EE_BUILDER_IMAGE 的作用非常重要。下一节将更详细地解释这一点。

自动化执行环境设计

上图概述了自动化执行环境的设计方式。我在同一个框中提到了上游镜像名称及其下游对应镜像。

作为参考，CentOS 8 和 UBI8（对于下游）充当 python-base 容器镜像的基础镜像，该镜像用作运行基于 Python 的项目的镜像，因此它捆绑了一个 ansible-core 软件包支持的 Python 版本（例如 Python 3.8）。

此 python-base 镜像作为 python-builder 镜像和 ansible-runner (ee-minimal 下游) 镜像的基础镜像。为了总结 python-builder 和 ansible-builder 镜像的目的，它们构建 Python 项目，例如 ansible-core 和任何依赖于 Python 的集合。例如，如果您的集合依赖于需要在机器本身上构建 wheel 的 Python 依赖项，则它们将在 python-builder 镜像上构建。

最后，ansible-runner (ee-minimal 下游) 镜像包含 ansible-core 软件包的一个版本。ansible-builder 镜像与该镜像协同工作以构建 Python wheel，以便最终的自动化执行环境大小最小，只需保留运行所需自动化所需的内容。图中的 custom-ee1 和 custom-ee2 代表可以使用 ansible-runner (ee-minimal 下游) 和 ansible-builder 镜像创建的任何自定义自动化执行环境。

验证您的基础镜像

要开始构建自定义自动化执行环境，您应该首先验证 ansible-builder 默认使用哪些 EE_BASE_IMAGE 和 EE_BUILDER_IMAGE。要验证，首先创建一个名为 execution-environment.yml 的空自动化执行环境定义文件。

touch execution-environment.yml

然后通过在创建空定义文件的同一目录中运行以下命令，从空定义文件创建构建上下文

ansible-builder create

这将在您的工作目录中创建一个包含 Containerfile 的上下文目录。打开 Containerfile 将显示哪些镜像被设置为 BASE 和 BUILDER 镜像，并告诉您正在使用哪个 ansible-builder，上游还是下游。例如，如果您打开通过上述过程以及 ansible-builder 的 pip install 创建的 Containerfile，您将看到以下内容

ARG EE_BASE_IMAGE=quay.io/ansible/ansible-runner:latest
ARG EE_BUILDER_IMAGE=quay.io/ansible/ansible-builder:latest

FROM $EE_BASE_IMAGE as galaxy
ARG ANSIBLE_GALAXY_CLI_COLLECTION_OPTS=
USER root


FROM $EE_BUILDER_IMAGE as builder

FROM $EE_BASE_IMAGE
USER root
COPY --from=builder /output/ /output/
RUN /output/install-from-bindep && rm -rf /output/wheels

在前两行中，您可以观察到镜像指向上游镜像。如果您对 ansible-builder 的下游安装执行相同的过程，您将在类似的 Containerfile 中找到下游镜像。

使用 ansible-builder 上下文

上下文构建是 ansible-builder 的一个重要方面。您可以使用上下文更改 Containerfile 并根据您的需要自定义自动化执行环境。您可以使用此上下文以及使用 BUILDER 和 BASE 镜像进行多阶段构建的知识，在断开连接的环境中构建自动化执行环境。以下显示了一个从私有自动化中心实例提取 BUILDER 和 BASE 镜像的执行环境定义

# cat execution-environment.yml
---
version: 1
build_arg_defaults:
  EE_BASE_IMAGE: 'automation-hub.demolab.local/ansible-automation-platform-22/ee-minimal-rhel8:latest'
  EE_BUILDER_IMAGE: 'automation-hub.demolab.local/ansible-automation-platform-22/ansible-builder-rhel8:latest'

dependencies:
  python: requirements.txt

requirements.txt 文件的内容如下

# cat requirements.txt
dnspython==1.15.0

让我们为上述定义文件 execution-environment.yml 创建一个上下文

# ansible-builder create
Complete! The build context can be found at: /root/disconnected_ee/context

在断开连接的环境中构建自动化执行环境时，可能会出现以下问题（此示例考虑了构建下游镜像）。

• 无法访问外部 yum 存储库。
• 无法从外部 PyPI 服务器拉取 Python 依赖项，因此在构建自动化执行环境时使用内部 PyPI 代理。
• （可选）从内部 PyPI 镜像拉取时出现 SSL 证书问题。

首先，创建一个指向本地镜像的 pip.conf

# cat context/pip.conf
[global]
index-url = https://nexus-nexus.apps.celeron.demolab.local/repository/pypi-proxy/simple/

您将上述 pip.conf 文件和证书添加到目标自动化执行环境创建的上下文文件夹中，以将这些文件添加到您的自定义执行环境中。

使用多阶段构建知识和上下文编辑，编辑 Containerfile。请注意以粗体文本标记的部分以及一些注释。这些是用于以断开连接的方式构建自动化执行环境的更改。

# cat Containerfile
ARG EE_BASE_IMAGE=automation-hub.demolab.local/ansible-automation-platform-21/ee-supported-rhel8:latest
ARG EE_BUILDER_IMAGE=automation-hub.demolab.local/ansible-automation-platform-21/ansible-builder-rhel8:latest

FROM $EE_BASE_IMAGE as galaxy
ARG ANSIBLE_GALAXY_CLI_COLLECTION_OPTS=
USER root

ADD _build /build
WORKDIR /build


FROM $EE_BUILDER_IMAGE as builder
ADD _build/requirements.txt requirements.txt
RUN ansible-builder introspect --sanitize --user-pip=requirements.txt --write-bindep=/tmp/src/bindep.txt --write-pip=/tmp/src/requirements.txt

####### Changes to create EE in a disconnected environment
# Remove ubi repo which tries to reach external links
RUN rm -f /etc/yum.repos.d/ubi.repo
# Add pip.conf for internal pypi proxy
ADD pip.conf /etc/pip.conf
# Add CA certificate and update trust
ADD demolab-ca.crt /etc/pki/ca-trust/source/anchors/demolab-ca.crt
RUN update-ca-trust
####### This marks the end of edits for the builder stage

RUN assemble

FROM $EE_BASE_IMAGE
USER root
COPY --from=builder /output/ /output/

####### Changes to create EE in a disconnected environment
# Remove ubi repo which tries to reach external links
RUN rm -f /etc/yum.repos.d/ubi.repo
# Add pip.conf for internal pypi proxy
ADD pip.conf /etc/pip.conf
# Add CA certificate and update trust
ADD demolab-ca.crt /etc/pki/ca-trust/source/anchors/demolab-ca.crt
RUN update-ca-trust
####### This marks the end of edits for the main image

RUN /output/install-from-bindep && rm -rf /output/wheels

如果您仔细查看上面的 Containerfile，您会注意到这些补充内容修复了之前在 BUILDER 和 BASE 镜像阶段提到的所有问题，因为这两个镜像都使用此信息来拉取和构建 Python 依赖项。

了解每个阶段中发生的事情有助于您了解在何处以及在哪个阶段编辑您的 Containerfile，从而允许您对自定义自动化执行环境进行无限自定义。

最后，让我们使用以下命令构建上述执行环境

podman build -f context/Containerfile -t disconnected_ee:1.0

构建成功后，您应该会看到类似以下的消息

--> 2316db485a1
Successfully tagged localhost/disconnected_ee:1.0
2316db485a1c4e7be4a687c682d0fc90335372d7e5564774f1ff6451840ac35f

展望未来

我们的最终目标是为客户提供尽可能无缝的开发人员体验。Ansible 工程团队正在努力改进自动化执行环境构建体验，并且已经有多项改进处于计划阶段。在这些增强功能可用之前，此博客应帮助您解决围绕构建自动化执行环境过程的任何挑战。遵循上游优先模型意味着您还可以参与社区讨论，并通过 IRC 提供您的想法和反馈。请点击此处加入我们。此GitHub 拉取请求中正在讨论对自动化执行环境体验的主要增强之一，因此您也可以参与 GitHub 讨论。