Learning objectives
By the end of this module, you should be able to:
- Identify the main Ansible architecture components.
- Explain the agentless SSH-based model used for common Linux automation.
- Interpret ok, changed, failed and unreachable results.
Control node, inventory and managed nodes
The control node is the system where you run Ansible. Inventory tells Ansible which managed nodes exist and how they are grouped. Managed nodes are the systems on which Ansible performs work.
For common Linux automation, Ansible connects using SSH, transfers or invokes module code as required, receives the result and then removes temporary execution artifacts. A permanently running Ansible agent is not normally required on each Linux host.
Modules are the units of work
A module performs a focused action such as managing a package, file, user or service. An ad-hoc command executes one module directly. A playbook organizes modules into ordered tasks that can be repeated and reviewed.
- ansible.builtin.ping checks usable Ansible connectivity; it is not ICMP ping.
- ansible.builtin.command runs a command without a shell.
- ansible.builtin.copy manages files.
- ansible.builtin.service manages service state where supported.
Read the result, not just the colour
Ansible reports whether a task was already correct (ok), changed the host (changed), could not connect (unreachable) or executed but failed (failed). Understanding these states is essential for troubleshooting and for judging whether automation is truly repeatable.
Worked examples
See the idea in practice.
Connectivity test
ansible all -i inventory.ini -m ansible.builtin.ping
- all targets every host in the selected inventory.
- -i chooses the inventory source.
- -m selects the module.
- A pong response means Ansible reached the host and executed the module successfully.
Typical recap vocabulary
web01 : ok=3 changed=1 unreachable=0 failed=0 skipped=0
- ok counts successfully processed tasks.
- changed counts tasks that modified state.
- unreachable indicates a connection problem.
- failed means the connection worked but a task failed.
Hands-on lab
Lab — Trace an Ansible request
Goal: Follow what happens from the control node to a managed host and back.
Before you start
- One Linux control node with Ansible installed.
- One reachable Linux managed node with SSH access.
STEP 1Confirm normal SSH first
ssh learner@managed01 hostname
STEP 2Run the Ansible ping module
ansible all -i inventory.ini -m ansible.builtin.ping
STEP 3Increase verbosity
ansible all -i inventory.ini -m ansible.builtin.ping -vv
Verify
- Identify which host Ansible connected to.
- Identify the remote user and SSH path in verbose output.
- Confirm the final result is successful and not unreachable.
Expected outcome
- The managed node returns pong.
- The learner can explain the path control node → SSH → module execution → result.
If it fails
- If SSH itself fails, fix SSH before troubleshooting playbook logic.
- If Python is missing or Ansible chooses the wrong interpreter, configure the appropriate interpreter for that host.
Real-world connectionSeparating transport problems from module/task problems makes Ansible incidents much faster to diagnose.
Avoid these traps
Common mistakes
- Treating ansible.builtin.ping as a network ICMP test.
- Troubleshooting YAML before verifying basic SSH authentication.
- Confusing a failed task with an unreachable host.
Knowledge check
Can you explain it without looking back?
Open each answer only after you have tried to answer the question yourself.
1What is inventory?
A source describing managed nodes and their logical grouping for Ansible.
2Does common Linux Ansible automation require a permanent agent?
Normally no; Ansible commonly connects over SSH and executes modules remotely.
3What is the difference between failed and unreachable?
Unreachable means Ansible could not establish the required connection; failed means execution reached the host but the task did not succeed.