Using host groups

There is rarely one playbook that will suit an entire infrastructure, and although it is easy to tell Ansible to use an alternate inventory for a different playbook, this could get very messy, very quickly, with potentially hundreds of small inventory files dotted around your network. You can imagine how quickly this would get unmanageable, and Ansible is supposed to make things more manageable, not the opposite. One possible simple solution to this is to start adding groups into your inventories.

Let's assume you have a simple three-tier web architecture, with multiple hosts in each tier for high availability and/or load balancing. The three tiers in this architecture might be the following:

• Frontend servers
• Application servers
• Database servers

With this architecture set out, let's set about creating an inventory for it, again mixing up the YAML and INI formats to give you experience in both. To keep the examples clear and concise, we'll assume that you can access all servers using their Fully Qualified Domain Names (FQDNs), and hence won't add any host variables into these inventory files. There is nothing to stop you from doing this of course, and every example is different.

Let's, first of all, create the inventory for the three-tier frontend using the INI format. We will call this file hostsgroups-ini, and the contents of this file should look something like this:

loadbalancer.example.com

[frontends]
frt01.example.com
frt02.example.com

[apps]
app01.example.com
app02.example.com

[databases]
dbms01.example.com
dbms02.example.com

In the preceding inventory, we have created three groups called frontends, apps, and databases. Note that, in INI-formatted inventories, group names go inside square braces. Under each group name goes the server names that belong in each group, so the preceding example shows two servers in each group. Notice the outlier at the top, loadbalancer.example.com—this host isn't in any group. All ungrouped hosts must go at the very top of an INI-formatted file. 

Before we proceed any further, it's worth noting that inventories can also contain groups of groups, which is incredibly useful for processing certain tasks by a different division. The preceding inventory stands in its own right, but what if our frontend servers are built on Ubuntu, and the app and database servers are built on CentOS? There will be some fundamental differences in the ways we handle these hosts—for example, we might use the apt module to manage packages on Ubuntu and the yum module on CentOS.

We could, of course, handle this case using facts gathered from each host as these will contain the operating system details. We could also create a new version of the inventory, as follows:

loadbalancer.example.com

[frontends]
frt01.example.com
frt02.example.com

[apps]
app01.example.com
app02.example.com

[databases]
dbms01.example.com
dbms02.example.com

[centos:children]
apps
databases

[ubuntu:children]
frontends

With the use of the children keyword in the group definition (inside the square braces), we can create groups of groups; hence, we can perform clever groupings to help our playbook design without having to specify each host more than once.

This structure in INI format is quite readable but takes some getting used to when it is converted into YAML format. The code listed next shows the YAML version of the preceding inventory—the two are identical as far as Ansible is concerned, but it is left to you to decide which format you prefer working with:

all:
  hosts:
    loadbalancer.example.com:
  children:
    centos:
      children:
        apps:
          hosts:
            app01.example.com:
            app02.example.com:
        databases:
          hosts:
            dbms01.example.com:
            dbms02.example.com:
    ubuntu:
      children:
        frontends:
          hosts:
            frt01.example.com:
            frt02.example.com:

You can see that the children keyword is still used in the YAML-formatted inventory, but now the structure is more hierarchical than it was in the INI format. The indentation might be easier for you to follow, but note how the hosts are ultimately defined at quite a high level of indentation—this format could be more difficult to extend depending on your desired approach.

When you want to work with any of the groups from the preceding inventory, you would simply reference it either in your playbook or on the command line. For example, in the last section we ran, we can use the following:

$ ansible -i /etc/ansible/my_inventory.yaml all -m shell -a 'echo hello-yaml' -f 5

Note the all keyword in the middle of that line. That is the special all group that is implicit in all inventories and is explicitly mentioned in your previous YAML example. If we wanted to run the same command, but this time on just the centos group hosts from the previous YAML inventory, we would run this variation of the command:

$ ansible -i hostgroups-yml centos -m shell -a 'echo hello-yaml' -f 5
app01.example.com | CHANGED | rc=0 >>
hello-yaml
app02.example.com | CHANGED | rc=0 >>
hello-yaml
dbms01.example.com | CHANGED | rc=0 >>
hello-yaml
dbms02.example.com | CHANGED | rc=0 >>
hello-yaml

As you can see, this is a powerful way of managing your inventory and making it easy to run commands on just the hosts you want to. The possibility of creating multiple groups makes life simple and easy, especially when you want to run different tasks on different groups of servers.

As an aside to developing your inventories, it is worth noting that there is a quick shorthand notation that you can use to create multiple hosts. Let's assume you have 100 app servers, all named sequentially, as follows:

[apps]
app01.example.com
app02.example.com
...
app99.example.com
app100.example.com

This is entirely possible, but would be tedious and error-prone to create by hand and would produce some very hard to read and interpret inventories. Luckily, Ansible provides a quick shorthand notation to achieve this, and the following inventory snippet actually produces an inventory with the same 100 app servers that we could create manually:

[apps]
app[01:100].prod.com

It is also possible to use alphabetic ranges as well as numeric ones—extending our example to add some cache servers, you might have the following:

[caches]
cache-[a:e].prod.com 

This is the same as manually creating the following:

[caches]
cache-a.prod.com
cache-b.prod.com
cache-c.prod.com
cache-d.prod.com
cache-e.prod.com 

Now that we've completed our exploration of the various static inventory formats and how to create groups (and indeed, child groups), let's expand in the next section on our previously brief look at host variables.