Ansible: Working with Ansible Facts

One of my most important articles from the RHCE chronicles. Ansible facts. These are the gems of Ansible, which configuration management a breeze. Enjoy!

Let’s talk about #ansible facts. Ansible facts are system properties that are collected when executing a remote system. Ansible facts are stored in a “multivalued variable”; ansible_facts. The facts are basically stored in a dictionary that can be accessed using two formats:

· Notation with brackets: ansible_facts[‘default_ipv4’][‘address’]
· Dotted notation: ansible_facts.default_ipv4.address

Ansible docs recommend we access ansible_facts using the square bracket notation. We can check for ansible facts with multiple methods, such as a playbook using a debug module, or we can use ansible-adhoc commands using the setup module. When I first saw the output of Ansible facts, it was overwhelming at first, which is why I kind of skimmed over this topic. That was a huge mistake because accessing ansible_facts can give us more control over plays that we create. The facts Ansible gathers can be utilized in so many ways, task control, conditionals, and many other aspects to take advantage of. We can also create custom facts for even more control. Below are a few examples of accessing ansible_facts and the task control facts brings to a playbook:

Example 1
· Accessing ansible_facts using debug module

Example 2
· Task control using ansible_facts
· Fail module verifies remote system total RAM before proceeding

This was an example that was overwhelming at first, especially since the playbook has multiple conditions and task control, such as the fail module, block & rescue, and handlers.

In conclusion:

This is a subject that should be etched into your mind when learning Ansible. Most of our configuration management will be derived from the facts from the remote systems.