Arrêter tous les conteneurs Docker sans casser le reste de l’environnement demande surtout de choisir le bon niveau d’action. Ici, je montre la commande la plus directe pour stopper les conteneurs actifs, les variantes plus fiables pour un script ou un alias, et la différence entre un arrêt propre, un arrêt forcé et une pile gérée par Compose. Je termine avec les pièges que je vois le plus souvent quand on travaille en DevOps sur une machine de dev, un serveur de test ou un poste partagé.
Les points essentiels à retenir avant d’arrêter tous les conteneurs
- `docker ps -q` retourne uniquement les conteneurs en cours d’exécution.
- `docker stop` envoie d’abord un signal propre, puis force l’arrêt si le délai expire.
- Le délai par défaut est de 10 secondes sous Linux et de 30 secondes sous Windows.
- `docker compose stop` arrête les services sans supprimer les conteneurs.
- `docker compose down` va plus loin et retire aussi les réseaux créés par `up`, avec des options supplémentaires pour les volumes et les images.
Ce que l’arrêt global change vraiment
Quand j’arrête tous les conteneurs, je ne fais pas une suppression. Je demande d’abord à Docker d’envoyer un signal d’arrêt au processus principal, puis je lui laisse un délai pour quitter proprement. Si le processus ne répond pas, Docker finit par forcer l’arrêt avec un signal plus brutal. C’est une nuance importante, parce qu’elle évite les coupures sèches sur des services qui ont besoin de fermer une connexion, d’écrire un état ou de terminer un traitement en cours.
Par défaut, le conteneur reçoit un signal de type SIGTERM, puis Docker attend avant de passer à SIGKILL. D’après la documentation Docker, le délai standard est de 10 secondes sous Linux et de 30 secondes sous Windows si rien n’a été configuré au niveau du conteneur. C’est généralement suffisant pour des services bien conçus, mais trop court pour une base de données en charge ou un traitement long. Si j’ai un doute, j’allonge temporairement le délai avec `-t` au lieu de forcer l’arrêt.
Le point le plus souvent mal compris, c’est que l’arrêt ne supprime pas les conteneurs ni leurs volumes. Les données persistées dans un volume nommé restent en place. Autrement dit, couper tous les conteneurs est une opération de contrôle, pas une remise à zéro. C’est exactement ce qu’on veut dans beaucoup de cas DevOps, surtout quand on prépare un redéploiement ou un diagnostic. La question suivante devient donc très concrète: quelle commande taper pour viser uniquement les conteneurs actifs?
| Commande | Effet | Quand je l’utilise |
|---|---|---|
docker stop |
Arrêt propre d’un ou plusieurs conteneurs en cours d’exécution | Quand je veux couper sans casser l’état interne |
docker kill |
Arrêt forcé via signal de type SIGKILL
|
Quand un conteneur refuse de quitter proprement |
docker compose stop |
Arrêt des services d’un projet Compose, sans suppression | Quand la pile est pilotée par Compose |
docker compose down |
Arrêt et suppression des conteneurs, réseaux, et éventuellement volumes/images selon les options | Quand je veux remettre un environnement à plat |
La commande la plus simple pour arrêter tous les conteneurs actifs
Pour la plupart des cas, je pars de cette forme:
docker stop $(docker ps -q)La logique est simple: docker ps -q renvoie seulement les identifiants des conteneurs en cours d’exécution, puis docker stop les arrête un par un. Je n’ai donc pas besoin de la variante -a ici, parce que docker ps -a liste aussi les conteneurs déjà stoppés. Les inclure n’apporte rien à l’arrêt global et produit surtout du bruit inutile.
Je préfère cette commande pour un usage ponctuel en terminal, parce qu’elle est lisible et directe. En revanche, elle a un défaut classique: si aucun conteneur ne tourne, la substitution de commande peut devenir vide et docker stop se plaindre d’un manque d’arguments. Ce n’est pas grave dans un usage manuel, mais dans un script, je veux quelque chose de plus robuste.
| Besoin | Commande | Remarque |
|---|---|---|
| Arrêt rapide en interactif | docker stop $(docker ps -q) |
Simple, clair, mais pas idéal si la liste est vide |
| Arrêt dans un script Linux | docker ps -q | xargs -r docker stop |
-r évite d’appeler docker stop sans argument |
| Version portable en shell | ids=$(docker ps -q); [ -n "$ids" ] && docker stop $ids |
Je la garde quand je veux éviter les surprises entre shells |
Ce point paraît mineur, mais il fait gagner du temps: dans un environnement de dev où les conteneurs démarrent et s’arrêtent souvent, une commande qui tolère la liste vide est plus agréable à automatiser. C’est aussi la raison pour laquelle je passe volontiers à une fonction shell dès que je répète l’opération plusieurs fois par jour.
Rendre la commande fiable dans un script ou un alias
Pour un usage répétitif, je préfère une petite fonction shell plutôt qu’un copier-coller à la main. Elle permet d’ajouter un garde-fou, de documenter l’intention et d’éviter les erreurs quand il n’y a rien à arrêter. Voici une version simple et portable:
dstopall() {
ids=$(docker ps -q)
[ -n "$ids" ] && docker stop $ids
}Cette forme me plaît parce qu’elle dit exactement ce qu’elle fait: elle récupère les conteneurs actifs, teste s’il y en a, puis les arrête. Sur Linux GNU, xargs -r est pratique et compact. Sur macOS ou dans un environnement où xargs ne propose pas -r, le test shell reste plus sûr. C’est un détail, mais en DevOps les détails de portabilité finissent toujours par compter.
Si je veux aller un peu plus vite sans sacrifier la lisibilité, je peux aussi créer un alias de confort. Je le réserve toutefois aux usages très simples, parce qu’un alias devient vite opaque dès qu’on ajoute une condition, un délai ou une journalisation. Dès que le comportement doit être explicite, je reviens à une fonction. Et si les services sont gérés par Compose, je ne m’acharne pas à tout arrêter globalement: je passe par l’outil du projet.
Docker Compose change la logique
Quand une application est décrite dans un fichier Compose, je préfère arrêter la pile avec docker compose stop. C’est la commande la plus cohérente pour un projet multi-conteneurs, parce qu’elle cible les services du projet au lieu de viser tous les conteneurs du host. La documentation Docker indique aussi que Compose arrête les services dans l’ordre de dépendance, ce qui évite de couper un backend avant son proxy ou sa couche applicative.
La vraie alternative, c’est docker compose down. Là, on change d’échelle: on arrête les conteneurs, puis on supprime aussi les conteneurs et les réseaux créés par up. Avec certaines options, on peut aller plus loin et retirer des volumes ou des images. C’est utile pour repartir de zéro, mais je le considère comme une opération de nettoyage, pas comme un simple arrêt.
| Commande Compose | Effet | Mon usage |
|---|---|---|
docker compose stop |
Arrête les services sans supprimer les conteneurs | Pause temporaire, maintenance courte, reprise avec start
|
docker compose down |
Arrête et supprime les conteneurs et les réseaux créés par up
|
Remise à plat d’un environnement |
docker compose down -v |
Ajoute la suppression des volumes nommés déclarés dans le fichier et des volumes anonymes attachés | Réinitialisation complète, à utiliser avec prudence |
Le point de vigilance ici, c’est la donnée. Un down -v peut faire disparaître ce que l’on pensait conserver, alors que l’arrêt simple ne touche pas aux volumes. Les volumes externes, eux, ne sont pas supprimés par défaut, ce qui est rassurant pour les bases ou les données partagées entre environnements. Quand j’ai un doute, je relis la configuration avant d’appuyer sur la touche entrée.
Les pièges que je vois le plus souvent
Le premier piège, c’est de confondre docker ps et docker ps -a. Le premier montre les conteneurs qui tournent encore; le second ajoute ceux qui sont déjà arrêtés. Pour arrêter tout ce qui tourne, je me limite au premier. Pour inspecter l’ensemble de l’état du host, j’utilise le second, mais pas pour lancer un arrêt en masse.
Le deuxième piège, c’est le conteneur qui redémarre tout seul. Si une politique de redémarrage est configurée, notamment avec always ou unless-stopped, l’arrêt manuel ne raconte pas toute l’histoire. Docker documente bien ce comportement: un conteneur stoppé manuellement n’est pas relancé immédiatement par la politique, mais il peut revenir après un redémarrage du daemon selon la stratégie choisie. Dans un environnement de prod, je vérifie donc la politique avant de croire qu’un simple stop suffira à figer l’état.
Le troisième piège, c’est le processus qui refuse de s’éteindre proprement. Là, je ne commence pas par docker kill sur tout le monde. J’essaie d’abord d’identifier le conteneur récalcitrant, puis je le force uniquement si le service ne respecte pas le délai de shutdown. C’est plus propre, et ça évite de transformer un incident local en coupure globale.
Enfin, beaucoup de gens pensent que l’arrêt global nettoie l’espace disque. Ce n’est pas le cas. Pour supprimer les conteneurs déjà arrêtés, je passe par docker container prune. Docker précise d’ailleurs que cette commande cible uniquement les conteneurs stoppés. C’est exactement pour cela qu’il ne faut pas mélanger arrêt, suppression et nettoyage dans un seul réflexe automatique.
| Symptôme | Cause probable | Ce que je fais |
|---|---|---|
| Erreur sur une commande vide | Aucun conteneur ne tourne | Je teste la présence d’IDs avant d’appeler docker stop
|
| Un service revient après coup | Politique de redémarrage ou orchestration | Je regarde la stratégie de redémarrage et le niveau d’orchestration |
| Le conteneur ne s’arrête pas | Shutdown trop lent ou processus bloqué | J’augmente temporairement le délai ou je force le stop sur ce conteneur seulement |
| Le disque reste plein après l’arrêt | Les conteneurs stoppés occupent encore de l’espace | Je nettoie ensuite avec docker container prune si c’est justifié |
Le réflexe que j’applique avant de tout couper sur une machine de dev
Sur une machine de développement, je procède presque toujours dans le même ordre. D’abord, je vérifie ce qui tourne avec docker ps. Ensuite, j’arrête proprement les conteneurs actifs. Si la stack est pilotée par Compose, je passe directement par docker compose stop ou, si je veux repartir d’une base propre, par docker compose down. Ce découpage m’évite de faire un arrêt global alors qu’un projet est isolé d’un autre.
Quand je sais que je vais relancer les services rapidement, je m’arrête là. Quand je veux libérer de l’espace ou repartir d’un environnement net, j’ajoute un nettoyage ciblé des conteneurs stoppés, puis je vérifie que les volumes que je veux conserver sont bien nommés ou externes. C’est une discipline simple, mais elle évite la plupart des accidents inutiles.
Au fond, la bonne pratique n’est pas de mémoriser une seule commande magique, mais de choisir le bon niveau d’action: arrêt propre, arrêt forcé, arrêt de projet, ou nettoyage. C’est cette hiérarchie qui rend la gestion des conteneurs prévisible, surtout quand on travaille vite et sur plusieurs services à la fois.
