Using inventory plugins from Ansible Content Collections in Ansible Tower

IT environments are becoming more and more complex. Under these conditions, it is critically important for an IT automation system to have up-to-date information about the nodes that are present in the network and are to be processed. In Red Hat Ansible Automation Platform, this issue is solved through the so-called inventories (inventory) – lists of managed nodes.

In its simplest form, an inventory is a static file. This is ideal when you start working with Ansible, but as automation expands, it becomes insufficient.

And that's why:

1. How do you update and keep up-to-date the complete list of monitored nodes when things are constantly changing, when workloads - and after them, the nodes on which they run - come and go?
2. How to classify the components of the IT infrastructure in order to select nodes for the use of this or that automation?

Both of these questions are answered by a dynamic inventory (dynamic inventory) is a script or plugin that searches for nodes to automate by referring to the source of truth. In addition, the dynamic inventory automatically categorizes nodes into groups so you can more accurately select target systems to perform any given Ansible automation.

Inventory plugins give the Ansible user the ability to access external platforms to dynamically find target nodes and use these platforms as a source of truth when building an inventory. The standard list of sources in Ansible includes AWS EC2 cloud platforms, Google GCP and Microsoft Azure, and there are many other inventory plugins for Ansible.

Ansible Tower comes with a number of inventory plugins, which work right out of the box and, in addition to the above cloud platforms, provide integration with VMware vCenter, Red Hat OpenStack Platform and Red Hat Satellite. For these plugins, it is enough to provide credentials to connect to the target platform, after which they can be used as an inventory data source in Ansible Tower.

In addition to the regular plugins from the Ansible Tower distribution kit, there are other inventory plugins supported by the Ansible community. With the transition to Red Hat Ansible Content Collections these plug-ins began to be included in the corresponding collections.

In this post, we will take an example of working with an inventory plugin for ServiceNow, a popular IT service management platform in which customers often store information about all their devices in the CMDB. In addition, the CMDB can contain useful context for automation, such as server ownership, service levels (production/non-production), installed updates, and maintenance windows. The Ansible inventory plugin can work with CMDB ServiceNow and is part of the collection service now on the portal galaxy.ansible.com.

Git repository

To use an inventory plugin from the collection in Ansible Tower, it must be set as the project source. In Ansible Tower, a project is an integration with some version control system, like a git repository, that can be used to keep not only automation playbooks in sync, but variables and inventory lists as well.

Our repository is actually very simple:

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

The servicenow.yml file contains the details for the plugin inventory. In our case, we simply specify the table in the ServiceNow CMDB that we want to use. We also set the fields that will be added as node variables, plus certain information on the groups we want to create.

$ 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: ''

Note that it doesn't specify the ServiceNow instance we'll be connecting to, and it doesn't specify any connection credentials. We will configure all this later in Ansible Tower.

collections/requirements.yml file is needed so that Ansible Tower can download the desired collection and thereby get the desired inventory plugin. Otherwise, we would have to manually install and maintain this collection on all of our Ansible Tower nodes.

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

- name: servicenow.servicenow

Once we have submitted this configuration to version control, we can create a project in Ansible Tower that references the appropriate repository. The example below links Ansible Tower to our github repository. Pay attention to the SCM URL: it allows you to specify an account to connect to a private repository, as well as specify a specific branch, tag or commit to checkout.

Create credentials for ServiceNow

As already mentioned, the configuration in our repository does not contain credentials to connect to ServiceNow and does not specify the ServiceNow instance with which we will communicate. Therefore, to set this data, we will create credentials in Ansible Tower. According to ServiceNow inventory plugin documentation, there are a number of environment variables with which we will set the connection parameters, for example, like this:

= 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

In this case, if the SN_USERNAME environment variable is set, then the inventory plugin will use it as an account to connect to ServiceNow.

We also need to set the SN_INSTANCE and SN_PASSWORD variables.

However, there is no such type of credentials in Ansible Tower where you can specify these data for ServiceNow. But Ansible Tower allows us to define custom credentials types, you can read more about this in the article "Ansible Tower Feature Spotlight: Custom Credentials".

In our case, the input configuration for custom credentials for ServiceNow looks like this:

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

These credentials will be exposed as environment variables of the same name. This is described in the injector configuration:

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

So, we have defined the type of credential we need, now we can add the ServiceNow account and set the instance, username and password, like this:

Create an inventory

So, now we are all set to create an inventory in Ansible Tower. Let's call it ServiceNow:

After creating an inventory, we can attach a data source to it. Here we point to the project we created earlier and enter the path to our YAML inventory file in the source control repository, in our case servicenow.yml at the root of the project. In addition, the ServiceNow account must also be linked.

To check how everything works, let's try to synchronize with the data source by clicking the "Sync all" button. If everything is configured correctly, then the nodes should be imported into our inventory:

Please note that the groups we need have also been created.

Conclusion

In this post, we looked at how to use inventory plugins from collections in Ansible Tower using the ServiceNow plugin as an example. We've also securely written credentials to connect to our ServiceNow instance. Linking an inventory plugin from a project works not only with third-party or custom plugins, but can also be used to modify the work of some regular inventories. This allows Ansible Automation Platform to easily and seamlessly integrate with existing tools to automate increasingly complex IT environments.

Find more information on the topics covered in this post, as well as other aspects of using Ansible, here:

• Blog by ServiceNow automation using Ansible.
• How to create your own collections.
• List of Red Hat supported collections on the Automation Hub site (cloud.redhat.com).
• Ansible Automation Platform eBooks.

*Red Hat makes no warranties for the correctness of the code shown here. All materials are provided on a non-supporting basis, unless otherwise expressly stated.

Source: habr.com