Inventory Variables

ansible_host and ansible_user have been sitting in your inventory since the very first inventory chapter. Here’s the reveal: those aren’t special syntax — they’re ordinary variables, and Ansible just happens to give a handful of specific names (like these two) built-in meaning. Nothing stops you from adding your own.

Inventory Variables Aren’t Just For Connections

Any key you attach to a host in your inventory becomes a variable available to that host, exactly the same mechanism ansible_host and ansible_user already use:

servers:
  hosts:
    ubuntu:
      ansible_host: 10.0.0.1
      ansible_user: alice
      environment_type: staging

- name: Print environment_type
  hosts: servers
  tasks:
    - name: Show it
      ansible.builtin.debug:
        msg: "{{ environment_type }}"

environment_type isn’t an Ansible built-in — it’s just a name we made up, and it works exactly like any other variable the moment it’s referenced.

Adding Variables To A Group

Rather than repeating the same variable on every host, a group-level vars: key applies it to everything in that group:

servers:
  hosts:
    ubuntu:
      ansible_host: 10.0.0.1
      ansible_user: alice
    fedora:
      ansible_host: 10.0.0.2
      ansible_user: alice
  vars:
    environment_type: staging

Both ubuntu and fedora now see environment_type as staging, defined once instead of twice.

host_vars/ And group_vars/ Directories

Just like vars_files let us move a playbook’s variables into their own file, Ansible supports moving inventory variables into their own files too — with one extra convenience: these are loaded automatically, purely by filename, with nothing to reference explicitly anywhere.

host_vars/
  ubuntu.yaml
group_vars/
  servers.yaml

environment_type: staging

backup_enabled: true

Place these directories alongside your inventory file, and Ansible loads host_vars/ubuntu.yaml for the host named ubuntu, and group_vars/servers.yaml for the group named servers, without a single line in inventory.yaml pointing at either one.

Why Move Variables Out Of The Inventory File?

The same motivation as vars_files from the last chapter — keeping structure and data separate. inventory.yaml stays focused on which hosts and groups exist, while host_vars/ and group_vars/ hold the actual configuration data about them. The one genuine structural difference from vars_files: these load automatically by naming convention, with no explicit include needed in any playbook.

A Gotcha: Host Vars Beat Group Vars

Unlike the vars_files-beats-vars surprise from the last chapter, this one matches your intuition: if the same variable is set both on a group and on a specific host within it, the host-level value wins. More specific beats more general — the behavior you’d probably guess without being told.

The sharper gotcha here is different: host_vars/group_vars filenames must match the host or group name exactly. host_vars/Ubuntu.yaml (capitalized) won’t apply to a host named ubuntu — it simply won’t be loaded, silently, with no error telling you it was skipped. A typo in a filename here doesn’t fail loudly; it just quietly leaves that variable undefined.

Best Practices

• Move to host_vars/group_vars once your inventory file starts accumulating more than a couple of inline variables — keep inventory.yaml itself minimal and structural.
• Double-check filenames match host and group names exactly, including case — this fails silently, not loudly, so it’s worth verifying deliberately rather than assuming it worked.
• Remember host-level variables override group-level ones — this is the one variable-precedence rule in this course so far that behaves exactly as you’d expect.