Ansible in Maestro

In this article, we would like to introduce Ansible, an automation tool for provisioning and configuring virtual infrastructures, allowing to install software on virtual machines and manage large clusters of VMs on different cloud providers. In brief, Ansible can easily become an effort-saving alternative to a DevOps engineer.

How does Ansible work?

Let's take a closer look at how Ansible works. For example, we need to install software on all computers in the office. There are around one hundred computers to be affected, all with the Linux operating system. To perform such a task effectively, the developers came up with the solution - an automation tool called Ansible. This tool is represented by an Ansible node, which does not contain the client-side, i.e., you do not need a client to be installed on instances. The node identifies the necessary computers and installs the required software on them. Such workflow relieves the system administrator of the necessity to run the installer on each of these computers sequentially. Ansible is intended for working with Linux machines, though it is possible to use it for Windows as well.

Ansible requires specific information to access the computers - instance IP, password, SSH key, or any other data allowing to log in to the instance as an ordinary user. Upon logging in, the control node needs to install the software, based on specific requirements. These requirements are defined in a so-called playbook. For example, the required software should be installed on instances with different operating systems. The playbook describes the details - Ansible should install the name of the program and specify its version, with specified plugins, should install a license, register specified users in the program, create a shared folder for using documents, etc.

Ansible needs to execute the playbook file for a group of specific instances. But before this, the group of computers should be defined and prepared. For this, the serial numbers and other instance-related data should be collected into an inventory. Ansible accesses each instance defined by IP/serial number and installs the required software on them.

One of the advantages of Ansible is that it can work with different operating systems at once. Thus, a user can set a requirement in the playbook to install software on instances with different OS, describe the conditions in a unified way, and let Ansible execute it. Ansible playbook is written alone for all types of OS, since Ansible server knows how to convert, where to get the necessary information, where to go, how to install a program on different OS, etc. Also, different Ansible plugins allow you to install various software, as well as configure the instance.

Host groups

Ansible also works with host groups where hosts are described/registered. The host group defines instances that Ansible should affect. Grouping is necessary to limit work scope, i.e., a playbook is launched for a specific group.

Every host group is created manually as file and contains the following:

• name of the host group
• DNS names or IP addresses of the VMs to perform automation configuration on
• additional variables

For example, to install a new Java software version on a group of Jenkins slaves, you can define the conditions in a playbook. Running a playbook will make Ansible go to all hosts and perform the same playbook on them.

However, the developers of Ansible moved further and created a more effective and less effort- and time-consuming way round – by using Dynamic Inventory.

Dynamic Inventory

The Dynamic Inventory option enables retrieving information from dynamic sources. In this case, dynamic groups are created on the fly using data from cloud providers (Maestro). You can configure dynamic groups to any criteria - keys, security groups, tags.

Maestro works with dynamic groups, their management, and the provisioning of these groups to users.

The dynamic inventory is represented by a list of virtual machines, including their IPs, DNS addresses, and all other VM properties grouped by parameters, e.g., tags, keys, owners, security groups, etc.

Dynamic inventory uses two approaches to storing data – scrips and plugins. Ansible recommends using its native plugins, since it is possible to set and install plugins for all cloud providers once, and from this point on Ansible will itself execute them.

Maestro uses scripts approach, thus aggregating data from different cloud providers. These scripts dynamically collect host groups in order to simplify work and allow selecting necessary hosts in real time.

Why should we use Ansible via Maestro instead of native Ansible?

• Since Maestro is an Orchestrator, the solution works with all cloud providers, thus being able to dynamically collect groups on different cloud providers by executing a single script.
• Maestro allows DevOps specialists to collect dynamic inventory data from the same source application where they manage their virtual infrastructure, deploy instances, and provide the Ansible file for configuring groups of instances.
• Maestro supports the cross-cloud providers’ ownership mechanism, thus allowing to manage dynamic inventory by instances’ ownership parameters which is quite convenient if you work within an organization.
• It is possible to collect dynamic inventory of a group of instances marked by tag for all cloud providers supported by Maestro.
• Collecting dynamic inventory on groups of instances launched by SSH keys used in Maestro.
• Maestro allows defining various parameters of the system and add parameters necessary for the customer into the dynamic inventory file.

Thus, with the Ansible automation tool's help, the infrastructure management in Maestro is significantly simplified by automating the processes and lessening the efforts of DevOps specialists.