Using static groups with dynamic groups

Of course, the possibility of mixing inventories brings with it an interesting question—what happens to the groups from a dynamic inventory and a static inventory if you define both? The answer is that Ansible combines both, and this leads to an interesting possibility. As you will have observed, our Cobbler inventory script produced an Ansible group called webservers from a Cobbler profile that we called webservers. This is common for most dynamic inventory providers; most inventory sources (for example, Cobbler and Amazon EC2) are not Ansible-aware and so do not offer groups that Ansible can directly use. As a result, most dynamic inventory scripts will use some facet of information from the inventory source to produce groupings, the Cobbler machine profile being one such example.

Let's extend our Cobbler example from the preceding section by mixing a static inventory. Suppose that we want to make our webservers machines a child group of a group called centos so that we can, in the future, group all CentOS machines together. We know that we only have a Cobbler profile called webservers, and ideally, we don't want to start messing with the Cobbler setup to do something solely Ansible-related.

The answer to this is to create a static inventory file with two group definitions. The first must be the same name as the group you are expecting from the dynamic inventory, except that you should leave it blank. When Ansible combines the static and dynamic inventory contents, it will overlap the two groups and so add the hosts from Cobbler to these webservers groups.

The second group definition should state that webservers is a child group of the centos group. The resulting file should look something like this:

[webservers]

[centos:children]
webservers

Now let's run a simple ad hoc ping command in Ansible to see how it evaluates the two inventories together. Notice how we will specify the centos group to run ping against, instead of the webservers group. We know that Cobbler has no centos group because we never created one, and we know that any hosts in this group must come via the webservers group when you combine the two inventories, as our static inventory has no hosts in it. The results will look something like this:

$ ansible -i static-groups-mix-ini -i cobbler.py centos -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"
}

As you can see from the preceding output, we have referenced two different inventories, one static and the other dynamic. We have combined groups, taking hosts that only exist in one inventory source, and combining them with a group that only exists in another. As you can see, this is an incredibly simple example, and it would be easy to extend this to combine lists of static and dynamic hosts or to add a custom variable to a host that comes from a dynamic inventory.

This is a trick of Ansible that is little known but can be very powerful as your inventories expand and grow. As we have worked through this chapter, you will have observed that we have been very precise about specifying our inventory hosts either individually or by group; for example, we explicitly told ansible to run the ad hoc command against all hosts in the webservers group. In the next section, we will build on this to look at how Ansible can manage a set of hosts specified using patterns.