In these days of cloud computing and infrastructure-as-code, the hosts you may wish to automate could change on a daily if not hourly basis! Keeping a static Ansible inventory up to date could become a full-time job, and hence, in many large-scale scenarios, it becomes unrealistic to attempt to use a static inventory on an ongoing basis.

This is where Ansible's dynamic inventory support comes in. In short, Ansible can gather its inventory data from just about any executable file (though you will find that most dynamic inventories are written in Python)—the only requirement is that the executable returns the inventory data in a specified JSON format. You are free to create your own inventory scripts if you wish, but thankfully, many have been created already for you to use that cover a multitude of potential inventory sources including Amazon EC2, Microsoft Azure, Red Hat Satellite, LDAP directories, and many more systems. 

When writing a book, it is difficult to know for certain which dynamic inventory script to use as an example as it is not a given that everyone will have an Amazon EC2 account they can freely use to test against (for example). As a result, we will use the Cobbler provisioning system by way of example, as this is freely available and easy to roll out on a CentOS system. For those interested, Cobbler is a system for dynamically provisioning and building Linux systems, and it can handle all aspects of this including DNS, DHCP, PXE booting, and so on. Hence, if you were to use this to provision virtual or physical machines in your infrastructure, it would make sense to also use this as your inventory source as Cobbler was responsible for building the systems in the first place, and so knows all of the system names.

This example will demonstrate for you the fundamentals of working with a dynamic inventory, which you can then take forward to use the dynamic inventory scripts for other systems. Let's get started with this process by first of all installing Cobbler—the process outlined here was tested on CentOS 7.8:

1. Your first task is to install the relevant Cobbler packages using yum. Note that, at the time of writing, the SELinux policy provided with CentOS 7 did not support Cobbler's functionality and blocks some aspects from working. Although this is not something you should do in a production environment, your simplest path to getting this demo up and running is to simply disable SELinux:

$ yum install -y cobbler cobbler-web
$ setenforce 0

2. Next, ensure that the cobblerd service is configured to listen on the loopback address by checking the settings in /etc/cobbler/settings—the relevant snippet of the file is shown here and should appear as follows:

# default, localhost
server: 127.0.0.1  

3. With this step complete, you can start the cobblerd service using systemctl:

$ systemctl start cobblerd.service
$ systemctl enable cobblerd.service
$ systemctl status cobblerd.service

4. With the Cobbler service up and running, we'll now step through the process of adding a distribution to Cobbler to create some hosts off of. This process is fairly simple, but you do need to add a kernel file and an initial RAM disk file. The easiest source to obtain these from is your /boot directory, assuming you have installed Cobbler on CentOS 7. On the test system used for this demo, the following commands were used—however, you must replace the version number in the vmlinuz and initramfs filenames with the appropriate version numbers from your system's /boot directory:

$ cobbler distro add --name=CentOS --kernel=/boot/vmlinuz-3.10.0-957.el7.x86_64 --initrd=/boot/initramfs-3.10.0-957.el7.x86_64.img

$ cobbler profile add --name=webservers --distro=CentOS

This definition is quite rudimentary and would not necessarily be able to produce working server images; however, it will suffice for our simple demo as we can add some systems based on this notional CentOS-based image. Note that the profile name we are creating, webservers, will later become our inventory group name in our dynamic inventory.

5. Let's now add those systems to Cobbler. The following two commands will add two hosts called frontend01 and frontend02 to our Cobbler system, using the webservers profile we created previously: 

$ cobbler system add --name=frontend01 --profile=webservers --dns-name=frontend01.example.com --interface=eth0

$ cobbler system add --name=frontend02 --profile=webservers --dns-name=frontend02.example.com --interface=eth0

Note that, for Ansible to work, it must be able to reach these FQDNs specified in the --dns-name parameter. To achieve this, I am also adding entries to /etc/hosts on the Cobbler system for these two machines to ensure we can reach them later. These entries can point to any two systems of your choosing as this is just a test.

At this point, you have successfully installed Cobbler, created a profile, and added two hypothetical systems to this profile. The next stage in our process is to download and configure the Ansible dynamic inventory scripts to work with these entries. To achieve this, let's get started on the process given here:

1. Download the Cobbler dynamic inventory file from the GitHub Ansible repository and the associated configuration file template. Note that most dynamic inventory scripts provided with Ansible also have a templated configuration file, which will contain parameters that you may need to set to get the dynamic inventory script working. For our simple example, we will download these files into our current working directory:

$ wget https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/cobbler.py
$ wget https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/cobbler.ini
$ chmod +x cobbler.py

It is important to remember to make whatever dynamic inventory script you download executable, as shown previously; if you don't do this, then Ansible won't be able to run the script even if everything else is set up perfectly.

2. Edit the cobbler.ini file and ensure that it points to the localhost as, for this example, we are going to run Ansible and Cobbler on the same system. In real life, you would point it at the remote URL of your Cobbler system. A snippet of the configuration file is shown here to give you an idea of what to configure:

[cobbler]

# Specify IP address or Hostname of the cobbler server. The default variable is here:
host = http://127.0.0.1/cobbler_api

# (Optional) With caching, you will have responses of API call with the cobbler server quicker
cache_path = /tmp
cache_max_age = 900

3. You can now run an Ansible ad hoc command in the manner you are used to—the only difference this time is that you will specify the filename of the dynamic inventory script rather than the name of the static inventory file. Assuming you have set up hosts at the two addresses we entered into Cobbler earlier, your output should look something like that shown here:

$  ansible -i cobbler.py webservers -m ping
frontend01.example.com | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "ping": "pong"
}
frontend02.example.com | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "ping": "pong"
}

That's it! You have just implemented your first dynamic inventory in Ansible. Of course, we know that many readers won't be using Cobbler, and some of the other dynamic inventory plugins are a little more complex to get going. For example, the Amazon EC2 dynamic inventory script requires your authentication details for Amazon Web Services (or a suitable IAM account) and the installation of the Python boto and boto3 libraries. How would you know to do all of this? Luckily, it is all documented in the headers of either the dynamic inventory script or the configuration file, so the most fundamental piece of advice I can give is this: whenever you download a new dynamic inventory script, be sure to check out the files themselves in your favorite editor as their requirements have most likely been documented for you.

Before we end this section of this book, let's have a look at a few other handy hints for working with inventories, starting with the use of multiple inventory sources in the next section.