Ansible for Network Engineers
Installing Ansible and Its Architecture
What you'll learn
- Control node vs. managed node, and why Ansible is called 'agentless'
- How to install ansible-core, and on which operating systems this curriculum supports it
- The three-layer model this module uses: ansible-core, cisco.ios, and a real device
- That this module's terminal examples describe Ansible's documented behavior, not a live capture from this curriculum's own build environment
Listen to a guided explanation of this lesson.
Spoken narration isn't supported in this browser.
Agentless: the same SSH model you already trust
Ansible needs no software installed on the network device it manages — no agent, no daemon. It reaches out over SSH from wherever Ansible itself runs, does its work, and disconnects. That's exactly the transport Netmiko already used.
- Control nodewhere ansible-core runs — your machine, or a jump host
- SSHthe same transport ConnectHandler() used in Netmiko Fundamentals
- Managed deviceno agent, no extra software required on the device
The machine running Ansible is called the control node. The device being managed — a switch, a router — is the managed node. "Agentless" means the managed node needs nothing extra installed; it just needs to accept the same kind of SSH connection Netmiko already made in Phase 2.7.
Installing the control node
For the Ansible control node, use Linux, macOS, or WSL2 on Windows
Native Windows is not the supported control-node path for this curriculum. If your everyday machine is Windows, run Ansible inside WSL2 (Windows Subsystem for Linux) rather than directly in a Windows shell.
pip install ansible-coreRun this on Linux, macOS, or inside WSL2 on Windows. Like Netmiko and Jinja2 before it, this is a learner-side Python package — never something this website itself depends on.
How this module's terminal examples were produced
Every runnable Jinja2 template and every piece of YAML in this module was written and directly verified — the same standard as every prior module. Ansible's own command-line output (ansible --version, ansible-playbook --check, and similar) is different: those examples in this module describe Ansible's own documented, well-established behavior. They are not a live capture from this curriculum's own build/test environment, which does not have a Linux/WSL2 control node available. On your own Linux/macOS/WSL2 setup, running these commands yourself will produce genuinely live output — this distinction is noted again wherever it matters.
$ ansible --version
ansible [core 2.1x.x]
config file = None
...
python version = 3.x.xThe exact version numbers depend on what you installed. Run this yourself on Linux/macOS/WSL2 to see your own real output.
Three layers, not one
This module uses three distinct things, and mixing them up is a common source of confusion:
- ansible-corethe Ansible engine — inventory, playbooks, variables, the template module
- cisco.iosa separate collection — Cisco IOS-specific modules like ios_config, ios_command
- A real or virtual Cisco devicewhat's actually needed to run cisco.ios tasks for real
ansible-core alone is enough for everything through Lesson 5 of this module — inventory, playbooks, variables, and even rendering the same vlan_config.j2 template from Configuration & Template Automation. The cisco.ios collection (installed separately, via ansible-galaxy collection install cisco.ios) is only needed once Lesson 6 introduces real Cisco-specific modules — and even then, only to run them against an actual device. Nothing before Lesson 6 requires it.
Key takeaways
- Ansible is agentless — no software is installed on the managed device, which connects over the same SSH transport Netmiko already used.
- For the Ansible control node, use Linux, macOS, or WSL2 on Windows. Native Windows is not the supported control-node path for this curriculum.
- Three distinct layers: ansible-core (the engine), cisco.ios (a separate Cisco-specific collection), and a real device (needed only to run cisco.ios tasks for real).
- This module's Jinja2 and YAML examples were directly verified, the same standard as every prior module. Ansible's own CLI output describes documented behavior rather than a live capture from this curriculum's own environment — stated plainly wherever it applies.