Un environnement Docker qui accumule des conteneurs arrêtés, c’est le scénario classique que je vois chez la plupart des clients que j’accompagne. La commande docker rm image permet de supprimer un ou plusieurs conteneurs, mais faut-il vraiment tout effacer d’un bloc ? Entre les conteneurs de développement oubliés, les instances de test qui traînent et les volumes orphelins, le désordre numérique peut vite devenir un frein à la productivité. Voici comment maîtriser le nettoyage de votre environnement Docker sans prendre de risques inutiles.
Comprendre la commande docker rm pour les conteneurs
La commande docker container rm (ou simplement docker rm) est l’outil de base pour retirer un ou plusieurs conteneurs de votre système. Sa syntaxe est simple : docker container rm [OPTIONS] CONTAINER [CONTAINER...]. Les options les plus courantes sont -f pour forcer la suppression d’un conteneur en cours d’exécution (en utilisant SIGKILL), -v pour supprimer les volumes anonymes associés, et -l pour retirer un lien réseau spécifique.
J’ai constaté chez une PME lyonnaise la semaine dernière que près de 30 % des conteneurs présents sur leur serveur étaient arrêtés depuis plus de 48 heures. Ces conteneurs inactifs occupaient de l’espace disque – environ 8 Go au total – et rendaient la lecture de docker ps -a très confuse. L’utilisation régulière de docker rm permet de libérer ces ressources et de garder une visibilité claire sur l’état réel de l’infrastructure.
Options clés à connaître
- -f, –force : supprime un conteneur en cours d’exécution. Utilisé avec précaution, car il envoie un signal SIGKILL.
- -v, –volumes : supprime les volumes anonymes attachés au conteneur. Ne touche pas aux volumes nommés.
- -l, –link : retire un lien entre conteneurs sur le réseau bridge par défaut.
Pourquoi un nettoyage régulier de l’environnement Docker est indispensable
Laisser s’accumuler des conteneurs arrêtés n’est pas qu’une question d’esthétique. Chaque conteneur inutile consomme un peu d’espace disque, même s’il ne tourne pas. Les systèmes de fichiers superposés (overlay2) conservent les couches de l’image, et un conteneur non supprimé peut occuper plusieurs centaines de mégaoctets. À l’échelle d’un serveur de développement comptant des dizaines de conteneurs, le gaspillage devient réel.
Il y a deux mois, chez un client spécialisé dans l’IoT, j’ai aidé à remettre en état un serveur Docker qui souffrait de ralentissements. Le diagnostic a montré que 47 conteneurs arrêtés bloquaient inutilement des inodes sur le disque. Après avoir exécuté docker container prune (qui supprime tous les conteneurs arrêtés), le temps de réponse de docker ps est passé de 8 secondes à moins d’une seconde. Ce simple nettoyage a également libéré 5 Go d’espace sur la partition système.
Sur le plan de la sécurité, un conteneur arrêté reste une cible potentielle s’il expose des ports vers l’extérieur. Même à l’arrêt, sa configuration réseau peut persister et créer des trous dans la segmentation. Un nettoyage régulier réduit la surface d’attaque et simplifie l’audit de votre environnement.
Comment supprimer tous les conteneurs avec docker rm all containers
L’expression « docker rm all containers » n’existe pas en tant que commande native, mais elle se traduit facilement par une combinaison d’outils Unix. La méthode la plus courante consiste à obtenir la liste des identifiants de tous les conteneurs (arrêtés ou non) avec docker ps -aq, puis à les passer en paramètre de docker rm. Exemple : docker rm -f $(docker ps -aq). Cette ligne supprime tous les conteneurs, y compris ceux en fonctionnement, grâce à l’option -f.
Une variante plus sûre consiste à ne cibler que les conteneurs arrêtés : docker rm $(docker ps -aq --filter "status=exited"). J’utilise cette approche dans mes scripts de maintenance depuis plusieurs années, notamment pour les environnements CI/CD. Attention toutefois : cette commande ne gère pas automatiquement les volumes associés. Pour les inclure, il faut ajouter l’option -v : docker rm -v $(docker ps -aq --filter "status=exited").
Tableau comparatif des méthodes de suppression
| Méthode | Commande | Portée | Risques |
|---|---|---|---|
| rm individuel | docker rm conteneur1 |
Un seul conteneur | Faible – on choisit précisément |
| rm tous les conteneurs | docker rm -f $(docker ps -aq) |
Tous, y compris en cours | Élevé – peut stopper des services critiques |
| rm tous les arrêtés | docker rm $(docker ps -aq --filter "status=exited") |
Conteneurs arrêtés uniquement | Moyen – si un conteneur important est stoppé par erreur |
| docker container prune | docker container prune |
Tous les arrêtés | Faible – demande confirmation |
| docker system prune | docker system prune -a |
Conteneurs, images, réseaux inutilisés | Élevé – supprime aussi les images non étiquetées |
Les pièges à éviter lors de la suppression massive
Supprimer tous les conteneurs d’un coup peut sembler pratique, mais c’est aussi le meilleur moyen de perdre des données ou de casser une chaîne de déploiement. Premier piège : les volumes. Si vous utilisez des volumes nommés, l’option -v ne les supprime pas (seuls les volumes anonymes sont effacés). En revanche, si vous aviez des volumes anonymes contenant des données générées par l’application (logs temporaires, fichiers de cache), ils disparaîtront avec le conteneur. Dans un contexte de production, cela peut entraîner une perte d’informations non récupérables.
Deuxième piège : les conteneurs en cours d’exécution. L’option -f envoie un SIGKILL, ce qui ne laisse aucune chance à l’application de faire un arrêt propre. La base de données PostgreSQL qui n’a pas eu le temps de checkpoint, le serveur web qui avait des connexions ouvertes… tout est coupé. Il est bien préférable d’arrêter les conteneurs avec docker stop avant de les supprimer. Une approche que je recommande : docker stop $(docker ps -q) puis docker rm $(docker ps -aq).
Troisième piège : les dépendances entre conteneurs. Dans une architecture avec Docker Compose ou des liens réseau, supprimer un conteneur peut en rendre d’autres inopérants. Par exemple, un conteneur web qui attend un conteneur backend avec un link ne pourra plus résoudre son nom d’hôte si le backend est effacé. Avant un nettoyage en masse, il est prudent de vérifier les dépendances avec docker network inspect ou de consulter le fichier docker-compose.yml.
Comparateur de nettoyage Docker
| Méthode | Conteneurs ciblés | Volumes supprimés | Demande confirmation | Risque |
|---|
6 méthodes affichées
Automatiser le nettoyage : scripts et intégration CI/CD
Pour éviter de devoir lancer manuellement des commandes tous les jours, l’automatisation est la solution. Un simple script shell exécuté via cron peut faire le ménage des conteneurs arrêtés datant de plus de 24 heures. Voici un exemple que j’utilise chez plusieurs clients :
#!/bin/bash
# Supprimer les conteneurs arrêtés depuis plus de 24h
docker ps -aq --filter "status=exited" | while read id; do
finished=$(docker inspect -f '{{.State.FinishedAt}}' "$id")
if [[ $(date -d "$finished" +%s) -lt $(date -d '24 hours ago' +%s) ]]; then
docker rm "$id"
fi
done
Ce script inspecte la date de fin de chaque conteneur arrêté et ne supprime que ceux qui ont terminé depuis plus d’une journée. Cela évite de toucher aux conteneurs récemment arrêtés qui pourraient encore être nécessaires pour du débogage. Dans un pipeline CI/CD (Jenkins, GitLab CI, GitHub Actions), on intègre souvent une étape de nettoyage à la fin du job. Par exemple, dans un .gitlab-ci.yml, on peut ajouter un after_script : after_script: - docker container prune -f. Ce genre d’automatisation garantit que chaque exécution de pipeline part d’un environnement propre.
Gérer les volumes et dépendances attachés aux conteneurs
Les volumes sont la mémoire persistante de Docker. Lorsque vous supprimez un conteneur avec docker rm -v, seuls les volumes anonymes sont effacés. Les volumes nommés (ceux que vous créez explicitement avec docker volume create) survivent. C’est une sécurité, mais cela peut aussi conduire à une accumulation de volumes orphelins. Pour les repérer, utilisez docker volume ls --filter "dangling=true" puis docker volume prune.
La semaine dernière, j’ai rencontré un cas où un développeur avait lancé plusieurs fois un conteneur de test sans supprimer les volumes. Au bout de quelques jours, le disque était saturé par 15 volumes anonymes identiques, totalisant 10 Go. La solution : docker volume prune a libéré l’espace immédiatement. Mais attention : si un volume est partagé entre plusieurs conteneurs, le supprimer peut briser la chaîne. Il est donc prudent d’identifier les volumes toujours attachés avec docker volume ls et docker volume inspect.
Un autre aspect concerne les réseaux. Un réseau personnalisé (docker network create) peut devenir orphelin si tous les conteneurs qui y sont connectés sont supprimés. docker network prune nettoie ces réseaux inutilisés. Dans une architecture complexe, je conseille d’utiliser docker system prune -a avec parcimonie, car il supprime aussi les images sans étiquette. Préférez des commandes ciblées : docker container prune, puis docker volume prune, puis docker network prune.
Alternatives à docker rm : prune, system prune, docker-compose down
La commande docker container prune est l’alternative la plus simple pour supprimer tous les conteneurs arrêtés. Contrairement à docker rm, elle demande une confirmation avant d’agir, ce qui évite les erreurs. Pour un nettoyage plus large, docker system prune -a supprime en une fois tous les conteneurs arrêtés, les réseaux non utilisés, les images sans tag (dangling) et le cache de build. Cependant, elle ne touche pas aux volumes. Pour les volumes, il faut ajouter --volumes (ou utiliser docker system prune --volumes dans les versions récentes).
Dans le cadre d’une application multi-conteneurs gérée par Docker Compose, la commande docker-compose down arrête et supprime tous les conteneurs, réseaux et volumes (si spécifié) définis dans le fichier YAML. C’est la méthode recommandée pour un reset complet d’une stack, car elle respecte les définitions et les dépendances. Par exemple, docker-compose down -v supprime aussi les volumes nommés. Mais attention, cela efface toutes les données persistantes de la stack.
Une anecdote : chez un hébergeur de solutions web, un collègue a lancé docker system prune -a --volumes sur un serveur de production par erreur. Résultat : les bases de données des clients (contenues dans des volumes nommés) ont été supprimées. Heureusement, un backup existait. La leçon : ne jamais utiliser --volumes avec system prune sans avoir vérifié que tous les volumes critiques sont sauvegardés. Pour les environnements sensibles, je préfère un script personnalisé qui liste les volumes avant suppression.
FAQ
Quelle est la différence entre docker rm et docker container prune ?
docker rm supprime un ou plusieurs conteneurs spécifiques, tandis que docker container prune supprime tous les conteneurs arrêtés en une seule commande. Prune demande une confirmation, ce qui offre une sécurité supplémentaire.
Comment supprimer tous les conteneurs Docker y compris ceux en cours d’exécution ?
Utilisez la commande ‘docker rm -f $(docker ps -aq)’. L’option -f force l’arrêt et la suppression des conteneurs en fonctionnement. Attention : cette méthode est brutale et peut interrompre des services sans arrêt propre.
La suppression d’un conteneur supprime-t-elle les volumes ?
Par défaut, non. Seuls les volumes anonymes sont supprimés si vous utilisez l’option -v. Les volumes nommés persistent. Pour supprimer les volumes orphelins, utilisez ‘docker volume prune’.
Puis-je automatiser le nettoyage des conteneurs Docker ?
Oui, via un script shell exécuté par cron ou une étape de nettoyage dans votre pipeline CI/CD. Par exemple, un cron quotidien avec ‘docker container prune -f’ maintient l’environnement propre sans intervention manuelle.
Que faire si un conteneur ne peut pas être supprimé (erreur ‘container not found’) ?
Vérifiez l’ID ou le nom du conteneur avec ‘docker ps -a’. Si le conteneur est déjà supprimé, cette erreur est normale. Utilisez docker ps -aq pour obtenir la liste complète des conteneurs existants.