Ansible

In Part 4 of this series, we decoupled our network intent from the execution logic, using Jinja2 templates and model-driven YANG schemas to push VPLS configurations to our Nokia SR OS nodes via NETCONF. But seeing a yellow CHANGED status in your terminal is only half the battle. The ultimate question isn’t “Did the configuration push successfully?”, it is “Is the service actually operational in the data plane?” In this fifth and final part of our series, we close the loop. We will look at how to treat network operational states as structured data, execute automated Pre-Checks vs. Post-Checks, and build an immutable validation gate using Ansible assertions to guarantee compliance across our Containerlab fabric. ...

In Part 3 of this series, we treated our physical network topology like software application code, using Containerlab to spin up our test sandbox in seconds. With our nodes live, how do we actually generate and push configurations to them? If you hardcode configuration blocks directly into your Ansible tasks, your playbooks quickly become unmanageable. The moment a VLAN ID changes, or you swap a router from a Nokia SR OS node to a Cisco instance, your entire automation framework collapses under its own weight. ...

Up until now, our pipeline has focused on the management and mapping of data. We modeled our nodes inside our NetBox source of truth (Part 1), and then we built a dynamic handshake to pull that data straight into Ansible (Part 2). But there’s a missing link: Where are the actual routers coming from? If we have to manually spin up heavy virtual machines, map virtual interfaces, and configure bridge links every time we want to test our playbooks, we lose all the speed advantages of automation. ...

By default, Ansible relies on static inventory files (hosts.ini or hosts.yaml). In a dynamic, modern network environment, managing these text files manually becomes an operational nightmare. To bridge this gap, we can tie Ansible’s execution directly to NetBox, using it as our single source of truth. Before we configure the plugin, your local control machine needs the official NetBox collection along with its underlying Python API wrapper and timezone dependencies: ...