Pièges du homelab Docker : espace disque, journaux et dérive de configuration

Un récent article technique détaille plusieurs dangers opérationnels rencontrés lors de la gestion d'un environnement Docker auto-hébergé sur Proxmox et un stockage attaché réseau (NAS). L'auteur décrit comment les commandes de diagnostic standard peuvent induire en erreur les administrateurs, les poussant à supprimer des services actifs ou à négliger une dérive critique de la configuration. Ces incidents mettent en évidence l'écart entre l'état de santé des conteneurs et la fonctionnalité réelle des services dans des configurations complexes de home lab.

Ce qui s'est passé

L'investigation a commencé lorsqu'un hôte Docker a atteint 82 % de sa capacité disque. Les diagnostics initiaux utilisant docker system df suggéraient 6,67 Go d'espace récupérable, mais une inspection plus approfondie a révélé que les vues récapitulatives étaient trompeuses. La commande docker ps affichait des identifiants SHA bruts au lieu de noms d'images pour plusieurs conteneurs, faisant apparaître comme orpheline une image active nommée unclecode/crawl4ai. Le conteneur était sain, fonctionnait depuis deux semaines et servait du trafic. L'administrateur a évité de le supprimer uniquement en croisant les ports en écoute avec les inspections de conteneurs.

Une analyse plus poussée a montré que la pression sur le disque provenait des images et des caches de construction plutôt que des données utilisateur. Un invité contenait 16 Go d'images, tandis qu'un autre avait 11,4 Go d'images et 11,3 Go de cache de construction. La suppression de seize balises obsolètes d'une application personnalisée n'a libéré que 60 Mo malgré chaque balise listée comme pesant 240 Mo, en raison des couches partagées. Un incident distinct impliquait un autre hôte atteignant 100 % d'utilisation du disque car le démon Docker manquait d'un fichier de configuration pour limiter la taille des journaux. Un seul fichier journal Home Assistant avait grossi jusqu'à 1,9 Go, provoquant l'échec de cinq unités systemd sans alerter personne.

La dérive de configuration a également causé des pannes prolongées. Un conteneur de navigateur de fichiers est resté hors service pendant six jours parce que sa politique de redémarrage était revenue à no malgré la spécification unless-stopped dans le fichier compose. Cela s'est produit parce que le conteneur avait été créé avant la modification de la politique et n'avait jamais été recréé. De plus, des problèmes d'interpolation de variables d'environnement ont corrompu une chaîne de mot de passe Argon2, entraînant des échecs d'authentification, tandis que des valeurs par défaut codées en dur dans une pile de traçabilité ont conduit à des erreurs de connexion à la base de données. Des failles de sécurité réseau ont été découvertes là où les ports publiés permettaient un accès direct aux instances privées, contournant les proxys inverses.

Détails clés

• Les outils de nettoyage de disque comme docker system df peuvent mal représenter l'utilisation de l'espace en raison des couches d'images partagées et des caches de construction.
• La journalisation Docker par défaut n'a pas de limite de taille, permettant à des fichiers journaux uniques de remplir des systèmes de fichiers entiers si daemon.json n'est pas configuré.
• La modification des fichiers .env ou des configurations compose nécessite docker compose up -d --force-recreate pour prendre effet, et non simplement un redémarrage.
• Les conteneurs créés avant une mise à jour de la politique de redémarrage conservent leur politique originale jusqu'à ce qu'ils soient explicitement recréés ou mis à jour.
• Les vérifications de santé indiquent l'état du processus mais ne vérifient pas la connectivité fonctionnelle, telle que les connexions de tunnel ou la disponibilité du GPU.
• Les règles de pare-feu pour les ports publiés doivent correspondre aux adresses de destination originales en utilisant --ctorigdst en raison du comportement DNAT.

Contexte

Les conteneurs Docker sont des environnements virtualisés légers qui partagent le noyau du système d'exploitation hôte. Lorsqu'un conteneur est créé, Docker capture la configuration, y compris les variables d'environnement, les politiques de redémarrage et les pilotes de journalisation, dans un état d'exécution spécifique. Les modifications ultérieures apportées aux fichiers sources, tels que les fichiers YAML compose ou les définitions de variables d'environnement, ne mettent pas automatiquement à jour les conteneurs en cours d'exécution. Les administrateurs doivent recréer explicitement les conteneurs pour appliquer ces changements. Ce comportement conduit souvent à une « dérive de configuration », où le système en ligne diverge du code d'infrastructure déclaré.

La journalisation dans Docker utilise généralement un pilote de fichier JSON par défaut, qui écrit tous les flux de sortie standard et d'erreur sur le disque sans rotation sauf configuration contraire. Dans les home labs de production ou à longue durée de vie, cela peut entraîner une consommation rapide du disque. De même, la gestion des images implique des couches partagées entre plusieurs balises et versions. Supprimer une balise spécifique ne supprime pas nécessairement les blocs de données sous-jacents si d'autres images y font référence, rendant la récupération d'espace disque moins prévisible qu'une simple suppression de fichier.

Pourquoi c'est important

Pour les équipes exécutant des logiciels auto-hébergés, ces pièges représentent des risques significatifs pour la fiabilité. S'appuyer sur des vérifications de santé superficielles peut masquer des défaillances de service, telles qu'un agent de tunnel en cours d'exécution mais non connecté, ou un conteneur d'apprentissage automatique revenant au CPU en raison d'une incompatibilité matérielle. Sans une surveillance robuste de la fonctionnalité réelle des services, les pannes peuvent persister pendant des jours sans être remarquées. L'incident où un navigateur de fichiers est resté hors service pendant six jours illustre comment les défaillances silencieuses peuvent perturber les flux de travail sans déclencher d'alertes immédiates.

L'épuisement de l'espace disque est une autre menace critique pour la disponibilité. La croissance illimitée des journaux peut faire planter des hôtes entiers, mettant hors service simultanément tous les services co-localisés. L'absence de rotation des journaux par défaut signifie que chaque nouveau déploiement hérite de ce risque sauf atténuation explicite. De plus, la dérive de configuration sape les avantages de reproductibilité des pratiques d'infrastructure-as-code. Si les variables d'environnement ou les politiques de redémarrage ne sont pas synchronisées entre le dépôt de code et les conteneurs en cours d'exécution, le débogage devient difficile et les déploiements imprévisibles.

La sécurité réseau est également compromise lorsque les comportements de publication par défaut ne sont pas soigneusement gérés. Exposer des services privés sur toutes les interfaces permet des mouvements latéraux non autorisés au sein du réseau. Une configuration correcte du pare-feu nécessite de comprendre les mécanismes de traduction d'adresses réseau de Docker, qui diffèrent du routage standard basé sur l'hôte. Des règles mal configurées peuvent laisser des services internes sensibles accessibles à des segments moins fiables, violant les principes du moindre privilège.

Ce que vous pouvez faire

• Vérifiez l'utilisation des images avec docker inspect et contrôlez les ports en écoute avant de supprimer toute image ou tout conteneur.
• Configurez daemon.json avec des limites max-size et max-file pour les journaux.
• Utilisez docker compose up -d --force-recreate après avoir modifié les fichiers .env ou les configurations compose pour forcer la prise en compte des changements.
• Recréez explicitement les conteneurs dont la politique de redémarrage doit être mise à jour.
• Implémentez des règles de pare-feu précises pour les ports publiés en tenant compte du comportement DNAT.
• Testez périodiquement la connectivité fonctionnelle réelle au-delà des simples vérifications de santé des processus.