Nornir for Network Engineers
Why Nornir? Python-Native Automation, Not YAML Playbooks
What you'll learn
- How Nornir differs architecturally from Ansible's YAML/playbook model
- How Nornir relates to the package Phase 3.3 built by hand
- The five capabilities this module covers, each mapped to something already built
- That Netmiko itself is not being re-taught — only how Nornir invokes it
Listen to a guided explanation of this lesson.
Spoken narration isn't supported in this browser.
You already built this framework, by hand
Phase 3.3's entire arc was building, piece by piece, in real Python: inventory loading, a connection abstraction, structured results, and concurrent execution. Nornir is a real, popular framework that provides most of that out of the box.
- Phase 3.3 — you built it yourselfinventory.py, models.py, connections.py, ThreadPoolExecutor
- Nornir — a real framework provides itthis module
- Still 100% Pythontask functions, not YAML plays
- Still built on Netmikovia the nornir_netmiko plugin
Python-native, not YAML playbooks
Ansible describes automation as YAML plays: tasks are declared, not written as code. Nornir describes automation as real Python functions.
- Tasks are YAMLa playbook, declarative
- Modules do the workios_config, ios_command
- No Python function to write
- Tasks are Python functionsdef my_task(task: Task) -> Result:
- Plugins wrap real toolsnornir_netmiko wraps Netmiko
- Ordinary Python, testable and debuggable like any other function
What this module covers, mapped to what you already built
Inventory -- Lesson 2 (you built inventory.py by hand)
InitNornir() + tasks -- Lesson 3 (you built check_device() by hand)
Filtering -- Lesson 4 (a genuinely new capability)
nornir_netmiko -- Lesson 5 (you already know Netmiko itself)
Built-in concurrency -- Lesson 6 (you built ThreadPoolExecutor code by hand)Four of these five map directly onto something Phase 3.3 already built by hand. Only filtering is a genuinely new capability this module introduces — everything else is 'a framework does this for you now.'
Netmiko itself is not re-taught
ConnectHandler, send_command, send_config_set, and Netmiko's own exceptions were fully covered in Netmiko Fundamentals (Phase 2.7) — this module doesn't repeat any of that. Lesson 5 covers only how nornir_netmiko invokes the Netmiko you already know, inside a Nornir task.
Not a replacement for Ansible either
Two legitimate, different tools
Ansible and Nornir solve the same broad problem — orchestrating many devices — with genuinely different philosophies: YAML-declarative vs. Python-native. Neither replaces the other. An engineer comfortable in Python who wants full programming-language control reaches for Nornir; a team standardizing on readable, non-programmer-friendly playbooks reaches for Ansible. Both remain valid, exactly as Lesson 1 of every prior tool-focused module has said about its own tool.
Key takeaways
- Nornir provides, as a real framework, much of what Phase 3.3 built by hand: inventory handling, structured results, and concurrent execution.
- Nornir tasks are real Python functions (def task(task: Task) -> Result), not YAML plays — the core architectural difference from Ansible.
- This module's five topics map directly onto Phase 3.3's own package pieces, except filtering — a genuinely new capability.
- Netmiko itself (ConnectHandler, send_command, exceptions) is not re-taught — only how nornir_netmiko wraps it, in Lesson 5.
- Nornir doesn't replace Ansible any more than Ansible replaced Netmiko — different tools for different situations.