When using Ansible to consume APIs such as cloud services, the
logic runs from the controller machine. As a result, people tend
to think that as this runs locally, using hosts: localhost is
the best option.
In reality, using localhost as your host loses you a lot of power.
To avoid this, we can use a ‘runner’ pattern, where a runner
is a local target on which you can hang inventory.
In our environment we tend to be either managing whole environments (e.g. provisioning an entire network) and infrastructure components within them (load balancers, database servies) or specific applications.
For environments, we might have a hierarchy that looks a little like:
[non_prod_account:children]
dev
test
[dev:children]
dev-runner
[test:children]
test-runner
[runner:children]
dev-runner
test-runner
or, in picture form:
That way, when we use hosts: test-runner we can pick up all the
inventory associated with the test group - the CIDR prefix of networks,
the tag to use for Environment, DNS zones, and many many other things
(in reality a lot of our variables come from the all group but with
the env property used in populating variables - so our VPC name
is {{ env }}-{{ cidr_prefix }}.
To avoid needing to add connection: local to plays using runners,
create a runner group vars file (e.g. inventory/group_vars/runners)
and add ansible_connection: local.
With applications, and the right inventory structure, we can do things like create all the loadbalancers with:
- hosts: application:&{{ env }}:&runner
connection: local
roles:
- loadbalancer
Each application group contains a (possibly empty) list of loadbalancers,
each item in the list containing the configuration used when calling
something like elb_application_lb module.
Using the runner pattern allows us to avoid a whole bunch of variable files, and structure inventory in a logical hierarchical fashion, making use of inheritance to minimise repetition of data.
One disadvantage of the runner pattern is that it creates a ridiculous combinatorial explosion of hosts and groups in inventory files. In my next post, I’ll show a very simple solution to that.
Oh, and ansible-inventory-grapher is currently working reasonably well against Ansible 2.4 at last (I need to tidy some magic variables from the host before it’s totally ready for release, but it’s on the ansible-2.4 branch if you’re keen)