Group and Host Variables

Instead of cramming every variable into the inventory file itself or a single play's vars: block, Ansible automatically loads variables from group_vars/<groupname>.yml (or a directory of that name) and host_vars/<hostname>.yml, placed alongside the inventory file or in the playbook's root directory. group_vars/all.yml applies to every host in the inventory regardless of group membership, while group_vars/webservers.yml applies only to hosts listed under the webservers group, giving you a clean, file-based way to separate broad defaults from environment- or role-specific overrides.

group_vars/webservers can be either a single file, group_vars/webservers.yml, or a directory, group_vars/webservers/, containing multiple files like vars.yml and vault.yml that Ansible merges together — this directory form is the recommended pattern specifically so that non-sensitive variables and vault-encrypted secrets can live in separate files while both apply to the same group. The exact same rule applies to host_vars/web01.yml versus a host_vars/web01/ directory, and Ansible discovers these files automatically based on their location relative to the inventory file, requiring no explicit include_vars statement in the playbook.

Inventory groups can nest via a children: key, so a group like datacenter_east can have webservers and dbservers as child groups, and a host belonging to webservers automatically inherits from both webservers and its ancestor datacenter_east's group_vars. When the same variable is set in two ancestor groups, the group_vars of the more specific (child) group wins over the more general (parent) group, and the special group_vars/all.yml always sits at the bottom, below every named group, since 'all' is the implicit parent of every other group in the inventory.

In a project managing dozens of environments, a common and battle-tested layout keeps group_vars/production/vars.yml and group_vars/production/vault.yml separate from group_vars/staging/vars.yml and group_vars/staging/vault.yml, each pair scoped to its own inventory group, so promoting a change from staging to production means editing one clearly-named file rather than hunting through a monolithic variables file for environment-specific lines. Combined with host_vars/ for the rare per-machine override (like a specific server's unique hostname-derived certificate path), this structure keeps large inventories navigable without sacrificing the ability to override any single value at exactly the right scope.