Quand on travaille avec Docker depuis plusieurs années, on finit par accumuler des conteneurs comme on accumule des tasses de café sur un bureau. Certains sont arrêtés depuis des semaines, d’autres tournent en arrière-plan sans servir à rien. Régulièrement, je vois des collègues chez Tech Solutions à Lyon perdre du temps à identifier quel conteneur supprimer, alors qu’docker rm all containers ferait l’affaire. La suppression massive de conteneurs Docker n’est pas qu’un caprice d’administrateur : c’est une opération de maintenance qui libère de l’espace disque, réduit les risques de conflit réseau et améliore les performances globales du serveur. Mais attention, une suppression aveugle peut aussi casser des dépendances si on ne maîtrise pas les options disponibles. Voyons ensemble comment utiliser Docker Remove All Container de manière efficace et sécurisée.
Pourquoi accumuler des conteneurs Docker nuit à votre système ?
Chaque conteneur arrêté consomme encore des ressources : de l’espace sur le disque pour son système de fichiers en couches, des entrées dans la table de routage réseau, et parfois des volumes persistants oubliés. J’ai constaté, lors d’un audit chez un client à Villeurbanne le mois dernier, que 18 conteneurs arrêtés occupaient près de 4,2 Go d’espace disque. En les supprimant avec la commande docker delete container, nous avons récupéré 3,8 Go et la commande docker ps est devenue lisible en deux secondes au lieu de dix.
Un autre problème fréquent : les conteneurs stoppés peuvent entrer en conflit avec de nouvelles instances si les ports sont réservés. Par exemple, un conteneur Nginx arrêté mais toujours présent bloque le port 8080, empêchant le lancement d’un autre service. La solution ? Les supprimer proprement. L’objectif n’est pas de tout détruire à chaque fin de journée, mais d’instaurer une routine de nettoyage hebdomadaire. Avec l’option docker container prune, vous supprimez d’un coup tous les conteneurs arrêtés sans avoir à les lister un par un.


La commande magique : docker system prune
Quand je forme mes équipes, je leur montre d’abord la commande star : docker system prune -a. Elle nettoie les conteneurs arrêtés, les images non utilisées, les réseaux orphelins et le cache de construction. Attention, l’option -a supprime aussi les images non taguées, ce qui peut être agressif si vous en avez besoin pour des tests. Pour éviter les mauvaises surprises, je recommande d’exécuter d’abord docker system prune sans flag : cela ne touche que les éléments dangling (non associés à un conteneur).
Un exemple concret : la semaine dernière, j’ai optimisé un serveur Debian d’un client qui hébergeait 5 instances WordPress. Après avoir appliqué docker system prune -a --volumes, nous avons libéré 12 Go d’espace. Mais cette commande supprime aussi les volumes non utilisés, ce qui peut effacer définitivement des données. Je déconseille d’utiliser l’option --volumes sans avoir vérifié qu’aucun volume nommé n’est nécessaire. Privilégiez docker volume prune séparément, après avoir arrêté les piles de conteneurs.


Les subtilités de docker rm et docker container prune
La commande docker rm supprime un conteneur spécifique, mais il faut d’abord l’arrêter avec docker stop. Pour tout supprimer en une ligne : docker rm -f $(docker ps -aq). Le -f force la suppression même si le conteneur tourne. Mais attention : forcer l’arrêt envoie un signal SIGKILL, ce qui peut corrompre les données si le conteneur est en pleine écriture. J’ai vu un administrateur chez un client lyonnais perdre une base de données MongoDB entière à cause de ça.
| Commande | Action | Risque |
|---|---|---|
docker rm $(docker ps -aq) |
Supprime tous les conteneurs arrêtés | Échoue si un conteneur est en cours |
docker rm -f $(docker ps -aq) |
Supprime tous les conteneurs (forcé) | Risque de perte de données |
docker container prune |
Supprime tous les conteneurs arrêtés | Aucun, demande confirmation par défaut |
docker system prune |
Nettoie tout sauf les volumes | Supprime images non utilisées |
Pour les environnements de développement, docker container prune -f est idéal : pas de confirmation, on supprime tout ce qui est arrêté. En production, je préfère une approche plus fine : lister les conteneurs anciens (plus de 7 jours) avec docker ps -a --filter "status=exited" --format "{{.ID}}" et supprimer seulement ceux-là.


Automatiser le nettoyage pour ne plus y penser
La maintenance manuelle est chronophage. Sur mon serveur personnel à la maison, j’ai configuré une tâche cron qui exécute docker system prune -af chaque dimanche à 3h du matin. Le -a supprime toutes les images non utilisées, le -f évite la confirmation. Mais attention : si vous utilisez Docker Compose avec des images personnalisées, elles risquent d’être nettoyées si aucun conteneur ne les référence. Pour éviter ça, je garde un conteneur « garde-fou » qui tourne en permanence avec une image de base (par exemple alpine sleep infinity).
Vous pouvez aussi utiliser des outils comme docker-cleanup ou watchtower (pour les mises à jour). Mais le plus simple reste un script shell :
#!/bin/bash docker container prune -f docker image prune -a -f docker volume prune -f docker network prune -fCe script, exécuté via cron, garde votre système léger. Testez-le d’abord sans
-fpour vérifier ce qui serait supprimé. J’ai perdu une image personnalisée de Home Assistant une fois parce que j’avais oublié de la taguer correctement. Depuis, j’ajoute toujours un tag fixe (ex:myapp:prod) pour éviter qu’elle soit éligible au prune.Simulateur d’espace libéré
Calculez l’espace que vous pouvez récupérer en supprimant vos conteneurs Docker arrêtés.
Ce simulateur utilise une multiplication simple : nombre de conteneurs × espace moyen.
Aucune API externe n’est utilisée ; le calcul est local et instantané.
Les pièges à éviter quand on supprime tout
Il y a quelques mois, un client a accidentellement supprimé tous ses conteneurs de production en voulant exécuter
docker rm -f $(docker ps -aq)sur le mauvais terminal. Résultat : 3 applications critiques indisponibles pendant 20 minutes, le temps de relancer les services depuis les images. La leçon : vérifiez toujours sur quel hôte vous tapez la commande. J’utilise désormais un aliasalias docker-kill-all="docker stop $(docker ps -q) && docker rm $(docker ps -aq)"qui stoppe d’abord proprement.Un autre piège : la substitution de commande
$(docker ps -aq)échoue si la liste est vide (la commande devientdocker rmsans argument, ce qui affiche l’aide). Ajoutez2>/dev/nullou utilisezdocker ps -aq | xargs -r docker rm(l’option-rempêche l’exécution si l’entrée est vide). Pour les volumes,docker volume prune -fsupprime aussi les volumes anonymes liés à des conteneurs supprimés, mais pas les volumes nommés. Si vous voulez supprimer ces volumes nommés inutilisés, utilisezdocker volume ls -qf dangling=true | xargs -r docker volume rm.Questions fréquentes sur la suppression de conteneurs Docker
Puis-je supprimer un conteneur en cours d’exécution ?
Oui, avec l’option -f ou –force de docker rm. Mais cela envoie un signal SIGKILL, ce qui peut corrompre les données en écriture. Il vaut mieux d’abord utiliser docker stop (SIGTERM) puis docker rm.
La commande docker system prune supprime-t-elle mes images personnalisées ?
Oui, si l’image n’est associée à aucun conteneur (même arrêté). Pour la protéger, taggez-la avec un nom spécifique et créez un conteneur factice qui l’utilise, ou utilisez docker image prune sans -a pour ne supprimer que les images dangling.
Comment supprimer tous les conteneurs sans confirmation ?
Utilisez docker container prune -f. Pour les conteneurs en cours, combinez docker stop $(docker ps -q) && docker rm $(docker ps -aq). Attention à la substitution vide : préférez xargs -r.
Que faire si je veux garder certains conteneurs ?
Filtrez par nom ou label. Par exemple : docker container prune –filter ‘label!=keep=true’. Ou listez les conteneurs à supprimer avec une commande personnalisée.














