Clever Geek Handbook

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 Red Hat Ansible Automation Platform, this problem is solved through the so-called The inventory ( inventory a ) - the list 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. -, ?


The answers to both these questions give a dynamic inventori ( the dynamic inventory a ) - the script or plugin that is looking to be the automation units, referring to the source of truth (source of truth). In addition, the dynamic inventory automatically categorizes 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 forming 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 plugins that 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 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 move to Red Hat Ansible Content Collections, these plugins have been 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 servicenow collection on 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 this later in the Ansible Tower.



The collections / requirements.yml file is needed so that Ansible Tower can download the required collection and thus 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 the documentation of the ServiceNow inventory plugin , 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 point to the project we created earlier and enter the path to our inventory YAML file in the source control repository, in our case it is servicenow.yml in the root of the project. 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 . , .


More articles:


All Articles