Beyond Facts: Retrieving AWS Resource IDsSun, Feb 11, 2018
I’m a huge fan of Ansible and I’ve made use of it in several projects to orchstrate AWS services. Ansible is designed to be simple, with most functionality contained in modules which are callable via tasks in playbooks. This has huge benefits, but also bears the major drawback of significant boilerplate when you need to retrieve data from external sources.
From the beginning, Ansible has had a dynamic inventory facility to allow host data to be dynamically imported from sources like AWS, but although this is undergoing great improvements in Ansible 2.5, does not yet provide a way to retrieve arbitrary data which is commonly used when interacting with AWS services. Specifically, if you want to retrieve VPC, subnet or security group details, you are forced to do this with facts modules. When you have a large number of these resources, this quickly becomes unwieldy and repetitive.
I was determined to find a better way. I experimented with various plugin types available in Ansible, but most of these are designed to manipulate existing data, or to perform once off lookups. Nothing really lends itself to mass-lookup of large data sets. I also wanted to do this automatically - since almost every playbook interacts with one or more AWS services this would have a massive payoff. Enter the widely underused (and underdocumented) Vars Plugins.
Creating a vars plugin turns out to be surprisingly straightforward. First you need to configure a directory (or directories) for vars plugins. This can be done in
ansible.cfg, but since there might be an existing default here, I wanted to supplement whatever might already be configured. Like many Ansible configuration values, a vars plugins directory can also be specified via an environment variable:
ANSIBLE_VARS_PLUGINS. You can export this in your wrapper script(s), set it in your shell rc, CI tool, or wherever/however you use Ansible.
I prefer to keep everything together for a project, so I set this to the
vars_plugins/ directory, relative to the playbooks for a project. Once this is set, you need only place Python scripts in this directory, with each one describing a VarsModule class. Here’s what an empty vars module looks like.
Ramping this up pretty quickly, here’s how you’d retrieve VPC IDs and populate a glocal dictionary variable keyed by VPC name.
This uses Boto3 to connect to EC2 and retrieve a list of VPCs, then parses the list and builds a dictionary indexed by Name tag values. In the
get_vars() method, we return a dictionary of variables to set, and Ansible kindly obliges and makes these dictionary values available as variables on all hosts.
We can extend this to also retrieve subnet IDs.
Just as with VPCs, we’re now retrieving subnet details and making a variable
subnets available to playbooks for all hosts. We can make use of these super-handy variables with something like this:
Note how we’re specifying the subnet in which to launch this instance by looking up the subnet ID in our global
subnet_ids variable. We don’t have to use ec2_vpc_subnet_facts to explicitly look up the subnet, it’s just done in the background by the plugin.
You can see the potential for vastly simplifying playbooks. Wherever we need an AWS resource ID, we can add the ability for our plugin to look it up transparently, and totally avoid a facts module call each time.
I took this concept further and built a more comprehensive plugin, which is published on GitHub. It adds some nice features like caching lookup results, reading a configuration file for multi-region support and is able to parse any tag values to build a nested dictionary for each type of AWS resource it supports.