迁移到 Ansible 集合（网络研讨会问答）

Sean Cavanaugh、Anshul Behl 和我最近举办了一个名为“迁移到 Ansible 集合”的网络研讨会。这是 网络研讨会回放的链接。本次网络研讨会的重点是帮助 Ansible Playbook 编写者，希望将现有 Ansible 2.9 环境及更高版本迁移到 Ansible 集合的奇妙世界。

网络研讨会的参与人数远远超出了我们的预期，以至于我们没有足够的时间回答所有问题，因此我们将所有问题都放在了这篇博客中，以供所有人查看。

我想使用 Ansible 自动化使用 REST API 的应用程序（例如，创建一个新的 Bitbucket 项目）。我应该编写一个角色还是一个自定义模块？然后应该将它发布为一个集合吗？

这取决于您想对开发的模块或角色投入多少。例如，可以评估创建引用内置 Ansible URI 模块的角色，而不是创建用 Python 编写的 Ansible 模块。如果您要创建模块，它可以通过您或剧本作者开发的角色来使用。有时可能更喜欢独立的角色，具体取决于与 REST API 端点交互的确切功能或要求。总的来说，重要的是保持干净的资源/模块映射，并尽可能避免操作/模块。不幸的是，这里没有正确或错误的答案（“这取决于 Ansible 的使用者”），无论如何，都可以开发 Ansible 模块和/或 Ansible 角色，然后将其包含到集合中，以便在 Ansible 剧本中使用。集合是分发 Ansible 内容的标准方式，其中包括角色和模块。

我们什么时候才能在脱机环境中使用 requirements.yml 文件安装集合？角色似乎可以使用 Git 存储库作为上游，但对于集合，它似乎还无法使用，我总是想在线查看 galaxy.ansible.com。也就是说，我是否可以使用 GitHub URL（就像在角色中一样）？

您可以将 ansible-galaxy CLI 客户端指向从不同来源拉取集合，请查看 以下文档页面。请注意，从 GitHub（或其他来源）拉取集合不会被官方支持，作为 Ansible 自动化平台的一部分。即使使用社区集合，最好从 Ansible Galaxy 安装。

某些模块需要额外的 Python 包，例如用于 VMware 模块的 pyvmomi。集合将来是否能够包含此 Python 代码以使其正常工作？

将来，我们将拥有名为 Ansible 执行环境的容器化技术，它是在集合之上的一个抽象层，允许安装操作系统级组件。在 AnsibleFest 上 有一些关于此的演讲，以及一篇关于 Ansible Builder 的博客，但目前的答案是 venv，但很快就会有执行环境。

ansible-doc 什么时候才能显示集合的文档？使用 FQCN 与 ansible-doc 结合使用目前还无法使用。

ansible-doc 目前支持 FQCN；检查详细日志以查看 ansible-doc 在发现集合时是否存在问题。例如，以下命令可以正常运行

$ ansible-doc infoblox.nios_modules.nios_a_record

Ansible 执行环境将如何协同工作？

该主题目前处于非常活跃的开发阶段，将在即将发布的博客、网络研讨会和文档中进行介绍。敬请期待，敬请关注更多信息。

是否有关于网络自动化的特定资源？我一直难以在非标准网络设备上创建剧本。我只是觉得网络方面的在线文档不足。

查看我们的 网络入门指南。目前 Ansible 连接插件（如 network_cli、netconf 和 httpapi）已支持超过 75 个网络平台。此外，使用 cli_command 和 cli_config，通用模块可能会有所帮助。查看 github.com/ansible/workshops，看看是否有帮助。此外，直接联系网络设备供应商可能会有所帮助，因为他们可能提供私有的 Ansible 内容。

Ansible 2.10 什么时候可以通过 yum 在 Red Hat Linux 上使用？    

Ansible 2.10 不会以 RPM 格式在下游提供，有关详细信息，请参阅以下链接：https://access.redhat.com/articles/5392421。

集合什么时候会成为硬性要求，并且会弃用旧方法（2.9 或更早版本）？

2.10 及更高版本需要集合，但如果 2.9 中的现有内容已迁移出去，则当前剧本应该可以正常工作，因为它们正在使用 2.10 分发版中的全局 runtime.yml 文件。因此，我们专注于 2.9 + 集合，以延长过渡过程。

为了未来证明，我是否可以在 2.9 中实现这一点并使用 FQCN？

是的，应该没问题，假设集合是从 Ansible 2.9 迁移的，或者在发布之前针对它进行了测试。

您也可以只将 collections: cyberark 放在剧本顶部，对吧？你能展示一下它是什么样子吗？

您需要指定具体的 Cyberark 命名空间.集合，而不仅仅是您所述的 Cyberark 命名空间。我们也不建议使用 collections 关键字，而是建议在每个任务中使用完全限定的集合名称 (FQCN)（请参阅幻灯片中的说明）。

使用 collections 关键字

使用推荐的方式 FQCN（完全限定的集合名称）

在我们环境中，有些客户依赖于 CLI，因为 CLI 的开发速度更快，例如 aws-cli。我们是否预计 AWS 等供应商会更快地为集合方面做出贡献？

Ansible 工程团队实际上维护着所有 AWS Ansible 内容，通常采用“CLI优先”或“API优先”的理念，但总的来说，参与的供应商在更新其集合以支持新功能方面做得很好！Ansible 集合的目标之一是让合作伙伴和认证内容比 Ansible 自动化平台版本更快地异步迁移，这意味着社区和客户将更快地获得新内容。

访问自动化中心需要哪些站点许可证？  

任何 Red Hat Ansible 自动化平台订阅都将提供对自动化中心的访问权限，以及在您的环境中运行私有自动化中心的能力。

Ansible 执行环境计划何时发布？   

初步计划是明年（2021 年）年中，作为产品的一部分，但这些部分将开始以持续的方式在上游提供。

如果所有模块都迁移到集合（ansible.builtin 等）中，那么基本/核心部分还剩下什么？   

嗯，一些模块仍然在其中，因此被称为“builtin”，但它们仍然可能异步迁移。但是，有很多代码用于运行实际的 Ansible 可执行文件，包括我们如何进行并行处理、条件、循环、块等构造，以及更多。其中许多是很多 Ansible 用户不会真正交互的东西（把它想象成汽车的发动机）。

是否可以在同一个代码库中使用多个版本的集合？（例如，在剧本级别列出版本）

目前这不是一种选择，您无法在剧本中固定集合版本，这在使用 venv 或未来的执行环境时可能是理想的。

私有自动化中心是否可以作为二进制存储库（如 Artifactory 或 Nexus）中的存储库？

不，私有自动化中心利用 cloud.redhat.com 中的相同内容类型。构建并发布到自动化中心的 Ansible 集合 tar 包将被解压缩，并将显示其内容。

我可以在 CentOS8 上使用 Ansible 集合吗？

如果 Ansible 2.9 可以安装在 CentOS8（或任何其他 Linux 发行版）上，则可以在其中使用集合。

Galaxy 将被弃用，还是在未来仍然有效？ 

Galaxy 仍然是发布和下载社区 Ansible 集合的当前位置！

Ansible 2.9 不支持使用私有存储库作为集合的占位符，对吧？

您可以使用私有自动化中心指向自托管实例以获取您的集合，并策划和控制您的组对哪些内容有访问权限。

私有自动化中心是独立的，还是可以集群？

目前它只能作为独立的提供，但在未来可能会支持集群。

FQCN 如何使用集合而不是常规映射的模块（在 2.9 中）？

FQCN 代表完全限定的集合名称，它将始终指向集合，而不是标准 Ansible 2.9 安装中的模块，因为它们位于 Ansible 控制节点上的不同位置。

执行环境和 Red Hat Ansible Tower 中的技术预览版容器隔离组之间有什么区别？

容器隔离组使用相同的执行原则。最简单的理解方式是，您可以将容器组视为基于“执行环境 v0.1”。当执行环境发布后，它将远远优于容器组。

是否有方法下载最新的集合版本？还是会自动获得？

会自动拉取最新版本，但您也可以指定确切的版本。您不需要使用 :latest - 这是您会自动获得的，假设它不包含类似“-beta”或预发布版本（使用连字符）的内容，这些版本不被视为 GA 版本（并且会被跳过）。

[

对于我们自己编写的角色，现在或者将来是否有一种方法可以将相关角色组织为集合？

现在可以在集合中组织多个角色，作为 /roles 目录的一部分。

我所看到的所有关于 Collection 的内容都是关于如何使用它们（来自 Galaxy 或其他来源）。有没有关于如何编写我们自己的 Collection 的文档/参考？

是的！请查看 开发者指南

Automation Hub 是否包含官方/主要供应商模块。例如 NetApp 或 Dell 模块。

是的，它今天已经包含了。我们有一个认证计划，并且已经获得了许多供应商（如 Dell 和 Netapp）的认证内容。Automation Hub 包含所有支持和认证的 Collection，有一个公开的 KBASE 列出了它们，请查看 https://access.redhat.com/articles/3642632[。

如果我选择试用 Ansible Automation Platform，它是否允许访问 Automation Hub？

是的，它作为订阅的一部分提供。Ansible Automation Platform 订阅包括试用所需的一切，包括所有组件以及与 cloud.redhat.com 上的服务的连接，以及 Red Hat 客户门户网站。

从 ansible-galaxy CLI 中删除 Collection 是否即将到来，或者我们仍然需要进入 Collection 目录手动删除它？

目前，这是删除 Collection 的唯一方法。您可以使用 force 标志覆盖 Collection。

我们是否可以将 Collection 安装在除默认的 ~/.ansible/collections 之外的其他位置？

是的，您可以将它们放在任何地方，但请确保控制节点知道它们在路径中的位置。例如：ansible-galaxy install -p /path/to/collections namespace.collection 和 相关文档。

我可以检查服务器上现有 Collection 的版本吗？

对于 Ansible 2.10 及更高版本，ansible-galaxy collection list 命令提供 Collection 和版本的列表。

为了在 RHV 中添加一个新的主机，我不得不将 Ansible 的版本降级到 2.9.13，否则它无法工作（Red Hat 的已知错误）。在哪个 2.9 版本中该错误会被解决？

您是否有一个我们可以看到的 GitHub 问题？我们可以确保跟进。错误通常在 GitHub Ansible 项目中跟踪，那里的对话应该有助于您了解时间线。

对于那些对事物变化绝对没有兴趣的用户，未来的发展路径是什么？我已经为改变部门文化，使其更利于自动化思考而努力了一两年，而这将有效地让我回到原点，甚至更糟糕。当企业准备实施重大变更时，它们不喜欢大规模的变更。

我们认为我们创建了一种双赢的局面，客户和社区成员现在可以使用 Collection 并更快地获得新内容，同时保持与现有 Ansible 自动化的向后兼容性。虽然我们鼓励大家开始使用 Collection 并使用 FQCN 编写 Ansible 剧本，但在客户被要求使用它们之前，将有一段很长的时间。Red Hat 提供长期支持选项/产品，因此您无需在相当长的时间内进行更改。对于订阅客户，Ansible 2.9 将比最初计划的支持时间更长。

Ansible 是否有一组路径来检查在基本 Ansible 中定义的 runtime.yml？

重定向规则目前遵循优先级，在以下两个文件之间级联

1. 作为 Ansible 发行版一部分的内置 runtime.yml 文件。在本例中，Ansible 2.10 内置 runtime.yml。此文件首先被查阅。
2. 作为实际 Collection 一部分的 runtime.yml 文件，作为 /meta/runtime.yml。此文件接下来被查阅。

Ansible Builder 简介

您好，欢迎阅读另一篇 Ansible 入门博客文章，我们将介绍一个新的命令行界面 (CLI) 工具 Ansible Builder。请注意，本文将涵盖一些中级主题，例如容器（Ansible Builder 默认使用 Podman）、虚拟环境和 Ansible 内容 Collection。如果您对这些主题有一些了解，那么继续阅读以了解什么是 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 内容 Collection 非常费力，用户在管理自定义 Python 虚拟环境和 Ansible 模块依赖项方面遇到了很多挑战。执行环境的概念是解决这些问题的方案；简而言之，它们是可以用作 Ansible 控制节点的容器镜像。这些容器镜像可以简化和自动化过时的流程。

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

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

为了使开发人员、贡献者和用户能够利用这个新概念，Ansible Builder 被开发出来以自动化构建执行环境的过程。它通过使用各种 Ansible 内容 Collection 中定义的依赖项信息以及用户定义的信息来做到这一点。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 文件，它概述了执行环境的 Collection 级依赖项、基本镜像源以及对执行环境内特定项目的覆盖。ansible-builder build 命令（我们将在稍后详细讨论）将定义文件作为输入，然后输出创建执行环境镜像所需的构建上下文，然后使用它来实际构建该镜像。相同的构建上下文可以一致地重建其他地方的执行环境镜像，这使用户能够为任何 Collection 创建可分发的运行环境。

以下是一个定义文件中可能包含的内容示例

---
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

注意：build 命令将默认使用名为 execution-environment.yml 的定义文件。如果您想使用其他文件，则需要使用 -f（或 --file）标志指定文件名。此文件必须是 .yml 格式的文件。

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

注意：以下 Collection 示例来自 cloud.redhat.com 上的 Automation Hub，需要有效的 Ansible Automation Platform 订阅 和即将推出的 Ansible Builder 功能才能访问。

• 有关使用 Automation Hub 的更多信息，请参阅 用户指南
• 有关如何在 Ansible Builder 中使用 ansible.cfg 文件的说明，请参见 此处提供的文档

---
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.

启动构建

让我们看看运行 build 命令时会发生什么！构建定义将从默认的 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 .

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

python: {}
system: {}

使用 Ansible Runner 进行验证

由于此新工具仍在开发中，我们正在利用当前可用的工具集作为捷径来帮助我们进行验证。也就是说，目前，ansible-runner 是一款命令行实用程序，能够与剧本进行交互。此外，由于它是执行环境的关键部分，因此我们目前对它的验证是内容按预期运行。这将在将来改变，我们一定会想出更强大、更好的方法！敬请关注。

现在让我们深入探讨...

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

---
- 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（或任何其他版本控制系统）以进行分发。以下是一些示例存储库，其中包含重新构建特定镜像所需的一切

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

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

还有其他方法可以共享您的执行环境镜像；以上只是一个简化且易于集成的示例方法。

结论

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

使用 NetBox 作为 Ansible 的真相来源

在这里，您将了解 NetBox 的高级知识，了解它是如何成为真相来源 (SoT) 的，以及深入了解 Ansible 内容集合的使用，该集合可在 Ansible Galaxy 中获取。目标是展示一些使 NetBox 成为一款绝佳工具的功能，以及为什么您将想要使用 NetBox 作为网络真相来源进行自动化！

真相来源

为什么要使用真相来源？真相来源是您获取设备的预期状态的地方。不需要只有一个真相来源，但您应该为每个数据域拥有一个真相来源，通常称为记录系统 (SoR)。例如，如果您有一个维护物理站点的数据库，该数据库被 IT 域以外的团队使用，那么它应该是物理站点的真相来源。您可以将来自物理站点真相来源的数据聚合到其他数据源中以进行自动化。请注意，在收集数据时，应从该其他工具中获取数据。

创建网络自动化框架的第一步是确定数据的真相来源，这些数据将用于将来的自动化。对于传统网络，设备本身通常被认为是 SoT。每次需要配置数据点进行自动化时，从设备读取配置效率低下，并且假定设备配置符合预期，而不是仅仅保留在故障排除中或意外保留。在向网络组织以外的团队提供数据时，公开 API 可以帮助加快数据收集速度，而无需先查看设备。

NetBox

对于真相来源，一个流行的开源选择是 NetBox。来自主要文档站点 netbox.readthedocs.io

"NetBox 是一款开源 Web 应用程序，旨在帮助管理和记录计算机网络"。

NetBox 目前旨在帮助管理您的

• DCIM（数据中心基础设施管理）
• IPAM（IP 地址管理）
• 数据电路
• 连接（网络、控制台和电源）
• 设备机架
• 虚拟化
• 秘密

由于 NetBox 是一款 IPAM 工具，因此有时会对 NetBox 的功能存在误解。明确地说，NetBox 不是

• 网络监控
• DNS 服务器
• RADIUS 服务器
• 配置管理
• 设施管理

为什么选择 NetBox？

NetBox 是一款基于许多常见的基于 Python 的开源工具构建的工具，使用 Postgres 作为后端数据库，使用 Python Django 作为后端 API 和前端 UI。API 非常友好，因为它支持 CRUD（创建、读取、更新、删除）操作，并且使用 Swagger 文档进行全面记录。NetBox 集合有助于 NetBox 的几个方面，包括库存插件、查找插件以及用于更新 NetBox 中数据的几个模块。

从网络组织的角度来看，NetBox 提供了一个现代的 UI，有助于记录 IP 地址，同时将重点放在网络设备、系统基础设施和虚拟机上。这使其成为自动化真相来源的理想选择。

NetBox 本身不会扫描任何网络资源。它旨在由人工维护数据，因为这将是真相来源。它代表环境应该是什么样子。

适用于 NetBox 的 Ansible 内容集合

您将在 netbox-community GitHub 组织 (github.com/netbox-community/) 中找到该集合。在这里，您将找到 Docker 容器镜像、设备类型库、社区生成的 NetBox 报告 以及 NetBox 本身的源代码。

如果您不熟悉 Ansible 内容集合是什么，请观看此简短的 YouTube 视频。

该集合的 Galaxy 链接位于 galaxy.ansible.com/netbox/netbox。

NetBox 集合允许您快速开始将信息添加到 NetBox 实例中。唯一的要求是提供 API 密钥和 URL 才能开始。使用此集合、基本库存和 NetBox 环境，您能够非常快速地填充真相来源。

让我们一起完成基本设置，以便开始使用 NetBox 库存插件作为您的 Ansible 库存。首先是将用于任务的项目列表的示例 group_vars/all.yml 文件。

---
site_list:
  - name: “NYC”
    time_zone: America/New_York
    status: Active
  - name: “CHI”
    time_zone: America/Chicago
    status: Active
  - name: “RTP”
    time_zone: America/New_York
    status: Active
manufacturers:  # In alphabetical order
  - Arista
  - Cisco
  - Juniper
device_types:
  - model: “ASAv”
    manufacturer: “Cisco”
    slug: “asav”
    part_number: “asav”
    Full_depth: False
  - model: “CSR1000v”
    manufacturer: “Cisco”
    slug: “csr1000v”
    part_number: “csr1000v”
    Full_depth: False
  - model: “vEOS”
    manufacturer: “Arista”
    slug: “veos”
    part_number: “veos”
    Full_depth: False
  - model: “vSRX”
    manufacturer: “Juniper”
    slug: “vsrx”
    part_number: “vsrx”
    Full_depth: False
platforms:
  - name: “ASA”
    slug: “asa”
  - name: “EOS”
    slug: “eos”
  - name: “IOS”
    slug: “ios”
  - name: “JUNOS”
    slug: “junos”

示例 group_vars/all.yml

第一步是创建一个站点。由于 NetBox 对物理设备进行建模，因此您将在物理位置安装设备。无论是在您自己的设施中还是在云中，这都是一个站点。此模块是 netbox.netbox.netbox_site 模块。

剧本中的任务可能是

- name: "TASK 10: SETUP SITES"
  netbox.netbox.netbox_site:
    netbox_url: "{{ lookup('ENV', 'NETBOX_URL') }}"
    netbox_token: "{{ lookup('ENV', 'NETBOX_API_KEY') }}"
    data: "{{ item }}"
  loop: "{{ site_list }}"

示例：站点任务

接下来的两部分是将设备添加到 NetBox 的基础。为了创建特定设备，您还需要在 NetBox 实例中拥有设备类型和制造商。为此，可以使用特定的模块来创建它们。平台将有助于识别设备的 OS。我建议您使用您的自动化平台正在使用的平台——例如 IOS、NXOS 和 EOS 是不错的选择，应该与您的 ansible_network_os 选择匹配。这些任务如下所示

- name: "TASK 20: SETUP MANUFACTURERS"
      netbox.netbox.netbox_manufacturer:
        netbox_url: "{{ lookup('ENV', 'NETBOX_URL') }}"
        netbox_token: "{{ lookup('ENV', 'NETBOX_API_KEY') }}"
        data:
          name: "{{ manufacturer }}"
      loop: "{{ manufacturers }}"
      loop_control:
        loop_var: manufacturer

   - name: "TASK 30: SETUP DEVICE TYPES"
      netbox.netbox.netbox_device_type:
        netbox_url: "{{ lookup('ENV', 'NETBOX_URL') }}"
        netbox_token: "{{ lookup('ENV', 'NETBOX_API_KEY') }}"
        data:
          model: "{{ device_type.model }}"
          manufacturer: "{{ device_type.manufacturer }}"
          slug: "{{ device_type.slug }}"
          part_number: "{{ device_type.part_number }}"
          is_full_depth: "{{ device_type.full_depth }}"
      loop: "{{ device_types }}"
      loop_control:
        loop_var: device_type
        label: "{{ device_type['model'] }}"

    - name: "TASK 40: SETUP PLATFORMS"
      netbox.netbox.netbox_platform:
        netbox_url: "{{ lookup('ENV', 'NETBOX_URL') }}"
        netbox_token: "{{ lookup('ENV', 'NETBOX_API_KEY') }}"
        data:
          name: "{{ platform.name }}"
          slug: "{{ platform.slug }}"
      loop: "{{ platforms }}"
      loop_control:
        loop_var: platform
        label: "{{ platform['name'] }}"

示例：制造商、设备类型和平台

在此阶段，您已准备好将设备和设备信息添加到 NetBox 中。以下任务利用 Ansible 自动收集的 ansible_facts。因此，对于这些特定的设备类型，无需在使用 Ansible 收集事实之外执行任何其他解析/数据收集。在此添加设备的示例中，您将注意到 custom_fields。NetBox 的一个很好的扩展是，如果没有已定义的字段，您可以设置自己的字段并在工具中使用它们。

- name: "TASK 100: NETBOX >> ADD DEVICE TO NETBOX"
      netbox.netbox.netbox_device:
        netbox_url: "{{ lookup('ENV', 'NETBOX_URL') }}"
        netbox_token: "{{ lookup('ENV', 'NETBOX_API_KEY') }}"
        data:
          name: "{{ inventory_hostname }}"
          device_type: "{{ ansible_facts['net_model'] }}"
          platform: IOS  # May be able to use a filter to define in future
          serial: "{{ ansible_facts['net_serialnum'] }}"
          status: Active
          device_role: "{{ inventory_hostname | get_role_from_hostname }}"
          site: “ANSIBLE_DEMO_SITE"
          custom_fields:
            code_version: "{{ ansible_facts['net_version'] }}"

    - name: "TASK 110: NETBOX >> ADD INTERFACES TO NETBOX"
      netbox.netbox.netbox_device_interface:
        netbox_url: "{{ lookup('ENV', 'NETBOX_URL') }}"
        netbox_token: "{{ lookup('ENV', 'NETBOX_API_KEY') }}"
        data:
          device: "{{ inventory_hostname }}"
          name: "{{ item.key }}"
          form_factor: "{{ item.key | get_interface_type }}"  # Define types
          mac_address: "{{ item.value.macaddress | ansible.netcommon.hwaddr }}"
        state: present
      with_dict:
        - "{{ ansible_facts['net_interfaces'] }}"

示例：添加设备和接口

拥有接口后，您可以添加 ansible_facts 数据中包含的 IP 地址信息，我展示了三个步骤。首先是添加一个临时接口 (TASK 200)，然后添加 IP 地址 (TASK 210)，最后将 IP 地址与设备关联 (TASK 220)。

- name: "TASK 200: NETBOX >> Add temporary interface"
      netbox.netbox.netbox_device_interface:
        netbox_url: "{{ lookup('ENV', 'NETBOX_URL') }}"
        netbox_token: "{{ lookup('ENV', 'NETBOX_API_KEY') }}"
        data:
          device: "{{ inventory_hostname }}"
          name: Temporary_Interface
          form_factor: Virtual
        state: present

    - name: "TASK 210: NETBOX >> ADD IP ADDRESS OF ANSIBLE HOST"
      netbox.netbox.netbox_ip_address:
        netbox_url: "{{ lookup('ENV', 'NETBOX_URL') }}"
        netbox_token: "{{ lookup('ENV', 'NETBOX_API_KEY') }}"
        data:
          family: 4
          address: "{{ ansible_host }}/24"
          status: active
          interface:
            name: Temporary_Interface
            device: "{{ inventory_hostname }}"

    - name: "TASK 220: NETBOX >> ASSOCIATE IP ADDRESS TO DEVICE"
      netbox.netbox.netbox_device:
        netbox_url: "{{ lookup('ENV', 'NETBOX_URL') }}"
        netbox_token: "{{ lookup('ENV', 'NETBOX_API_KEY') }}"
        data:
          name: "{{ inventory_hostname }}"
          device_type: "{{ ansible_facts['net_model'] }}"
          platform: IOS
          serial: "{{ ansible_facts['net_serialnum'] }}"
          status: Active
          primary_ip4: "{{ ansible_host }}/24"

示例：添加临时接口、添加 IP 地址、重新添加与 IP 地址关联的设备

Ansible 库存来源

现在，您已经将 NetBox 填充了静态清单中的所有设备。现在是时候将 NetBox 用作 Ansible 动态清单插件的真相来源。这样，您就不必在更改环境时不断查找所有需要更新的项目。您只需要更改真相来源数据库 - NetBox。

您使用一个 YAML 文件定义要使用的清单插件，该文件定义了如何配置您预期的插件使用方式。以下是一个示例，向您展示了您可以查询 NetBox 的许多组件以在您的 Ansible 清单中使用。您可能只想更新您的接入交换机？使用 query_filters 键来定义应执行哪些 NetBox API 搜索。查看插件文档以了解 GitHub 或 ReadTheDocs 上的更新支持参数。compose 键允许您传入要由 Ansible 使用的额外变量，因此来自上面的平台将与 ansible_network_os 键一起使用。这就是您看到定义以及从清单源传递的内容的地方。

此定义还根据在 NetBox 中定义的设备角色和平台创建了组。因此，您将能够访问所有 platforms_ios 设备或 platforms_eos 设备（例如），这取决于真相来源中的信息。

---
plugin: netbox.netbox.nb_inventory
api_endpoint: http://netbox03
validate_certs: false
config_context: false
group_by:
 - device_roles
 - platforms
compose:
 ansible_network_os: platform.slug
query_filters:
 - site: "minnesota01"
 - has_primary_ip: True

示例：netbox_inventory.yml

使用插件扩展 NetBox

NetBox 本身最近添加的一项功能是能够通过您自己或社区驱动的插件来扩展它。来自维基百科

"插件是打包的 Django 应用程序，可以与 NetBox 一起安装以提供核心应用程序中不存在的自定义功能"

https://github.com/netbox-community/netbox/wiki/Plugins

您可以在该链接处的社区中找到一些特色插件。其中一些包括

• 动态 DNS 连接器
• NetBox 入职插件（来自网络到代码） - 这将读取有关设备的附加信息并更新 NetBox
• NetBox 二维码 - 生成有关设备的二维码
• 使用 SAML2 进行 SSO

社区中提供了许多插件供您选择 - 或者您可以编写自己的附加组件！

搜索 https://github.com/topics/netbox-plugi 以查找主题“NetBox 插件”。

摘要

NetBox 和 Ansible 结合在一起，是满足您的网络自动化需求的绝佳组合！

NetBox 是一款出色的开源工具，有助于轻松创建、更新和使用它作为真相来源。即使您不想使用 Ansible 可用的 NetBox 集合，其 API 也易于使用，并可以对其进行更新。拥有灵活、功能强大且准确的工具对于通过真相来源提供自动化至关重要。NetBox 在这些方面都做到了。 

这篇文章的灵感来自 2020 年 3 月在明尼阿波利斯 Ansible 聚会上的一次演讲。有关此方面的更多资料，我在 ansible_netbox_demo 上提供许多此类任务作为工作示例。来自 Ansible 聚会的演讲的 YouTube 录音可供观看。