Conception et exploitation d'un homelab auto-hébergé

fiche rédigée le 08 octobre 2026infrastructure

Période 2023 → aujourd'hui

Contexte

Le homelab Beerlover est une infrastructure personnelle qui tourne en permanence, sur du matériel que je gère du réseau jusqu’au stockage. Elle héberge des services dont je dépends au quotidien, à commencer par le multimédia et la messagerie. (fait)

Le déclencheur tient en deux choses, une envie d’apprendre et des besoins concrets. La gestion des mots de passe, un serveur multimédia pour la maison, et des serveurs de jeux pour jouer entre amis. (fait)

C’est aussi mon terrain d’essai. Les technologies que je veux pratiquer sans attendre qu’elles arrivent au travail passent d’abord par là, sur des services réels avec un vrai besoin derrière. (fait)

Objectif

Héberger moi-même ce que je confierais sinon à des services tiers, et apprendre en le faisant. La contrainte est double : l’infrastructure doit tenir seule sans intervention quotidienne, et elle doit rester assez souple pour accueillir un service nouveau sans tout repenser. (fait)

Architecture

Le réseau est segmenté en quatre VLANs, avec un backplane de stockage dédié qui relie l’hyperviseur, le stockage et la sauvegarde. Tout ce qui circule entre les VLANs passe par le pare-feu, qui porte aussi la terminaison TLS. (fait)

L’exposition publique suit sa propre chaîne. Cloudflare est en amont, le reverse proxy décrypte le trafic, et le pare-feu fait office de proxy de niveau 4 avec une zone démilitarisée. (fait)

La virtualisation repose sur Proxmox, avec TrueNAS pour le stockage et un serveur de sauvegarde dédié. Sur cette base, deux familles d’hébergement coexistent : Docker pour ce qui est simple et stable, et un cluster Kubernetes léger pour ce qui demande de l’orchestration, de l’ingress et des volumes qui survivent au redémarrage d’un nœud. (fait)

Le stockage suit une règle qui ne souffre pas d’exception. Les médias et les téléchargements vont sur le stockage réseau partagé, la configuration des applications va sur un volume répliqué entre les nœuds, et le cache va sur un volume local dont la perte est sans conséquence. (fait)

Décisions

Kubernetes plutôt que Docker pour tout ce qui est exposé en HTTPS. Le routage par ingress, les certificats et les volumes répliqués sont déjà gérés par le cluster, ce qui évite de reconstruire à la main ce qu’il fait nativement. (déduit)

Helm plutôt que les manifests bruts. Dès qu’un chart existe, il est préféré, parce qu’une montée de version propre vaut mieux qu’une réécriture de YAML. Les manifests purs restent pour ce que Helm ne couvre pas ou quand le contrôle fin est nécessaire. (fait)

Une seule carte graphique, découpée en profils plutôt que donnée en entier. Le homelab n’en possède qu’une, une T1000 de 8 Go, partagée en plusieurs profils via vGPU. C’est ce découpage qui permet d’en réserver une partie au serveur multimédia tout en gardant le nœud utilisable pour le reste. Le profil présenté à la machine invitée porte le nom d’une RTX 6000, alors que la carte physique est une T1000, et c’est ce qui explique que les deux dénominations circulent. (fait)

Un reverse proxy en passthrough TLS devant le cluster. Le cluster termine lui-même le TLS et garde la main sur ses certificats, le proxy ne fait que router par le nom. (fait)

Une tâche auxiliaire se nomme au lieu de se deviner. Laisser un service choisir lui-même son fournisseur fonctionne tant que l’environnement ne change pas. Le nommer explicitement coûte une ligne de configuration et évite une panne silencieuse au premier changement d’abonnement. Sur le même principe, le modèle retenu pour lire les images est celui qui répond le plus court, parce que l’entrée est identique partout et que seule la sortie fait la facture. (fait)

Un mode silencieux n’est pas un mode discret. Le réglage de notification le plus restrictif ne réduit pas le nombre de messages, il retire seulement la sonnerie et laisse tout arriver. Pour recevoir moins, ce sont les surfaces d’affichage qu’il faut fermer, pas les alertes. Et quand le réglage qui compte n’existe que pour le terminal, il vaut mieux le dire que le laisser croire. (fait)

Défis

Le plus marquant est une panne en cascade qui part d’un disque plein. Quand le disque système du nœud principal se remplit, la chaîne complète se casse : le pilote de stockage ne peut plus s’enregistrer auprès du cluster, plus aucun volume ne se monte, tous les services qui en dépendent tombent, et le routage et les certificats tombent avec eux. Le diagnostic remonte donc du côté du disque avant de regarder les services, parce que rien de ce qu’on voit à l’écran ne dit la cause réelle. (fait)

La deuxième leçon vient d’un piège de Kubernetes. Modifier le sélecteur d’un service ne le remplace pas, cela l’enrichit. Le service se met alors à exiger tous les anciens labels en plus des nouveaux, ne trouve plus aucun pod, et n’a plus aucun endpoint. Il faut le supprimer et le recréer, jamais le patcher. (fait)

Il y a aussi les pièges de persistance. Le pilote de la carte graphique se perd après une mise à jour du noyau, et le réinstaller ne suffit pas : il faut qu’il soit compilé pour la bonne version, qu’il soit rechargé au démarrage, et que l’image d’amorçage soit reconstruite. Sans ces trois choses, la carte disparaît du cluster à chaque mise à jour. (fait)

Et un conflit de marqueurs, plus sournois. Deux images du même logiciel, l’une officielle et l’autre communautaire, écrivent un fichier de marqueur différent dans la configuration. Si les deux coexistent sur le même volume, le logiciel refuse de démarrer. La sortie est manuelle, il faut retirer le mauvais marqueur depuis un conteneur de diagnostic. (fait)

Un service s’est arrêté en silence au moment d’un changement d’abonnement chez le fournisseur. La lecture d’images fonctionnait encore la veille, mais seulement parce que le modèle principal savait voir une image. Le jour où un modèle plus léger l’a remplacé, la tâche est retombée sur une configuration automatique. Cette configuration ne cherchait qu’un fournisseur absent du système, donc elle n’a trouvé personne. La lecture a échoué sans qu’aucun autre service ne bouge, et rien dans l’interface ne désignait la cause. Il a fallu lire la configuration et le code de routage pour voir que le repli n’avait jamais eu de cible. (fait)

Ce même épisode a révélé un piège de facturation invisible à l’usage. Quand le modèle principal traite une image, celle-ci reste attachée à l’historique de la conversation. Elle se fait donc refacturer à chaque tour suivant, même quand la suite n’a plus rien à voir avec elle. Une seule capture peut être payée vingt fois de cette manière. Passer la lecture d’images à une tâche auxiliaire, qui rend un texte et non une image, coupe la répétition à la racine. (fait)

Un autre piège tient à un réglage dont le nom rassure plus qu’il ne renseigne. Le mode de notification le plus restrictif ne coupe aucun message, il les envoie simplement sans sonnerie. On croit avoir réduit le bruit alors qu’on n’a réduit que la sonnerie du téléphone, ce qui n’est pas la même chose. Le récapitulatif de fin de tour, qui rend un décompte lisible du travail effectué, n’existe pour sa part que dans le terminal. Côté messagerie il n’y a rien à activer, et il vaut mieux le dire que le laisser croire. (fait)

Résultats / Impact

L’infrastructure tourne en continu et se maintient sans intervention quotidienne, mais le nombre de services hébergés reste encore à préciser. (à creuser)

C’est aussi devenu l’endroit où j’ai rencontré et pratiqué des technologies que je n’aurais pas touchées autrement. Au départ, Docker, Kubernetes, le pare-feu et l’agent conversationnel qui vit dessus m’étaient tous étrangers. (fait)

Le gratuit n’existe pas pour autant, un homelab coûte du temps, surtout les jours de panne. L’impact chiffré, coût évité ou temps passé, reste (non mesuré, assumé). (fait)

Les procédures de dépannage que j’ai écrites au fil des pannes existent, dans un document de référence interne. Elles restent (preuves confidentielles, non versées). (fait)

Apprentissages

Sur une infrastructure qui dépend d’une chaîne, un incident se diagnostique à l’envers du symptôme. Un disque plein ressemble à quinze services en panne, et c’est le disque qu’il faut regarder d’abord. (déduit)

Ce qui n’est pas persistant se reperd. Un pilote installé à la main, un module chargé à chaud, une configuration vivante hors dépôt : tout cela survit jusqu’au prochain redémarrage, et pas au-delà. (déduit)

Documenter un dépannage coûte moins cher que le rediagnostiquer. La deuxième fois qu’un incident se produit, la procédure écrite vaut mieux que la mémoire. (déduit)

Un homelab apprend la contrainte réelle. Sur du matériel qu’on ne remplace pas, on conçoit pour ce qu’on a, pas pour ce qu’on aimerait avoir. (déduit)

Une dépendance implicite casse sans bruit, et c’est ce qui la rend coûteuse à réparer. Un service qui fonctionne parce qu’un autre sait faire quelque chose en plus ne le déclare nulle part. Le jour où l’autre change, il tombe seul, et le message d’erreur pointe ailleurs que la cause. (déduit)

Un réglage se juge sur ce qu’il coupe réellement, jamais sur le nom qu’il porte ni sur l’intention qu’on lui prête. Lire les quelques lignes qui l’appliquent prend cinq minutes et évite de croire qu’on a corrigé un problème qu’on a seulement déplacé. (déduit)

Sources

Propos tirés du document de référence du homelab, écrit par l’utilisateur et maintenu à jour.

« Ta mission : conseiller déploiements, dépannage et optimisation. »

« Sans driver opérationnel, le device plugin ne publie plus nvidia.com/gpu → tout pod GPU reste Pending. »

« kubectl patch svc AJOUTE les nouveaux sélecteurs aux anciens, il ne les remplace pas. »

« Le disque système de guinness se sature rapidement […] Le Kubelet détecte FreeDiskSpaceFailed et bloque tout scheduling + montage CSI. »

« Doctrine : les médias et downloads sur NFS, la configuration des apps sur Piraeus/Linstor, jamais de hostPath. »

Précisions (2026-10-08) :

« 2023 à aujourd’hui le homelab »

« envie d’apprendre, besoin précis, gestion mdp, jellyfin, serveurs de jeux entre amis »

« docker, hermes-agent, firewall, kubernetes, tout ça c’est du nouveau »

« cloudflare, caddy, layer4 proxy, opnsense, dmz »

Précisions (2026-10-26) :

« le but c’est de payer le moins possible sur la lecture d’images »

« moins de détails m’irait bien mais en garder quand même un peu »

« on laisse la progression stp, par contre on bascule les notifications en important uniquement »

« y’a pas un moyen d’avoir un récap process plutôt qu’un cleanup ? »