Auto-update blog content from Obsidian: 2026-10-18 08:59:50

2026-10-18 08:59:50 +00:00
parent a042099223
commit ee35da62d8
6 changed files with 280 additions and 0 deletions
@@ -0,0 +1,140 @@
 ---
 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" >}})
@@ -0,0 +1,140 @@
 ---
 slug: homelab-page-preview
 title: Homelab page preview
 description: Inside my compact homelab, with Proxmox, Ceph, TrueNAS and OPNsense, the services it runs today and my ongoing Kubernetes migration project.
 date: 2026-10-18
 draft: true
 tags:
  - proxmox
  - ceph
  - truenas
  - opnsense
 categories:
  - homelab
 image: cover-26.webp
 ---
 My homelab started in 2013 with the first Raspberry Pi. I wanted a cheap machine to learn Linux, and it became a basic NAS called Vezpibox. The name hasn't aged particularly well.
 More Raspberry Pis followed, then a mini PC in 2019, when I started experimenting with virtualization and Docker at home. Eventually, that single server became a problem: it was both my playground and the machine keeping useful things running. Breaking a test environment is one thing. Taking the lights or the internet down with it is another.
 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
 The original idea was to build a tiny datacenter in a closet. Space, noise, power consumption and budget all mattered, so the setup grew around compact machines rather than rack servers.
 ![The homelab enclosure open and closed, next to the kitchen. The available space is part of the design, not an unlimited server room.](images/homelab-enclore-open-closed.png)
 The rack is a DeskPi RackMate T1. It fits into the narrow enclosure, with shelves and a power strip to make use of the available space. With the door closed, the lab disappears into the apartment.
 ![The original rack layout. The router and HDD labels show the earlier setup; the current firewall and storage architecture is described below.](images/homelab-rack-legend.png)
 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:
 | Node | Hardware | CPU | RAM |
 | --- | --- | --- | --- |
 | vertex | ASRock DeskMini A300 | Ryzen 3 2200G, 4 cores / 4 threads | 16 GB |
 | apex | Minisforum HM50 | Ryzen 5 4500U, 6 cores / 6 threads | 32 GB |
 | zenith | T-bao MN57 | Ryzen 7 5700U, 8 cores / 16 threads | 32 GB |
 Each has a 256 GB SSD for the operating system, ISOs and templates, plus a 1 TB NVMe drive for Ceph. A 1 Gbps interface carries LAN and management traffic, and a separate 2.5 Gbps interface is dedicated to Ceph.
 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
 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.
 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.
 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.
 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.
 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.
 ## Keeping the network outside one failure domain
 OPNsense no longer runs on the original dedicated firewall box. There are now two firewall VMs:
 - `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.
 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.
 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.
 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.
 ### From HAProxy to the applications
 HAProxy has replaced Caddy on OPNsense. For Docker-hosted HTTPS services, the main path is:
 ```text
 HTTPS request → OPNsense HAProxy → Traefik on dockerVM → application
 ```
 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.
 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.
 ## What runs here
 Most of the everyday services still use one Docker Compose stack per application on `dockerVM`.
 | Purpose | Services |
 | --- | --- |
 | 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.
 ## 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" >}})