如何使用 Ansible 自动化平台 2.4 中全新的构建清单功能

全新的构建清单功能

在这篇博客中，我们介绍了一种基于 Ansible 构建插件、更为智能的清单处理思路。而现在，随着 Ansible 自动化平台 2.4 的发布，这一思路已经演化为一个全面支持的功能。本篇博客的目标就是带您深入了解这一全新功能！ 

构建清单是现有智能清单功能的升级版，现已成为在 Ansible 自动化平台控制器中创建清单时的另一种选择。 这会接受一系列“正常”清单作为输入，执行用户定义的操作，进行过滤，然后生成一个包含输入清单内容的清单。

什么是构建清单？

该功能类似于现有的智能清单，允许用户对多个清单中的主机运行作业。 

不过，构建清单引入了新的功能，包括用于定义和使用主机变量和组变量的内置功能：

• 组存在于构建的清单中，并在其配置中发挥着至关重要的作用。
• 用户定义的逻辑（用于添加组、变量和向下选择主机）通过 ansible-inventory 运行， 由控制器为您执行，并通过清单更新显示在 UI 中。
• 用户定义逻辑的格式是广泛使用的 Ansible 样式 jinja2。

创建构建清单的指导原则是，采用与编写 playbook 时相同的思维方式。这与智能清单有所不同，在智能清单中，您必须从应用的视角来考虑清单。

UI 中的构建清单

单击清单下的“添加构建清单”后，您将看到以下菜单：

构建清单有三个特有的关键项目。

• 输入清单中列出了构建清单将从中获取清单内容（主机、组等）的现有清单。
• 限制会直接传递到 ansible-inventory，并允许使用 Ansible 主机模式的标准语法过滤主机。
• 源变量是传递到 ansible.buildin.constructed 清单插件的输入。

注：输入清单按顺序排列，因此在主机名和变量发生冲突时，将优先使用最后一个清单中的变量。变量采用合并方式，因此这不会取消设置之前输入清单中的变量。如果没有主机名冲突，清单顺序便无关紧要；此处使用的示例将展示排序的影响。

现在不用担心这些问题，我们将在下面的示例中进行探讨。

最简单形式的构建清单

您必须至少有一个输入清单，但其他字段不必填写。在某些情况下，提供两个或更多输入清单并将“限制”和“源变量”留空，可能会比较合理。然后，您可以运行作业，作用于这两个输入清单中清单内容的组合。 

更高级的构建清单用例

为了解释提供最终功能的限制和源变量的作用，我们不妨举一个具体示例。

设置构建清单

假设您有两个清单，它们来自同一个云提供商，但覆盖不同的区域，因此拥有不同的主机集。由于帐户、功能和位置不同，这些清单都保持独立。在本例中，我们设想简单的东/西区域输入清单。

我们将从基于 Git 的 .ini 文件中获取清单，并采用 devops 类型的实践，使用“配置即代码”方法对其进行维护。

首先设置一个新的项目并进行同步，以便明确从哪里获取清单信息。在 UI 中选择项目，然后单击添加：

填写并保存后，项目将自动同步：

现在，我们创建新的清单，这些清单将引用项目文件中的信息。在“清单”下，单击“创建”：

现在，依次单击清单来源和添加：

我们为此来源提供名称，对于本例中的东部区域主机，将来源定义为源自项目，然后提供刚才添加的项目和适当的 east.ini 源文件：

保存后，单击同步按钮以调取信息：

同步后，查看作业输出即可看到已处理的内容：

在本例中，可以看到已发现来源并自动添加了 3 个主机和 3 个组。您可以在 UI 中的主机下查看此信息。

现在，我们必须对西部区域执行相同的操作。这部分留给您作为练习，请按照上面的示例进行操作，但使用 west.ini 信息作为来源。

在该假设情景中，我们希望根据我们定义的条件，同时对来自东部和西部区域的部分主机运行作业。

现在，让我们在 UI 中创建一个新的构建清单：

我们将两个云清单都添加为输入。然后，我们将使用源变量构建一个新的“target_group”组，并使用限制对该组进行过滤：

同步后，您可以通过作业输出查看发生的情况：

我们现在有 4 个组和 4 个主机，您可以在 UI 中的主机和组下浏览，以确认结果。让我们看看这个特定示例中的组：

当构建清单更新运行时，它会将输入清单中的“account_1234”、“account_4321”和“accounts”组复制到生成的构建清单中。 

我们还可以看到，构建清单还包含“target_group”组，稍后我们将对此进行探讨。

如果作业模板使用此构建清单来运行作业，则定义的任何组都可供该作业使用。

现在来看看主要“魔法”，如果您参考构建清单表单中的源变量，就可以找到新的“target_group”组的定义。

    plugin: constructed
    strict: true
    groups:
        target_group: account_alias | default("") == "product_dev"

原始的东部和西部清单中不存在“target_group”。它是在更新发生时由构建清单插件创建。 

在本例中，当 jinja2 模板 {{ account_alias | default("") == "product_dev" }} 解析为给定主机的真实值（如 1、“1”或 True）时，主机就会添加到组中。 

在更新过程中，Ansible 会为输入清单中的每台主机渲染这些模板，以进行相应评估。对于较大的输入清单，完成更新预计需要几分钟时间。 

构建清单将在使用它的任何模板作业运行之前自动更新，但如果这些更新花费的时间太长，您可以使用 UI 中“构建清单”设置中的更新缓存超时选项来放宽更新频率。将此选项设置为 > 1 的值，构建清单更新的结果将缓存相应秒数。

用于创建“target_group”的 jinja2 模板将包含主机，前提是在检查该主机时，“account_alias”的主机变量存在且值为“product_dev”。 

如果某些主机未定义变量，则需要使用“| default”语法。 

“strict: true”指示引用未定义的变量将导致清单更新失败，因此必须使用“| default”。 

使用“|default|”和严格参数是最佳实践，这样可以强制您明确处理未定义的情况。

构建组可用于动态添加组以供 playbook 引用。为什么要这样做呢？有时候，从主机变量合成组会很方便，因为您可以对组执行主机变量无法执行的操作，例如在主机模式中使用，就像本例中的限制一样。 

查看为我们的构建清单生成的所有主机：

我们可以在本例中看到，east 清单中的 host3 和 [ west 清单中的 host5未包含在内。这是因为在输入清单中，它们位于不同的帐户（account_4321）中，该帐户的“account_alias”与我们指定的“product_dev”值不匹配。请注意，尽管 account_4321 的组已导入到构建清单中，但该组中没有主机符合我们的要求，因此导入的组在构建清单中为空。

除了添加组外，源变量输入还可以包含主机变量。

Alan 的 Github 存储库还包含另一个示例，您可能会发现很有用。在 fabric.yml 中，我们解析主机的“状态”，并根据主机是关机还是属于特定环境（dev），将它分配到多个组。此 .yml 文件的事实来源可以来自 Ansible 自动化平台之外的其他系统，我们可以使用它对动态主机的子集执行自动化运行。

调试技巧

仍沿用前面的示例，在开发构建清单时，请考虑删除限制值并将源变量更改为以下内容。

这将运行类似的 {{ account_alias | default(“”) }} 模板，并将它保存到名为“effective_account_alias”的变量中。通过将限制留空，我们将确保从输入清单中获取所有主机。这样，我们就可以检查各个主机上的包含条件的精细详情，如下面的 host3 示例所示。

在这里，我们看到主机变量“effective_account_alias”的评估值为“sustaining”，而不是“product_dev”。 

构建清单插件还有许多其他非常有用且功能强大的选项。有关更多详细信息，请参阅插件文档，网址为：https://docs.ansible.com/ansible/latest/collections/ansible/builtin/constructed_inventory.html。

还可在用户指南中找到其他一些示例，网址为：https://docs.ansible.com/automation-controller/4.4/html/userguide/inventories.html#ug-inventories-constructed

总结：

希望这篇文章能让您大致了解 Ansible 自动化平台中构建清单的实际用途。 

由于主机模式和构建清单插件等基础概念是通用的 Ansible 概念，用户将能够基于任意复杂条件添加组、变量或主机。

其优势包括：

• 能够从多个事实来源动态创建组。
• 能够从多个清单中过滤、解析和限制主机，但允许在自动化运行中使用它们。
• 能够在过滤时使用预定义的主机变量。
• 多个团队可以拥有自己的清单和与其主机关联的元数据，并可通过 Ansible 自动化平台集中使用。