diff --git a/content/post/26-homelab-page-preview/images/homelab-hosting-overview.png b/content/post/26-homelab-page-preview/images/homelab-hosting-overview.png new file mode 100644 index 0000000..7ecde3c Binary files /dev/null and b/content/post/26-homelab-page-preview/images/homelab-hosting-overview.png differ diff --git a/content/post/26-homelab-page-preview/images/homelab-overview-simple.png b/content/post/26-homelab-page-preview/images/homelab-overview-simple.png deleted file mode 100644 index 0e93672..0000000 Binary files a/content/post/26-homelab-page-preview/images/homelab-overview-simple.png and /dev/null differ diff --git a/content/post/26-homelab-page-preview/index.fr.md b/content/post/26-homelab-page-preview/index.fr.md deleted file mode 100644 index 2ac4d51..0000000 --- a/content/post/26-homelab-page-preview/index.fr.md +++ /dev/null @@ -1,140 +0,0 @@ ---- -slug: homelab-page-preview -title: Prévisualisation de la page Homelab -description: Mon homelab compact avec Proxmox, Ceph, TrueNAS et OPNsense, les services qui y tournent et mon projet de migration vers Kubernetes. -date: 2026-10-18 -draft: true -tags: - - proxmox - - ceph - - truenas - - opnsense -categories: - - homelab -image: cover-26.webp ---- - -Mon homelab a commencé en 2013 avec le tout premier Raspberry Pi. Je voulais une machine bon marché pour apprendre Linux, et elle est devenue un petit NAS appelé Vezpibox. Le nom n'a pas particulièrement bien vieilli. - -D'autres Raspberry Pi ont suivi, puis un mini-PC en 2019, quand j'ai commencé à expérimenter la virtualisation et Docker à la maison. Ce serveur unique a fini par poser problème : c'était à la fois mon terrain de jeu et la machine qui faisait tourner les services utiles. Casser un environnement de test est une chose. Emporter les lumières ou Internet avec lui en est une autre. - -Aujourd'hui, le lab comprend un cluster Proxmox à trois nœuds, du stockage distribué, un NAS séparé et une paire de firewalls redondants. La plupart des applications tournent encore avec Docker Compose. Kubernetes fonctionne aussi, mais la migration des applications est la suite du projet, pas quelque chose que j'ai déjà terminé. - -Cette page présente la configuration actuelle. Les articles détaillent les installations, les migrations et les erreurs occasionnelles. - -*Dernière revue : octobre 2026.* - -## Un lab dans une armoire - -L'idée de départ était de construire un mini datacenter dans un placard. L'espace, le bruit, la consommation électrique et le budget comptaient tous, alors le setup s'est construit autour de machines compactes plutôt que de serveurs rackables. - -![L'armoire du homelab ouverte et fermée, à côté de la cuisine. L'espace disponible fait partie de la conception, ce n'est pas une salle de serveurs extensible à volonté.](images/homelab-enclore-open-closed.png) - -Le rack est un DeskPi RackMate T1. Il tient dans cette armoire étroite, avec des étagères et une multiprise pour utiliser l'espace disponible. Une fois la porte fermée, le lab disparaît dans l'appartement. - -![L'agencement initial du rack. Les légendes du routeur et des HDD correspondent à l'ancien setup ; l'architecture actuelle du firewall et du stockage est décrite plus bas.](images/homelab-rack-legend.png) - -Le refroidissement a demandé un peu d'attention aussi. Lors de la construction initiale, j'ai ajouté deux ventilateurs d'extraction de 40 mm au-dessus du meuble, avec des conduits en PVC et de la mousse pour limiter les vibrations. Deux ventilateurs de 80 mm dans le rack et un contrôleur PWM ont aidé à équilibrer le flux d'air et le bruit. Dans une armoire au milieu d'un espace de vie, faire rentrer les machines ne résout que la moitié du problème. - -## Le lab en un coup d'œil - -![Une vue synthétique du lab, de la connexion Internet au réseau, au compute et au stockage partagé.](images/homelab-overview-simple.png) - -OPNsense gère le routage et le firewall, UniFi fournit le réseau filaire et le Wi-Fi, et les serveurs ont deux rôles principaux : Proxmox et Ceph hébergent les VM, tandis que TrueNAS fournit les fichiers partagés et les photos. Le schéma laisse volontairement de côté les VM individuelles, les segments réseau et les dépendances des applications. - -## Le matériel - -Les trois nœuds Proxmox sont des mini-PC différents : - -| Nœud | Matériel | CPU | RAM | -| --- | --- | --- | --- | -| vertex | ASRock DeskMini A300 | Ryzen 3 2200G, 4 cœurs / 4 threads | 16 GB | -| apex | Minisforum HM50 | Ryzen 5 4500U, 6 cœurs / 6 threads | 32 GB | -| zenith | T-bao MN57 | Ryzen 7 5700U, 8 cœurs / 16 threads | 32 GB | - -Chacun dispose d'un SSD de 256 GB pour le système, les ISO et les templates, ainsi que d'un NVMe de 1 TB pour Ceph. Une interface 1 Gbps transporte le trafic LAN et management, et une interface 2.5 Gbps séparée est dédiée à Ceph. - -Une quatrième machine, `granite`, est un Beelink ME mini avec un Intel N200 et 12 GB de RAM. Elle fait tourner TrueNAS indépendamment du cluster Proxmox. Cette séparation ne sert pas qu'au stockage. - -## Proxmox et deux rôles de stockage différents - -Le cluster tourne maintenant sous Proxmox VE 9. Il héberge la VM applicative, le firewall principal, les VM Kubernetes et celle de Hermes Agent, ainsi que les environnements LXC pour l'administration et OpenCode. - -Ceph tourne sur les trois mêmes nœuds physiques. Chacun apporte un NVMe, avec une réplication à trois copies sur le réseau dédié 2.5 Gbps. Il fournit le stockage partagé des VM et permet leur migration entre les nœuds Proxmox. - -Cela ne rend pas chaque application hautement disponible. `dockerVM` reste une seule VM contenant la plupart de mes services. Le cluster en dessous ne supprime pas les pannes à l'intérieur de cette VM ou de ses conteneurs. Les NVMe grand public et le réseau de stockage imposent aussi des limites concrètes aux performances, qui restent un sujet d'investigation. - -TrueNAS a un autre rôle. Son pool de stockage est un miroir de deux NVMe de 2 TB. Il fournit des partages SMB et NFSv4, notamment pour les données Nextcloud et les photos Immich. Ces partages sont distincts des disques des VM stockés sur Ceph. - -L'ancien conteneur NFS sur Vertex n'existe plus. TrueNAS est désormais le NAS, mais reste une machine unique, pas un autre cluster HA. La réplication, un miroir et des snapshots ne doivent pas non plus être confondus avec une stratégie complète de sauvegarde hors site. - -## Ne pas enfermer tout le réseau dans le même domaine de panne - -OPNsense ne tourne plus sur le boîtier dédié d'origine. Il y a maintenant deux VM firewall : - -- `cerbere-head1`, le principal, tourne sur Proxmox avec son disque sur Ceph. -- `cerbere-head2`, le secondaire, tourne sur TrueNAS avec son propre disque sur zvol. - -CARP assure la redondance des passerelles, pfSync synchronise l'état des connexions et XMLRPC synchronise la configuration. Placer le secondaire sur TrueNAS évite de perdre les deux VM firewall quand le cluster Proxmox ou Ceph est indisponible. Cela ne rend pas tout le reste du réseau domestique redondant. - -Le réseau physique utilise un UniFi Switch Lite 16 PoE, un Flex Mini 2.5G pour Ceph et un point d'accès U7 Pro Wall. L'application UniFi Network tourne dans un conteneur Docker sur `dockerVM`, pas comme plugin OPNsense. - -Le réseau est découpé en segments management, utilisateurs, IoT, DMZ et lab, avec des réseaux supplémentaires pour le WAN, la synchronisation des firewalls, le heartbeat Proxmox, Ceph et l'accès VPN. OPNsense gère le routage et les règles de firewall. Dnsmasq fournit le DHCP et les noms locaux, tandis qu'Unbound assure la résolution DNS récursive et le filtrage avec les blocklists Hagezi. WireGuard permet l'accès distant depuis mes appareils mobiles. - -### De HAProxy aux applications - -HAProxy a remplacé Caddy sur OPNsense. Pour les services HTTPS hébergés dans Docker, le chemin principal est le suivant : - -```text -HTTPS request → OPNsense HAProxy → Traefik on dockerVM → application -``` - -HAProxy distribue les connexions HTTPS en utilisant le SNI. Les services d'infrastructure empruntent une branche reverse proxy HTTPS séparée sur OPNsense ; ils ne passent pas tous par le Traefik de Docker. - -Le plugin ACME d'OPNsense gère le renouvellement des certificats d'infrastructure. Sa tâche de renouvellement tourne uniquement sur le firewall principal : synchroniser la configuration du proxy ne revient donc pas à rendre le renouvellement des certificats redondant. - -## Ce qui tourne ici - -La plupart des services du quotidien utilisent encore une stack Docker Compose par application sur `dockerVM`. - -| Usage | Services | -| --- | --- | -| Domotique | Home Assistant, Node-RED et InfluxDB | -| Fichiers, photos et mots de passe | Nextcloud, Immich et Vaultwarden | -| Médias | Jellyfin et la stack ARR | -| Code et publication | Gitea avec Actions, ce blog Hugo servi par Nginx et Umami | -| Administration | Semaphore UI, Portainer et l'application UniFi Network | -| Notifications | Ntfy | - -Le blog fait lui aussi partie du lab. Son contenu commence sous forme de Markdown dans mon vault Obsidian, passe par Gitea Actions et est généré par Hugo. Le résultat est servi par Nginx sur la même VM applicative. - -Les outils d'IA ont leurs propres environnements. Hermes Agent tourne dans une VM séparée, avec des profils pour l'orchestration, la recherche, l'ingénierie et la rédaction. OpenCode CLI reste dans un LXC. Ils m'aident dans le travail autour du lab ; je reste responsable de l'application des changements d'infrastructure. - -## Faciliter la reconstruction - -Le LXC `bastion` est mon environnement d'administration, avec SSH, Ansible, Terraform, OpenTofu, Helm et kubectl. Semaphore UI fournit une interface web pour lancer les automatisations. - -Chaque semaine, Semaphore reconstruit le template cloud-init Ubuntu Noble et envoie une notification via Ntfy. Terraform provisionne les VM Kubernetes et Ansible les prépare avant le bootstrap manuel avec kubeadm. - -Tout n'est pas encore automatisé. Les mises à jour des applications Docker restent manuelles, et reconstruire l'ensemble du lab depuis Git est encore un objectif, pas une capacité que je peux revendiquer aujourd'hui. - -## Kubernetes fonctionne, la migration n'est pas terminée - -Le cluster Kubernetes comprend six VM : trois nœuds control plane et trois workers. Il a été initialisé avec kubeadm et utilise Cilium. HAProxy répartit les accès à l'API Kubernetes, et des sessions BGP relient les workers Cilium à OPNsense. - -Il n'héberge encore aucune application. La gateway Traefik et cert-manager restent à déployer. L'instance Traefik qui dessert les applications Docker est une installation distincte, et le fait que Ceph héberge les disques des VM ne signifie pas que Kubernetes possède déjà une storage class Ceph. - -Le plan est de valider la gateway et les certificats, de définir le stockage et sa protection, puis de migrer les applications progressivement. GitOps viendra plus tard. Tout déplacer d'un coup irait à l'encontre de l'idée de conserver un environnement utile à la maison à côté d'un espace d'expérimentation. - -## Toujours en chantier - -Le setup est plus résilient que le serveur unique d'origine, mais il garde des limites évidentes. La plupart des applications dépendent de `dockerVM`, le NAS est une machine unique, et TrueNAS nécessite actuellement des redémarrages périodiques pour contourner une augmentation de l'utilisation mémoire non résolue. Le firewall secondaire vit sur cette machine : le problème ne concerne donc pas que le stockage des fichiers. - -Cela fait aussi partie du lab. Cette page en donne la vue d'ensemble ; les articles racontent comment les différents éléments sont arrivés là et ce qui change ensuite. - -## Les projets derrière cette page - -- [Construire le serveur TrueNAS]({{< ref "post/18-create-nas-server-with-truenas" >}}) -- [Déplacer la VM OPNsense secondaire sur TrueNAS]({{< ref "post/19-migrate-passive-opnsense-node-to-truenas" >}}) -- [Remplacer Caddy par HAProxy sur OPNsense]({{< ref "post/23-install-haproxy-opnsense-replace-caddy" >}}) -- [Préparer la migration de Docker Compose vers Kubernetes]({{< ref "post/24-roadmap-migrate-docker-applications-kubernetes" >}}) diff --git a/content/post/26-homelab-page-preview/index.md b/content/post/26-homelab-page-preview/index.md index c5302ae..359353d 100644 --- a/content/post/26-homelab-page-preview/index.md +++ b/content/post/26-homelab-page-preview/index.md @@ -20,8 +20,6 @@ More Raspberry Pis followed, then a mini PC in 2019, when I started experimentin Today, the lab has a three-node Proxmox cluster, distributed storage, a separate NAS and a redundant firewall pair. Most applications still run in Docker Compose. Kubernetes is running too, but moving the applications is the next part of the project, not something I've already finished. -This page describes the current setup. The articles go into the individual builds, migrations and occasional mistakes. - *Last reviewed: October 2026.* ## A lab inside a cupboard @@ -36,12 +34,6 @@ The rack is a DeskPi RackMate T1. It fits into the narrow enclosure, with shelve Cooling needed some attention too. During the original build, I added two 40 mm extraction fans above the cabinet, with PVC ducts and foam to limit vibration. Two 80 mm fans inside the rack and a PWM controller helped balance airflow and noise. In a cupboard in the middle of a living space, fitting the machines is only half the problem. -## The lab at a glance - -![A high-level view of the lab, from the internet connection to the network, compute and shared storage.](images/homelab-overview-simple.png) - -OPNsense handles routing and firewalling, UniFi provides switching and Wi-Fi, and the servers have two main jobs: Proxmox and Ceph host the VMs, while TrueNAS provides shared files and photos. The diagram deliberately leaves out individual VMs, network segments and application dependencies. - ## The hardware The three Proxmox nodes are different mini PCs: @@ -56,85 +48,77 @@ Each has a 256 GB SSD for the operating system, ISOs and templates, plus a 1 TB A fourth machine, `granite`, is a Beelink ME mini with an Intel N200 and 12 GB of RAM. It runs TrueNAS separately from the Proxmox cluster. That separation matters for more than storage. -## Proxmox and two different storage jobs +## Platform -The cluster now runs Proxmox VE 9. It hosts the application VM, the primary firewall, the Kubernetes VMs and the Hermes Agent VM, along with LXC environments for administration and OpenCode. +![Selected VMs inside the Proxmox cluster, with TrueNAS alongside it. The OPNsense Master and Backup VMs form one HA pair across the two hosting platforms.](images/homelab-hosting-overview.png) -Ceph runs on the same three physical nodes. Each contributes one NVMe drive, with three-way replication over the dedicated 2.5 Gbps network. It provides shared VM storage and supports migration between Proxmox nodes. +### Proxmox and Ceph -That does not make every application highly available. `dockerVM` is still one VM containing most of my services. A cluster underneath it does not remove failures inside that VM or its containers. Consumer NVMe drives and the storage network also put practical limits on performance, which remains a topic of investigation. +Proxmox VE 9 provides the virtualization layer across the three mini PCs. Ceph runs on the same physical nodes, using one NVMe drive per node and three-way replication over the dedicated 2.5 Gbps network. It provides shared VM storage and allows workloads to move between Proxmox nodes. -TrueNAS has a different role. Its storage pool is a mirror of two 2 TB NVMe drives. It provides SMB file sharing and NFSv4 shares, including Nextcloud data and Immich photos. Those shares are separate from the VM disks stored on Ceph. +That is the foundation for the lab, but it does not make every application highly available. A VM can still fail internally, and an application can still break inside a perfectly healthy VM. Consumer NVMe drives and the storage network also put practical limits on performance. -The old NFS container on Vertex is gone. TrueNAS is now the NAS, but it is still a single machine, not another HA cluster. Replication, a mirror and snapshots also should not be confused with a complete offsite backup strategy. +### TrueNAS -## Keeping the network outside one failure domain +TrueNAS runs on `granite`, outside the Proxmox cluster. Its storage pool is a mirror of two 2 TB NVMe drives, with SMB file sharing and NFSv4 shares for application data. Nextcloud files and Immich photos live here rather than inside their containers. -OPNsense no longer runs on the original dedicated firewall box. There are now two firewall VMs: +This is a different storage job from Ceph: Ceph holds VM disks, while TrueNAS provides shared files and photos. The old NFS container on Vertex is gone. TrueNAS also hosts the backup OPNsense VM, with its disk on a zvol, keeping that firewall outside the Proxmox and Ceph failure domain. -- `cerbere-head1`, the primary, runs on Proxmox with its disk on Ceph. -- `cerbere-head2`, the backup, runs on TrueNAS with its own zvol-backed disk. +### dockerVM -CARP provides gateway redundancy, pfSync synchronizes connection state, and XMLRPC synchronizes configuration. Putting the backup on TrueNAS avoids losing both firewall VMs when the Proxmox or Ceph cluster is unavailable. It does not make the rest of the home network redundant. +Most applications currently run on `dockerVM`, with one Docker Compose stack per application. Its VM disk lives on Ceph, while services that need shared data mount the relevant TrueNAS shares. -The physical network uses a UniFi Switch Lite 16 PoE, a Flex Mini 2.5G for Ceph, and a U7 Pro Wall access point. The UniFi Network Application runs as a Docker container on `dockerVM`, not as an OPNsense plugin. +Docker remains the everyday application platform. It is also a concentration point: most services depend on this one VM, updates are still manual, and recovering an application is not the same thing as restarting its VM elsewhere in the cluster. -The network is split into management, user, IoT, DMZ and lab segments, with additional networks for WAN, firewall synchronization, Proxmox heartbeat, Ceph and VPN access. OPNsense handles routing and firewall policy. Dnsmasq provides DHCP and local naming, while Unbound handles recursive DNS and Hagezi blocklists. WireGuard provides remote access for my mobile devices. +### Kubernetes -### From HAProxy to the applications +Kubernetes is the intended replacement for the Compose application platform. Its six VMs already run on Proxmox: three control-plane nodes and three workers, bootstrapped with kubeadm and connected with Cilium. Terraform provisions the VMs and Ansible prepares them before the manual cluster bootstrap. -HAProxy has replaced Caddy on OPNsense. For Docker-hosted HTTPS services, the main path is: +The foundation is running, but no applications have moved there yet. The Kubernetes Traefik gateway and cert-manager are still to be deployed, followed by storage and protection work before the gradual migration. GitOps comes later. The Traefik instance serving Docker applications today is a separate installation. -```text -HTTPS request → OPNsense HAProxy → Traefik on dockerVM → application -``` +## Network -HAProxy dispatches HTTPS connections using SNI. Infrastructure services use a separate HTTPS reverse-proxy branch on OPNsense; they do not all pass through Docker's Traefik. +### UniFi for switching and Wi-Fi -The OPNsense ACME plugin handles infrastructure certificate renewal. Its renewal job runs only on the primary firewall, so synchronized proxy configuration is not the same thing as redundant certificate renewal. +The physical network uses a UniFi Switch Lite 16 PoE, a Flex Mini 2.5G dedicated to Ceph, and a U7 Pro Wall access point. The UniFi Network Application runs as a container on `dockerVM` and manages those devices. -## What runs here +VLANs separate user devices, IoT equipment, the lab, the DMZ and management. There are also dedicated networks for the WAN, firewall synchronization, Proxmox heartbeat, Ceph and VPN access. UniFi carries the traffic; OPNsense decides what can cross between the routed segments. -Most of the everyday services still use one Docker Compose stack per application on `dockerVM`. +### OPNsense for routing and firewalling -| Purpose | Services | +The two firewall VMs are `cerbere-head1`, the Master on Proxmox, and `cerbere-head2`, the Backup on TrueNAS. CARP provides gateway redundancy, pfSync synchronizes connection state, and XMLRPC synchronizes configuration. + +Hosting the Backup on TrueNAS means that taking the Proxmox or Ceph cluster down does not take both firewall VMs with it. This improves the firewall's resilience, without pretending that every switch, cable or other component is redundant too. + +Dnsmasq provides DHCP and local naming. Unbound handles recursive DNS with Hagezi blocklists, and WireGuard provides remote access for my mobile devices. + +HAProxy runs on OPNsense and dispatches incoming HTTPS connections. Docker-hosted services go through Traefik on `dockerVM`; infrastructure interfaces use a separate HTTPS reverse-proxy branch on OPNsense. The OPNsense ACME plugin handles infrastructure certificate renewal on the primary firewall. + +## Applications + +The applications below still run on `dockerVM`. Some are services used at home, while others support the network, automation or the blog itself. + +| Application | What I use it for | | --- | --- | -| Home automation | Home Assistant, Node-RED and InfluxDB | -| Files, photos and passwords | Nextcloud, Immich and Vaultwarden | -| Media | Jellyfin and the ARR stack | -| Code and publishing | Gitea with Actions, this Hugo blog served by Nginx, and Umami | -| Administration | Semaphore UI, Portainer and the UniFi Network Application | -| Notifications | Ntfy | - -The blog is part of the lab too. Its content starts as Markdown in my Obsidian vault, moves through Gitea Actions, and is built by Hugo. The result is served by Nginx on the same application VM. - -AI tools have their own environments. Hermes Agent runs in a separate VM, with profiles for orchestration, research, engineering and writing. OpenCode CLI remains in an LXC. They help with the work around the lab; I remain responsible for applying infrastructure changes. - -## Making it easier to rebuild - -The `bastion` LXC is my administration environment, with SSH, Ansible, Terraform, OpenTofu, Helm and kubectl. Semaphore UI provides a web interface for automation runs. - -Every week, Semaphore rebuilds the Ubuntu Noble cloud-init template and sends a notification through Ntfy. Terraform provisions the Kubernetes VMs, and Ansible prepares them before the manual kubeadm bootstrap. - -Automation is not universal yet. Docker application updates remain manual, and rebuilding the entire lab from Git is still a goal rather than a capability I can claim today. - -## Kubernetes is running, the migration is not done - -The Kubernetes cluster has six VMs: three control-plane nodes and three workers. It was bootstrapped with kubeadm and uses Cilium. HAProxy balances access to the Kubernetes API, and BGP sessions connect the Cilium workers to OPNsense. - -There are no application workloads on it yet. The Traefik gateway and cert-manager are still to be deployed. The Traefik instance serving Docker applications is a different installation, and Ceph backing the VM disks does not mean Kubernetes already has a Ceph storage class. - -The plan is to validate the gateway and certificates, define storage and protection, then migrate applications progressively. GitOps comes later. Moving everything at once would defeat the point of keeping a useful home environment alongside a place to experiment. +| Home Assistant | Integrating connected devices and running home automation. | +| Node-RED | Visual automation flows alongside Home Assistant, including Daikin AC control. | +| InfluxDB | Storing historical Home Assistant data. | +| Nextcloud | File synchronization and collaboration, with its data on a TrueNAS share. | +| Immich | Managing photos and videos, with the photo library on TrueNAS. | +| Vaultwarden | Hosting a lightweight Bitwarden-compatible password manager. | +| Jellyfin | Serving the media library. | +| ARR stack | Automating media acquisition and organization with Sonarr, Radarr, Prowlarr and related tools. | +| Gitea | Hosting Git repositories and running CI/CD workflows with Gitea Actions. | +| Hugo blog | Generating this static website from Markdown in Obsidian, then serving it through Nginx. | +| Umami | Collecting web analytics for the blog. | +| Traefik | Routing requests to Docker applications behind OPNsense HAProxy and terminating their HTTPS connections. | +| UniFi Network Application | Managing the switches and Wi-Fi access point. | +| Semaphore UI | Launching Ansible and Terraform automation from a web interface. | +| Portainer | Inspecting and managing the Docker containers, stacks and logs. | +| Ntfy | Delivering push notifications from deployments, automation runs and media services. | ## Still a work in progress The setup is more resilient than the original single server, but it still has obvious limits. Most applications depend on `dockerVM`, the NAS is a single host, and TrueNAS currently needs periodic restarts to work around unresolved memory growth. The firewall backup lives on that host, so the issue matters beyond file storage. Those are part of the lab too. This page is the overview; the articles document how the pieces got here and what changes next. - -## The builds behind this page - -- [Building the TrueNAS server]({{< ref "post/18-create-nas-server-with-truenas" >}}) -- [Moving the backup OPNsense VM to TrueNAS]({{< ref "post/19-migrate-passive-opnsense-node-to-truenas" >}}) -- [Replacing Caddy with HAProxy on OPNsense]({{< ref "post/23-install-haproxy-opnsense-replace-caddy" >}}) -- [Planning the Docker Compose to Kubernetes migration]({{< ref "post/24-roadmap-migrate-docker-applications-kubernetes" >}})