在 Ansible Tower 中使用来自 Ansible Content Collections 的库存插件

IT 环境变得越来越复杂。 在这些情况下,IT 自动化系统拥有有关网络中存在并需要处理的节点的最新信息至关重要。 在红帽 Ansible 自动化平台中,这个问题通过所谓的清单来解决(库存) – 受管节点列表。

在 Ansible Tower 中使用来自 Ansible Content Collections 的库存插件

最简单的形式是,库存是一个静态文件。 当您开始使用 Ansible 时,这是理想的选择,但随着自动化程度的提高,它就变得不够了。

原因如下:

  1. 当情况不断变化、工作负载及其运行的节点来来去去时,如何更新和维护受监控节点的完整列表?
  2. 如何对 IT 基础设施的组件进行分类,以便专门选择应用特定自动化的节点?

动态库存为这两个问题提供了答案(动态库存) – 搜索要自动化的节点的脚本或插件,参考事实来源。 此外,动态清单会自动将节点分组,以便您可以更准确地选择目标系统来执行特定的 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 社区还支持其他库存插件。 随着过渡到 红帽 Ansible 内容集合 这些插件开始包含在相应的集合中。

在这篇文章中,我们将举一个使用 ServiceNow 的库存插件的示例,ServiceNow 是一个流行的 IT 服务管理平台,客户经常在 CMDB 中存储有关其所有设备的信息。 此外,CMDB 还可以包含对自动化有用的上下文,例如有关服务器所有者、服务级别(生产/非生产)、已安装的更新和维护时段的信息。 Ansible 库存插件可以与 ServiceNow CMDB 配合使用,并且是集合的一部分 现在服务 在门户网站上 Galaxy.ansible.com.

Git 存储库

要使用 Ansible Tower 中集合中的清单插件,必须将其设置为项目源。 在 Ansible Tower 中,项目是与某种版本控制系统(例如 git 存储库)的集成,它不仅可用于同步自动化剧本,还可用于同步变量和库存列表。

我们的存储库实际上非常简单:

├── 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 中配置所有这些。

文件集合/requirements.yml 以便 Ansible Tower 可以下载所需的集合,从而获得所需的库存插件。 否则,我们必须在所有 Ansible Tower 节点上手动安装和维护此集合。

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

- name: servicenow.servicenow

一旦我们将此配置推送到版本控制,我们就可以在 Ansible Tower 中创建一个引用相应存储库的项目。 下面的示例将 Ansible Tower 链接到我们的 github 存储库。 请注意 SCM URL:它允许您注册帐户以连接到私有存储库,以及指定要签出的特定分支、标签或提交。

在 Ansible Tower 中使用来自 Ansible Content Collections 的库存插件

为 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 允许我们定义 自定义凭证类型,您可以在文章中阅读更多相关内容 “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 中使用来自 Ansible Content Collections 的库存插件

我们创建库存

现在我们已经准备好在 Ansible Tower 中创建清单了。 我们称之为 ServiceNow:

在 Ansible Tower 中使用来自 Ansible Content Collections 的库存插件

创建清单后,我们可以为其附加数据源。 在这里,我们指定之前创建的项目,并输入源代码控制存储库中 YAML 库存文件的路径,在我们的示例中,它是项目根目录中的 servicenow.yml。 此外,您需要关联您的 ServiceNow 帐户。

在 Ansible Tower 中使用来自 Ansible Content Collections 的库存插件

为了检查一切如何工作,让我们尝试通过单击“全部同步”按钮来与数据源同步。 如果一切配置正确,那么节点应该导入到我们的清单中:

在 Ansible Tower 中使用来自 Ansible Content Collections 的库存插件

请注意,我们需要的组也已创建。

结论

在这篇文章中,我们以 ServiceNow 插件为例,了解了如何在 Ansible Tower 中使用集合中的库存插件。 我们还安全地注册了凭据以连接到我们的 ServiceNow 实例。 从项目链接库存插件不仅可以与第三方或自定义插件配合使用,还可以用于修改某些标准库存的操作。 这使得 Ansible 自动化平台在自动化日益复杂的 IT 环境时可以轻松、无缝地与现有工具集成。

您可以在此处找到有关本文讨论的主题以及使用 Ansible 的其他方面的更多信息:

*红帽不保证此处包含的代码是正确的。 除非另有明确说明,所有材料均在非认可的基础上提供。

来源: habr.com

添加评论