Using inventory plugins from Ansible Content Collections in Ansible Tower

IT environments are becoming more and more complex. In 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 subject to processing. In the Red Hat Ansible Automation Platform, this issue is resolved 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 get started with Ansible, but as automation expands, it becomes insufficient.

And that’s why:

  1. How to update and maintain up to date a complete list of monitored nodes when something is constantly changing, when workloads – and after them the nodes on which they run – appear and disappear?
  2. How to classify the components of the IT infrastructure in order to target the nodes for applying one or another automation?

The answers to both of these questions are given by the dynamic inventory (dynamic inventory) Is a script or plugin that searches for nodes to be automated by referring to the source of truth. In addition, the dynamic inventory automatically categorizes the nodes into groups so that you can more accurately select the target systems for performing an 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 shaping inventories. The standard Ansible source list includes cloud platforms AWS EC2, Google GCP and Microsoft Azure, and there are many other inventory plugins for Ansible.

Ansible Tower comes with a number of inventory pluginsthat work right out of the box and in addition to the above-listed 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 a source of inventory data in Ansible Tower.

In addition to the standard plugins supplied with Ansible Tower, there are other inventory plugins supported by the Ansible community. With the transition to Red Hat Ansible Content Collections these plugins began to be included in their respective 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 context useful for automation, such as information about server owners, service levels (production / non-production), installed updates, and maintenance windows. Ansible inventory plugin can work with CMDB ServiceNow and is part of the collection servicenow 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 kind of version control system, like a git repository, which can be used to synchronize not only automation playbooks, but also variables and inventory lists.

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 CMDB ServiceNow that we want to use. And also we set the fields that will be added as node variables, plus certain information on the groups that 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: ''

Please note that this does not specify the ServiceNow instance to which we will connect in any way, and does not specify any credentials for connecting. We’ll configure all of this later in the Ansible Tower.

Collections / requirements.yml file is needed so that Ansible Tower can download the required collection and thereby get the required 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 pushed this configuration to source control, we can create a project in Ansible Tower that links to the corresponding repository. The example below links the Ansible Tower to our github repository. Pay attention to the SCM URL: it allows you to register 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 stated, the configuration in our repository does not contain credentials to connect to ServiceNow and does not flesh out the ServiceNow instance we will communicate with. Therefore, to set this data, we will create credentials in the 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, 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, Ansible Tower does not have such type of credentials where one could specify this 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 with 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 you can add the ServiceNow account and set the instance, username and password, like this:

We create inventory

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

After creating the inventory, we can attach a data source to it. Here we indicate the project that we created earlier and enter the path to our YAML inventory file in the source control repository, in our case it is servicenow.yml in the project root. In addition, the ServiceNow account must be bound.

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 assigned credentials to connect to our ServiceNow instance. Binding an inventory plugin from a project works not only with third-party or custom plugins, but it can also be used to modify the work of some regular inventories. This allows Ansible Automation Platform to seamlessly 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:

* Red Hat makes no guarantees of the correctness of the code provided. All materials are provided without support unless otherwise explicitly stated.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *