Skip to content

Managing Ansible Facts

Avatar photo

https://www.linkedin.com/in/gineesh/ https://twitter.com/GiniGangadharan

Ansible facts are nothing but some variables which are automatically discovered by the Ansible on managed hosts while running ansible adhoc commands or playbooks.

See Automation with Ansible full chapters.

Ansible Facts Examples

  • Hostname
  • IP Address and Interface details
  • CPU/Memory/Disk space information
  • Kernel and OS info
  • etc

Facts can be used to retrieve system status and take action based on the same. Eg: You can check available memory before installing a software.

Facts are collected via setup module, which will run automatically before the first task in a play; you can see this output as Gathering Facts tasks.

$ ansible servera -m setup

You can also filter facts as below to retrieve only required information.

$ ansible servera.lab.example.com -m setup -a 'filter=ansible_hostname'
servera.lab.example.com | SUCCESS => {
	"ansible_facts": {
    	"ansible_hostname": "servera"
	},
	"changed": false
}

You can also retrieve values as below,

ansible_default_ipv4[‘address’]
ansible_devices[‘vda’][‘partitions’][‘vda1’][‘size’]
ansible_fqdn
ansible_kernel                     # Running kernel version
ansible_interfaces                 # list of interfaces
ansible_dns.nameservers            # list of DNS servers

How to turn off Facts Gathering

If you are not using any facts variables, you can disable Gathering Facts as below.

- hosts: whatever
  gather_facts: no

And you can collect facts at anytime in the playbook by calling setup modules.

  tasks:
    - name: Collect Facts
      setup:

Custom Facts

We can configure custom facts inside the managed hosts and these facts will be retrieved by setup together with ansible facts. Custom facts can be used in managed hosts to control the play based on custom values.

You can setup local custom variables in facts.d directory – /etc/ansible/facts.d. If the directory doesn’t exist, create it. You can also use JSON format for custom facts files.

[root@servera ~]# mkdir /etc/ansible/facts.d -p
[root@servera ~]# cat >custom.facts
myname = localname
value2 = this is value 2

[database]
database_port = 3306

[packages]
db_package = mariadb-server

When Ansible run the setup module, custom facts will be retrieved under ansible_local variable. See examples below.

ansible_local['custom']['database']['database_port']   # this will be 3306
ansible_local['custom']['packages']['db_package']      # this will be mariadb-server

Magic Variables

There are some variables defined by Ansible which are called magic variables. Some examples below.

  • hostvars – contains variables for managed hosts
  • groups – list of all groups and hosts in the inventory
  • group_names – list of all groups the current managed hosts is in
  • inventory_hostname – hostname for the current managed host as configured in the inventory.
$ ansible servera.lab.example.com -m debug -a 'msg={{ groups }}'
servera.lab.example.com | SUCCESS => {
	"msg": {
    	"all": [
        	"servera.lab.example.com"
    	],
    	"ungrouped": [],
    	"webserver": [
        	"servera.lab.example.com"
    	]
	}
}

$ ansible servera.lab.example.com -m debug -a 'msg={{ groups.webserver }}'
servera.lab.example.com | SUCCESS => {
	"msg": [
    	"servera.lab.example.com"
	]
}

Refer : Special Variables Documentation

See Automation with Ansible full chapters.

Disclaimer:

The views expressed and the content shared in all published articles on this website are solely those of the respective authors, and they do not necessarily reflect the views of the author’s employer or the techbeatly platform. We strive to ensure the accuracy and validity of the content published on our website. However, we cannot guarantee the absolute correctness or completeness of the information provided. It is the responsibility of the readers and users of this website to verify the accuracy and appropriateness of any information or opinions expressed within the articles. If you come across any content that you believe to be incorrect or invalid, please contact us immediately so that we can address the issue promptly.

Avatar photo


https://www.linkedin.com/in/gineesh/ https://twitter.com/GiniGangadharan
Gineesh Madapparambath is the founder of techbeatly and he is the co-author of The Kubernetes Bible, Second Edition. and the author of 𝗔𝗻𝘀𝗶𝗯𝗹𝗲 𝗳𝗼𝗿 𝗥𝗲𝗮𝗹-𝗟𝗶𝗳𝗲 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻. He has worked as a Systems Engineer, Automation Specialist, and content author. His primary focus is on Ansible Automation, Containerisation (OpenShift & Kubernetes), and Infrastructure as Code (Terraform). (aka Gini Gangadharan - iamgini.com)

Comments

1 Response

  1. Kim Soon says:

    Great Tutorial…. Easy and Simple 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.