Mon homelab de zéro (Partie 5) : penser l'architecture avant de tout reconstruire

Dans les parties 1 à 4, on a passé beaucoup de temps sur le réseau : état des lieux, refonte complète, installation de l’UniFi, et même un backup 5G pour le jour où la fibre décide de faire des siennes. Le réseau est propre, segmenté, fiable. Bref, les fondations sont posées. Il ne me reste qu’un peu de cosmétique à faire dans la baie avec du câblage propre, des impressions 3D, l’ajout de l’onduleur, … J’ai déjà commencé ces sujets mais avec la canicule je mets ça en stand-by et je préfère me concentrer sur la théorie du homelab plutôt que de mettre en route une imprimante 3D à 210°C. Je reprendrai plus tard et je documenterai évidemment dans un article dédié ces dernières finitions de la baie principale.

Maintenant, on attaque la partie qui me démange depuis le début : le homelab lui-même. Les serveurs, la virtualisation, les services. Mais avant de brancher quoi que ce soit et de lancer la moindre installation, je vais faire quelque chose qui peut sembler contre-intuitif quand on a envie de mettre les mains dedans : je vais tout réfléchir d’abord, sur le papier (enfin l’écran mais vous m’avez compris).

Documenter ses décisions : la démarche ADR

#

Au boulot, j’ai pris une habitude que je trouve excellente et que je voulais absolument appliquer à ce projet : documenter les décisions d’architecture sous forme d’ADR (Architecture Decision Records). Le principe est tout bête : pour chaque choix technique un peu structurant, on écrit un petit paragraphe qui répond à quatre questions. Quel est le contexte ? Quelles étaient les options ? Quelle est la décision ? Et surtout, pourquoi ?

L’intérêt, ce n’est pas de faire joli. C’est que dans six mois, quand je me demanderai “mais pourquoi j’ai choisi ça déjà ?”, j’aurai la réponse écrite noir sur blanc, avec le raisonnement de l’époque. Et si je change d’avis plus tard, je ne réécris pas l’histoire : je marque l’ancienne décision comme dépassée et je documente la nouvelle. C’est honnête, c’est traçable, et franchement ça force à réfléchir avant d’agir.

Tout cet article, c’est en réalité la version racontée de mon document d’ADR. J’ai pris une vingtaine de décisions avant d’écrire la moindre ligne de code, et je vais vous les dérouler par thème.

Ma grille de décision

#

Avant de plonger dans les choix, il faut poser le cadre. Parce qu’un “bon” choix technique n’existe pas dans l’absolu : il est bon pour un contexte donné. Le mien tient en trois critères, et l’ordre compte :

1. La valeur d’apprentissage. À choix techniques équivalents, je prends celui qui m’apprend le plus. Ce homelab est avant tout un terrain de jeu pour monter en compétence : Kubernetes, GitOps, réseau, gestion des secrets. Si une techno me fait progresser, elle part avec un avantage.
2. La disponibilité. Quand un choix touche un service qui doit tenir debout, la robustesse prime. Mais attention : ici, la haute disponibilité sert surtout à apprendre la haute disponibilité. C’est un lab de test, pas un socle critique dont dépendent des services de production, en tout cas pas pour l’instant.
3. Le budget. Je fais avec le matériel existant en priorité, et je n’achète que si l’existant ne suffit vraiment pas.

Ces trois critères, vous allez les voir revenir en permanence dans la suite. Chaque fois que j’ai tranché entre deux options, c’est l’un d’eux qui a fait pencher la balance.

Ce que je veux en faire

#

Soyons clairs sur l’usage, ça évite de sur-dimensionner. Ce lab me sert à deux choses : tester des infrastructures (jouer avec des technos, casser des trucs, recommencer) et auto-héberger des services que j’utilise aujourd’hui dans le cloud, principalement pour les essayer. Pas de service “famille” critique à ce stade. Personne ne va râler si je fais tomber le cluster un dimanche après-midi pour tester une bascule.

Le principe directeur : tout doit se redéployer depuis git

#

S’il y a bien une idée qui structure tout le reste, c’est celle-là : tout doit pouvoir se reconstruire automatiquement à partir de mes dépôts GitLab, à l’identique, sans effort.

L’Infrastructure as Code (IaC) n’est pas un accessoire que je rajouterai “quand j’aurai le temps”, c’est le principe de départ. Si demain les trois machines prennent feu (ce que je n’espère pas mais que j’ai quand même couvert avec un détecteur de fumée dédié au lab), je dois pouvoir tout reconstruire depuis le code. C’est cette contrainte qui explique une bonne partie des décisions qui suivent.

Le matériel avec lequel je compose

#

On ne part pas de rien : j’ai déjà quatre machines qui dormaient dans le homelab. Plutôt que de racheter, je compose avec.

Trois OptiPlex 7050 identiques, ça tombe bien pour monter un cluster homogène. Et un 9020 un peu plus ancien et plus léger, parfait pour un rôle à part.

Côté réseau, chaque OptiPlex a un unique port 1 GbE intégré. Tout est raccordé sur le switch 2.5G (pas encore documenté mais il s’agit d’un USW-Flex-2.5G-8-PoE), dans le VLAN de lab dédié (192.168.3.0/24, passerelle en .1) — celui qu’on a préparé dans les épisodes réseau. Pour le provisionnement à distance, j’ai aussi un JetKVM, un petit boîtier KVM-over-IP qui me permet de monter des ISO à distance et de garder un accès console même quand la machine ne répond plus. On en reparlera, c’est un outil clé de la démarche “tout en code”.

Un point à garder en tête, parce qu’il va revenir sans arrêt : la ressource rare ici, c’est la RAM. Avec 24 Go par nœud, chaque brique logicielle se juge aussi à ce qu’elle coûte en mémoire. Un composant qui mange 4 Go de RAM “pour faire joli”, je ne peux pas me le permettre. Cette contrainte a éliminé plusieurs candidats, vous allez voir.

Deux leviers d’upgrade sont identifiés si jamais ça coince : passer les 7050 à 32 Go (il me semble que c’est le maximum compatible avec le CPU) et le 9020 à 16 Go (l’achat le plus rentable), et ajouter une carte réseau 2.5 GbE en M.2 pour exploiter enfin le switch. Mais je ne les active que si c’est vraiment nécessaire. Budget d’abord.

Le socle : Proxmox en cluster 3 nœuds

#

Première grande décision, la plus fondatrice : l’hyperviseur. C’est la couche sur laquelle tout le reste va tourner.

Le choix s’est porté sur Proxmox VE 9.2 sans trop d’hésitation. J’ai regardé les alternatives (XCP-ng, ESXi), mais ESXi est sorti de l’équation depuis le rachat par Broadcom et le grand n’importe quoi sur les licences, et Proxmox reste le standard du homelab : libre, mature, basé sur Debian, avec le clustering et la réplication intégrés, et un écosystème as-code très riche (Ansible, OpenTofu, Packer le supportent tous). Il coche à la fois la case apprentissage et la case budget (c’est gratuit). Facile.

Ensuite, comment agencer les quatre machines ? Là, un piège classique : la tentation de mettre les quatre en cluster. Sauf qu’un cluster à 4 nœuds, c’est un nombre pair, et un nombre pair de votants c’est le risque du split-brain (deux moitiés de 2 nœuds qui ne se départagent pas). J’ai donc tranché pour un cluster de 3 nœuds (les trois 7050 identiques) et le 9020 sorti du cluster, dédié aux sauvegardes avec Proxmox Backup Server.

Deux bonnes raisons à ça. D’abord, un nombre impair de nœuds donne un quorum sain sans avoir à bricoler un QDevice. Ensuite, c’est une bonne pratique de sortir la cible de sauvegarde de ce qu’elle protège : si le cluster part en vrille, les backups, eux, sont sur une machine indépendante. Conséquence assumée : je tolère la perte d’un nœud sans broncher, mais la perte de deux nœuds rend le cluster non fonctionnel. Pour un lab, c’est parfaitement acceptable.

La haute dispo, oui, mais avec de la réplication ZFS

#

Qui dit cluster et haute disponibilité dit stockage. Deux écoles s’affrontent ici : Ceph (le stockage distribué hyperconvergé, la Rolls du genre) ou la réplication ZFS asynchrone entre nœuds.

J’aurais adoré faire du Ceph, sincèrement, pour l’apprentissage. Mais Ceph, c’est gourmand : comptez environ 4 Go de RAM par OSD et un réseau d’au moins 10 GbE pour que ça respire. Ma RAM est rare et mon réseau est en 1 GbE. Bref, ce serait un peu compliqué avec ce matériel. J’ai donc opté pour la réplication ZFS entre les trois nœuds : Proxmox réplique périodiquement les disques des VM d’un nœud à l’autre, et en cas de panne, la VM redémarre sur un autre nœud avec les données de la dernière réplication.

Le compromis, c’est que ce n’est pas du zéro-perte : on perd ce qui s’est passé entre deux réplications. Pour un lab, c’est très largement suffisant. Et Ceph, je le garde sous le coude comme sujet d’apprentissage pour le jour où j’aurai le réseau et la RAM pour l’accueillir dignement.

Le stockage : ZFS là où il gagne sa place

#

Chaque 7050 a deux disques : un SSD SATA de 256 Go et un NVMe de 512 Go. Plutôt que de tout mélanger, je répartis les rôles.

• L’OS Proxmox va sur le SSD SATA, en ext4/LVM tout ce qu’il y a de classique. L’espace libre restant sert de datastore local pour les ISO, templates et autres dumps.
• Les VM et conteneurs vont sur le NVMe, dans un pool ZFS (avec le même nom de pool sur les trois nœuds, indispensable pour la réplication, et l’ARC ZFS bridé à 4-6 Go pour ne pas qu’il dévore la RAM).

Pourquoi ce découpage ? Le NVMe est plus gros et plus rapide, donc il accueille ce qui grossit et ce qui a besoin d’I/O. Et je ne mets ZFS que là où il apporte vraiment quelque chose : les checksums, les snapshots, la réplication. Mettre ZFS sur le disque système ne servirait à rien : l’hôte est entièrement reproductible depuis le code, donc en cas de pépin je réinstalle, je ne restaure pas. Autant garder le système simple. La contrepartie, c’est qu’il n’y a pas de redondance à l’intérieur d’un nœud (un seul disque par pool), mais c’est compensé par la réplication entre nœuds et par les backups.

Une exception pour le serveur de backup

#

Petite subtilité qui va à l’encontre de mon intuition de départ (“du ZFS partout !”). Le nœud de sauvegarde, le 9020, n’a que 8 Go de RAM. Or Proxmox Backup Server fait déjà sa propre vérification d’intégrité des données qu’il stocke (des jobs qui vérifient les chunks régulièrement). Les checksums de ZFS feraient donc double emploi, et l’ARC de ZFS gaspillerait une RAM déjà comptée. Résultat : le datastore de PBS sera en ext4, tout simplement. L’intégrité est assurée par PBS lui-même, et je garde de la simplicité sur une machine contrainte. Comme quoi, “la meilleure techno” cède parfois la place à “la techno adaptée au contexte”.

Le cœur du projet : tout en code

#

On arrive à la partie qui me tient le plus à cœur, celle qui donne son sens à toute la démarche. Rappelez-vous le principe directeur : tout doit se reconstruire depuis git. Voici la chaîne d’outils qui rend ça possible, couche par couche.

L’installation des serveurs eux-mêmes. Même le bare-metal doit être reproductible. Proxmox 9 propose une installation automatisée via un fichier de réponse (un TOML qui décrit tout : disques, réseau, mots de passe…). Ce fichier vit dans git. Pour déclencher l’install à distance sans clé USB, je monte l’ISO via le JetKVM. C’est la seule étape que j’assume comme “semi-manuelle” : il faut déclencher l’installation nœud par nœud. Mais ce qui est installé est entièrement décrit par le code.

La configuration des hôtes et la création du cluster. Une fois Proxmox installé, il faut configurer les dépôts, le réseau, ZFS, et surtout créer le cluster et les jobs de réplication. Ça, c’est le boulot d’Ansible (avec le rôle lae.proxmox). Pourquoi Ansible ici et pas l’outil de la couche suivante ? Parce que la création du cluster est précisément le maillon que les outils de provisionnement déclaratif ne savent pas faire. Ansible me resservira aussi pour configurer l’intérieur des VM.

Le provisionnement des VM et conteneurs. Une fois le cluster debout, je crée mes VM et LXC avec OpenTofu (le fork libre de Terraform) et le provider bpg/proxmox. Le choix d’OpenTofu plutôt que Terraform n’est pas idéologique : OpenTofu propose le chiffrement du state côté client, nativement, ce que le Terraform en ligne de commande n’a pas. Et comme le state contient des secrets en clair, c’est décisif (on y revient juste après). Ajoutez à ça une licence ouverte, une gouvernance sous la Linux Foundation cohérente avec mes autres choix et un provider bpg qui supporte explicitement OpenTofu et couvre VM, LXC, SDN et HA. Le vieux provider Telmate a été écarté, il n’est plus assez maintenu.

Les images de base. Pour que la création des VM soit vraiment reproductible, il faut des templates versionnés. C’est le rôle de Packer, qui construit des images cloud-init propres et rejouables. Pour Talos (mon futur Kubernetes, on y arrive), l’image vient de la Talos Image Factory.

Le dépôt et la CI/CD. Tout ça vit dans un monorepo GitLab, avec un dossier par couche (answer-files/, ansible/, tofu/, packer/, argocd/). La CI/CD GitLab fait le plan et le lint sur chaque merge request, et le apply au merge. Détail important : les runners partagés de GitLab.com ne peuvent pas atteindre mon réseau local, donc il me faut un runner self-hosted, dans un LXC dédié, pour exécuter les apply. Et des hooks pre-commit (gitleaks, tflint, ansible-lint) montent la garde pour éviter qu’une bêtise ou un secret en clair ne parte dans un commit.

Le state OpenTofu. Le fichier d’état (le state, qui décrit ce qui existe réellement) est stocké dans le backend HTTP managé par GitLab, et par-dessus je chiffre le state côté client avec la passphrase gérée par SOPS. Le state ne vit jamais dans git, et même si le backend fuitait, il resterait illisible. Défense en profondeur. Et le token API que j’utilise pour piloter Proxmox est scopé et révocable, ce n’est surtout pas le mot de passe root.

Les secrets : une seule mécanique partout

#

Un repo privé n’est pas un coffre-fort : l’historique git est éternel, un secret commité par erreur y reste pour toujours. Il me fallait donc une vraie gestion des secrets. J’ai comparé Ansible Vault (trop limité à Ansible), Vault/OpenBao (lourd, et un point unique de défaillance s’il tourne dans le cluster qu’il est censé sécuriser), un coffre externe type Bitwarden… et j’ai choisi SOPS + age.

Le principe : les secrets sont chiffrés dans le repo, mais SOPS ne chiffre que les valeurs, pas la structure. Les diffs restent donc lisibles (on voit quelle clé a changé, pas sa valeur). Et surtout, une seule mécanique sert à tout le monde : Ansible (via community.sops) et OpenTofu (via le provider carlpett/sops) lisent les mêmes secrets. C’est du GitOps pur, sans dépendance externe ni point unique de défaillance. Bonus : c’est un outil que je ne connais pas encore, donc case apprentissage cochée.

La racine de confiance, c’est la clé privée age. Elle vit hors de git, sur mon ordi et en variable protégée dans la CI/CD, avec une copie de secours dans Bitwarden (mon gestionnaire de mot de passe) au cas où. C’est le seul secret que je dois protéger manuellement, tout le reste en découle.

Et cette mécanique, je la prolonge jusque dans Kubernetes. Plutôt que de réintroduire un coffre externe que j’avais écarté, j’utiliserai KSOPS : ArgoCD déchiffre les secrets SOPS-age au moment du déploiement. Une seule et même logique du bare-metal jusqu’aux pods, des secrets chiffrés dans git, et une rotation qui se résume à un commit. Cohérent avec le “tout reconstructible depuis git” de bout en bout.

Réseau, noms et certificats

#

Le réseau physique, on l’a déjà traité dans les épisodes précédents. Ici, il s’agit surtout du plan d’adressage et de deux ou trois choix logiques.

Tout le lab vit dans le VLAN 192.168.3.0/24, avec un plan d’adressage carré :

Concernant Corosync (le service qui assure la communication entre nœuds du cluster), je le laisse pour l’instant sur le lien 1 GbE partagé. À trois nœuds et sur un lab peu chargé, c’est acceptable. Si je constate des retransmissions Corosync plus tard, l’upgrade est clair : ajouter une carte 2.5 GbE dédiée pour isoler le trafic du cluster. Mais pas d’achat prématuré.

Un vrai domaine et un DNS pilotable en code

#

Un choix que je trouve important : abandonner le .lan au profit d’un vrai domaine, ktw.ovh, dédié au lab. Pourquoi ? Parce que le .lan interdit d’obtenir des certificats publics valides, et je ne veux pas passer mon temps à cliquer sur “accepter le certificat non sécurisé”. Avec un vrai domaine, j’ai un espace de nommage cohérent (pve01.ktw.ovh, argocd.ktw.ovh…) et des certificats valides même en interne.

Pour la résolution interne, j’utiliserai Technitium en split-horizon (il répond différemment selon qu’on interroge depuis l’intérieur ou l’extérieur). Je l’ai choisi parce qu’il expose une API complète — donc pilotable en code, forcément — qu’il gère le split-horizon nativement, et qu’il tourne dans un petit LXC léger. Fidèle au principe : tout ce qui peut être décrit en code doit l’être.

Des certificats valides, sans rien exposer

#

Les certificats, justement : Let’s Encrypt via le challenge ACME DNS-01 sur l’API OVH de ktw.ovh. L’astuce du DNS-01, c’est qu’il prouve que je possède le domaine en créant un enregistrement DNS temporaire, sans avoir à exposer quoi que ce soit sur Internet. Comme .ovh est géré par OVH, l’API DNS est supportée nativement par les clients ACME (Traefik, cert-manager…). Le token OVH est scopé à la seule zone DNS et rangé dans SOPS. Résultat : une chaîne de certificats entièrement automatisée, des certificats valides partout en interne, et zéro service exposé. La zone publique ktw.ovh ne sert qu’à ça, elle n’a aucun enregistrement A public.

Les workloads : deux étages, Docker et Kubernetes

#

Voilà une décision qui pourrait surprendre : je ne choisis pas entre Docker et Kubernetes, je fais les deux, à deux étages.

Je suis déjà à l’aise avec Docker et Compose, et je veux progresser sérieusement sur Kubernetes, que je ne connais que dans les grandes lignes. Plutôt que de me forcer à tout faire en k8s (et de galérer pour déployer le moindre petit service), je monte :

• Un étage Docker avec Dokploy (dans un LXC), qui tire depuis git et me permet de déployer un service en deux minutes. C’est mon tier de confort.
• Un étage Kubernetes avec Talos, pour apprendre pour de vrai.

L’intérêt de ce duo, au-delà du confort, c’est qu’il m’offre un terrain d’observabilité génial : pouvoir comparer les deux paradigmes côte à côte. Et il y a une logique de disponibilité : mon confort ne dépend pas de la santé de mon cluster k8s d’apprentissage, que je vais forcément casser de temps en temps. La seule contrainte, c’est la RAM (encore elle) : je dimensionne modestement et j’évite de pousser les deux étages à fond en même temps.

La pile Kubernetes

#

Pour le cluster k8s, j’ai volontairement choisi des briques standard de l’industrie. L’idée : que chaque heure passée dessus ait une valeur au-delà de mon lab, tout en restant abordable pour un profil qui n’est pas expert sur k8s.

• Talos comme OS : trois VM qui combinent control-plane et worker (une par nœud physique), avec etcd à trois pour la haute dispo. Talos est un OS Linux minimaliste, immuable, entièrement piloté par API. Zéro SSH, tout en code : exactement dans l’esprit du projet.
• Cilium comme CNI (la couche réseau des pods), qui remplace kube-proxy et apporte l’observabilité de Hubble.
• Longhorn pour le stockage persistant répliqué. C’est un choix de débutant assumé, simple à prendre en main ; je garde democratic-csi vers ZFS pour plus tard, quand je voudrai aller plus loin.
• Traefik comme ingress, avec la gestion ACME intégrée (qui s’articule pile avec mon choix de certificats plus haut).
• ArgoCD pour le GitOps, avec le pattern app-of-apps. Tout ce qui tourne dans le cluster est décrit dans git et déployé par ArgoCD. On boucle la boucle du “tout reconstructible”.

L’observabilité : une seule vitre, trois mondes

#

C’est un peu ma déformation professionnelle, mais je ne conçois pas une infra sans savoir ce qui s’y passe.

L’objectif : un seul Grafana qui agrège trois mondes différents. Les métriques de Kubernetes (via kube-prometheus-stack), celles de Proxmox (via prometheus-pve-exporter) et celles de l’étage Docker (via cAdvisor et node_exporter). Le tout collecté par Grafana Alloy (métriques et logs) et envoyé vers Loki pour les logs. Pouvoir comparer sur un même écran l’hyperviseur, Docker et Kubernetes, c’est extrêmement formateur.

Et fidèle au principe “on observe depuis l’extérieur”, je mettrai probablement un Uptime Kuma ailleurs, indépendant du cluster qu’il surveille. Même logique que le serveur de backup hors cluster : le veilleur ne doit pas tomber en même temps que ce qu’il veille.

Résilience et sécurité

#

Deux derniers sujets, vite fait mais essentiels.

Les sauvegardes, avec la bonne vieille règle 3-2-1 abordée par paliers. PBS sauvegarde les VM et LXC. Longhorn sauvegarde ses volumes vers une cible S3. Pour l’externalisation (le “1” de 3-2-1), je démarre avec un simple disque USB chiffré, puis j’évoluerai vers Backblaze B2 ou équivalent quand ce sera pertinent. Budget d’abord, robustesse ensuite. Et une distinction que je trouve importante : git redéploie la plateforme, les backups restaurent les données. Deux chemins de reprise bien distincts.

Le firewall. Je démarre avec le firewall natif de Proxmox, largement suffisant tant que rien n’est exposé. J’évaluerai peut-être OPNsense une fois le cluster en place.

L’architecture cible, en un schéma

#

Si je devais résumer tout ça en une image, ça donnerait ceci :

La roadmap

#

Toute cette réflexion se traduit par un plan en 8 phases, que je suivrai (à peu près) dans l’ordre pour les prochains articles :

Le point de bascule, c’est la fin de la phase 2 : à partir du moment où le cluster existe, tout le reste s’enchaîne en code rejouable. Les phases 0 et 1 se font une fois, un peu à la main. Les phases 3 à 8 sont entièrement automatisées.

Les questions encore ouvertes

#

Je ne vais pas faire semblant d’avoir tout tranché. Il reste des points en suspens, et je préfère l’assumer :

• L’accès distant et l’exposition. Tailscale me semble le bon candidat pour l’accès à distance, mais l’exposition de certains services sur Internet n’est pas encore décidée. À trancher avant de publier quoi que ce soit vers l’extérieur.
• Le stockage Kubernetes. Longhorn pour démarrer, democratic-csi vers ZFS quand je voudrai passer au niveau au-dessus.
• L’externalisation des backups. La bascule du disque USB vers Backblaze B2, à quel moment ?
• Le réseau Corosync. Rester en 1 GbE partagé, ou isoler un lien 2.5 GbE dédié ?
• La RAM. Passer les nœuds à 32 Go si les workloads le réclament.

Honnêtement, je trouve qu’un projet qui liste ses questions ouvertes inspire plus confiance qu’un qui prétend avoir réponse à tout. Une décision marquée “à trancher plus tard” reste une décision honnête.

Et maintenant ?

#

Voilà, les fondations théoriques sont posées. Ça peut paraître beaucoup de réflexion avant d’avoir branché le moindre câble, mais c’est justement tout l’intérêt : les prochains articles vont pouvoir se concentrer sur la pratique, sans que j’aie à m’arrêter tous les trois paragraphes pour justifier un choix. Le pourquoi, il est là, dans cet article.

Dans la partie 6, on passe enfin aux mains dans le cambouis : préparation de la workstation, squelette du dépôt, et les premiers pas de l’automatisation. On va commencer à transformer tout ce beau plan en code qui tourne.

À bientôt !