Ansible Inventory

In this lesson we’re going to be going over Ansible inventory files. Ansible has a method of defining Ansible managed devices and grouping those devices, and using this definition to be able to run your playbooks and modules on a very specific group of devices or a subset thereof. In this lesson we’re going to be talking about how to create those groups and to find them in a file as well as where the default group is located and how to limit those either to a specific subset that you define or a retry subset from failed devices that may have failed during a previous playbook execution. So let’s go ahead and jump right on in!

First up, our default inventory location is the /etc/ansible/hosts file. This is on a linux distribution, or a unix-like box. Meaning, this is located in our /etc folder and then our /ansible folder within there. and then our hosts file. Now you can specify a separate inventory file during your playbook execution, or within your ansible.cfg file you can specify a different default inventory file. The ansible.cfg file, our main configuration file, is located within the /etc/ansible/ansible.cfg.

Our managed devices within the inventory file are defined as IP addresses or hostnames. It’s important to note that a hostname must be resolvable by the ansible management node. So the ansible management server that you are running these playbooks on, or have your inventory defined on, this server needs to be able to resolve any hostnames. So either within its own hosts file or by DNS through the configured DNS server that it’s using for resolution, it needs to be able to resolve those hostnames. Otherwise you need to specify all of your inventory by IP addresses.

Host groups are named so we would have a [routers] group or a [switches] group, or perhaps an [SRX] group. They are named groups, so rather than group1 group2 etc., you can actually specify names. These groups contain one or more hosts or groups. Hosts and groups can be members of one or more groups, so you can have nested grouping and they can also be members of multiple different groups.

If I have my 192.168.2.126 node and this is a vSRX router, then I can have it be a member of the [routers] group and also of the [vsrx] group so that I can specify both of these. It might feel a little redundant, but in your particular environment you might find a reason. If perhaps we have [ISP_routers] as a group and perhaps this device is an ISP router as part of that group, and it also happens to be a vSRX. Maybe you also have MX devices, this could have been an MX204 and within the [mx] group as well.

Host and group variables may be stored in the inventory file, or in separate files. You can have specific variables for specific groups, and also specific variables for specific hosts. These specific variables to be used within your playbook can be specified and stored within the inventory or within separate files.

Excellent, so let’s move on a little bit here and talk about what the inventory file really looks like and its structure. Above we have a example of an inventory file. I just did ‘cat’ to go ahead and write out the contents of a file, so above we have the inventory file, and below the hosts file within /etc ansible directory.

We can have comments within our inventory file. Any line that begins with a hash or a pound sign ( # ), this starts a comment line.

Our groups are defined by putting some characters between square brackets, like [router_group]. That defines the name of our group and then any items below that name, either IP addresses or host names, are the members of that group.

We can also use some expressions within our host names or IP addresses, as we did in the same inventory above to define many items within one line, this would be 192.168.2.200 through 203 inclusive, meaning .200, .201, .202 and .203 .

Similarly we can do an expression where we have core-sw-01 and 02, both defined by these two items.

Hostnames need to be resolvable. In this particular case we have our hosts file here on our Linux box, so I’m just cat’ing the content right out of our /etc/hosts file. In that file we have our localhost and ansible-lab for our own hostname here on our ansible management node, and then we have that vmx1 is also defined here as 192.168.2.203 IP address.

Because vmx1 is resolvable, we are able to use that hostname within our inventory file.

In order to have a group of groups, to have nested groups our group that contains child groups must have the :children on the end of the group name. This is so the names within this group are known to be other groups, and not hostnames of individual inventory nodes. Because of this, a group of groups can only have groups within it. You cannot have individual inventory items within that group.

In the example above we have our routers:children group which contains groups because of the :children. The two groups that are within this routers group are vsrx and mx. So we have our mx group and our vsrx group and then we also have our core group that is a group of groups because of the :children.

Excellent, so this is how you would organize and how you would structure your inventory file. This is all text, there is no indentation going on here, there are simply places where we have square brackets to define either expressions or group names and we have the :children on the end of a group name within our square brackets to define a group of groups.

That’s all we need to know as the JNCIA-DevOps and that’s how we’ll be looking at the structure of our inventory files. So let’s take a little look at how we use our inventory files.

Our inventory can either be in our default inventory file, recall our /etc/ansible/hosts file is our default inventory file.

If no inventory file is specified that’s what we’ll be using. Otherwise we specify a custom inventory file with the -i flag. In addition to -i we can also limit the hosts that will be used within that inventory file, or in our default inventory file as well. We can either limit to some group name like we have above with the –limit vsrx or we can limit to some specific IP address or host like we have with -l 192.168.2.181. We can also specify a file which contains a list of hosts that we would like to limit to, in this case we are using the retry_hosts.txt file, by specifying the @ symbol before the file name.

This retry_hosts.txt file would be generated in the event a playbook fails against some set of hosts. It will generate a list of hosts that the playbook failed on and that these are ones that we’re looking to retry our playbook against to see if that completes successfully.

For a full video lesson of this content, please review the lesson video below!