在 Ansible Tower 中使用来自 Collection 的 Inventory 插件

在 Ansible Tower 中使用来自 Collection 的 Inventory 插件

许多 IT 环境变得越来越复杂。自动化解决方案始终拥有有关哪些节点存在以及需要自动化的最新信息比以往任何时候都更加重要。为了应对这一挑战，Red Hat Ansible Automation Platform 使用了清单：受管节点的列表。

在最简单的形式中，清单可以是静态文件。这非常适合开始使用 Ansible，但随着自动化的扩展，静态清单文件不再足够。

1. 如果某些内容发生变化，如果工作负载启动或拆除，我们如何更新和维护所有受管节点的列表？
2. 我们如何对基础设施进行分类，以便我们可以更具选择性地确定要针对其进行自动化的受管节点？

这两个问题的答案都是使用动态清单：一个脚本或插件，它将转到真相来源并发现需要管理的节点。它还将通过将节点放入组中来自动对节点进行分类，这些组可用于在使用 Ansible 自动化时更具选择性地定位设备。

清单插件允许 Ansible 用户使用外部平台动态发现目标主机并使用这些平台作为其 Ansible 清单的真相来源。常见的真相来源包括 AWS EC2、Google GCP 和 Microsoft Azure，但 Ansible 还提供了许多其他清单插件。

Ansible Tower 附带了许多开箱即用的清单插件。这些包括前面提到的云示例，以及 VMware vCenter、Red Hat OpenStack Platform 和 Red Hat Satellite。要使用这些清单插件，需要添加可以查询源平台的凭据。之后，可以将清单插件用作 Ansible Tower 中清单的来源。

还有其他清单插件可用，这些插件未随 Ansible Tower 一起提供，但由 Ansible 社区编写。随着迁移到 Red Hat Ansible 内容集合，这些清单插件正在作为相应集合的一部分进行打包。

在此示例中，我们正在查看 ServiceNow 清单插件。ServiceNow 是一个非常流行的 IT 服务管理平台，客户通常使用 ServiceNow CMDB 来存储其所有设备的详细信息。CMDB 可以为自动化提供额外的上下文。例如，服务器所有者、服务级别（生产/非生产）以及补丁和维护窗口。他们的 Ansible 清单插件可用于查询 ServiceNow CMDB，并作为galaxy 上提供的 servicenow.servicenow 集合的一部分交付。

Git 仓库

要在 Ansible Tower 中使用来自 Collection 的清单插件，我们需要从项目中获取它。Ansible Tower 中的项目是源代码控制存储库（如 git 存储库）的集成。在 Ansible Tower 中，项目用于提取 Ansible Playbook，以及变量和清单。

我的源代码控制存储库的内容非常简单

├── collections
│   └── requirements.yml
└── servicenow.yml

servicenow.yml 文件包含清单插件的详细信息。在我们的例子中，我们指定了我们要使用的 ServiceNow CMDB 中的正确表。我们还选择了我们想要添加为主机变量的字段以及有关我们想要创建的组的一些信息。

$ cat servicenow.yml
plugin: servicenow.servicenow.now
table: cmdb_ci_linux_server
fields: [ip_address,fqdn,host_name,sys_class_name,name,os]
keyed_groups:
  - key: sn_sys_class_name | lower
    prefix: ''
    separator: ''
  - key: sn_os | lower
    prefix: ''
    separator: ''

请注意，此处未定义我们要连接到的 ServiceNow 实例的任何详细信息或任何凭据。这些将在以后的 Ansible Tower 中进行配置。

需要collections/requirements.yml 文件，以便 Ansible Tower 可以下载 Collection，从而下载清单插件。否则，我们必须手动在所有 Ansible Tower 节点上安装和维护 Collection。

$ cat collections/requirements.yml
---
collections:

- name: servicenow.servicenow

将此配置推送到源代码控制存储库后，我们可以在 Ansible Tower 中创建一个项目来引用该存储库。下面是一个将 Ansible Tower 链接到我的 github 存储库的示例。请注意 SCM URL。如果存储库是私有的，我们可以选择指定凭据，还可以指定要从中提取的特定分支、标签或提交。

创建 ServiceNow 凭据

如前所述，我们存储库中的配置不包括要与 ServiceNow 一起使用的凭据，也不包括要与之通信的 ServiceNow 实例的定义。因此，我们将在 Ansible Tower 中创建一个凭据来定义这些值。查看ServiceNow 清单插件的文档，我们可以看到可以设置许多环境变量来定义连接详细信息。例如

= username
        The ServiceNow user account, it should have rights to read cmdb_ci_server (default), or table specified by SN_TABLE

        set_via:
        env:
        - name: SN_USERNAME

在这种情况下，如果设置了 SN_USERNAME 环境变量，则清单插件将使用它作为连接到 ServiceNow 的用户帐户。

我们需要设置的其他变量是 - SN_INSTANCE 和 SN_PASSWORD

但是，在 Ansible Tower 中，没有我们可以输入这些详细信息的 ServiceNow 凭据类型。幸运的是，对于此类用例，Ansible Tower 允许我们定义自定义凭据类型。

在我们的例子中，ServiceNow 自定义凭据的输入配置如下

fields:
  - id: SN_USERNAME
    type: string
    label: Username
  - id: SN_PASSWORD
    type: string
    label: Password
    secret: true
  - id: SN_INSTANCE
    type: string
    label: Snow Instance
required:
  - SN_USERNAME
  - SN_PASSWORD
  - SN_INSTANCE

凭据将作为相同名称的环境变量公开。这在注入器配置中进行了描述

env:
  SN_INSTANCE: '{{ SN_INSTANCE }}'
  SN_PASSWORD: '{{ SN_PASSWORD }}'
  SN_USERNAME: '{{ SN_USERNAME }}'

定义了自定义凭据类型后，我们现在可以添加 ServiceNow 凭据并设置实例、用户名和密码，如下所示

创建清单

最后一步是在 Ansible Tower 中创建清单。我们需要一个名称 - 此处为 ServiceNow：

创建清单后，我们现在可以附加一个源。在这里，我们指定之前创建的项目，并在源代码控制存储库中输入清单 YAML 文件的路径 - 在这种情况下，是项目根目录中的 servicenow.yml。我们还需要关联我们的 ServiceNow 凭据。

要测试设置，我们可以尝试与源同步。按下“全部同步”按钮即可执行此操作。如果所有内容都配置正确，则主机应导入到清单中

请注意我们请求的组也已创建。

总结

在此示例中，我们演示了如何使用 Ansible Tower 中 Collection 中的清单插件，使用 ServiceNow 清单插件。我们还安全地定义了用于向我们的 ServiceNow 实例进行身份验证的凭据。从项目中获取清单插件也不仅限于第三方或自定义插件：这对于修改某些内置清单插件的行为也是一种有效的方法。这些功能使 Ansible Automation Platform 能够与现有工具无缝集成，同时自动化日益复杂的 IT 环境。