Ansible basics cheat sheet

The chapter on one page: the ideas to remember, the commands to have at your fingertips, and a deck of flashcards for quick revision.

The chapter in eight sentences

Automation reduces human error and keeps your infrastructure in a consistent, correct state.
Infrastructure as Code means describing that state in readable text files kept in version control, and changing systems only by changing the code.
Ansible is an open source automation platform that adapts to many workflows and environments.
It is agentless: Ansible is installed only on the control node (and in its execution environments), and it reaches managed hosts over SSH or WinRM.
Playbooks are human-readable YAML files describing the desired state. A playbook holds plays, a play holds tasks, and each task runs a module.
Modules are idempotent: they change a host only when it differs from the desired state, so playbooks are safe to re-run.
Red Hat Ansible Automation Platform is the fully supported distribution, adding certified collections, execution environments, navigator, controller and hub.
ansible-navigator is the key tool for developing and running automation, and it runs playbooks inside an execution environment container.

Cheat sheet

Task	Command
Install navigator	`sudo dnf install ansible-navigator`
Install classic tools (`ansible-playbook`)	`sudo dnf install ansible-core`
Check the version	`ansible-navigator --version`
Log in to a registry	`podman login utility.lab.example.com`
Pull an EE by hand	`podman pull <registry>/ee-supported-rhel8:latest`
List available EEs	`ansible-navigator images`
Leave interactive mode	Esc (repeat to go back further) or `:q`

The registry and execution environment rows are classroom-only. At home the control node was prepared in section 1.6: ansible-core from dnf, navigator from pip, execution environment switched off.

Managed host type	Needs
Linux / UNIX	SSH, Python 3.8+, sudo for the remote user, `python3-libselinux` if SELinux is on
Windows	WinRM, PowerShell 3.0+, .NET Framework 4.0+
Network device	Nothing extra; modules run on the control node

What are the two types of machine in an Ansible architecture?: The **control node**, where Ansible runs, and **managed hosts**, which Ansible configures.
Playbook, play, task, module: how do they nest?: A playbook contains plays; a play is an ordered list of tasks for some hosts; each task runs one module.
What does idempotent mean for a playbook?: Running it again on hosts already in the desired state makes **no changes** (`changed=0`).
Why are `command` and `shell` tasks risky?: Ansible cannot tell whether the command was needed, so they report `changed` every run and are easy to make non-idempotent.
What is an automation execution environment?: A **container image** with Ansible Core, collections and dependencies, used by ansible-navigator and automation controller.
Which tool builds custom execution environments?: `ansible-builder`
Automation controller used to be called…: Red Hat Ansible **Tower**.
Which collection always ships with Ansible Core?: `ansible.builtin`
What does a Linux managed host need for most modules?: SSH access and **Python 3.8 or later** (plus sudo for privilege escalation).
Where do network device modules usually run?: On the **control node**, talking to the device via CLI over SSH, XML over SSH or an HTTP(S) API.