Data model for Ansible

This extension is dedicated to Ansible, the application that automates the management of remote systems and controls their desired state. It enriches iTop's CMDB by modelizing Ansible inventories which enforces the central role of iTop for all CMDB matters. Together with the Ansible playbooks for iTop, it enables Ansible administrators and developpers to fetch in iTop, directly from Ansible playbooks, tasks or modules, CMDB related information like inventory files or list of hosts to work on.

When installed on iTop, the extension creates a set of different classes that represent Ansible objects. These classes are displayed in a specific dashboard that is accessible from a submenu of the standard CMDB overview menu.

The model brings a TagSet attribute on a n:n relation. Such attribute cannot be changed on iTop 2.7 nor iTop 3.0 and therefore cannot be used with these versions.

The extension can only be installed on iTop 2.7.x and above, including iTop 3.x, of course

Use the Standard installation process for this extension. It can be installed on any iTop datamodels as it just depends on iTop configuration management module, which is a core module that is always activated.

By default, the extension limits the class of CIs that can be attached to an Inventory group. A configuration parameter allows you to overload this default behaviour.
The section below is by default hidden in the configuration file, you have to copy it from below if you need to adapt the list of CI classes.

Configuration

      'combodo-ansible-datamodel' => array (
                'ci_classes_in_inventory_groups' => array (
                  0 => 'Server',
                  1 => 'VirtualMachine',
                  2 => 'AzureVirtualMachine',
                  3 => 'ApplicationSolution',
                ),
        ),

This class modelizes the well-known Ansible applications from which CIs can be managed via commands applied to inventories.

An inventory is a list of managed nodes, or hosts, that Ansible deploys and configures. These hosts can be classified within groups.

From the “Other actions” menu of an Ansible inventory, the “Display inventory file” menu will let you visualize the entire inventory as a file in INI or YAML formats.

• A button on the top of the “file” allows you to switch from one format to the other.
• The Details menu will bring you back to the details page of the inventory.

These hierarchical objects are used to classify hosts and decide which hosts are controlled, when and for what purpose.

This relation hosts a Tag attribute.

• This field is defined as an iTop tagset attribute,
• Several tags can therefore be added to the relation (maximum 12),
• All values will appear in inventory files, according to Ansible standards.

The Tag attribute is a TagSet. Being hosted on a n:n relation, it cannot be changed on iTop 2.7 nor iTop 3.0 and therefore cannot be used with these versions where it is left empty. On iTop 3.1, it must be edited in modal windows, through the or icons of the CIs box.

The group called “ungrouped” is a mandatory object in YAML inventories. It contains all CIs that are not attached to a specific Inventory group. This is not the case with INI inventories where such CIs are directly attached to the root of the file. Regardless of the format, CIs that should not be attached to a group must be attached to the ungrouped group in iTop.

In iTop standard data model, Virtual Machines are linked to a Virtual Host i.e. the vCluster or Hypervisor on which they have been activated. This link is mandatory… which may cause problems when virtual machines are created from Ansible as their virtual host is not always known by the playbooks in charge of their creation (Ansible playbooks for iTop extension) or by the facts gathered from the Ansible controller (Data collector for Ansible).

The extension brings with it the new profile “Ansible Manager” which has full rights on all classes brought by the extensions as well as read rights over the General, Configuration and Documentation groups.

In addition to the classes described above, the extension provides a set of WEB services dedicated to Ansible. Based on iTop standard REST/JSON interface, they can be used to retrieve inventory files or host lists from third-party applications such as Ansible.

Provides the version currently used for iTop WEB services dedicated to Ansible.

Required parameters: None

For example, passing the following json_data:

{
   "operation": "get_webservices_version"
}

will return the information:

“Running version of the iTop WEB services dedicated to Ansible is: 1.0”

Get an inventory defined for an Ansible application.

Required parameters:

For example, passing the following json_data:

{
   "operation": "ansible/get_inventory",
   "uuid": "DEMO_UUID",
   "inventory": "DMZ-1",
   "format": "yml"
}

will return the “DMZ-1” inventory file in YAML format, like the one displayed in the previous chapter.

Get a subset of hosts belonging to an inventory defined for an Ansible application.

Required parameters:

For example, passing the following json_data:

{
   "operation": "ansible/get_inventory",
   "uuid": "DEMO_UUID",
   "inventory": "DMZ-1",
   "OQL": "SELECT VirtualMachine",
   "attribute": "name"
}

will return, as a list, the names of the virtual machines belonging to “DMZ-1” inventory:

“3cxTelephonie,VM1,VM2,VSphere Server,Windows Server 2008R2”

The Ansible web services have been embedded in “ready to use” Ansible playbooks that can be integrated in any Ansible scripts (playbooks, tasks or modules). Please, refer to the Ansible playbooks for iTop documentation.