https://blog.lerenn.dev/Recent content on Louis FRADINHugo -- gohugo.ioen-USThu, 18 Dec 2025 10:00:00 +0100https://blog.lerenn.dev/posts/homelab-longhorn-ftp-backups/Thu, 18 Dec 2025 10:00:00 +0100https://blog.lerenn.dev/posts/homelab-longhorn-ftp-backups/This is the eighth post in our “K8s Homelab” series. Check out the previous post to see how we migrated PVCs and implemented backup strategies. The Backup Storage Challenge After optimizing storage usage and implementing manual backup procedures, the next critical step was setting up automated, off-site backups for Longhorn volumes. Longhorn supports S3-compatible storage for backups, but I needed a solution that: Runs on-premises - A dedicated backup server (Raspberry Pi) with local storage Provides S3-compatible API - For seamless Longhorn integration Encrypts backups - Secure data at rest and in transit Syncs to cloud storage - Off-site backup to Box.https://blog.lerenn.dev/posts/homelab-forge/Sun, 14 Dec 2025 10:00:00 +0100https://blog.lerenn.dev/posts/homelab-forge/This is the ninth post in our “K8s Homelab” series. Check out the previous post to see how we set up automated, encrypted backups for Longhorn volumes. The Need for Self-Hosted Git Hosting With the cluster infrastructure in place—MetalLB, Traefik, Longhorn, the LGTM observability stack, and container registries—I had a solid foundation for running services. But I needed a way to host my Git repositories privately, without relying on external services like GitHub or GitLab.https://blog.lerenn.dev/posts/use-dagger-on-fedora-silverblue/Thu, 11 Dec 2025 12:02:04 +0100https://blog.lerenn.dev/posts/use-dagger-on-fedora-silverblue/Fedora Silverblue is an immutable operating system that uses toolboxes for development environments. When trying to run Dagger Engine inside a toolbox, you’ll quickly encounter a critical issue: Dagger requires rootful Podman access for its CNI networking, but toolboxes run with rootless Podman by default. This post documents the problem and provides a solution using a shared Podman Machine to provide rootful Podman access for Dagger across all your toolboxes.https://blog.lerenn.dev/posts/homelab-homeassistant/Sat, 29 Nov 2025 18:00:00 +0100https://blog.lerenn.dev/posts/homelab-homeassistant/This is the seventh post in our “K8s Homelab” series. Check out the previous post to see how we deployed gaming VMs with GPU passthrough. From Raspberry Pi to Kubernetes-Native HomeAssistant has been running on a Raspberry Pi 5 in my homelab, managing smart home devices including Philips Hue lights, electrical sockets, A/C units, and surveillance cameras. While the Pi worked well, I wanted to migrate it to the Kubernetes cluster for better resource management, automated backups, and integration with the rest of the infrastructure.https://blog.lerenn.dev/posts/homelab-pvc-migration-backup/Sat, 29 Nov 2025 16:00:00 +0100https://blog.lerenn.dev/posts/homelab-pvc-migration-backup/This is the seventh post in our “K8s Homelab” series. Check out the previous post to see how we deployed gaming VMs with KubeVirt and GPU passthrough. The Storage Optimization Challenge After deploying gaming VMs with KubeVirt, we faced a storage capacity challenge. The Windows system volume was configured with 3 replicas (x3) for high availability, consuming 384Gi of NVME storage (128Gi × 3 replicas) across the cluster. However, with only 256GB NVME drives on the Lenovo nodes and a 1TB drive on Tower, this was consuming too much space.https://blog.lerenn.dev/posts/homelab-gaming-kubevirt/Sat, 29 Nov 2025 14:00:00 +0100https://blog.lerenn.dev/posts/homelab-gaming-kubevirt/This is the sixth post in our “K8s Homelab” series. Check out the previous post to see how we deployed the observability stack with Loki, Grafana, Tempo, and Mimir. From Physical Gaming PC to Kubernetes-Native VMs The original goal of this homelab project was to migrate my gaming setup from a physical PC with QEMU/Libvirt VMs to a Kubernetes-native solution. The gaming PC (Tower) had an NVIDIA RTX 3080 GPU that needed to be passed through to VMs, and I wanted the flexibility to run gaming sessions with full GPU access or maintenance tasks without GPU overhead.https://blog.lerenn.dev/posts/homelab-ha-control-plane/Thu, 20 Nov 2025 15:00:00 +0100https://blog.lerenn.dev/posts/homelab-ha-control-plane/This is the fifth post in our “K8s Homelab” series. Check out the previous post to see how we deployed MetalLB, Traefik, Longhorn, and container registries. The Single Point of Failure Problem The cluster was running beautifully. Three nodes, all services deployed, everything humming along. I could access my services from anywhere via VPN, manage the cluster with kubectl, and life was good. Until I realized I had a problem.https://blog.lerenn.dev/posts/homelab-registries/Wed, 19 Nov 2025 10:00:00 +0100https://blog.lerenn.dev/posts/homelab-registries/This is the sixth post in our “K8s Homelab” series. Check out the previous post to see how we deployed the observability stack. The Need for Container Registries With the cluster infrastructure in place—MetalLB, Traefik, Longhorn, and the LGTM observability stack—I had a solid, production-ready Kubernetes environment. But I needed a way to store custom container images and cache public images to avoid rate limiting and speed up pulls. I needed:https://blog.lerenn.dev/posts/homelab-lgtm-stack/Wed, 05 Nov 2025 10:00:00 +0100https://blog.lerenn.dev/posts/homelab-lgtm-stack/This is the fifth post in our “K8s Homelab” series. Check out the previous post to see how we deployed MetalLB, Traefik, and Longhorn as the foundation layer. From Infrastructure to Observability With the cluster infrastructure in place—MetalLB providing load balancing, Traefik handling ingress, and Longhorn offering distributed storage—the cluster was functional but blind. I had no visibility into what was happening inside. Pods could crash, nodes could fail, services could degrade, and I’d have no idea until something broke catastrophically.https://blog.lerenn.dev/posts/homelab-foundation-layer/Tue, 28 Oct 2025 10:00:00 +0100https://blog.lerenn.dev/posts/homelab-foundation-layer/This is the fourth post in our “K8s Homelab” series. Check out the previous post to see how we deployed the physical K3s cluster with PXE boot and Butane configurations. Building the Foundation Layer With the physical K3s cluster up and running across our three Lenovo nodes, it was time to deploy the essential infrastructure services that would form the foundation for everything else. These services provide the core primitives that all workloads running on the cluster will depend on.https://blog.lerenn.dev/posts/homelab-kubernetes-cluster/Sun, 12 Oct 2025 13:00:00 +0100https://blog.lerenn.dev/posts/homelab-kubernetes-cluster/This is the third post in my “K8s Homelab” series. If you haven’t read the first post and second post, start there — they set the stage for what comes next. The Leap: From Clean VLANs to a Real Cluster The network was finally stable. VLANs behaved, DHCP worked, and devices were segmented the way I had always wanted. After hours of troubleshooting OpenWRT, fighting with proprietary firmware, and wrestling with WiFi configuration, I finally had the foundation I needed.https://blog.lerenn.dev/posts/homelab-network/Sat, 20 Sep 2025 11:00:00 +0100https://blog.lerenn.dev/posts/homelab-network/This is the second post in our “K8s Homelab” series. Check out the previous post to see how we planned the network architecture. The Beginning: A Dream and a Plan It all started with a simple dream: transform my basic homelab into a properly segmented, Kubernetes-based infrastructure. I had been running everything on a single network for years, and the security implications were starting to keep me up at night. Smart home devices mixed with servers, personal devices sharing the same subnet as my lab equipment – it was a security nightmare waiting to happen.https://blog.lerenn.dev/posts/homelab-introduction/Sat, 20 Sep 2025 10:00:00 +0100https://blog.lerenn.dev/posts/homelab-introduction/The Journey Begins: From Chaos to Order I’ve always been fascinated by infrastructure and automation. What started as a simple gaming PC running Fedora Linux with a few VMs has evolved into a full-scale homelab project. This series of blog posts documents my journey from a basic setup to a properly segmented, Kubernetes-based infrastructure. Current Setup: A Gaming PC with VMs My current setup is humble but functional: Gaming PC (Tower): Fedora Linux host with 3 VMs via QEMU/Libvirthttps://blog.lerenn.dev/posts/dagger-kubernetes-deployment/Wed, 06 Aug 2025 15:30:00 +0200https://blog.lerenn.dev/posts/dagger-kubernetes-deployment/This blog post covers how to deploy Dagger Engine with a Docker registry mirror on Kubernetes to speed up CI/CD pipelines and avoid Docker Hub rate limiting issues. I’ll explore the problem, the solution architecture, and provide complete Kubernetes manifests for production use. What is Dagger? Dagger is a modern CI/CD engine that allows you to write your pipelines as code. It provides a powerful API for building, testing, and deploying applications.https://blog.lerenn.dev/posts/asyncapi-codegen-presentation/Sat, 14 Oct 2023 16:41:34 +0200https://blog.lerenn.dev/posts/asyncapi-codegen-presentation/This first blog post is about an open-source tool that I’m currently writing here. AsyncAPI, an initiative to rule them all What is AsyncAPI? As a response to the lack of tools to define contracts between asynchronous services, Fran Méndez started the project AsyncAPI as a set of tools heavily inspired by OpenAPI initiative to define communication inside an Event-Driven Architecture (EDA). Like OpenAPI, you have a specification, in YAML or JSON, that can be used to define the interfaces of asynchronous APIs.https://blog.lerenn.dev/pages/about/Sun, 14 May 2023 00:00:00 +0000https://blog.lerenn.dev/pages/about/Hello ! I’m a back-end / devops / sysadmin developer and this is my blog!