State, not shell history
Ansible
Ansible describes the end state of a host: this package present, this service running, this file in place. Run it twice and the second run changes nothing — that is idempotence, and it is the point.
Inventory and playbook
The inventory answers 'which hosts'; the playbook answers 'what state'. A play targets a group and runs tasks in order, each task naming a module (`apt`, `service`, `copy`) rather than a command.
Modules check before they act, which is why the same playbook is safe to re-run. A `shell:` task does not, which is why it is the wrong default and why the output says `changed` every time.
Privilege and repetition
`become: true` is how the play escalates once, rather than you prefixing every command with sudo. Handlers run at the end and only when notified — the mechanism behind 'restart nginx if the config changed'.
Secrets belong in Vault or an environment variable, never inline. A playbook is code; code gets committed.
Commands in this lesson
Every one of these runs in the sandbox — no real account, no real bill.
| Command | Why |
|---|---|
ansible-playbook -i inventory.ini site.yml | Inventory + playbook is the whole invocation. |
echo ' become: true' >> site.yml | Escalate once for the play instead of per task. |
echo ' apt:' >> site.yml | A module asserts state: present, not 'run apt-get install'. |
echo ' service:' >> site.yml | Start and enable in one declarative step. |
Now do it
Reading the model makes the first attempt faster. Only the lab makes you able to do it.
- Open the lab
Ansible: Configure Nginx with a Playbook
Intermediate · 30 min · members
- Open the lab
Ansible: Configure Apache httpd
Intermediate · 25 min · members
Ansible · OphirCloud Academy · all lessons