Multiple clients and multiple sub groups

We have a naming convention for both inventories and groups within, and some guidelines.

  • Each inventory source should have a clear purpose.
  • All groups from a given inventory source will start with the same prefix.
  • All sub-groups are named such that it’s obvious which group(s) they are a sub of.
  • Any host should show up only once in a given inventory source.

Problems with that last bullet point indicate that we either haven’t fully articulated our groups in the inventory source, or that we’re mixing inventory purposes - i.e. we’re trying to use one inventory source for two different things, such that we probably need another source at that level.

So if we were looking at your inventory, we’d structure it like this (maybe):
{prefix}_{customer}_{environment}_{tier}
and the whole thing might look like this:

[client_all:children]
client_jack
client_jill

#### jack ####
[client_jack:children]
client_jack_dev
client_jack_prd

[client_jack_dev:children]
client_jack_dev_db
client_jack_dev_web
client_jack_dev_stg

[client_jack_dev_db]
dbdev1

[client_jack_dev_web]
webdev1

[client_jack_dev_stg]
stgdev1

[client_jack_prd:children]
client_jack_prd_db
client_jack_prd_web
client_jack_prd_stg

[client_jack_prd_db]
dbprd1
dbprd2

[client_jack_prd_web]
webprd1
webprd2

[client_jack_prd_stg]
stgprd1

#### jill ####
[client_jill:children]
client_jill_dev
client_jill_prd

[client_jill_dev:children]
client_jill_dev_db
client_jill_dev_web
client_jill_dev_stg

[client_jill_dev_db]
dbdev2

[client_jill_dev_web]
webdev2

[client_jill_dev_stg]
stgdev2

[client_jill_prd:children]
client_jill_prd_db
client_jill_prd_web
client_jill_prd_stg

[client_jill_prd_db]
dbprd3
dbprd4

[client_jill_prd_web]
webprd3
webprd4

[client_jill_prd_stg]
stgprd2

Only we’d use hosts’ FQDNs, For us, {{ inventory_hostname }} always equals {{ ansible_fqdn }} after gathering facts.

About hosts only being listed in one place: If you set up your groups right, then the hosts will always pop into whatever parent groups they should be in. But if they’re listed in multiple places, then every time you add or change a host, you have to examine the whole inventory source’s groups and make a decision about each one. That’s the kind of work computers were supposed to do for us, not the other way around.

This looks overblown for such a small set of hosts, and maybe it is practical to leave out some intermediate groups if you never need them. But if you ever do, it’s clear just from the group names how the hierarchy fits together so you could add them later.

If you take nothing else from our experience, consider this suggestion: Although Ansible allows you to structure your inventory in gajillions of ways besides a strict hierarchy, don’t do it. It’s easy to understand, verify, and maintain a hierarchy, and therefor easy(ish) to see when you mess it up. But if you accidentally build an N-dimensional ad hoc polyfrackus inventory from Mordor, you could get in pretty deep before you realize you’ve created a monster.