Variable Precedence in Ansible

Ansible is a powerful tool for managing infrastructure and automating tasks. It allows you to define variables that can be used throughout your playbooks and roles, making it easy to reuse configuration and logic across multiple tasks and systems. However, when using variables in Ansible, it is important to understand the order in which they are defined, as this determines which value will be used when a variable is defined multiple times. This is known as "variable precedence".

The variable precedence order in Ansible is as follows:

  1. command line values (for example, -u my_user, these are not variables)
  2. role defaults (defined in role/defaults/main.yml)
  3. inventory file or script group vars
  4. inventory group_vars/all
  5. playbook group_vars/all
  6. inventory group_vars/*
  7. playbook group_vars/*
  8. inventory file or script host vars
  9. inventory host_vars/*
  10. playbook host_vars/*
  11. host facts / cached set_facts
  12. play vars
  13. play vars_prompt
  14. play vars_files
  15. role vars (defined in role/vars/main.yml)
  16. block vars (only for tasks in block)
  17. task vars (only for the task)
  18. include_vars
  19. set_facts / registered vars
  20. role (and include_role) params
  21. include params
  22. extra vars (for example, -e "user=my_user")(always win precedence)

Variables with higher precedence will override variables with lower precedence. For example, if a variable is defined in both the inventory file and the playbook file, the value defined in the inventory file will take precedence.


Example 1: Using Extra Vars

Suppose you have a playbook that defines a variable called my_var. You can override this variable using the -e or --extra-vars option when running the playbook, like this:

ansible-playbook my_playbook.yml -e "my_var=foo"

In this case, the value of my_var will be set to foo, regardless of any other variable definitions in the playbook or role files.

Example 2: Using Role Defaults

Suppose you have a role that defines a variable called my_var in the defaults/main.yml file:

# roles/my_role/defaults/main.yml
my_var: default_value

If you use this role in a playbook and don't define my_var anywhere else in the playbook, the value of my_var will be set to default_value.

Example 3: Using Inventory Variables

Suppose you have an inventory file that defines a variable called my_var for a specific host:

# inventory/my_inventory.yml
  my_var: host_value

If you run a playbook that uses my_host as the target, the value of my_var will be set to host_value for that host.

Example 4: Using Block Variables

Suppose you have a playbook that defines a variable called my_var within a block:

- name: My Playbook
  hosts: all
    - block:
        - name: Task 1
            my_var: block_value
        - name: Task 2
            var: my_var
      become: yes

In this case, the value of my_var will be set to block_value within the block, and will be available only to Task 2.

Example 5: Using Registered Variables

Suppose you have a playbook that uses the yum module to install a package, and registers the output using the register keyword:

- name: Install Package
  hosts: all
    - name: Install Package
        name: my_package
        state: present
      register: install_result

    - name: Display Output
        var: install_result

In this case, the output of the yum module is registered as install_result, and can be used in subsequent tasks in the playbook. The value of install_result will be available only to subsequent tasks in the playbook.

These examples illustrate how variable precedence works in Ansible, and how different types of variables are defined and used. By understanding the order in which variables are defined and the context in which they are used, you can ensure that your playbooks and roles are using the correct values for each variable, and avoid unexpected behaviour.