Ansible Facts

Ansible Facts
Techiio-author
Written by Nilima PaulJanuary 23, 2022
11 min read
Ansible
0 VIEWS 0 LIKES 0 DISLIKES SHARE
0 LIKES 0 DISLIKES 0 VIEWS SHARE
Techiio-author
Nilima Paul

Technology Security Analyst

We will know in this article, what's the Ansible Facts.

Introduction to Ansible Facts

Ansible realities are the data of remote hosts which is assembled by the Ansible regulator. This data is put away in predefined factors on the regulator hub and the entire arrangement of this data is ready in JSON design. This is a vital component as we can settle on choices concerning which assignment is to perform on which remote machine gave these realities.

Additionally, when you are playing with continuous information, this is helpful to get these realities and use them in playbooks as factors. This data can be the hostname, IP address, macintosh address, introduced OS-related data, the current status of the machine, and so forth

Explaining Ansible Facts

Ansible realities are assembled utilizing the arrangement module, which runs behind the scenes without fail. Yet, this can be turned off by utilizing referencing gather_facts: no in the playbook. We can run an arrangement module and register the result in a variable, the entire arrangement of data will be on JSON design, assuming you want a snippet of data from this set, you can dismantle that and utilize this piece as it were.

The set of facts which is gathered from remote hosts can be divided into three categories:

  • List: This is the list of items. This can be a list of interfaces etc. The information inside lists is placed in square brackets [].
  • Dictionary: This is the collection of key pair values, the information inside the dictionary is placed in curly brackets {}.
  • Ansible unsafe text: Which is a variable, holding value and there is no subpart of

A little scrap of the accumulated realities is beneath. Here you can see, data of remote-have is accumulated and put in factors like in ansible_all_ipv4_addresses variable which will get all our IPv4 addresses.

Likewise, note that a few realities contain values in [] like ansible_all_ipv4_addresses which implies it is a List, a few factors like ansible_apparmor have data in {} and that implies it is a word reference and some are putting esteems after the colon (:) like ansible_architecture which implies it is ansible risky text classification.

ansible host-one –m setup

blogpost

To get the category of a fact use a filter type_debug, which will tell whether your variable/fact is a List, a Dictionary, or an Ansible unsafe text. To check this, create a playbook like the below:

---
- hosts:
all
tasks:
- set_fact:
check_category: "{{ ansible_hostname|type_debug }}"
- debug:
msg: 'Variable "ansible_hostname" with value "{{ ansible_hostname }}" have category "{{ check_category }}"'

Then execute it, you will get the output like below, where you can see the category of fact ansible_hostname

ansible-playbook ansible_fact_category_check.yaml

blogpost

How are Facts Done in Ansible?

Ansible facts are fetched from remote hosts using a setup module that runs automatically every time, if not disabled. This can be done by running the setup module on the command line using the Adhoc method or by default in a playbook.

Ad hoc method

Run the below command on the Ansible controller node to get all available facts.

ansible host-one -m setup

Also, the same is possible by running below the ad-hoc command.

ansible all -m gather_facts --tree /tmp/facts

Also, if you need to show only a specific fact, then you can use like below:

ansible host-two -m setup -a "filter=ansible_mounts"

The output will belong in JSON format. Like below.

blogpost

Playbook method

If you have a playbook like below where we have not mentioned the setup module.

---
- hosts:
all
tasks:
- debug:
var: ansible_architecture

After running it. In the output, you will see that we get the variable ansible_architecture value.

ansible-playbook ansible_fact.yaml

blogpost

But if you mention gather_facts: no like below.

---
- hosts: all
gather_facts:
no tasks:
debug:
var: ansible_architecture

Then you will see, in output, the variable ansible_architecture will be shown as not defined.

ansible-playbook ansible_fact.yaml

blogpost

Examples of Ansible Facts

Presently by utilizing models, we will attempt to find out with regards to ansible realities, which you may need to use in everyday activities. We will take a few models, yet priobeforeng there, we initially comprehend our lab utilized for testing reasons.

Here we have an Ansible control server named ansible-regulator and two controllers have named have one and host-two. We will make playbooks run Ansible orders on the ansible-regulator hub and deal with the clients on remote hosts. The following are a few specially appointed orders which are not difficult to utilize yet not reusable like playbooks.

To get a fact by using filter and setup:

ansible all -m setup -a "filter=ansible_distribution"

The output will be like below:

ansible all -m setup -a "filter=ansible_distribution"

blogpost

To get all facts related to a keyword like a processor, memory, product, etc. We can make use of wildcard characters like below: –

ansible all -m setup -a "filter=ansible_processor*"

The output will be like below:

blogpost

You can utilize gather_subset, to get just realities connected with a subject. Subset's name can be all, min, equipment, organization, virtual, ohai, and factor. If interjection sign (!) is put as introductory to a subset, that subset's realities won't be brought. Like in the underneath model, where we will get just virtual subset related realities and by utilizing the! all, !min, we are not permitting even default least realities.

ansible host-one -m setup -a 'gather_subset=virtual,!all,!min'

The output will be like below:

blogpost

In the beneath model, we will utilize a condition, wherein we will check reality esteem on remote hosts, and afterward founded on that esteem our condition will permit exthe ecution of assignments.

Here, we need to make a record just to having one, so we take a look at utilizing ansible realities that if ansible_hostname has a worth equivalent to having one. On the off chance that that is valid, the record will be made and for other remote has, the activity will be skipped.

---
hosts:
all
tasks:
name: When hostname is host-one, create a file named example.ini under /tmp file:
path:
/tmp/example.ini
state: touch
when: ansible_hostname == "host-one"
name: This is under debug to ensure it was checked on all remote hosts debug:
msg: Hostname is "{{ ansible_hostname }}"

The output will be like below:

ansible-playbook ansible_fact_condition.YAML

blogpost

Conclusion

Ansible truth is a valuable apparatus. Which will run and assist you with social affair data from your remote hosts? In any case, you might recognize that on the off chance that you have a lot of hosts to be overseen by Ansible, gathering realities and not utilizing these realities will just add weight to your transfer speed and handling limit. So better examination first that whether or not you really want realities and afterward utilize these appropriately.

Ansible
Ansible Facts
ubuntu
0 VIEWS 0 LIKES 0 DISLIKES SHARE
0 LIKES 0 DISLIKES 0 VIEWS SHARE
Was this blog helpful?
techiio-price-plantechiio-price-plantechiio-price-plantechiio-price-plantechiio-price-plan
You must be Logged in to comment
Code Block
Techiio-author
Nilima Paul
Technology Security Analyst
Techiio-followerTechiio-followerTechiio-follower
201 Blog Posts
0 Discussion Threads
Trending Technologies
15
Software91
DevOps48
Frontend Development24
Backend Development20
Server Administration17
Linux Administration28
Data Center24
Sentry24
Terraform23
Ansible83
Docker70
Penetration Testing16
Kubernetes21
NGINX20
JenkinsX17
Techiio-logo

Techiio is on the journey to build an ocean of technical knowledge, scouring the emerging stars in process and proffering them to the corporate world.

Follow us on:

Subscribe to get latest updates

You can unsubscribe anytime from getting updates from us
Developed and maintained by Wikiance
Developed and maintained by Wikiance