Ranges, aliases and connection variables · Ansible

Two mechanisms in this lesson, and they solve opposite problems.

Ranges compress a regular fleet into one line. Aliases and connection variables handle the irregular hosts that a range cannot describe — the one on a non-standard port, the one behind a bastion, the one whose name in your head is not the name DNS knows.

Between them they cover almost everything a static inventory needs to say about how to reach a host, as distinct from what to do to it.

Ranges

Three forms, and all three are worth knowing because you will meet all three in inherited repositories.

[webservers]
web[01:04].example.com

[oddweb]
node[01:07:2].example.com

[shards]
db-[a:d].example.com

Read-only / Safeexactly what those three lines expand to— Real output from ansible-core 2.21.3. Three inventory lines became twelve hosts. Read the second group carefully - the stride form produced four hosts, not seven.

$ ansible-inventory -i inventory/hosts.ini --graph

@all:
|--@ungrouped:
|--@webservers:
|  |--web01.example.com
|  |--web02.example.com
|  |--web03.example.com
|  |--web04.example.com
|--@oddweb:
|  |--node01.example.com
|  |--node03.example.com
|  |--node05.example.com
|  |--node07.example.com
|--@shards:
|  |--db-a.example.com
|  |--db-b.example.com
|  |--db-c.example.com
|  |--db-d.example.com

The rules the output demonstrates:

[01:04] is inclusive at both ends. Four hosts, not three. This differs from most programming languages you know, and it is the single commonest range mistake.
Leading zeros are preserved. [01:04] gives web01; [1:4] gives web1. The width of the first number sets the padding, so the hostnames match whatever your naming convention actually is.
[01:07:2] is start, end, stride. It produced the odd numbers from 1 to 7. This form is rare and almost always a sign that the inventory is encoding something — alternating racks, odd and even power feeds — that would be clearer as two explicit groups.
[a:d] walks the alphabet, also inclusive.

A range asserts that hosts exist; it does not check

web[01:50].example.com creates fifty inventory entries whether or not fifty machines exist. Nothing resolves a name or tests reachability at parse time.

The two failure directions are asymmetric, in the same way as a hostname typo.

If the range is too large — you have forty machines and wrote fifty — the extra ten fail to connect and appear as unreachable in the recap. Visible, and self-correcting once someone reads the output.

If it is too small — you have sixty and wrote fifty — ten production hosts are absent from every play that targets the group. The run succeeds. The recap is clean. Those ten drift for as long as it takes someone to notice, and the only way to notice is to compare the inventory against reality deliberately.

A range is a compression of a list you believe in. Reconciling that belief against the actual fleet is the subject of the inventory source-of-truth lesson in the next part; here, the point is that the inventory will never do it for you.

Aliases: the name and the address are different things

An inventory host name does not have to resolve. You can name a host whatever is useful and tell Ansible separately where to connect:

[edge]
edge1 ansible_host=192.0.2.11
edge2 ansible_host=192.0.2.12

Read-only / Safethe alias and its address— Real output from ansible-core 2.21.3. --graph --vars shows each host with the variables in effect. edge1 is a label; ansible_host is where the connection actually goes.

$ ansible-inventory -i inventory/hosts.ini --graph edge --vars

@edge:
|--edge1
|  |--{ansible_host = 192.0.2.11}
|--edge2
|  |--{ansible_host = 192.0.2.12}

The alias — edge1 — is what appears in the recap, in --limit, in group_vars filenames and in log output. ansible_host is where the SSH connection goes. They are entirely independent.

This is genuinely useful for:

Hosts with no DNS, or with DNS that is wrong, or that is right only from inside a network you are not in.
Naming by role rather than by hostname, so the recap reads db-primary instead of pgsql-prod-euw1-0447a.internal.
Two entries for the same machine reached by different paths — one via a bastion, one direct — which is occasionally the honest way to express a dual-homed host.

It is also a way to make an inventory lie convincingly, which is why the alias should be more meaningful than the hostname, never less.

The connection variables

Four variables carry most of the “how do I reach this” burden.

inventory/hosts.ymlThe behavioural inventory variables, with the operational reason each belongs in inventory rather than in a play.

ansible_host: ansible_host: 203.0.113.9
ansible_port: ansible_port: 2222
ansible_user: ansible_user: ops
ansible_connection: ansible_connection: local

01ansible_host= ansible_host: 203.0.113.9
The address or name to connect to, overriding the inventory host name.
Production: Set this when the inventory name is an alias, or when DNS is not authoritative from the controller. It is the only one of these four that changes which machine you reach.
⚠ Confusing it with ansible_hostname, which is a gathered fact reporting what the host calls itself. Setting ansible_hostname in inventory does not redirect anything.
02ansible_port= ansible_port: 2222
The SSH port. Defaults to 22.
Production: A per-host fact about the estate, so it belongs beside the host. An estate with a handful of non-standard ports will otherwise grow a conditional in every playbook.
⚠ Setting it as a group variable on a group that only mostly uses that port. One member on 22 then fails, and the failure looks like a network problem.
03ansible_user= ansible_user: ops
The remote user to log in as. Defaults to the controller user running the command.
Production: Set it explicitly rather than relying on the default, so a run behaves identically for every operator and for the scheduled job. Group level is usually right - the account is a property of how the estate was built.
⚠ Leaving it unset on a shared controller. The playbook then connects as whoever ran it, which works interactively and fails in cron under a service account.
04ansible_connection= ansible_connection: local
Which connection plugin to use. Defaults to ssh; local, docker, podman and network plugins are the common alternatives.
Production: Set it on the group whose hosts genuinely need a different transport - containers in a test scenario, or the controller itself. Never as a fleet-wide default.
⚠ Setting ansible_connection: local on a host you meant to reach over SSH. Every task then executes on the controller against the controller, reports success, and changes the wrong machine.

A host with all four looks like this, and it is the shape of every awkward machine in an estate:

all:
  children:
    legacy:
      hosts:
        oldbox:
          ansible_host: 192.0.2.55
          ansible_user: root
          ansible_python_interpreter: /usr/bin/python3.9

Read-only / Safereading the awkward host back— Real output from ansible-core 2.21.3. --graph --vars sorts the variables alphabetically. Everything needed to reach this host is visible in one place, which is the point of putting it in inventory.

$ ansible-inventory -i inventory/hosts.yml --graph legacy --vars

@legacy:
|--oldbox
|  |--{ansible_host = 192.0.2.55}
|  |--{ansible_python_interpreter = /usr/bin/python3.9}
|  |--{ansible_user = root}

Why these belong in inventory

The alternative is setting them in the play, and the argument against that is worth making explicitly because the play is where people naturally reach for.

They describe the host, not the change. ansible_port: 2222 is true of that machine regardless of what you are doing to it. Putting it in a play means every play that touches the host must repeat it, and a play that forgets fails in a way that looks like a network fault.

They must be right for ad-hoc commands too. ansible legacy -m ping has no play to read settings from. If the connection details are not in inventory, the ad-hoc command — which is what you reach for during an incident — does not work.

They are reviewed with the host. A change to how you reach a machine appears in the inventory diff, next to the machine, where the person reviewing knows what it means.

The general principle, which the course returns to: inventory answers which hosts and how to reach them; playbooks answer what to do to them. Connection variables are unambiguously the first kind.

Under the hood

Ranges are expanded by the inventory parser at load time, before anything else happens. By the time any group membership, variable resolution or pattern matching occurs, web[01:50].example.com has already become fifty separate host objects. There is no range left to inspect at run time, which is why --graph shows you the expansion rather than the expression — and why the expansion is the thing to review, not the line you wrote.

ansible_host is consumed by the connection plugin, not by the inventory. The inventory keeps the host under its alias throughout; ansible_host is read when the SSH command line is built. That is why the alias appears in the recap, in --limit and in group_vars filenames while the address appears only in the connection itself, and at -vvv verbosity in the SSH command.

Because the connection is ordinary SSH, your ~/.ssh/config applies. A Host block with a ProxyJump, an IdentityFile or a Port will take effect for a host Ansible connects to by that name — which is convenient on a workstation and a reproducibility hazard on a shared controller, since it is per-user state that no one else has. If a connection works for one person and not another and the inventory is identical, ~/.ssh/config is the first place to look. Making SSH behaviour explicit in inventory or in ansible.cfg rather than in a personal file is the fix; the SSH part of the course covers the options in full.

What happens if a range overlaps another group?

Nothing bad, and it is often deliberate. web[01:50] in webservers and web[01:10] in canary gives you ten hosts in both groups, which is exactly how a canary group is usually built.

The hosts are not duplicated. Ansible identifies hosts by name, so web01.example.com appearing in two ranges is one host with two group memberships — you can confirm this by counting: ansible all --list-hosts reports fifty, not sixty.

Two things to watch.

Variables now collide. Both groups can set the same key, and one wins by a rule rather than by intent. That is the last lesson in this part.

The canary is only a canary if the main play excludes it. A group called canary whose members are also in webservers gets changed twice by a webservers play — once as itself and once as part of the fleet — unless the pattern says webservers:!canary. Naming a group canary does not make Ansible treat it as one; the exclusion has to be written.

Ranges

Aliases: the name and the address are different things

The connection variables

Why these belong in inventory

Knowledge check