<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Containerlab on Dennis Mwangi</title><link>https://dennismwangi.com/tags/containerlab/</link><description>Recent content in Containerlab on Dennis Mwangi</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 02 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://dennismwangi.com/tags/containerlab/index.xml" rel="self" type="application/rss+xml"/><item><title>NetDevOps Pipeline Part 3: Topology Orchestration with Containerlab</title><link>https://dennismwangi.com/posts/iac-containerlab/</link><pubDate>Thu, 02 Jul 2026 00:00:00 +0000</pubDate><guid>https://dennismwangi.com/posts/iac-containerlab/</guid><description>&lt;p&gt;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).&lt;/p&gt;
&lt;p&gt;But there’s a missing link: &lt;strong&gt;Where are the actual routers coming from?&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</description></item></channel></rss>