Enhancing Ansible Inventory with DDI

Ansible is a configuration manager whose main role is to bring devices to a specific level of configuration. Ansible uses an inventory from which it selects devices to configure, this is where a DDI solution EfficientIP’s suite of SOLIDserver products can bring many benefits like exhaustiveness, robustness, integrity and extensibility through actionable metadata.

Ansible is able to handle complex situations through regrouping of several small tasks into “playbooks”. Tasks are available for multiple operating systems, applications, and device vendors in a very impressive ecosystem. Thanks to this approach it is able to be used on various devices with different levels of configuration in order to bring all of them to a defined similar level. The Ansible inventory is generally a file with all the devices grouped together by families, operating systems or environment. Each playbook can use a specific inventory file, but how can you be sure all the devices on the network are being addressed during an operation if the inventory file is not always accurate?

This is where a dynamic inventory based on a remote source makes sense. The source can vary over time, the filter template getting devices from the source is always the same and may produce different results over time. This can help to apply the same Ansible playbook recipe to a varying list of devices from an always up-to-date inventory. One option is to use the Ansible Tower system, but most Ansible users are still relying on the free open source version available on most Linux distributions.

Ansible & DDI Central Repository Ensures Accurate Data and Powerful Grouping

The EfficientIP dynamic inventory extension for Ansible offers an advanced way of using the Device Manager product as the central repository, even on the free version of Ansible. Each time a playbook is run, the inventory uses the rich information located in the IPAM and Device Manager in order to extract all the nodes to apply the playbook tasks. The integration provides a rich set of filters allowing selection of only the appropriate devices for the playbook. The filter definition is located in a specific playbook file and can produce different results from one invocation to another, as the Device Manager content may have been updated in the meantime.

In addition to the filtering functions, the Ansible inventory also proposes the grouping of devices. Grouping is a powerful notion from Ansible, allowing execution of a specific playbook for only part of the inventory, based on a group. The extraction of the devices from EfficientIP Device Manager can then be wider than the set of devices on which part of the playbook will be applied. For example, the filter can select all Linux devices from the inventory list and perform the grouping by version. Then, the playbook would be only applied to a specific version of the Linux devices selected. That may help a playbook to be more generic and able to be applied to a larger set of devices. This kind of usage is helpful when performing upgrades, for example where patches may need to be applied on specific versions of the operating system. Since most upgrade functions are not reversible (due to complexity of rollback), grouping is a very valuable solution.

Demo Videos showing Example Use Cases for Ansible DDI & IPAM

In the first part of the demonstration video we explore some very basic use cases of the filtering and grouping capabilities offered by the dynamic Ansible inventory:

• All devices: get all the entries in Device Manager: this one is mainly to start with basic configuration of the dynamic inventory structure. It can also be used to perform very global tasks for all the devices on the network, like fingerprinting, checking open ports or verifying reachability
• Limit number of devices: here we limit the number of devices returned from the inventory, it can be useful when a specific task needs to be done on a regular basis for specific devices that match specific rules and the process is either long, expensive to execute or needs to be terminated in a very short window period
• Limit to an IPAM space: the EfficientIP IPAM can be segmented into multiple independent spaces. A device in Device Manager can have interfaces and IP addresses registered in the IPAM, they are therefore in a space. Limiting the query to a space ensures that the device list is controlled and restricted to a specific part of the infrastructure
• Limit to a subnet: this query will only select devices with an interface in the subnet
• Grouping by metadata: if the device has metadata, it will appear in a specific group composed of the name of the metadata and its value. This is useful to limit the tasks of the playbook to only part of the inventory
• Limit to class and metadata value: this query will only return the devices that have the metadata with the specific value and with a specific class set. Since each object in the IPAM can be labelled with a specific class of parameters, it can be very useful to only select these and eventually refine the search by a value of one parameter from the class
• The last example demonstrates the use of filters on specific parameters and a grouping on another one, since grouping and filtering can be performed individually.

There are some improvements in development to enhance this dynamic inventory with additional filters that can leverage other components of the SOLIDserver solution such as IPAM or NetChange.

The second part of the demonstration video is more focused on the use of the dynamic inventory linked to SOLIDserver directly in a playbook. The story here is to use a playbook capable of collecting some information from Linux hosts and pushing it back in Device Manager metadata attached to the device. The metadata can then be actioned in any other playbook.

• Playbook 1: the first playbook selects from the inventory all the devices in a specific space, gathers information from the device and updates the appropriate device entry in Device Manager. In our example, the playbook updates the OS, the major release of Linux and the update time
• Playbook 2: the second playbook selects all the devices in the space and asks for a grouping by OS version number. The playbook only runs on a specific version of device, so here we are using the filtering function of Ansible directly in the playbook, based on the metadata gathered from Device Manager. The selected devices will be updated by the playbook and the state updated.

These Ansible playbooks are really simple in their tasks, the main idea is to demonstrate how to use a remote inventory in Ansible, with the SOLIDserver as a repository. It for sure also works with the more complex and operational playbooks you may have on your systems. Therefore a migration of your inventory text files to the Device Manager is possible (an import may populate it) and through a very simple adaptation of the inventory section of the playbooks the functional part remains unmodified. For all further execution of the playbook you will then benefit from the Device Manager dynamic repository that may have been updated by another infrastructure process or through the graphical interface.

Actionable metadata for enhanced automation

Finally, this Ansible integration demonstrates the power of actionable metadata that is available on most objects in the SOLIDserver solution. Having a central repository with most information related to devices, IP related information or application can bring a lot of value to your automation journey. Learn more about EfficientIP SolidServer capabilities.