DevOps Practitioner · Module 5: Ansible and configuration management
Inventory, Connection and the First Honest Run
Configuration management starts with a list of machines you own and a connection you can audit. Inventory names the targets, SSH connects without shared secrets in files, and the first run proves the path before any playbook promises anything.
10 min reading
Objectives
- Explain what inventory declares: which machines, in which groups, with which variables
- Connect to learner-owned targets over SSH without passwords in the repo
- Run an ad-hoc command and read its changed-versus-ok output
- Scope every run to an explicit target pattern, never to everything by default
Why this matters
A playbook runs against all hosts because nobody set a limit, and a test task restarts the web server on the machine that serves the demo to visitors. The blast radius was the default, not a decision. Every configuration incident of this class shares one missing line: the run was never scoped. Inventory groups plus an explicit target pattern make the scope visible before execution, and the habit of limiting first turns accidents into no-ops.
Concepts
Inventory is a list with structure: hosts, groups of hosts, and variables attached at each level. Groups express roles (web, db, lab) so playbooks address intent instead of IP addresses; group variables hold the differences, host variables the exceptions. Static files suit fixed labs; dynamic sources suit clouds, but this module's labs stay static and local on purpose.
Connection is SSH with key authentication, and the private key never enters the repo, the chat or the screenshots. The control machine holds the key with tight file permissions; targets carry the public half. Test the connection with a read-only ad-hoc command before writing any playbook: ping the group, gather facts, read the output states. Green means reachable, and reachable is the precondition for everything else.
Ad-hoc output teaches the vocabulary the whole module uses: ok means already correct, changed means the task acted, failed means it did not. A run of many oks and zero changes is success, not silence; it proves the machines already match intent. Scope with explicit patterns and limits, and confirm the target list the tool prints before it acts.
Targets are machines you own: local VMs, lab containers, throwaway instances you created. The rule is absolute and repeated in every lab: never point these runs at machines you do not own, never borrow shared infrastructure for experiments, never embed real credentials to reach a target.
Worked example
A two-container lab stands in for web and db. The learner writes a static inventory with both groups, runs a read-only facts command limited to the lab group, and reads the ok output. Then a deliberately unlimited pattern is shown in check mode against an empty group first, demonstrating that scope is verified before execution, not after.
Common wrong move
Sharing one inventory file with production hosts and lab hosts in the same groups. A lab experiment with a broad pattern becomes a production incident. Separate inventories per trust domain; the lab inventory knows only lab machines.
Quick check
An optional 4-question self-check. Answers never leave your device, are not stored, and never count toward any assessment.
Lesson feedback
No published feedback yet.
Log in and complete the lesson to leave feedback.
Exercise
Write a static inventory for two learner-owned lab targets in groups, run a read-only command limited to one group, and quote the target list plus the ok output.
Pass criteria
The record shows the inventory with groups, the explicit limit used, and the quoted ok output with no changes and no production hosts present.