Problème
Un serveur qui héberge des conteneurs n'a plus d'espace disque. Les symptômes arrivent rarement sous la forme d'une alerte : une application refuse d'écrire, une base de données passe en lecture seule, une construction d'image échoue avec no space left on device, ou le moteur Docker lui-même cesse de répondre. Personne n'a rien ajouté de gros : ce sont des mois d'images anciennes, de conteneurs arrêtés, de volumes orphelins, de cache de construction et de journaux sans limite qui se sont empilés sans que rien ne prévienne.
Solution recommandée
Mesurer ce qui occupe la place avant de supprimer quoi que ce soit, puis nettoyer par ordre de risque croissant : le cache de construction et les images d'abord, qui se reconstruisent ou se retéléchargent, les volumes en dernier et un par un, parce qu'ils contiennent les données. La règle qui évite l'accident est simple : lister ce qui va être supprimé avant de lancer la suppression. Une fois l'espace récupéré, poser une limite sur les journaux de conteneurs et surveiller le remplissage, sans quoi la même panne revient dans quelques mois.
Matériel & outils
Un terminal sur la machine hôte avec des droits administrateur (sudo ou root), les commandes docker system df, docker ps, docker image ls, docker volume ls, docker inspect et les commandes prune, les commandes système df, du et truncate sous Linux, un éditeur de texte pour le fichier de configuration du démon Docker, docker compose si les services sont décrits dans un fichier compose, et une sauvegarde vérifiée des données avant toute suppression
Étapes
1. Confirmez d'abord que c'est bien le disque de Docker qui est plein. La commande df -h montre le taux de remplissage de chaque système de fichiers, et docker info donne la ligne Docker Root Dir, le répertoire où Docker range tout, par défaut /var/lib/docker sous Linux. Si ce répertoire est sur une partition dédiée, seule celle-ci est en cause. Regardez aussi df -i : un disque peut afficher de la place libre et refuser toute écriture parce que les inodes, le nombre de fichiers possibles, sont épuisés 2. Mesurez avant de supprimer, avec docker system df. La sortie donne quatre lignes, Images, Containers, Local Volumes et Build Cache, avec pour chacune la taille totale et la colonne RECLAIMABLE, c'est-à-dire ce qui serait récupérable. Cette seule ligne oriente tout le reste : nettoyer les images quand ce sont les journaux qui pèsent ne rend rien 3. Détaillez avec docker system df -v, qui liste chaque image, chaque conteneur et chaque volume avec sa taille. C'est la vue qui permet de désigner des éléments précis au lieu de lancer un nettoyage en aveugle. docker ps -s ajoute la taille de la couche d'écriture de chaque conteneur en fonctionnement, utile quand une application écrit dans le conteneur au lieu d'écrire dans un volume 4. Avant la moindre commande de nettoyage, retenez ceci : les commandes de suppression de Docker ne demandent qu'une confirmation par oui ou non, et cette confirmation annonce des catégories, pas la liste des éléments concernés. Elle ne vous dira jamais que le volume de votre base de données en fait partie. La suppression est immédiate et définitive, il n'y a ni corbeille ni annulation. Tout ce qui touche aux volumes touche à des données 5. Vérifiez donc que vos sauvegardes existent et sont récentes avant de commencer, en particulier celles des bases de données hébergées en conteneur. Un nettoyage sur un serveur sans sauvegarde valide n'est pas une opération de maintenance, c'est un pari 6. Commencez par le geste sans risque pour les données : le cache de construction. docker builder prune supprime le cache des constructions d'images, et docker builder prune -a le vide entièrement. Rien de fonctionnel ne disparaît, la seule conséquence est que la prochaine construction sera plus lente. Sur un serveur qui construit ses images régulièrement, ce cache atteint couramment plusieurs gigaoctets 7. Passez ensuite aux conteneurs arrêtés. Listez-les d'abord avec docker ps -a, dont la colonne STATUS distingue ce qui tourne de ce qui est en Exited. Lisez cette liste avant de la supprimer : un conteneur arrêté peut être une tâche ponctuelle que vous comptiez relire, et supprimer un conteneur efface ses journaux avec lui. docker container prune supprime tous les conteneurs arrêtés d'un coup, docker rm suivi d'un nom n'en supprime qu'un 8. Traitez les images. docker image ls montre ce qui est présent, avec la taille et la date de création. docker image prune ne retire que les images sans nom, celles qui apparaissent en none et qui sont des restes de constructions successives : c'est l'option prudente. docker image prune -a va beaucoup plus loin et retire toute image qu'aucun conteneur existant n'utilise, y compris des images que vous voudrez peut-être relancer : elles devront alors être retéléchargées, ce qui suppose un accès au registre et, pour une image privée, des identifiants valides. Aucune donnée applicative n'est perdue dans les deux cas 9. docker system prune regroupe les étapes précédentes en une commande : conteneurs arrêtés, réseaux inutilisés, images sans nom et cache de construction. Sans option supplémentaire, il ne supprime aucun volume. C'est la commande de nettoyage courante, et celle que vous pouvez lancer sans inquiétude pour vos données une fois la liste des conteneurs arrêtés relue 10. Les volumes viennent en dernier et méritent le traitement le plus lent, parce que c'est là que vivent les données. Listez-les avec docker volume ls, puis docker volume inspect suivi du nom, qui donne le chemin réel du volume sur l'hôte, sous Mountpoint : un du -sh sur ce chemin en donne la taille. Identifiez à quoi sert chaque volume avant d'y toucher. Quand vous êtes certain, supprimez-le nommément avec docker volume rm suivi de son nom, et pas autrement 11. Traitez docker volume prune comme une commande dangereuse. Elle supprime les volumes qu'aucun conteneur existant n'utilise, et le piège tient dans cette définition : un volume de base de données dont le conteneur a été supprimé une heure plus tôt pendant le nettoyage est considéré comme inutilisé, alors qu'il contient toutes vos données. Le périmètre exact varie de plus selon la version de Docker, certaines versions ne visant par défaut que les volumes anonymes et réservant les volumes nommés à une option supplémentaire. Ne pariez pas sur la version installée : listez avant, avec docker volume ls suivi de -f dangling=true, qui affiche les volumes qu'aucun conteneur ne réclame, vérifiez cette liste nom par nom, et supprimez ensuite à la main ceux que vous avez identifiés 12. Pour la même raison, méfiez-vous des options combinées trouvées sur un forum. Une commande de nettoyage général assortie de l'option volumes efface aussi les volumes inutilisés, dans le même mouvement que le cache de construction, sans énumérer ce qui part. C'est la manière la plus courante de perdre une base de production en une ligne 13. Occupez-vous des journaux, la cause la plus souvent ignorée. Avec le pilote de journalisation par défaut, un conteneur écrit ses sorties dans un fichier sur l'hôte, et ce fichier n'a aucune limite de taille : un conteneur bavard laissé six mois occupe plusieurs gigaoctets à lui seul. Ces journaux ne sont comptés ni dans les images ni dans les volumes de docker system df, ce qui explique les cas où le disque est plein alors que Docker annonce peu de choses à récupérer 14. Trouvez le fichier de journal d'un conteneur avec docker inspect suivi de --format '{{.LogPath}}' et du nom du conteneur, puis mesurez-le avec ls -lh. Pour vider un journal devenu énorme sans arrêter le service, videz le fichier au lieu de l'effacer, avec truncate -s 0 suivi du chemin, en root. Supprimer le fichier avec rm pendant que le conteneur tourne ne rend pas l'espace : le processus garde le fichier ouvert, et la place n'est libérée qu'au redémarrage du conteneur 15. Posez maintenant une limite pour que cela ne recommence pas. À la création d'un conteneur, les options de journalisation max-size, par exemple 10m, et max-file, par exemple 3, bornent la place occupée en faisant tourner les fichiers. Dans un fichier compose, les mêmes réglages se déclarent dans la section logging du service. Pour couvrir toute la machine d'un coup, déclarez ces mêmes options par défaut dans le fichier de configuration du démon, /etc/docker/daemon.json sous Linux, puis redémarrez le service Docker. Attention au point qui trompe tout le monde : ces réglages ne s'appliquent qu'aux conteneurs créés ensuite, les conteneurs existants gardent leur configuration jusqu'à ce qu'ils soient recréés 16. Si le disque est déjà plein au point que les commandes elles-mêmes échouent, il faut d'abord regagner quelques centaines de mégaoctets sans rien écrire. Videz le plus gros fichier de journal avec truncate : l'opération ne demande aucune place libre et rend l'espace immédiatement. Une fois Docker à nouveau capable de répondre, reprenez à l'étape 6 dans l'ordre prévu. Si le démon Docker ne répond plus du tout, cherchez les plus gros consommateurs directement sur le système de fichiers avec du -sh sur les sous-répertoires du Docker Root Dir, ce qui désigne sans ambiguïté la catégorie fautive 17. Vérifiez le résultat, et pas seulement l'espace libre. df -h doit montrer un taux de remplissage redescendu, docker system df une valeur récupérable faible, et surtout chaque service hébergé doit encore répondre : docker ps pour voir ce qui tourne, puis un accès réel à l'application et à ses données. Un nettoyage qui libère de la place et vide une base est un échec, pas une réussite 18. Terminez par la prévention, sinon la même panne revient. Posez une alerte de supervision sur le remplissage du disque, autour de 80 pour cent, pour être prévenu avant la panne. Planifiez au besoin un nettoyage récurrent des images anciennes et du cache de construction, jamais des volumes. Et vérifiez que les applications écrivent bien leurs données dans des volumes déclarés, pas dans la couche d'écriture des conteneurs, qui gonfle sans que personne ne la regarde
Coût estimé
0 €, hors temps passé : toutes les commandes sont livrées avec Docker et le système. Un coût apparaît seulement si la mesure montre que le serveur est réellement sous-dimensionné, auquel cas il faut agrandir le disque chez l'hébergeur
Limites
Ne traite pas le cas de Docker Desktop sous Windows ou macOS, où les données vivent dans un disque virtuel qui ne rétrécit pas tout seul après un nettoyage et demande une opération de récupération d'espace propre à cet outil. Ne couvre pas les orchestrateurs comme Kubernetes, dont le nettoyage des images est géré par l'agent de nœud et suit ses propres règles. Ne couvre pas un disque rempli par autre chose que Docker, sauvegardes locales, journaux du système ou fichiers applicatifs, que la première étape permet justement d'écarter. Ne permet pas de récupérer un volume déjà supprimé : seule une sauvegarde le peut.
Erreurs fréquentes
Lancer une commande de nettoyage complète copiée depuis un forum, avec l'option qui inclut les volumes, et découvrir ensuite que la base de données a disparu. Croire que la demande de confirmation liste ce qui va être supprimé, alors qu'elle n'annonce que des catégories. Supprimer les conteneurs arrêtés puis lancer un nettoyage des volumes dans la foulée, ce qui transforme des volumes de données parfaitement utiles en volumes orphelins supprimables. Effacer un fichier de journal avec rm pendant que le conteneur tourne, et constater que l'espace n'est pas rendu. Poser une limite de taille de journaux et croire qu'elle s'applique aux conteneurs déjà en place. Agrandir le disque sans traiter la cause, ce qui repousse la panne de quelques mois au lieu de la régler.
Alternatives
Déplacer le répertoire de données de Docker sur un autre disque plus grand, en arrêtant le service, en copiant le contenu puis en déclarant le nouveau chemin dans la configuration du démon : utile quand la partition système est petite par conception. Envoyer les journaux vers un collecteur externe plutôt que de les garder sur l'hôte, ce qui supprime le problème à la source sur un serveur bavard. Sur une machine virtuelle ou une instance chez un hébergeur, agrandir le volume est parfois la vraie réponse, quand la mesure montre que tout ce qui occupe la place est légitime. Enfin, sur un serveur qui héberge des données, la prévention la plus rentable reste une sauvegarde vérifiée des volumes : elle transforme une erreur de nettoyage en incident, pas en perte.
Besoin d'un accompagnement personnalisé ?
Cours 1:1, conseil de solution, ou simplement une question précise - contacte-moi directement.