Nettoyer les ressources Docker inutilisées sur un VPS Linux

Docker ne supprime jamais rien de lui-même. La documentation officielle décrit une approche volontairement conservatrice du nettoyage : images, conteneurs arrêtés, volumes et caches de build restent sur le disque tant que vous ne demandez pas explicitement leur suppression. Sur un serveur privé virtuel dont l’espace de stockage est fixe, cette accumulation finit par saturer la partition, et les conséquences arrivent toutes en même temps : plus de place pour télécharger une image, plus de place pour écrire un journal, services qui refusent de redémarrer.

Ce guide s’adresse à l’administrateur d’un VPS qui pilote Docker en ligne de commande depuis une session SSH, sous Ubuntu, Debian, CentOS, AlmaLinux ou une distribution équivalente : les commandes de nettoyage présentées ici sont identiques d’une distribution à l’autre. Elles s’exécutent en root ou précédées de sudo. Nous allons mesurer l’espace réellement récupérable, puis supprimer conteneurs arrêtés, images, cache de build et volumes sans effacer de données utiles. L’ordre des étapes compte : ce qui est supprimé ne se récupère pas, en particulier du côté des volumes.

Pourquoi Docker remplit le disque sans prévenir

Trois mécanismes expliquent la saturation progressive d’un serveur. Un conteneur arrêté conserve ses couches d’écriture : tant qu’il existe, cet espace reste occupé sur le disque. Les volumes, de leur côté, ne sont jamais supprimés automatiquement, précisément pour éviter de détruire des données applicatives. Enfin, les images intermédiaires et le cache de build subsistent après chaque construction, même lorsque le résultat final change à peine.

Un VPS naît de la virtualisation d’un serveur physique : vous disposez d’un serveur virtuel complet, mais les ressources allouées, processeur (CPU), RAM et espace disque, restent partagées et finies. C’est le principe des machines virtuelles : plusieurs serveurs virtuels se partagent un même serveur physique, et chaque système d’exploitation invité ne voit que la part qui lui est attribuée. L’espace de stockage est la ressource la plus facile à épuiser, parce que la RAM et le processeur se libèrent dès qu’un service s’arrête, alors que les objets Docker restent stockés. Un disque SSD ou NVMe de 80 Go se remplit plus vite qu’on ne l’imagine avec quelques images de base, et l’espace alloué n’est jamais illimité.

Le diagnostic commence donc par la mesure. Si vous ne savez pas encore à quelle vitesse votre partition se remplit, commencez par surveiller l’espace disque d’un VPS Linux : savoir si le disque se remplit en heures ou en semaines change complètement la méthode de nettoyage à appliquer.

Ce qui remplit le disque en dehors de Docker

Avant d’accuser Docker, vérifiez le reste. Un VPS qui héberge des sites web, plusieurs sites internet ou une boutique e-commerce consomme de l’espace pour ses fichiers, ses images, ses sauvegardes (backup) et ses journaux. Les configurations, les noms de domaine et les enregistrements DNS n’y changent rien : ce sont le contenu et les sauvegardes qui pèsent. S’y ajoutent les journaux du serveur web, nginx ou Apache, qui grossissent en continu, une base de données MySQL ou PostgreSQL placée dans un volume, qui peut représenter plusieurs gigaoctets, et les journaux du système d’exploitation lui-même.

Si la commande docker system df vous annonce peu d’espace récupérable alors que la partition est pleine, le nettoyage Docker ne suffira pas : le vrai consommateur est ailleurs, souvent dans /var/log ou dans un répertoire de sauvegardes. Cette distinction évite une erreur fréquente : supprimer des images encore utiles à un projet pour récupérer quelques gigaoctets, alors que la cause de la saturation est un journal applicatif ou une table de base de données qui gonfle.

Mesurer l’espace récupérable avant de nettoyer

La commande docker system df affiche la place occupée par le démon Docker, objet par objet, avec une colonne RECLAIMABLE :

docker system df

Le résultat se lit par type d’objet : images, conteneurs, volumes locaux et cache de build. La colonne SIZE indique l’espace utilisé, la colonne ACTIVE le nombre d’objets réellement utilisés, et la colonne RECLAIMABLE la part que vous pouvez récupérer. Un volume affiché à 0 % récupérable est encore utilisé par un conteneur : le supprimer couperait un service.

Pour obtenir le détail par conteneur, par image et par volume, utilisez docker system df -v. Sur un serveur qui héberge plusieurs projets, c’est cette vue qui permet d’identifier les gros consommateurs avant de toucher à quoi que ce soit.

Inventorier les objets présents

Un conteneur arrêté n’est pas forcément un déchet : il peut s’agir d’un service que vous avez stoppé pour une maintenance. Listez ce qui existe avant de supprimer :

docker ps -a
docker image ls
docker volume ls
docker network ls

Comparez ces listes avec vos fichiers docker-compose.yml. Un conteneur arrêté que Compose sait recréer à l’identique peut partir sans regret. Un conteneur lancé à la main avec des options spécifiques demande plus d’attention. Repérez aussi les volumes nommés : ce sont eux qui portent les données d’une base de données ou d’une application.

Supprimer les conteneurs arrêtés

La commande dédiée ne supprime que les conteneurs qui ne tournent plus :

docker container prune

Docker demande une confirmation, que vous pouvez éviter avec l’option -f. Pour ne cibler que les conteneurs arrêtés depuis un certain temps, ajoutez un filtre :

docker container prune --filter "until=24h"

Attention à ce que vous supprimez : les données écrites dans le système de fichiers d’un conteneur, hors volume monté, disparaissent avec lui. Si le service écrit dans un volume nommé, la suppression du conteneur ne touchera pas ce volume.

Supprimer les images inutilisées

Sans option, docker image prune ne supprime que les images dangling, c’est-à-dire les images sans étiquette et plus référencées par aucun conteneur. Ce sont typiquement les couches intermédiaires laissées par une reconstruction :

docker image prune

Avec l’option -a, la suppression s’étend à toutes les images qui ne sont associées à aucun conteneur, y compris les images étiquetées :

docker image prune -a

Cette variante libère beaucoup plus d’espace, mais elle a un coût : au prochain démarrage, Docker devra retélécharger les images concernées. Sur une connexion lente ou un serveur en production, mieux vaut limiter la suppression aux images anciennes avec un filtre, par exemple docker image prune -a --filter "until=24h".

Vider le cache de build

Le cache de build est souvent le plus gros poste invisible d’un serveur qui construit ses propres images. La commande suivante supprime le cache devenu inutile :

docker builder prune

Trois options précisent le nettoyage : -a supprime tout le cache et non seulement les entrées orphelines, --filter "until=24h" conserve les constructions récentes, et --keep-storage fixe la quantité d’espace à conserver. Après un nettoyage, la première reconstruction qui suit sera simplement plus lente.

Volumes : la partie qui efface réellement des données

C’est ici que le nettoyage devient risqué. Par défaut, docker volume prune supprime les volumes anonymes qui ne sont utilisés par aucun conteneur :

docker volume prune

Les volumes nommés, ceux que vous déclarez explicitement dans un fichier Compose, ne partent qu’avec l’option --all :

docker volume prune --all

Un volume supprimé n’est pas récupérable. Avant de lancer cette commande, vérifiez avec docker volume ls et docker system df -v à quoi correspondent les volumes présents : base de données d’un panel, données d’une application, fichiers reçus. Sur une machine qui héberge des données clients, la sauvegarde se prépare avant, jamais après.

Tout nettoyer en une commande

Quand vous connaissez les objets présents, docker system prune regroupe l’essentiel. La documentation liste exactement ce qui est supprimé : tous les conteneurs arrêtés, tous les réseaux non utilisés par au moins un conteneur, les images dangling et le cache de build inutilisé.

docker system prune

Deux options changent la portée de la commande. -a étend la suppression à toutes les images sans conteneur associé, et --volumes ajoute les volumes anonymes non utilisés. Les volumes nommés restent en place : docker system prune seul ne supprime donc jamais vos données applicatives.

docker system prune -a --volumes

Nettoyer régulièrement sans risque

Un nettoyage ponctuel ne règle pas le problème de fond si les mêmes objets se reconstituent en quelques semaines. Trois règles évitent les mauvaises surprises. D’abord, travaillez par filtre plutôt qu’en suppression totale : un conteneur arrêté depuis une heure appartient peut-être à un déploiement en cours. Ensuite, ne lancez jamais une suppression large d’images juste avant de redémarrer vos services, sous peine de payer le retéléchargement au pire moment. Enfin, mesurez après l’opération avec docker system df : si l’espace récupéré est faible, le problème vient probablement d’un volume ou d’un journal applicatif plutôt que de Docker lui-même.

Pour automatiser un entretien léger, des scripts planifiés qui s’exécutent en root et suppriment les conteneurs arrêtés depuis plus d’une semaine, ainsi que les images non utilisées depuis un mois, suffisent à contenir la croissance du disque. Réservez les suppressions d’images par -a et de volumes à des interventions manuelles. Ce type de script ne remplace ni un monitoring de l’espace disque, ni les mises à jour de sécurité du système et de Docker, qui se planifient séparément. Il ne remplace pas non plus une stratégie de sauvegarde : la haute disponibilité d’un service ne vient pas de Docker, mais des copies que vous conservez ailleurs.

Docker et le pare-feu : un point à connaître

Un dernier point mérite votre attention si vous publiez des ports de conteneurs. Sur Linux, Docker crée lui-même des règles de filtrage pour assurer l’isolation réseau, la publication de ports et le filtrage, et la documentation précise qu’il ne faut pas modifier ces règles à la main. Conséquence directe : lorsqu’un port de conteneur est publié, le trafic est détourné avant de passer par les règles de votre pare-feu (firewall). Autrement dit, une règle restrictive posée avec UFW, qui équipe Debian et Ubuntu, ne suffit pas à filtrer un port publié par Docker sur l’adresse IP publique du serveur. Si vous exposez un service, filtrez-le au niveau du conteneur ou dans la configuration de l’application, plutôt qu’en comptant uniquement sur le pare-feu de l’hôte.

Ce que cela change pour votre VPS

Un disque saturé ne prévient pas toujours par un message clair : le premier symptôme est souvent un service qui refuse de démarrer ou une image qui ne se télécharge plus. Une machine où Docker est déjà en place supprime l’étape d’installation, mais le suivi de l’espace disque reste votre responsabilité. Sur un hébergement mutualisé, ce nettoyage ne vous concerne pas : il n’y a pas de Docker et c’est l’hébergeur qui gère la partition. Sur un serveur VPS, la situation est inverse, et une offre en infogérance déplace cette charge vers l’hébergeur.

Pour aller plus loin dès le départ, le guide d’installation de Docker sur un VPS détaille la mise en route. Un VPS apporte surtout de la flexibilité et de l’évolutivité : vous installez ce que vous voulez, quand vous voulez, et vous ajustez vos ressources sans changer de machine. Si vous empilez plusieurs bases de données et des constructions fréquentes, un serveur dédié avec disque NVMe évite de partager les entrées et sorties disque avec d’autres clients, là où un hébergement cloud mutualise le stockage. Et si un panneau de contrôle comme Plesk cohabite avec vos conteneurs sur la même offre VPS, pensez à mesurer aussi sa consommation : ses sauvegardes et ses journaux ne sont pas gérés par Docker.

Pour approfondir : diagnostiquer un manque d’inodes sur un VPS, diagnostiquer les entrées et sorties disque avec iostat, surveiller l’espace disque et migrer un serveur de jeu vers un nouveau VPS.