Facts about network devices contribute to the information that you need to keep the example.com network running smoothly.
In later exercises, you will build plays that use facts to perform actions; to clear layer 3 addresses from interfaces, for instance.
In Chapter 4, Administering Ansible, you removed the need for each invocation to pass the SSH credentials to the managed nodes in order for ansible-playbook to run.
If you did not complete the section called “Guided Exercise: Safeguarding Sensitive Data with Ansible Vault”, do it now, because this and later lessons assume that it is done.
Some exercises in this chapter presume a new structure for group_vars, for which you can refer to the section called “Guided Exercise: Identifying Resources for Installed Plug-ins”.
In this exercise, you will gather and process facts.
Outcomes
You should be able to:
Examine the default set of facts returned by the vyos and ios instances of os_facts.
Examine the full set of facts returned by the vyos and ios instances of os_facts.
Recognize and understand differences between fact subsets, and how to interpret and make use of the data returned by facts modules.
Compose and run a playbook that displays specific facts.
Open a terminal window on the workstation VM and change to the proj/ directory.
Examine the default set of facts returned by the vyos and ios instances of os_facts.
Execute this ad hoc command to display the default set of facts returned for a host by the vyos_facts module.
[student@workstation proj]$ansible -m vyos_facts spine01spine01 | SUCCESS => { "ansible_facts": { "ansible_net_gather_subset": [ "neighbors", "default" ], "ansible_net_hostname": "vyos", "ansible_net_model": "OpenStack", "ansible_net_serialnum": "00000000-0000-0000-0000-ac1f6bc7ee96", "ansible_net_version": "VyOS" }, "changed": false }
Execute this ad hoc command to display the default set of facts returned for a host by the ios_facts module.
[student@workstation proj]$ansible -m ios_facts cs01
Examine the full set of facts returned by the vyos and ios instances of os_facts.
Execute this ad hoc command to display the full set of facts available under vyos_facts.
[student@workstation proj]$ansible -m vyos_facts -a 'gather_subset=all' spine01
Execute this ad hoc command to display the full set of facts available under ios_facts.
[student@workstation proj]$ansible -m ios_facts -a 'gather_subset=all' cs01
Recognize and understand differences between fact subsets, and how to interpret and make use of the data returned by facts modules.
What differences did you notice in the results returned by the four commands?
All four commands return data in JSON format.
The ios_facts module returns interface data in both default mode and all facts mode, but interface data is not provided by vyos_facts even when the all subset is requested.
Both the ios_facts and vyos_facts modules return an ansible_net_config variable only when gather_subset=all is specified.
Running ansible-doc ios_facts and ansible-doc vyos_facts tells us this about ansible_net_config (ansible-doc returns the same information about ansible_net_config for both modules):
ansible_net_config: description: The current active config from the device returned: when config is configured type: string
Run ansible-doc vyos_facts and review the EXAMPLES section.
[student@workstation proj]$ansible-doc vyos_facts...output omitted... EXAMPLES: - name: collect all facts from the device vyos_facts: gather_subset: all - name: collect only the config and default facts vyos_facts: gather_subset: config - name: collect everything exception the config vyos_facts: gather_subset: "!config"
Now we know that config is defined as a subset, which makes it easy to either include or exclude the configuration data.
The ios_config documentation mentions that the ios_config module has a subset named hardware, so we can gather or ignore hardware facts.
This illustrates the following:
A great deal of data can be gathered by way of facts.
The fact-gathering mechanism is flexible, with the ability to gather or not gather fact subsets based on your needs.
The ansible-doc command provides information that helps to make sense of what facts are available, how to manage your access to facts, data types of facts, and details about the nature of specific ones.
Compose and run a playbook that displays specific facts.
Start by converting the vyos all facts ad hoc command into a playbook named vyos-all-facts1.yml.
Set the value of hosts to vyos.
It is convenient to work with a single host while developing a playbook and becoming familiar with its behavior, and the --limit option makes it easy to do this.
With this initial version of the playbook, the objective is simply to gather facts, register the data that is returned as a variable, and use the debug module to display what we have.
[student@workstation proj]$cat vyos-all-facts1.yml--- - name: gather all facts from a particular vyos machine hosts: vyos vars: subset: all tasks: - name: invoke vyos_facts with gather_subset=all vyos_facts: gather_subset: "{{ subset }}" - debug: var: ansible_facts
Run the vyos-all-facts1.yml playbook, using the --limit option (-l) to limit the play to spine01.
[student@workstation proj]$ansible-playbook -l spine01 vyos-all-facts1.ymlPLAY [gather all facts from a particular vyos machine] ************************* TASK [invoke vyos_facts with gather_subset=all] ******************************** ok: [spine01] TASK [debug] ******************************************************************* ok: [spine01] => { "ansible_facts": { "net_commits": [ { "by": "root", "comment": null, "datetime": "2020-07-31 06:56:50 ", ...output omitted... PLAY RECAP ********************************************************************* spine01 : ok=2 changed=0 unreachable=0 failed=0
Make a copy of vyos-all-facts1.yml named vyos-some-facts1.yml and use it for editing.
[student@workstation proj]$cp vyos-all-facts1.yml vyos-some-facts1.yml
Edit the vyos-some-facts1.yml playbook.
Change the subset that is gathered from all to default.
When you ran the ad hoc command that displayed the default set of facts returned by vyos_facts, it listed in the output four facts: ansible_net_hostname, ansible_net_model, ansible_net_serialnum, and ansible_net_version.
Include a debug task in vyos-some-facts1.yml that displays those four facts.
[student@workstation proj]$cat vyos-some-facts1.yml--- - name: gather some facts from a particular vyos machine hosts: vyos vars: subset: default tasks: - name: invoke vyos_facts with gather_subset=all vyos_facts: gather_subset: "{{ subset }}" - debug: msg: - "Host name: {{ ansible_net_hostname }}" - "Model: {{ ansible_net_model }}" - "Version: {{ ansible_net_version }}" - "SerialNum: {{ ansible_net_serialnum }}"
Execute the ansible-playbook command to perform the play in vyos-some-facts1.yml playbook.
[student@workstation proj]$ansible-playbook -l spine01 vyos-some-facts1.ymlPLAY [gather some facts from a particular vyos machine] ************************ TASK [invoke vyos_facts with gather_subset=all] ******************************** ok: [spine01] TASK [debug] ******************************************************************* ok: [spine01] => { "msg": [ "Host name: vyos", "Model: OpenStack", "Version: VyOS", "SerialNum: 00000000-0000-0000-0000-ac1f6bc7ee96" ] } PLAY RECAP ********************************************************************* spine01 : ok=2 changed=0 unreachable=0 failed=0
This concludes the guided exercise.