Free preview · Beginner · 22 min read
Ansible Mental Model: Agentless Automation, Desired State & Architecture
Understand control nodes, managed nodes, inventory, plays, tasks, modules, plugins, collections, connections and why idempotency matters.
Free preview · Beginner · 22 min read
Understand control nodes, managed nodes, inventory, plays, tasks, modules, plugins, collections, connections and why idempotency matters.
Ansible is easiest to learn when you stop thinking of it as “SSH plus YAML” and instead see it as an automation engine that turns inventory + intent into controlled actions on systems.
Git repository / automation project
|
v
Ansible control node
- ansible-core
- inventory
- playbooks
- collections/plugins
|
connection plugins
SSH / WinRM / API / network CLI
|
v
Managed targets
Servers | cloud APIs | network devices | platforms
Ansible is commonly called agentless because you normally do not install a long-running Ansible agent on every Linux server. The control node connects using existing management protocols. That does not mean “no prerequisites”: many POSIX modules require a usable Python interpreter on the target, Windows commonly uses WinRM/PowerShell, and network/cloud automation may execute through APIs or specialized connection plugins.
| Term | Meaning |
|---|---|
| Inventory | The hosts, groups and variables Ansible can target |
| Play | Maps a set of hosts to tasks, roles and execution settings |
| Task | One automation step |
| Module | The unit that performs work, such as package, service, copy or user management |
| Plugin | Extends behavior such as connections, lookups, callbacks, inventory or filters |
| Collection | Versioned distribution unit containing modules, plugins, roles and sometimes playbooks |
| Role | Reusable project structure for tasks, defaults, handlers, templates and related content |
| Fact | Data discovered about a managed target |
| Handler | A task triggered by a change, often used for controlled restarts |
A good configuration task describes the state you want:
- name: Ensure Nginx is installed
ansible.builtin.package:
name: nginx
state: present
Run it once: Nginx may be installed. Run it again: a well-behaved module should report no change if the target already matches the requested state.
That property is idempotency. It is essential for repeatable automation, but it is not magic. A shell command such as this changes state every run:
- name: Bad repeatability example
ansible.builtin.shell: echo "run" >> /tmp/history.log
A common Ansible workflow is push-oriented:
Engineer / CI
↓
ansible-playbook
↓
Select inventory targets
↓
Gather context/facts if requested
↓
Run tasks in order
↓
Collect changed/failed/skipped results
Use Ansible when you need to automate things such as:
Terraform and Ansible can complement each other:
Terraform: create infrastructure
↓
Ansible: configure systems and applications
↓
Observability: verify production behavior