Ansible for one server: a description you can run
Describe the machine's state in a playbook, run it until changed=0, and know what a green run does and does not prove.
The Bash course ended on a script you can run twice. This course is that idea made into a tool: a playbook is a claim about what the machine should be, a run is the machine made to agree with it, and the second run has nothing to do and says so. It manages one server — yours, over SSH or on the loopback — and stops there on purpose. The first half makes the machine describable: install, inventory, a first playbook. The second teaches you to read what a run reports, and where that trust ends: handlers, the recap line field by field, and the secrets a repository must never hold in clear.
What you will be able to do
- Say what a playbook claims and what a run proves, and name the cases where a script is still the right answer
- Install ansible-core from Ubuntu's repositories, write an inventory of one machine and test the SSH-and-Python chain
- Write a playbook that installs nginx, templates a file and keeps a unit running, then read changed=0 for what it means
- Restart a service only when its configuration changed, with a handler rather than a task
- Read the recap line field by field, and keep the vault password out of the repository that holds the vault
Outline
- 01
Making the machine describable
What Ansible promises, how it reaches the server, and a first playbook read for what changed=0 means.
- 02
Trusting what a run reports
Handlers that restart only on change, the recap line field by field, and secrets kept out of the repository.
Technical content last reviewed on 18 September 2026