Avatar (Fabio Alessandro Locati|Fale)'s blog

Ansible Inventories

March 1, 2017

I often receive questions about Ansible Inventories (far more often than any other Ansible component). My guess is that Inventories are effectively among the most complex things in Ansible.

Ansible Inventories are complex in the following ways:

Grouping philosophies

The two main philosophies I saw in the many years I’ve worked with Ansible are:

In inventories that follow the first philosophy we would be able to find group names like:

In inventories that follow the second philosophy we would be able to find group names like:

As you can see, in the second philosophy the names are not different from the ones of the first philosophy, but the real difference is that in the first case you have more names in the same group name.

My philosophy

From my point of view, the second philosophy is often the suggested one, since the problem with the first one is that if you have a group name composed by 5 characteristics, in a very short time you’ll find yourself managing hundred of groups.

Now, which groups are sensible to make and which are not is a completely different and more complex question. My general rules on this are:

Clearly this list is not complete and often speaking with the operations teams they have point out additional needs that need to be addressed.

Be productive using Patterns

If you look the list of collections of groups that we have just discussed, you can notice that they will split your machines in different directions. This is important because Ansible is able to execute operations between groups to choose which modes will be targeted for a specific Playbook thanks to the Patterns.

We can two different kind of Patterns based on the number of parameters they have:

Patterns with one parameter

Patterns with one parameters are simpler but still very powerful. The main we have are:

Other patterns that respect the same principles are usable as well.

Patterns with two parameters

Ansible Patterns allow us to also do operations between two different groups, so we can do:

Complex Patterns

You can also refine your selection, so for instance you could be using


In this case, Ansible is going to run the Playbook on all loadbalancers and fronternd servers in the US that are not in production.

This allows a pretty big level of detail, as you can see, in fact in the end you have a granularity level comparable to the first philosophy granularity, but without the need of painful maintenance.

As you may immagine, you can also mix patterns with one and two parameters like:


In this case, Ansible is going to run the Playbook on all machines that appear under the .example.com in the inventory file, and frontend servers in the US that are not in production.

Regular Expressions

Sometimes simple patterns are not enough, and you want to leverage the power of Regular Expressions. This is possible in Ansible and you can do it specifying a ~ at the begin of the string:


This will match all hosts whose inventory name matches the Regular Expression, such as ws01.example com and db02.example.com.

Select groups at runtime

Sometimes the problem is that we want to create some Playbook that are generic and that can be used with groups chosen at runtime.

In Ansible, you can pass variables instead of explicit group names. So, if we want to create a Playbook that does a specific action on all machines that are hosting a specific application in a specific environment, we can simply write:

'{{ application }}:&{{ environment }}'

Now, setting the proper values for application and environment, we can run this Playbook on any applications and environments.

Leverage limits

Ansible allows us to limit the set of hosts that we are going to target using the --limit option.

You can use the limit option in the following ways:


Ansible Inventories are very flexible and powerful, is properly designed and I hope that this blog post would help designing your Inventories in the best way possible.