Qu’est-ce qui fait qu’un conteneur remplit le disque système alors que ses données se trouvent ailleurs ?

Un conteneur peut remplir le disque système lorsque des journaux, des caches, des fichiers temporaires ou des écritures accidentelles restent dans le stockage local de Docker.

Déplacer une bibliothèque multimédia ou un volume de base de données vers un autre pool ne déplace pas l’image du conteneur, la couche inscriptible, le journal JSON, le cache BuildKit, les métadonnées ni les chemins omis de la liste des montages. Un montage externe échoué peut également laisser vide le répertoire hôte attendu, ce qui pousse l’application à écrire de nouvelles données sur le disque système sans erreur évidente.

Mesurez la racine Docker avant d’inspecter les données de l’application

Vérifiez le système de fichiers contenant la racine de données Docker et comparez la taille des répertoires hôtes avec les informations fournies par Docker sur les images, les conteneurs, les volumes et le cache de compilation. Relevez l’utilisation avant de supprimer quoi que ce soit.

Un utilisateur de Cloudron a constaté que /var/lib/docker/overlay2 occupait davantage d’espace que l’ensemble des données d’application visibles, ce qui montre pourquoi la racine de stockage Docker doit être mesurée indépendamment des bibliothèques externes.

Si le disque système est plein alors que le pool externe dispose d’espace, déterminez si la croissance se situe dans les conteneurs, les couches overlay, les volumes, les images ou le cache de compilation. N’exécutez pas de nettoyage général avant d’avoir classé les données actives et récupérables.

Recherchez les journaux JSON de conteneurs sans limite

Inspectez le pilote de journalisation et la taille du fichier journal de chaque conteneur. Un service peut stocker ses données principales ailleurs, tandis que stdout et stderr grossissent indéfiniment dans le répertoire local des conteneurs Docker.

Code Maven décrit un cas où docker system df ne révélait pas le problème principal, car le fichier journal par défaut continuait de grossir en dehors de ce récapitulatif. Le consommateur caché était un journal de conteneur en croissance constante.

Trouvez et corrigez l’erreur bruyante de l’application avant de faire pivoter ou de tronquer les journaux. Configurez une rotation limitée pour les futurs conteneurs et vérifiez que les nouveaux fichiers cessent de grossir une fois la limite prévue atteinte.

Trouvez les données écrites dans la couche inscriptible du conteneur

Comparez les chemins persistants prévus avec les véritables répertoires de cache, de transcodage, de téléchargement, de base de données, de miniatures, de sauvegarde et de fichiers temporaires utilisés par l’application. Toute écriture non montée reste dans la couche inscriptible du conteneur sur le disque système.

Une explication publiée sur un forum Docker précise que les écritures et les fichiers d’image modifiés sont stockés dans la couche inscriptible, tandis que les journaux volumineux non soumis à une rotation résident dans les métadonnées du conteneur. Les deux peuvent faire qu’un seul conteneur consomme presque tout l’espace local malgré la présence d’un volume de données externe.

Utilisez les rapports de taille par conteneur et inspectez les chemins modifiés les plus volumineux à l’intérieur du conteneur. Ajoutez des montages bind explicites ou des volumes nommés uniquement pour les données qui doivent persister, puis recréez le conteneur afin d’éliminer le contenu obsolète de la couche inscriptible après avoir sauvegardé tout élément important.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Vérifiez que le montage externe était présent au démarrage du conteneur

Vérifiez que le SSD, le partage NAS ou le pool de stockage était monté sur le chemin hôte attendu avant le lancement du conteneur Docker. Comparez l’identité du périphérique et la sortie de la commande de montage avec le répertoire visible par le conteneur.

Lorsqu’un montage externe est absent, le répertoire sous-jacent vide du système de fichiers système peut tout de même exister. Le conteneur peut y écrire normalement dans ce répertoire de repli, faisant grossir le disque système tandis que le pool externe semble rester inchangé.

Arrêtez le conteneur avant de remonter le stockage par-dessus les données présentes dans le répertoire de repli. Déplacez ou réconciliez les fichiers cachés en toute sécurité, ajoutez des dépendances de montage ou des vérifications au démarrage, et empêchez le lancement de l’application lorsque le périphérique attendu est absent.

Inspectez les couches d’image, le cache de compilation et les objets abandonnés

Examinez les images inutilisées, les conteneurs arrêtés, les volumes anonymes et le cache BuildKit. Des mises à jour fréquentes ou des compilations locales peuvent accumuler de nombreuses couches, même lorsque les données persistantes de l’application sont correctement montées ailleurs.

Une explication publiée sur le forum du projet Moby précise que les montages overlay peuvent rendre les chiffres d’utilisation du disque difficiles à interpréter et que l’utilisation du système de fichiers sous-jacent doit être examinée avec attention. Un autre cas concernant Home Assistant a également montré une croissance d’overlay2 due aux journaux et aux couches au fil du temps.

Supprimez uniquement les objets dont l’inutilisation a été confirmée par les projets Compose actuels et les sauvegardes. Ne supprimez jamais manuellement des répertoires individuels overlay2, car les références des métadonnées Docker pourraient devenir incohérentes.

Validez la correction avec une référence de croissance

Après avoir corrigé le chemin responsable, relevez à intervalles réguliers l’utilisation de la racine Docker, la taille des journaux, la taille inscriptible des conteneurs et l’utilisation du pool externe pendant la charge de travail qui provoquait auparavant cette croissance.

Le processus ZimaSpace pour préparer un transfert NAS volumineux fournit une charge reproductible permettant de confirmer que les données sont bien écrites sur le pool prévu.

Le problème n’est résolu que lorsque la croissance du disque système correspond au comportement attendu des images et des journaux, que les données persistantes de l’application augmentent sur le pool externe et qu’un montage externe manquant provoque un échec sûr au démarrage plutôt que des écritures silencieuses sur le système de fichiers racine.