Homelab Rebuild 2026 : du homelab au mini-datacenter

🌐 Aussi en: English · Deutsch · Español

Épisode 0 — Le projet commence. Il s’agit de la refonte de tout mon homelab — pas simplement d’un service de plus empilé sur le reste, mais d’une remise à plat de la manière dont l’environnement entier est construit et exploité. J’ai en fait déjà travaillé avec Kubernetes, dans une configuration assez proche de celle que je m’apprête à décrire. En mars, j’avais publié une première ébauche de cette idée. Pour des raisons que je n’arrive toujours pas à expliquer complètement, je me suis éloigné du plan initial et je ne l’ai jamais terminé. Cet article a depuis été retiré. Cette fois, je veux repartir de zéro — en suivant un plan étonnamment proche de celui que j’avais à l’époque. Comme d’habitude, ça a vite dégénéré.

• Cluster Proxmox à 3 nœuds
• Windows Server Active Directory
• Clients Windows 11
• Serveur de fichiers Windows
• PKI interne
• GitLab
• RKE2 Kubernetes
• FluxCD GitOps
• Longhorn & MinIO (traités dans de futurs articles)
• Supervision Icinga2
• Proxmox Backup Server

🎯 Objectif

Il ne s’agit pas de construire un datacenter de production. Il s’agit d’apprendre comment fonctionne l’informatique d’entreprise en en construisant une à la maison.

🖥️ Matériel

• HP1 — 64 GB RAM, SSD système 512 GB, SSD 2 TB
• HP2 — 32 GB RAM, SSD système 512 GB, SSD 2 TB
• HP3 — 32 GB RAM, SSD système 512 GB, SSD 3×2 TB (RAID5 logiciel)

Toutes les VM Linux tourneront sous Ubuntu Server 26.04 LTS comme système de base.

🏛️ Architecture 2026 : pas tout neuf, mais enfin proprement assemblé

Avant d’écrire cet article, j’ai exhumé un vieux document de planification datant de février — une tentative antérieure, jamais achevée, de cette même idée. Je m’attendais à trouver quelque chose de dépassé et j’en avais déjà jeté l’essentiel dans ma tête avant même de le relire. J’avais tort. Ce brouillon de février était déjà étonnamment proche de là où j’en suis arrivé aujourd’hui. Le plan d’adressage IP, la convention de nommage et la répartition des rôles entre Active Directory, PKI et supervision étaient en grande partie justes. Ce qui lui manquait, ce n’était pas une meilleure technologie — c’était un vrai modèle d’exploitation. Alors plutôt que de partir d’une page blanche, cette reconstruction prend l’ancien plan comme une « version 0.9 », garde ce qui tient encore la route, abandonne le reste et ajoute GitOps comme la pièce manquante qui relie le tout.

Ce qui a survécu de l’ancien plan

• Plage IP et domaine — 192.168.10.x/24 sur le réseau interne, avec home.arpa comme suffixe de domaine. home.arpa est le TLD officiellement réservé aux réseaux domestiques — un petit détail que l’ancien plan avait déjà bien vu.
• Une convention de nommage lisible — au lieu de noms génériques du style VM11/VM12, chaque VM suit le schéma <host>-<role>-<number>, par exemple HP1-gitlab01 ou HP2-fs01. Rien qu’en lisant le nom, on sait où quelque chose tourne et ce qu’il fait. Les hôtes eux-mêmes portent le nom de la plage IP qui leur revient : HP1 pour les 30, HP2 pour les 40, HP3 pour les 50.
• Deux contrôleurs de domaine — HP1-dc01 (DNS, rôles FSMO, CA racine) et HP2-dc02 (DNS, catalogue global), répartis sur deux hôtes Proxmox différents pour la redondance.
• Une vraie hiérarchie PKI — CA racine hors ligne → CA émettrice → serveurs et clients, au lieu d’une seule CA à plat. Plus proche de ce que ferait une vraie organisation.
• Icinga2 pour la supervision classique de l’infrastructure (Proxmox, Windows Server, VM, réseau) — Kubernetes obtient à la place sa propre pile Prometheus/Grafana, plutôt que de forcer un seul outil à couvrir les deux mondes.
• GitLab, promu de « simple dépôt Git » au rang de plateforme centrale pour le code source, la CI/CD, le registre de conteneurs et le dépôt GitOps que FluxCD surveille.
• Vault (ou OpenBao) pour la gestion des secrets — conservé, mais volontairement repoussé en phase 2 plutôt que d’en faire une dépendance dès le premier jour, afin que la mise en place initiale de Kubernetes/GitOps ne soit pas bloquée par une gestion des secrets parfaite d’emblée.

Ce que je laisse volontairement de côté

Un homelab a tendance à se transformer en collection de technologies « ça aussi, ce serait intéressant ». Cette reconstruction doit démontrer une architecture réfléchie, pas un empilement de technologies — alors quelques éléments de l’ancien plan sont abandonnés exprès :

• Regrouper plusieurs services sur une seule VM (par exemple GitLab + Pi-hole + Grafana + Nextcloud ensemble). Plus difficile à sauvegarder, plus difficile à maintenir et moins réaliste. Une VM, une mission.
• Un serveur NAS séparé. Entre le serveur de fichiers Windows, le stockage propre à Proxmox et Longhorn/MinIO pour Kubernetes, une quatrième plateforme de stockage ajouterait de la complexité sans ajouter de capacités.
• NFS comme backend de stockage pour Kubernetes. Longhorn est conçu précisément pour cela et c’est la meilleure façon d’apprendre vraiment le stockage sous Kubernetes.
• Faire tourner Nextcloud en dehors de Kubernetes. C’est une charge de travail vraiment formatrice — ingress, stockage, base de données, secrets, sauvegarde — elle a donc sa place dans le cluster, pas à côté.
• Empiler plusieurs systèmes de supervision qui se chevauchent (Icinga + Zabbix + Nagios + Prometheus en même temps). Un outil par couche suffit : Icinga2 pour l’infrastructure classique, Prometheus/Grafana pour Kubernetes.
• Une appliance pare-feu dédiée (par exemple une VM pare-feu séparée basée sur FreeBSD). Intéressante en soi, mais c’est un projet à part entière qui ferait perdre de vue l’objectif de celui-ci.

Le plan consolidé des VM & des IP

Le placement des VM suit la RAM réellement disponible sur chaque hôte : HP1 a le plus de RAM (64 GB), il porte donc l’essentiel de la charge générale et du control plane. HP3 a moins de RAM mais le gros pool de stockage RAID5 ; il héberge donc moins de VM, mais reste le foyer naturel des workers Kubernetes gourmands en stockage. HP2 complète l’ensemble avec le serveur de fichiers, le second contrôleur de domaine et les workers restants.

VM	Rôle	IP	RAM	Disque
HP1-dc01	AD / DNS / CA racine	192.168.10.x	4 GB	60 GB
HP1-gitlab01	GitLab / registre de conteneurs	192.168.10.x	8 GB	120 GB
HP1-seed01	VM de dev (Ansible, kubectl, outillage)	192.168.10.x	4 GB	60 GB
HP1-vault01	Gestion des secrets (phase 2)	192.168.10.x	2 GB	40 GB
HP1-icinga01	Supervision	192.168.10.x	4 GB	60 GB
HP1-k8s-cp01	Control plane RKE2	192.168.10.x	8 GB	80 GB
HP1-k8s-cp02	Control plane RKE2	192.168.10.x	8 GB	80 GB
HP2-fs01	Serveur de fichiers Windows	192.168.10.x	8 GB	200 GB
HP2-dc02	AD / DNS / catalogue global	192.168.10.x	4 GB	60 GB
HP2-k8s-w03	Worker	192.168.10.x	8 GB	100 GB
HP2-k8s-w04	Worker	192.168.10.x	8 GB	100 GB
HP3-pihole01	Filtre DNS	192.168.10.x	1 GB	20 GB
HP3-k8s-cp03	Control plane RKE2	192.168.10.x	8 GB	80 GB
HP3-k8s-w01	Worker	192.168.10.x	8 GB	150 GB
HP3-k8s-w02	Worker	192.168.10.x	8 GB	150 GB

Toutes ces VM doivent être provisionnées automatiquement avec Terraform, plutôt qu’assemblées à la main à coups de clics dans l’interface Proxmox — un premier pas délibéré pour traiter tout le homelab comme du code, et pas seulement la couche Kubernetes posée dessus.

Le stockage, simplifié

Proxmox Storage (HP3)
    ZFS RAIDZ1 → VM storage, snapshots

Kubernetes Storage
    Longhorn → Persistent Volumes

Backup
    Proxmox Backup Server → VM backup

Pas de boîtier NAS supplémentaire au milieu — le stockage ZFS propre à Proxmox et Longhorn couvrent les deux mondes.

Les cinq piliers

                Homelab 2026

        +-----------------------+
        |                       |
   Classic IT              Cloud Native

   Active Directory        RKE2
   Windows                 FluxCD
   SMB                     GitOps
   PKI                     Longhorn

        +-----------------------+

              Proxmox

        +-----------------------+

              Backup (PBS)

Le but de cette reconstruction n’est pas « j’ai installé 25 technologies ». C’est plutôt : je construis chez moi une petite plateforme façon entreprise et je l’exploite comme le font réellement les équipes plateforme modernes — avec GitOps comme colonne vertébrale reliant l’infrastructure classique au monde cloud native.

📐 GitOps d’abord

Tout ce qui concerne Kubernetes vivra dans GitLab. Git est l’unique source de vérité et FluxCD synchronise le cluster en continu. Pas de dérive de configuration manuelle.

📝 Documentation

Tout — décisions d’architecture, configurations, leçons apprises et erreurs — sera documenté publiquement sur https://www.github.com/aptupgrademe/rebuild_2026. L’objectif est d’aider les autres tout en me constituant ma propre base de connaissances.

🤖 L’IA comme partenaire d’apprentissage

Contrairement à mes précédentes expériences avec Kubernetes, ce projet s’appuiera largement sur Claude comme partenaire de sparring technique pour comprendre les concepts, relire les configurations, résoudre les problèmes et améliorer la documentation. L’IA est là pour accélérer l’apprentissage — pas pour remplacer la compréhension.

🗺️ Feuille de route sur six mois

1. Cluster Proxmox & réseau
2. Active Directory, Windows 11 & services de fichiers
3. GitLab & VM seed de développement
4. RKE2 Kubernetes
5. FluxCD GitOps
6. Applications (WordPress, Nextcloud, …)
7. PKI
8. Supervision, sauvegarde & durcissement

Chaque étape fera l’objet de son propre article. Celui-ci est volontairement la vue d’ensemble — le début du voyage.

🔜 Et ensuite ?

Le prochain article portera sur le matériel, le réseau et l’installation initiale du cluster Proxmox. Bienvenue au début d’une aventure de six mois.

---

📚 Dans la même série : Homelab Rebuild 2026 (en anglais)

• Homelab Rebuild 2026 — Building the Proxmox Cluster and Provisioning It with Terraform
• Homelab Rebuild 2026 — Active Directory, Pi-hole Laundering, and a Drive Letter That Refuses to Exist
• Homelab Rebuild 2026 — GitLab, a Seed VM, and the Calm Before the Kubernetes Storm
• Homelab Rebuild 2026: Wait and See – A Server Crash, a Dead-End Advisory, and My New Prime Suspect