Chapter Three
Modules & Ad-hoc Commands
The module is the unit of work where idempotency physically lives, and the ad-hoc command is the fastest way to fire one at the fleet — running, reading, and dry-running real changes against the Larkspur stack before any playbook exists.
A module is the unit of work in Ansible — a small program that takes desired state as arguments, reads the machine's current state, and makes only the changes needed to match. It is where idempotency physically lives, where the honest ok/changed contract comes from, and where the no-state-file model becomes concrete: the module is copied over, run once, and deleted, leaving the managed node as the only record. Everything a playbook does is modules, called in order.
This chapter works the module model from the command line first, before playbooks enter the picture. You fire a single module at web or db as a one-off, learn which modules are idempotent and which only pretend to be, meet the toolbox that covers most of configuring a server, fence off the command/shell escape hatch, find any module's exact arguments with ansible-doc, and dry-run a change with --check --diff before touching a real host. By the end the Larkspur stack is something you can operate by hand, correctly.
Topics in This Chapter
--become, fleet diagnosis, and the firm line into playbooks.changed matters, and how a module physically runs with no state behind it.apt, service, copy/template, file, user, and lineinfile, every one idempotent against live state, worked against the Larkspur stack.changed every run, the creates/changed_when guards that restore honesty, and the rule to prefer a real module first.--check predicts what each module would do against the live host, --diff shows the literal lines. Why it substitutes for a state-file plan, and where the prediction is weak.