Introduction
Automation is only safe when it reaches the intended hosts. Two aliases for one machine, a missing host or an overly broad selection can make a successful command misleading.
In this lab, you will organize two distinct SSH targets into canary and stable groups, inspect a parent group, preview host patterns, and create a marker only on the canary. Ansible and the training connections are already prepared; you will work with the inventory and command scope.
Organize Hosts into Groups
In this step, you will group the two existing SSH hosts without duplicating their identities or addresses.
Open the Terminal and enter the project:
cd /home/labex/project
Read the supplied inventory before editing it:
cat inventory.ini
It defines web1 and web2 with different ansible_host values. Keep those lines and the [all:vars] connection settings. Inventory names identify hosts; placing the same name in multiple groups does not create another server.
A group describes a set of hosts. We will use canary for the first host, stable for the second and webservers as a parent containing both groups. Append these sections. >> preserves the existing file, and the quoted here-document marker keeps the pasted text literal:
cat >> inventory.ini <<'EOF'
[canary]
web1
[stable]
web2
[webservers:children]
canary
stable
EOF
[canary] and [stable] contain host names. A section ending in :children contains group names, so webservers inherits the hosts belonging to canary and stable. Do not put new destination addresses under these groups.
ansible-inventory --graph draws the resolved membership:
ansible-inventory --graph
Expect web1 under canary and web2 under stable, with both groups beneath webservers. The special all and ungrouped entries may also appear. A host can appear through more than one graph branch while remaining one inventory host.
A host pattern selects the targets for a command. Preview the parent group without executing a module:
ansible webservers --list-hosts
Expect exactly web1 and web2. In a pattern, :& means intersection: choose hosts belonging to both parts. Quote it so the shell does not interpret &:
ansible 'webservers:&canary' --list-hosts
Expect only web1. This preview gives you a chance to catch a selection mistake before changing any host.
Limit a Change to the Canary
In this step, you will make a small change on the canary while preserving the stable host and controller.
A command's first pattern selects an initial set. --limit narrows it further; it does not add hosts outside that set. Preview a limited selection before using it:
ansible webservers --limit canary --list-hosts
Expect one host, web1. A limit that matches nothing would not demonstrate a successful change, even if the command exits without a module failure.
Use the command module from the preceding lab to run touch. This Linux command creates an empty file when it does not exist, and updates its timestamp if it does. The marker belongs in the managed automation user's home. The quoted -a value keeps the executable and path together:
ansible webservers --limit canary -m ansible.builtin.command -a 'touch /home/automation/canary-ready'
Expect a successful command result for web1 only. This action is deliberately a simple scope exercise; touch can update timestamps on repeated runs, so its CHANGED status is not an idempotency demonstration.
Inspect the visible files in each managed user's home. ls lists the directory on each target because it is executed by Ansible's command module:
ansible webservers -m ansible.builtin.command -a 'ls /home/automation'
The web1 result should contain canary-ready. The web2 result should not contain that name; its stdout may be empty. These are remote directories, separate from your controller workspace.
Finally, inspect the controller's current directory:
ls
It should show the project configuration and inventory, without a local canary-ready marker. You selected a real managed host rather than making a change on the controller. Future labs will use modules that declare file state directly and then verify idempotency.
Summary
You preserved two distinct inventory identities, organized hosts and child groups, previewed a quoted intersection pattern, and narrowed a command with --limit. Actual target state showed the marker only on the canary while the stable host and controller remained outside the change.
