The first module Ansible implicitly runs on a playbook is the
setup module, which gathers “facts” about the system (unless you’ve disabled
that with the brand-new
gather_facts: False option in the playbook). We can gather our
own facts by writing modules we invoke explicitly in playbooks.
- We write the module in any language we want: the sole prerequisite is that the module output JSON. (Recall that the module is invoked on the managed node, so the node must have any language-specific modules your module requires installed.)
- Copy the module to the
$ANSIBLE_LIBRARYdirectory on the Ansible manager (or onto each node when using Ansible in pull-mode).
- Add an invocation of our module to our playbooks.
A fact-gathering module really can be written as trivially as something like this:
The example I’m going to show you contains everything I consider important to know about the subject.
It reports facts about the target node:
- Number of files in
/tmpand a constant.
- Reads “contact” information from a file /etc/sysinfo which exists on all nodes. (I provision that file at system installation-time with, say, contact information, what the box is for, etc.)
- The Kerberos keytab name (configurable) and the principals contained therein. (If you’re “into” Kerberos, you may be interested to read how I automatically deploy Kerberos keytabs.)
The JSON string returned by our module looks like this. The
is important, as it triggers Ansible to use the values as facts:
Facts returned by our localsetup module are available to all statements in the playbook just after it’s invoked, so I call it first (well, after setup has been invoked automatically):
If I want to split fact-gathering out into more than one module, I can do that as well, invoking them all in my playbook.
The next action uses the template module with the following template:
and it produces the following output on the machine I ran it against:
I’ve put the module’s source-code and all supporting files on Github for you.