Free tech learning for everyone, from basics to pro

AnsibleProgramming and Application SecurityBeginner

Ansible architecture and concepts: control node, inventory, modules and idempotency

In short: Ansible is an agentless automation tool. A control node reads an inventory of devices and playbooks of tasks, then uses modules over SSH or APIs to bring each device to the desired state. Well-written tasks are idempotent: running them again changes nothing.

What Ansible is

Ansible is an open-source automation tool for configuring servers, network devices and cloud services. You describe the state you want in YAML (a human-readable data format) and Ansible works out what to change. It is agentless: nothing needs to be installed on the devices you manage. It connects over SSH for Linux and network devices, WinRM or SSH for Windows, and HTTPS APIs for cloud platforms and some network operating systems.

The open-source engine is called ansible-core. The larger ansible package bundles ansible-core with a curated set of collections, which is usually what you install with pip install ansible on a lab machine.

How Ansible fits togetherControl noderuns ansibleInventorywhat to managePlaybookswhat to doModulesunits of workPluginsconnections, filtersCollectionspackaged contentManaged nodesservers, switches
Figure 1. The control node reads the inventory and playbooks, then uses modules and plugins to act on managed nodes.

The main building blocks

TermMeaningExample
Control nodeThe Linux or macOS machine where Ansible runsYour automation VM or a CI runner
Managed nodeA device Ansible configuresA switch, a web server
InventoryA list of managed nodes, grouped, with variablesinventory.yml
ModuleA unit of work with parametersansible.builtin.copy, cisco.ios.ios_vlans
TaskOne call to a module"Ensure VLAN 20 exists"
PlaybookAn ordered list of plays and taskssite.yml
CollectionA package of modules, plugins and rolescisco.ios, arista.eos

Modules are named with a fully qualified collection name (FQCN) such as ansible.builtin.service. Using the full name avoids confusion when two collections contain modules with the same short name.

Idempotency: the key idea

An idempotent task can run many times and only makes a change when the device is not already in the desired state. A task that says "VLAN 20 named USERS must exist" checks first: if the VLAN is there with the right name, it reports ok; if not, it creates it and reports changed. This is why you can run the same playbook every night to correct drift without harming devices that are already right.

ansible all -i inventory.yml -m ansible.builtin.ping          # test connectivity to servers
ansible switches -i inventory.yml -m cisco.ios.ios_facts      # gather facts from IOS switches
ansible-playbook -i inventory.yml site.yml --check --diff     # preview changes

Be careful with modules that send raw commands, such as ansible.builtin.command, ansible.builtin.shell or cisco.ios.ios_command. They are not idempotent by themselves and will report changes every time unless you add conditions. Prefer purpose-built modules where they exist.

Servers versus network devices

Servers vs network devicesLinux and Windows hostsSSH or WinRMModule copied and run on hostPython needed on Linux targetsFacts from the hostNetwork devicesnetwork_cli, netconf, httpapiModule runs on control nodeNo Python on deviceFacts via show or API
Figure 2. With servers, Ansible runs code on the target; with network devices, it runs locally and sends commands or API calls.

For a Linux server, Ansible copies a small Python program to the host, runs it and removes it. Network devices usually cannot run Python, so network modules run on the control node and talk to the device using a connection plugin: ansible.netcommon.network_cli for CLI over SSH, ansible.netcommon.netconf for NETCONF and ansible.netcommon.httpapi for REST APIs. You tell Ansible which one to use with the ansible_connection and ansible_network_os variables.

Tip: build a small lab with two or three virtual switches before automating real devices. Ansible questions in network automation interviews often start with "what does idempotent mean?" and "why is Ansible called agentless?".

Practice

Why is Ansible described as agentless?
It needs no software installed on managed devices; it connects using SSH, WinRM or APIs that already exist.
A task reports ok on the second run. What does that tell you?
The device was already in the desired state, so the idempotent module made no change.
Where do network modules usually execute?
On the control node, which then sends CLI commands or API calls to the device through a connection plugin.

Key takeaways

  • Ansible is agentless and describes desired state in YAML.
  • Control node, inventory, modules, playbooks and collections are the core parts.
  • Idempotent tasks only change what is not already correct.
  • Use fully qualified collection names for modules.
  • Network modules run on the control node via network_cli, netconf or httpapi.
Tracks your learning on this device only. See your progress on the learning paths.

About the author

Mohamed Fayas

Founder of FM TecHub. CCNA certified, with a BTEC HND in Network Engineering, and BEng (Hons) in Computer Networking and Cloud Security. He writes practical, plain-English guides on networking, security and cloud.

More about the author

Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.

Stay up to date by email

New notes, tools and security news from FM TecHub, explained simply. Free.

We only use your email to send these updates. See our privacy policy.