<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Ansible on Emanuel's Blog</title><link>https://emasblog.dev/tags/ansible/</link><description>Recent content in Ansible on Emanuel's Blog</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Mon, 08 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://emasblog.dev/tags/ansible/index.xml" rel="self" type="application/rss+xml"/><item><title>Turning an old Dell Laptop into a Disposable Homelab</title><link>https://emasblog.dev/posts/2026/06/disposable-homelab/</link><pubDate>Mon, 08 Jun 2026 00:00:00 +0000</pubDate><guid>https://emasblog.dev/posts/2026/06/disposable-homelab/</guid><description>&lt;p&gt;There is a category of infrastructure problem that cloud environments solve by making it expensive to ignore: the gap between your local test setup and what actually runs in production.&lt;/p&gt;
&lt;p&gt;Simplified local clusters, mocked dependencies and single or multi-node Kubernetes distributions are fast to spin up, but they paper over the networking behavior, resource contention and tooling quirks that only surface under realistic conditions. Cloud environments solve this faithfully, but they keep billing you whether or not you are actively testing anything. There is also another option, we discussed in this blog in the past: run &lt;a
 href="https://emasblog.dev/posts/2025/11/kubernetes-in-docker/"target="_blank"
 class="inline-flex items-center gap-1"
 &gt;kubernetes in docker&lt;svg class="h-3 w-3 flex-shrink-0" id="external-link" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"&gt;&lt;path fill="none" stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M15 3h6v6m-11 5L21 3m-3 10v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/&gt;&lt;/svg&gt;
 &lt;/a&gt;.&lt;/p&gt;</description></item></channel></rss>