Variable names must start with a letter, and they can only contain letters, numbers, and underscores.

The following table illustrates the difference between invalid and valid variable names.

You can define variables in various places in an Ansible project. If you set a variable using the same name in two places, and those settings have different values, Ansible uses the value that has the highest precedence.

The following simplified list shows ways to define an Ansible variable, ordered from the lowest to the highest precedence:

For example, a variable that is set to affect the all inventory group of managed nodes is overridden by a variable that has the same name and is set to affect a single managed node.

One recommended practice is to choose globally unique variable names, so that you do not have to consider precedence rules. However, sometimes you might want to use precedence to cause different managed nodes or managed node groups to get different settings from your defaults.

Precedence order is covered in the Variable Precedence: Where Should I Put a Variable? documentation at https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable.

After you have declared variables, you can use them in tasks. Place the variable name in double braces ({{ }}) to reference the variables. Ansible substitutes the variable with its value when the task is executed.

---
- name: Configuring hostname for IOS managed node
  hosts: iosxe.example.com
  gather_facts: false
  vars:
    router_hostname: rtr01.example.com
  tasks:
    # This line reads: Set the rtr01.example.com hostname
    - name: Set the {{ router_hostname }} hostname
      cisco.ios.ios_hostname:
        config:
          # This line sets the rtr01.example.com hostname for IOS
          hostname: "{{ router_hostname }}"
        state: merged

cisco.ios.ios_interfaces:
  config:
     name: {{ interface_name }}
            ^ here
We could be wrong, but this one looks like it might be an issue with
missing quotes.  Always quote template expression brackets when they
start a value. For instance:

    with_items:
      - {{ foo }}

Should be written as:

    with_items:
      - "{{ foo }}"

You can create a subdirectory named group_vars in the same directory as your Ansible project. In the group_vars subdirectory, create a file for each group in your inventory and then add variables specific to that group of managed nodes:

[user@host project]$ tree -F group_vars/
group_vars/
├── arista.yml
├── ios.yml
└── junos.yml

The above organizational structure makes it easier to locate configuration variables for any of the arista, ios, or junos inventory groups. That structure is sufficient when each inventory group does not contain too many variable definitions. As playbook complexity increases, however, even these files can become long and difficult to understand.

An even better approach for large, diverse environments is to create subdirectories for each inventory group of managed nodes under the group_vars subdirectory, such as the groups_vars/ios/ subdirectory, in your project directory. Ansible parses any YAML or JSON files in these subdirectories and associates the variables with an inventory group based on the parent directory.

For example, you might initially define the ansible_network_os and ansible_connection variables for the ios inventory group in the inventory file:

[ios:vars]
ansible_network_os = cisco.ios.ios
ansible_connection = ansible.netcommon.network_cli

Instead of defining those variables in your inventory file, create a YAML file in the group_vars/ios path in your project directory and the ansible_network_os and ansible_connection variables in the new file:

ansible_network_os: cisco.ios.ios
ansible_connection: ansible.netcommon.network_cli

If you use this organizational structure for variables, then place group variables with a common theme into the same file, and use a file name that indicates that common theme. A project organized according to this convention might appear as follows:

[user@host project]$ tree -F group_vars/
group_vars/
├── all/
│   └── common.yml
├── arista/
│   ├── acl.yml
│   ├── connection.yml
│   └── vlan.yml
├── ios/
│   ├── acl.yml
│   ├── connection.yml
│   ├── security.yml
|   └── vlan.yml
└── junos/
    ├── acl.yml
    ├── connection.yml
    ├── snmp.yml
    └── vlan.yml

With this organizational structure for a project, you can quickly see the variables that are defined for each group of managed nodes.

Ansible merges all the variables present in files in directories under the group_vars directory with the rest of the variables. Separating variables into files grouped by functionality makes the project easier to understand and maintain.

Likewise with inventory groups, you can create a subdirectory named host_vars in your Ansible project directory. Then, create a file named after an inventory managed node with the variable definitions for that managed node.

Variables defined for a managed node have a higher precedence than variables defined for the managed node's inventory group.

The group_vars and host_vars subdirectories can exist not only in your project directory, which is where your playbook is located, but in the directory where your inventory file is located. These two locations might not be the same directory.

For the group_vars and host_vars subdirectories relative to the inventory, the following is true: