Docker RM All Images : Libérez de l’espace

Docker, c’est pratique, mais ça finit toujours par bouffer tout le disque. Entre les images téléchargées, les couches de build intermédiaires, les conteneurs arrêtés qui traînent et les volumes orphelins, on se retrouve vite avec 20 ou 30 Go d’espace parti en fumée. La commande docker rm all containers (ou plutôt ses variantes officielles) permet de récupérer cet espace en une ou deux lignes. Mais attention : mal utilisée, elle peut aussi flinguer ce dont vous avez encore besoin. Je vous explique comment procéder, avec les commandes qui marchent et les pièges à éviter.

J’ai commencé à utiliser Docker en 2019 sur un serveur Debian à Lyon, chez Tech Solutions. À l’époque, je lançais des conteneurs pour tout : un WordPress, une instance Home Assistant, un Plex, quelques tests avec Node-RED. Au bout de six mois, le disque de 120 Go était plein. J’ai passé une après-midi à comprendre d’où venait le problème : les images accumulées, les builds non nettoyés. Depuis, j’ai intégré le ménage Docker dans ma routine hebdomadaire.

Pourquoi Docker occupe-t-il autant d’espace ?

Avant de supprimer quoi que ce soit, il faut comprendre ce qui prend de la place. Docker stocke plusieurs types de données : les images (les templates des conteneurs), les conteneurs eux-mêmes (même arrêtés), les volumes (données persistantes), les réseaux virtuels, et le cache de build (les couches intermédiaires quand vous compilez une image), comme expliqué dans ce guide sur docker installation debian.

Avec le temps, les couches s’accumulent. Par exemple, si vous mettez à jour une image Docker Hub chaque semaine, les anciennes versions ne sont pas supprimées automatiquement. J’ai vu un client à Villeurbanne garder 15 versions de nginx:alpine – 800 Mo chacune – parce qu’il ne savait pas qu’il pouvait toutes les virer. Résultat : 12 Go perdus.

La commande sudo docker system df affiche un tableau clair : la taille totale, le nombre d’éléments, et surtout la colonne RECLAIMABLE – ce que vous pouvez récupérer. Je fais un docker system df toutes les semaines. Si la part récupérable dépasse 2 Go, je lance un nettoyage.

Nettoyer tout d’un coup avec docker system prune – l’approche radicale

La commande la plus efficace pour libérer de l’espace en une fois est sudo docker system prune --all. Elle supprime : tous les conteneurs arrêtés, tous les réseaux non utilisés par au moins un conteneur, toutes les images « dangling » (sans tag) et toutes les images qui ne sont associées à aucun conteneur actif, ainsi que le cache de build.

Attention : elle ne touche pas aux volumes par défaut, car les volumes peuvent contenir des données importantes. Si vous voulez aussi supprimer les volumes orphelins, ajoutez l’option --volumes. Mais faites-le avec précaution.

J’ai utilisé cette commande la semaine dernière sur un serveur de production d’une PME lyonnaise. Avant, le disque affichait 87 % d’occupation. Après docker system prune -a --volumes (j’avais vérifié les volumes au préalable), nous sommes passés à 34 %. Près de 18 Go récupérés. Mais attention : si vous avez une image dont vous avez besoin plus tard et qu’aucun conteneur ne l’utilise au moment du prune, elle sera supprimée. Il faudra la re-télécharger. Donc utilisez cette commande seulement si vous êtes sûr de ne plus avoir besoin des images orphelines.

Quand éviter le prune global ?

Si vous testez plusieurs versions d’une même image localement et que vous voulez les conserver pour comparer, docker system prune -a les effacera. Dans ce cas, mieux vaut supprimer manuellement les images une par une avec docker image rm. Je préfère cette approche quand je développe un nouveau service : je garde les images utilitaires (comme python:3.11) et je ne supprime que celles que j’ai construites moi-même.

Supprimer les images de manière ciblée avec docker image rm

La commande docker image rm (ou docker rmi, l’ancienne syntaxe) supprime une image spécifique. Vous devez spécifier l’ID ou le nom:tag. Par exemple : docker image rm nginx:1.25. Pour supprimer plusieurs images d’un coup, listez-les : docker image rm image1 image2 image3.

Si une image a plusieurs tags, docker image rm ne supprime que le tag spécifié. Si c’était le seul tag, l’image entière est supprimée. C’est pratique pour nettoyer les anciennes versions sans toucher au dernier tag latest.

Pour supprimer toutes les images non utilisées (celles sans conteneur associé), utilisez : docker image prune --all. C’est moins brutal que docker system prune -a car il ne touche ni aux conteneurs, ni aux volumes, ni aux réseaux. Je l’utilise souvent après avoir retiré des conteneurs obsolètes.

Commande	Effet	Risque de perte de données
docker image prune	Supprime les images dangling (sans tag)	Faible
docker image prune -a	Supprime toutes les images inutilisées	Moyen (perte d’images non taggées)
docker system prune -a	Supprime images, conteneurs arrêtés, réseaux, cache	Élevé si des données sont dans des conteneurs arrêtés
docker system prune -a --volumes	Même chose + volumes orphelins	Très élevé (perte de données persistantes)

Nettoyer volumes, réseaux et cache de build – les oubliés

Les volumes sont souvent la cause principale de l’occupation disque. Un volume peut contenir des bases de données, des fichiers téléchargés, des logs. Avant de supprimer des volumes, listez-les avec docker volume ls et inspectez chacun avec docker volume inspect nom_volume pour voir son point de montage. Si vous êtes sûr qu’il n’est plus utilisé, supprimez-le : docker volume prune --all. J’ai déjà récupéré 5 Go sur un volume de logs de conteneur PostgreSQL qui n’était plus monté depuis un an.

Les réseaux virtuels, eux, prennent peu de place, mais docker network prune les nettoie. C’est surtout utile si vous testez des réseaux overlay ou des bridge personnalisés. Le cache de build, en revanche, peut être massif. docker builder prune --all supprime toutes les couches de build intermédiaires. Si vous compilez souvent des images (par exemple un Dockerfile pour une application Node.js), ce cache peut peser 5-10 Go. Je le nettoie une fois par mois.

Automatiser le nettoyage et bonnes pratiques

Plutôt que d’exécuter des commandes à la main, scriptez le nettoyage. Chez Tech Solutions, nous avons un cron qui tourne tous les dimanches à 4h : docker system prune -a --force --filter "until=24h". Le filtre until=24h évite de supprimer des images téléchargées il y a moins de 24 heures. Cela laisse une marge de sécurité. Pour les volumes, nous utilisons docker volume prune --force une fois par mois.

Une autre bonne pratique : ne laissez pas les conteneurs arrêtés s’accumuler. Utilisez l’option --rm au lancement (docker run --rm) pour que le conteneur soit automatiquement supprimé à l’arrêt. Pour les conteneurs de production, passez plutôt par des docker-compose down réguliers.

Enfin, surveillez les logs. Si un conteneur écrit dans un volume de logs sans rotation, cela peut saturer le disque. J’ai déjà vu un conteneur Plex générer 20 Go de logs en un mois. Aujourd’hui, je monte toujours un volume limité ou j’active la rotation via logrotate dans le conteneur.

FAQ : questions fréquentes sur la suppression d’images Docker

docker rm all images est-il une commande valide ?

Non. La commande réelle est `docker image rm` ou `docker rmi`. Pour supprimer toutes les images, utilisez `docker image prune -a` qui supprime toutes les images non utilisées. Pour tout supprimer (conteneurs, réseaux, cache), utilisez `docker system prune -a`. Aucune commande `docker rm all images` n’existe nativement dans Docker.

Que faire si une image utilisée par un conteneur en cours d’exécution ne peut pas être supprimée ?

Docker empêche la suppression d’une image si un conteneur (même arrêté) l’utilise. Arrêtez et supprimez d’abord le conteneur avec `docker container rm nom_du_conteneur`, puis supprimez l’image. Si le conteneur est en cours, stoppez-le avec `docker stop`.

La commande docker system prune supprime-t-elle les volumes ?

Par défaut non. Il faut ajouter l’option `–volumes` pour supprimer les volumes orphelins. Mais attention : les volumes peuvent contenir des données importantes (bases de données, fichiers utilisateurs). Vérifiez toujours avant d’ajouter `–volumes`.

Comment voir la taille des images avant de les supprimer ?

Utilisez `docker image ls –format ‘table {{.Repository}}t{{.Tag}}t{{.Size}}’` pour une liste claire. Vous pouvez aussi utiliser `docker system df` pour un récapitulatif de tout l’espace utilisé par Docker.

Y a-t-il un risque à supprimer le cache de build ?

Le cache de build accélère la reconstruction des images Docker. Si vous le supprimez, les prochains `docker build` seront plus longs, car Docker devra re-télécharger et reconstruire chaque couche. Aucune perte de fonctionnalité, seulement un ralentissement temporaire.

• Utilisez des filtres temporels avec `docker system prune –filter « until=24h »` pour éviter de supprimer les images récentes.
• Combinez `docker image prune -a` et `docker volume prune` dans un script cron pour un nettoyage automatique sans risquer les conteneurs actifs.
• Surveillez l’espace disque avec `docker system df` régulièrement – je le note dans mon agenda tous les lundis matin.
• Ne jamais exécuter `docker system prune -a –volumes` sur un serveur de production sans avoir sauvegardé les volumes importants au préalable.
• Documentez vos commandes de nettoyage dans un fichier `Makefile` ou un script shell partagé avec votre équipe.