Let us talk more about ansible variables precedence rules. At Bobcares with the support of Server management support services we can give you a detailed overview of Ansible Precedence.

Controlling how Ansible behaves: precedence rules

Ansible provides a variety of controls to manage how it behaves, including how it connects to managed nodes and how it operates while connected, to allow administrators the greatest freedom possible when controlling environments.

We can define Ansible behavior in several locations and pass it to Ansible in various ways if we use it to manage a large number of servers, network devices, and cloud services. This flexibility is useful, but it could backfire if we don’t grasp the precedence rules.

Any setting that describes a variety of ways is subject to these precedence guidelines (by configuration settings, command-line options, playbook keywords, and variables).

Precedence categories

There are four ways to manage Ansible’s behavior. The following categories in ascending order of importance, from lowest (most easily overridden) to greatest (overrides all others):

• Configuration settings
• Command-line options
• Playbook keywords
• ansible variables precedence

Any information from any category with a lower priority is overridden by that category. A playbook keyword, for instance, will take precedence over any configuration option.

There are particular rules that apply to each precedence group. However, usually speaking, the term that was most recently defined prevails and takes precedence.

Configuration settings: ansible variables precedence

Configuration parameters cover both ansible.cfg file values and environment variables. Within this category, configuration file values take precedence.

Ansible uses the first ansible.cfg file it encounters, disregarding all others.. Ansible looks for ansible.cfg in the following locations, in this order:

• ANSIBLE_CONFIG (environment variable if set)
• ansible.cfg (in the current directory)
• ~/.ansible.cfg (in the home directory)
• /etc/ansible/ansible.cfg

Environment variables take precedence over ansible.cfg entries. Environment variables placed on the control node override the values in the ansible.cfg file that Ansible loads.

The value of each given environment variable is determined by regular shell precedence; the most recently defined value overwrites earlier values.

Command-line options

When we type something directly at the command line, we may believe that the hand-crafted values should take precedence over all others, however, Ansible does not operate in this manner.

Command-line arguments have little precedence; they only override settings. They do not override playbook keywords, inventory variables, or playbook variables.

We can use -e extra variables at the command line to override all other settings from all other sources in all other precedence categories, but that is not a command-line option; it is a method of supplying a variable.

If we send numerous values to a parameter that only allows one, the last declared value prevails at the command line. This ad hoc task, for example, will connect as carol rather than mike:

ansible -u mike -m ping userhost -u carol

Some parameters have many value options. Ansible will append all values from the hosts indicated in inventory files inventory1 and inventory2 in this case: (Please remove ‘User’)

ansible -i /userpath/inventory1 -i /userpath/inventory2 -m ping all

Each command-line tool’s help file lists the possible options for that tool.

Playbook keywords

Any playbook keyword will take precedence over any command-line argument or configuration setting. Within playbook keywords, precedence follows the playbook; the more specialized triumphs over the more general:

• play (most general)
• blocks/includes/imports/roles (optional and can contain tasks and each other)
• tasks (most specific)

Here’s an easy example:

hosts: all
connection: ssh
tasks:
- name: This task uses ssh.
ping:
- name: This task uses paramiko.
connection: paramiko
ping:


At the play level, the connection keyword is set to ssh in this example. That value is sent down to the first task, which connects through ssh. The second task inherits that value, overrides it, and uses paramiko to connect.

The same reasoning applies to blocks and roles. Within a play, all tasks, blocks, and roles inherit play-level keywords; any task, block, or role can override any keyword by setting a new value for that keyword within the task, block, or role.

Please keep in mind that these are KEYWORDS, not variables. In YAML, both playbooks and variable files are defined, although they serve different purposes. Variables are data that we utilize to help make playbooks more dynamic.

Variables

Connection variables are variables that have comparable playbook keywords, command-line options, and configuration settings. Originally intended for connection parameters, this category has grown to contain additional important variables such as the temporary directory and the Python interpreter.

Connection variables, like other variables, can be set in a variety of ways and locations. In inventory, we can define variables for hosts and groups. We can define Variables for jobs and plays in vars: blocks in playbooks.

They are, however, variables – data, not keywords or configuration settings. Variables that override playbook keywords, command-line arguments, and configuration settings are subject to the same variable precedence rules as other variables.

Variables in a playbook obey the same inheritance rules as playbook keywords. We can assign a value to the game and then override it in a task, block, or role:

- hosts: cloud
gather_facts: false
become: yes
vars:
ansible_become_user: admin
tasks:
- name: This task uses admin as the become user.
dnf:
name: some-service
state: latest
- block:
- name: This task uses service-admin as the become user.
- name: This task also uses service-admin as the become user, defined in the block.
vars:
ansible_become_user: service-admin
- name: This task (outside of the block) uses admin as the become user again.
service:
name: some-service
state: restarted

Precedence order

Ansible defines the precedence order as follows:

1. Extra vars (from the command line) always triumph.
2. Task vars (only for the specific task).
3. Block vars (only for the tasks within the block).
4. Role and include vars.
5. Vars created with set_fact.
6. Vars created with the register task directive.
7. Play vars_files.
8. Play vars_prompt.
9. Play vars.
10. Host facts.
11. Playbook host_vars.
12. Playbook group_vars.
13. Inventory host_vars.
14. Inventory group_vars.
15. Inventory vars.
16. Role defaults.

[Need assistance with similar queries? We are here to help]

Conclusion

To conclude we have now learned more about ansible variables’ precedence and the configurations associated with it from the variables to precedence order with the assistance of our server management support services.