我们希望听到您的意见!帮助我们深入了解 Ansible 生态系统的现状。
参加 2024 年 Ansible 项目调查

Ansible Builder 简介

Ansible Builder 简介

您好,欢迎阅读另一篇 Ansible 简介博客文章,我们将介绍一个新的命令行界面 (CLI) 工具 Ansible Builder。请注意,本文将涵盖一些中级主题,例如容器(Ansible Builder 默认使用 Podman)、虚拟环境和 Ansible 内容集合。如果您对这些主题有所了解,请继续阅读,了解 Ansible Builder 是什么,它为什么被开发以及如何使用它。

该项目目前正在 GitHub 上进行上游开发,尚未成为 Red Hat Ansible Automation Platform 产品的一部分。与所有 Red Hat 软件一样,我们的 代码是开放的,并且我们的企业软件采用开源开发模式。这篇博客文章的目的是展示该计划的当前状态,并开始让社区和客户熟悉我们的方法、思维过程和执行环境的概念。有关此上游项目的反馈可以通过 GitHub 上的评论和问题提供,也可以通过我们网站上列出的各种方法提供。

什么是 Ansible Builder?

简而言之,Ansible Builder 是一款工具,可帮助创建 Ansible 执行环境。为了充分理解这一点,让我们退一步讨论执行环境到底是什么。

关于执行环境的入门介绍

在执行环境的概念出现之前,Ansible Automation Platform 执行系统仅限于在 bubblewrap 下执行作业以隔离进程。这方面存在一些问题,包括在 Red Hat OpenShift 和基于 Kubernetes 的部署的情况下,运行作业的任何容器都必须以特权模式运行。除了这个问题之外,使用 Ansible 内容集合非常费力,用户在管理自定义 Python 虚拟环境和 Ansible 模块依赖项方面面临着很多挑战。执行环境的概念是解决这些问题的方案;简单地说,它们是可以用作 Ansible 控制节点的容器镜像。这些容器镜像可以简化和自动化过时的流程。

例如,假设开发人员通过使用容器技术在本地编写 Ansible 内容,以便他们可以创建可移植的自动化运行时;这些容器镜像将允许该开发人员共享预打包的执行环境,这些环境可以进行测试并推广到生产环境。这将消除许多手动步骤(例如,从头开始创建 Dockerfile)并通过简化开发和部署来加速操作。

Ansible Builder 是用于构建执行环境的工具

为了让开发人员、贡献者和用户能够利用这一新概念,Ansible Builder 被开发出来,以自动化构建执行环境的过程。它通过使用各种 Ansible 内容集合中定义的依赖项信息以及用户定义的信息来实现这一点。Ansible Builder 将生成一个目录,该目录充当容器镜像构建的构建上下文,其中将包含 Containerfile 以及需要添加到镜像中的任何其他文件。

入门

安装

您可以从 Python 包索引 (PyPI) 或从托管在 GitHub 上的 ansible-builder 代码库的主开发分支安装 Ansible Builder。在您的终端中,只需运行

$ pip install ansible-builder

注意:Podman 默认用于构建镜像。要使用 Docker,请使用 ansible-builder build --container-runtime docker

编写定义

在 Ansible Builder 的世界中,“定义”是一个 YAML 文件,它概述了执行环境的集合级依赖项、基本镜像来源以及对执行环境中特定项目的覆盖。ansible-builder build 命令(我们将在后面详细讨论)以定义文件作为输入,然后输出创建执行环境镜像所需的构建上下文,然后使用该上下文实际构建该镜像。相同的构建上下文可以在其他地方一致地重新构建执行环境镜像,这使用户能够为任何集合创建可分发的运行环境。

以下是定义文件中的内容示例

---
version: 1
dependencies:
  galaxy: requirements.yml
  python: requirements.txt
  system: bindep.txt

additional_build_steps:
  prepend: |
    RUN pip3 install --upgrade pip setuptools
  append:
    - RUN ls -la /etc

注意:构建命令将默认使用名为 execution-environment.yml 的定义文件。如果您要使用其他文件,则需要使用 -f(或 --file)标志指定文件名。此文件必须.yml 格式的文件。

在上面的定义文件的 dependencies 部分中,列出的条目可能是相对于执行环境定义文件夹的目录的相对路径,也可能是绝对路径。以下是 requirements.yml 文件中可能包含的内容示例,它指向 ansible-galaxy collection install -r... 命令的有效需求文件

注意:以下集合示例源自 cloud.redhat.com 上的 Automation Hub,需要有效的 Ansible Automation Platform 订阅 以及即将推出的 ansible-builder 的一项功能才能访问。

  • 有关使用 Automation Hub 的更多信息,请参阅 用户指南
  • 有关如何将 ansible.cfg 文件与 Ansible Builder 一起使用的说明,请参见 此处文档
---
collections:
  - redhat.openshift

python 条目指向 pip install -r 的 Python 需求文件。例如,requirements.txt 文件可能包含以下内容

awxkit>=13.0.0
boto>=2.49.0
botocore>=1.12.249
boto3>=1.9.249
openshift>=0.6.2
requests-oauthlib

bindep 需求文件指定跨平台需求(如果有)。它们由 bindep 处理,然后传递给 dnf(其他平台在本文发表时尚不支持)。以下是 bindep.txt 文件内容示例

subversion [platform:rpm]
subversion [platform:dpkg]

可以在 additional_build_steps 部分指定其他命令,以便在主要构建步骤之前(prepend)或之后(append)执行。语法必须是多行字符串(如示例定义文件的 prepend 部分所示)或列表(如示例的 append 部分所示)。

可定制选项

在运行 build 命令之前,让我们讨论一下您可以与它一起使用的可定制选项。

'-f', '--file'

此标志指向执行环境的特定定义文件;如果没有指定其他文件名,它将默认指向 execution-environment.yml

'-b', '--base-image'

执行环境的父镜像;如果未提及,它将默认指向 quay.io/ansible/ansible-runner:devel

'-c', '--context'

要用于构建上下文的目录,如果它应该在特定位置生成。默认位置是 $PWD/context.

'--container-runtime'

指定要使用的容器运行时;选项有 podman(默认选项)或 docker

'--tag'

要构建的容器镜像的名称;如果没有使用此标志指定任何内容,该镜像将被命名为 ansible-execution-env

与大多数 CLI 一样,在任何 Ansible Builder 命令的末尾添加 --help 将提供帮助文本形式的输出,该输出将显示和解释任何特定命令下可用的选项。以下是一个查找帮助文本的命令示例及其对应的输出

$ ansible-builder --help
usage: ansible-builder [-h] [--version] {build,introspect} ...

Tooling to help build container images for running Ansible content. Get
started by looking at the help for one of the subcommands.

positional arguments:
  {build,introspect}  The command to invoke.
    build             Builds a container image.
    introspect        Introspects collections in folder.

optional arguments:
  -h, --help          show this help message and exit
  --version           Print ansible-builder version and exit.

启动构建

让我们看看运行构建命令时会发生什么!构建定义将从默认的 execution-environment.yml 文件中收集,如下所示

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

additional_build_steps:
  prepend: |
    RUN pip3 install --upgrade pip setuptools
  append:
    - RUN ls -la /etc

我们将通过运行以下命令来构建一个名为 my_first_ee_image 的镜像,使用 Docker

$ ansible-builder build --tag my_first_ee_image --container-runtime docker
Using python3 (3.7.7)
File context/introspect.py is already up-to-date.
Writing partial Containerfile without collection requirements
Running command:
  docker build -f context/Dockerfile -t my_first_ee_image context
Sending build context to Docker daemon  14.34kB
Step 1/3 : FROM quay.io/ansible/ansible-runner:devel
devel: Pulling from ansible/ansible-runner
85a0beca2b15: Pulling fs layer
...
e21f0ff5ad71: Pull complete
Digest: sha256:e2b84...
Status: Downloaded newer image for quay.io/ansible/ansible-runner:devel
 ---> 6b886a75333f
Step 2/3 : RUN echo this is a command
 ---> Running in e9cea402bd67
this is a command
Removing intermediate container e9cea402bd67
 ---> 5d253a1fbd54
Step 3/3 : RUN cat /etc/os-release
 ---> Running in 788173de3929
NAME=Fedora
VERSION="32 (Container Image)"
...
VARIANT="Container Image"
VARIANT_ID=container
Removing intermediate container 788173de3929
 ---> df802929c259
Successfully built df802929c259
Successfully tagged my_first_ee_image:latest
Running command:
  docker run --rm -v /Users/bhenderson/Documents/GitHub/ansible-builder/context:/context:Z my_first_ee_image /bin/bash -c python3 /context/introspect.py
python: {}
system: {}

Rewriting Containerfile to capture collection requirements
Running command:
  docker build -f context/Dockerfile -t my_first_ee_image context
Sending build context to Docker daemon  14.34kB
Step 1/4 : FROM quay.io/ansible/ansible-runner:devel
 ---> 6b886a75333f
Step 2/4 : RUN echo this is a command
 ---> Using cache
 ---> 5d253a1fbd54
Step 3/4 : RUN cat /etc/os-release
 ---> Using cache
 ---> df802929c259
Removing intermediate container 6bd2a824fe4f
 ---> ba254aa08b88
Step 4/4 : RUN ls -la /etc
 ---> Running in aa3d855d3ae7
total 1072
drwxr-xr-x 1 root root   4096 Sep 28 13:25 .
...
drwxr-xr-x 2 root root   4096 Jul  9 06:48 yum.repos.d
Removing intermediate container aa3d855d3ae7
 ---> 0b386b132825
Successfully built 0b386b132825
Successfully tagged my_first_ee_image:latest
Complete! The build context can be found at: context

从上面的输出可以看出,定义文件指向列出的特定集合,然后构建一个包含元数据中指定的所有依赖项的容器镜像。以下输出

Step 2/3 : RUN echo this is a command
 ---> Running in e9cea402bd67
this is a command

以及

Step 4/4 : RUN ls -la /etc
 ---> Running in aa3d855d3ae7
total 1072
drwxr-xr-x 1 root root   4096 Sep 28 13:25 .

表明 prependappend 步骤也正在正确运行。以下输出表明我们确实没有列出任何 Python 或系统需求

python: {}
system: {}

使用 Ansible Runner 进行验证

由于此新工具仍在开发中,我们正在使用我们当前可用的工具集来帮助我们对此进行验证。也就是说,截至目前,ansible-runner 是一种命令行实用程序,它能够与剧本进行交互。此外,由于它是执行环境的关键组成部分,因此我们目前的验证将是内容按预期运行。这将在未来发生变化;我们一定会想出一些更强大、更好的东西!敬请期待。

现在,让我们深入了解...

如果您尚未安装 Ansible Runner,请参考其文档以获取指导。以下是可以通过 Ansible Runner 运行的示例剧本(我们将其称为test.yml),用于确保执行环境正常工作。

---
- hosts: localhost
  connection: local

  tasks:
    - name: Ensure the myapp Namespace exists.
      redhat.openshift.k8s:
        api_version: v1
        kind: Namespace
        name: myapp
        state: present

要确认my_first_ee_image 执行环境映像是否已正确构建并能与redhat.openshift 集合一起使用,请运行以下命令以执行我们的test.yml 剧本。

$ ansible-runner playbook --container-image=my_first_ee_image test.yml
PLAY [localhost] *************************************************************

TASK [Gathering Facts] *******************************************************
ok: [localhost]

TASK [Ensure the myapp Namespace exists.] ************************************
changed: [localhost]

PLAY RECAP *******************************************************************
Localhost: ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0  ignored=0

运行命令ansible-runner playbook 将指示 Ansible Runner 执行类似于运行命令ansible-playbook 本身的剧本。但是,Ansible Runner 比传统的ansible-playbook 命令具有更多优势,其中之一是让我们利用执行环境映像及其依赖项,最终允许剧本运行。对于此特定示例,请注意我们还继承了根据redhat.openshift.k8s 模块设置的kubeconfig;此kubeconfig 会自动检测并安装到执行环境容器运行时(就像许多其他云提供商模块和 SSH 凭据一样),无需用户额外输入。

分发

执行环境构建上下文(以及由此构建的容器)可以通过公共或私有注册表轻松共享。此新的工作流程允许用户自动执行曾经更手动的任务(例如,当在容器映像中发现漏洞时,可以自动扫描和重建容器映像)。当我们运行ansible-builder 命令时生成的构建上下文可以提交到源代码控制,并在以后无需 Ansible Builder 的情况下本地或在另一个系统上使用。

推送到 GitHub

使用 Ansible Builder 构建执行环境映像后,所有构建上下文文件都可以推送到 GitHub(或任何其他版本控制系统)以进行分发。以下是一个托管构建特定映像所需所有内容的存储库的示例。

Ansible Builder Blog one

Red Hat Quay 是一个容器映像注册表,它提供存储并支持容器的构建、分发和部署。在 quay.io 中设置一个帐户并选择“创建新存储库”。将显示一系列选择,从以下显示的内容开始。

Ansible Builder blog two

从这里,您可以选择您的特定 GitHub 存储库(或您托管映像文件的任何位置),然后浏览其他设置,例如配置构建触发器,以及特定的 Containerfile/Dockerfile 和上下文,以及其他内容。

Ansible builder blog three

您还可以通过其他方式共享执行环境映像;以上只是一个简化且易于集成的示例方法。

结论

我们希望您喜欢学习有关执行环境以及如何使用新的 Ansible Builder CLI 工具构建它们的信息!在 Red Hat Ansible Automation Platform 的未来版本中,执行环境将能够用于在 Ansible Automation Platform 中运行作业,因此请密切关注有关下一个版本的详细信息。如需进一步阅读,请参考Ansible Builder 文档Ansible Runner 文档,并确保查看 GitHub 上的Ansible Builder 存储库