GitOps auto-heberge a la maison : gerer 30+ services avec Komodo et un cluster Proxmox

Mon, 13 Apr 2026 00:00:00 +0000

Faire tourner une poignee de services auto-heberges, c’est facile. Un seul docker-compose up et c’est regle. Mais a un moment, “une poignee” devient 30+ stacks repartis sur plusieurs serveurs, et la il faut une vraie solution pour tout gerer. C’est la ou j’en suis aujourd’hui, et la partie la plus interessante n’est pas un service en particulier, mais la couche d’orchestration qui relie tout ensemble.

Le probleme

Je fais tourner beaucoup de services chez moi. Gestion de photos, domotique, synchronisation de fichiers, NVR avec detection IA, un CRM personnel, lecteur RSS, gestion documentaire, gestionnaire de mots de passe, analytics, un serveur Matrix, inference LLM… la liste continue. Chacun est un stack Docker Compose. Chacun doit etre deploye, mis a jour, surveille, et occasionnellement debogue.

Pendant un moment, je gerais tout manuellement : SSH sur un serveur, cd dans le bon repertoire, docker compose pull && docker compose up -d, verifier les logs. Ca marche, mais ca ne passe pas a l’echelle. Quand on gere des services sur six hotes differents, on passe plus de temps sur la logistique que sur l’utilisation reelle des outils qu’on a construits.

J’avais besoin d’un plan de controle.

Le materiel : un cluster Proxmox

Tout tourne sur un cluster Proxmox VE construit a partir de materiel d’entreprise recycle :

Noeud	CPU	RAM	Role
Principal	Xeon E5-2640 (12 coeurs @ 2.5 GHz)	32 Go	Charges principales
Secondaire	Xeon E5-2430 (12 coeurs @ 2.2 GHz)	24 Go	Charges secondaires

Ce sont de vieux serveurs, le genre qu’on trouve pour presque rien. Ils sont bruyants, consomment de l’electricite, et ont plus de puissance de calcul que je n’en aurai jamais besoin. Parfait pour un homelab.

Le cluster fait tourner environ 40 conteneurs LXC. Les conteneurs LXC sont le vrai cheval de bataille : ils sont plus legers que des VMs, demarrent en quelques secondes, et offrent une isolation correcte sans le surcout de la virtualisation complete. La plupart de mes hotes Docker sont des conteneurs LXC avec quelques Go de RAM chacun.

Les serveurs : qui fait quoi

Tous les conteneurs LXC ne font pas tourner Docker. Certains hebergent des services standalone (DNS, monitoring, reverse proxy, authentification). Mais les hotes Docker sont regroupes logiquement dans Komodo comme “serveurs”, chacun etant un conteneur LXC leger dedie a un ensemble de stacks lies. Komodo voit six serveurs au total : quelques hotes Docker generalistes, une instance Home Assistant dediee, un hote de gestion de photos, un conteneur d’alertes, et le vault.

Le vault est le plus interessant. C’est en fait un NAS sous OpenMediaVault avec un GPU Intel Arc B580 installe. Cette seule carte gere le decodage video materiel pour les flux cameras de Frigate, la detection d’objets par IA, et l’inference LLM via Ollama, le tout en meme temps. J’ai ecrit sur le volet Frigate dans un article precedent.

Komodo entre en scene

Komodo est un gestionnaire de deploiement auto-heberge. Pensez-y comme une alternative legere a Portainer ou Coolify, mais axe sur la gestion de stacks Docker Compose a travers plusieurs serveurs. Pourquoi je l’ai choisi :

Gestion multi-serveur depuis un seul tableau de bord. Une seule interface pour voir et controler chaque stack sur chaque serveur.
Deploiements bases sur Git. Les stacks peuvent tirer leurs fichiers compose depuis un depot Git. Poussez un changement, et Komodo le deploie.
Mises a jour declenchees par webhook. Mon instance Gitea auto-hebergee envoie des webhooks a Komodo a chaque push. Le stack se redeploie automatiquement.
Mise a jour automatique des images. Komodo peut verifier les nouvelles images et mettre a jour les conteneurs sans intervention manuelle.
Gestion des variables d’environnement. Les secrets et la config vivent dans Komodo, pas dans le depot Git.

L’architecture est la suivante : une instance centrale Komodo Core tourne sur un serveur, et un agent leger Komodo Periphery tourne sur chaque hote distant. Le core communique avec les agents peripheriques pour deployer et gerer les stacks. C’est simple, fiable, et ne necessite pas Kubernetes.

Le workflow GitOps

C’est la que ca devient interessant. Environ la moitie de mes stacks sont geres via des depots Git sur mon instance Gitea auto-hebergee. Le workflow :

Je modifie un docker-compose.yml dans un depot Gitea
Je pousse le changement
Gitea envoie un webhook a Komodo
Komodo tire le fichier compose mis a jour
Komodo redeploie le stack sur le serveur cible

Pour les stacks qui n’ont pas besoin de fichiers compose versiones (services plus simples), Komodo gere les fichiers directement sur l’hote. Je peux quand meme les modifier via l’interface Komodo, mais ils ne sont pas sauvegardes dans Git.

La separation est intentionnelle. Les stacks complexes avec plusieurs services, des configs personnalisees, ou des changements frequents vivent dans Git. Les services simples a conteneur unique sont geres en ligne. Cela evite le surcout de Git pour ce qui n’en a pas besoin, tout en me donnant un historique complet et la possibilite de rollback pour ce qui en a besoin.

Home Assistant : un cas particulier

Home Assistant merite une mention car il est gere differemment. Toute sa configuration est dans un depot Gitea, et Komodo le surveille avec du polling et des webhooks. Quand je pousse un changement de config, Home Assistant recoit la mise a jour automatiquement. Plus besoin de SSH pour editer configuration.yaml.

Le reseau : OPNsense et VLANs

Faire tourner des dizaines de services sur un reseau plat serait un cauchemar de securite. J’utilise OPNsense comme pare-feu/routeur avec plusieurs VLANs :

Segment reseau	Fonction
Principal	Serveurs et appareils de confiance
IoT	Appareils domotiques (cameras, capteurs, ESPHome)
Lab	VMs et conteneurs experimentaux
WireGuard	Acces VPN depuis l’exterieur

Les appareils IoT ne peuvent pas communiquer entre eux ni avec le reseau principal directement : ils ne peuvent atteindre que les services dont ils ont besoin (Home Assistant, Frigate). Le reseau lab est isole pour les tests. WireGuard me donne un acces distant securise a tout.

DNS : Unbound + Technitium

Le DNS est gere par deux couches qui travaillent ensemble :

Unbound tourne directement sur OPNsense comme resolveur recursif principal. Il gere la resolution DNS en amont avec validation DNSSEC, et il est rapide, car la plupart des requetes sont servies depuis le cache.
Technitium DNS (dans deux conteneurs LXC pour la redondance) gere les zones DNS internes, pour que je puisse atteindre les services par nom au lieu de memoriser des IPs. Il fournit aussi du split-horizon DNS pour les services qui ont besoin de reponses differentes en interne et en externe.

NTP : temps GPS avec Chrony

Un detail dont je suis particulierement content : la source de temps du reseau est un recepteur GPS USB (BN-808, chipset u-blox M8N) connecte a un conteneur LXC dedie faisant tourner Chrony. Le GPS fournit un temps Stratum 1 a tout le reseau.

L’installation n’est pas parfaite : le GPS USB ne supporte pas le PPS (Pulse Per Second), donc la precision est limitee a environ 40ms a cause de la latence USB. Chrony compense avec une correction manuelle d’offset et bascule sur des serveurs NTP internet (Cloudflare, pools publics) si necessaire. OPNsense distribue ensuite le temps a tous les clients du reseau.

C’est surdimensionne pour un homelab, mais il y a quelque chose de satisfaisant a avoir sa propre source de temps disciplinee par GPS plutot que de dependre entierement de pools NTP externes.

Authelia fournit le single sign-on avec authentification a deux facteurs devant tous les services web, avec Traefik comme reverse proxy.

Stockage : le NAS vault

Le serveur “vault” est un NAS OpenMediaVault qui fait double emploi comme noeud de calcul. Il dispose de 8 disques (un NVMe pour l’OS et 7 HDD allant de 2 To a 16 To) :

Disque	Modele	Capacite
NVMe	WD BLACK SN770	500 Go (boot)
HDD 1	Seagate IronWolf	10 To
HDD 2	WD	10 To
HDD 3	WD	12 To
HDD 4	WD Green	2 To
HDD 5	WD Red	2 To
HDD 6	Seagate IronWolf Pro	16 To
HDD 7	HGST Deskstar NAS	6 To

Un melange de disques achetes au fil du temps ou en promo. La beaute de mon architecture de stockage, c’est qu’elle se fiche de l’uniformite.

L’architecture mergerfs imbriquee

Le stockage est organise en couches avec des pools mergerfs :

Un pool protege par parite : un pool mergerfs combinant 3 disques formates en btrfs. Ces disques sont proteges par la parite SnapRAID (le Seagate 16 To sert de disque de parite).
Un pool principal : un super-pool qui fusionne le pool protege par parite avec un disque supplementaire en un seul espace. C’est la qu’Immich stocke les photos, Kavita les livres, et Frigate les clips video.
Un pool photos en lecture seule : une vue mergerfs qui regroupe tous mes repertoires de photos (photos personnelles, imports DCIM) en un seul point de montage pour un acces facile.

SnapRAID effectue les syncs de parite de maniere programmee (pas en temps reel comme le RAID traditionnel), ce qui signifie :

Pas de penalite en ecriture, car les ecritures vont directement sur les disques btrfs
Si un disque tombe en panne, on peut recuperer son contenu grace a la parite + les disques restants
Les disques peuvent etre de tailles differentes (et ils le sont largement)
Chaque disque est un systeme de fichiers standard lisible individuellement en cas d’urgence

Le compromis : les donnees ecrites entre deux syncs de parite ne sont pas protegees. Pour un homelab qui stocke des photos et des medias, c’est un risque acceptable.

Proxmox Backup Server tourne aussi dans Docker sur ce meme NAS, assurant les sauvegardes de VMs et conteneurs depuis le cluster Proxmox. Les deux noeuds Proxmox montent le stockage PBS du vault directement.

Surveillance et alertes

On ne peut pas gerer ce qu’on ne voit pas. La stack de monitoring :

Outil	Role
Prometheus	Collecte de metriques
Grafana	Tableaux de bord et visualisation
Uptime Kuma	Surveillance de disponibilite
cAdvisor	Metriques de ressources des conteneurs
NetAlertX	Surveillance des appareils reseau
ntfy	Notifications push sur mon telephone

Komodo lui-meme s’integre avec ntfy pour les alertes de deploiement. Si un stack echoue a se deployer ou qu’un conteneur devient unhealthy, je recois une notification push immediatement. Le stack ntfy-alerter fait correspondre la severite des alertes Komodo aux niveaux de priorite ntfy : une alerte critique obtient un push haute priorite qui passe outre le mode Ne Pas Deranger.

L’ensemble tourne 24h/24, se gere en grande partie tout seul, et ne coute rien au-dela de l’electricite et de l’investissement materiel initial. Quand quelque chose a besoin d’attention, Komodo et ntfy s’assurent que je le sais, et le workflow GitOps fait que je peux regler la plupart des choses avec un git push depuis mon telephone.

Si vous faites tourner plus qu’une poignee de services auto-heberges et que vous les gerez encore manuellement, jetez un oeil a Komodo. Ca a transforme mon homelab d’une collection d’hotes Docker en une vraie plateforme geree.

Proxmox | Antoine Weill--Duflos