Ansible Architecture
Understanding how Ansible works under the hood helps you use it effectively. Ansible follows a simple push‑based architecture with no agents on managed nodes.
Core Components
- Control Node: The machine where Ansible is installed. It runs Ansible commands and playbooks.
- Managed Nodes: The target servers being automated. They have no Ansible agent – just Python and SSH.
- Inventory: A file that lists the managed nodes and groups them (e.g., webservers, databases).
- Modules: Units of work Ansible executes on managed nodes (e.g.,
copy,yum,service). - Playbooks: YAML files that define automation workflows with multiple tasks.
- Plugins: Extend Ansible’s core functionality (e.g., connection plugins, callback plugins).
How Ansible Works
1. You run a playbook or ad‑hoc command on the control node.
2. Ansible reads the inventory to determine which nodes to target.
3. It connects to each managed node via SSH (or WinRM for Windows).
4. It copies the module (Python script) to the managed node.
5. The module executes on the managed node and returns results.
6. Ansible removes the module after execution (no persistent agent).
Push vs. Pull Model
Ansible is push‑based: the control node initiates changes. This is simpler than pull‑based systems (like Puppet) where nodes periodically check in. Push gives you immediate control.
Idempotency
Ansible modules are idempotent: running a task multiple times results in the same final state. For example, if a package is already installed,
apt install won’t reinstall. This makes playbooks safe to rerun.Simplified Diagram
Control Node (Ansible) → SSH → Managed Node (runs module, returns JSON)
Two Minute Drill
- Control node runs Ansible; managed nodes need Python + SSH.
- Inventory lists managed nodes and groups.
- Modules are copied and executed via SSH, then removed.
- Idempotency ensures safe repeated runs.
Need more clarification?
Drop us an email at career@quipoinfotech.com