Share this post
L'article explore les nuances entre docker-compose stop et docker-compose down, soulignant leurs effets sur les conteneurs Docker et quand les utiliser pour éviter les pertes de données.
Premier projet, un flux de test local mal maitrisé et je casse la preprod. La principale root cause ? Je ne connaissais pas bien la différence entre docker-compose stop et docker-compose down .
Il y a quelques jours, j’ai rejoint une association pour les aider à développer un projet open-source. A la découverte du projet, lorsque j’ai voulu lancer l’application pour la première fois, j’ai été faire un tour du côté du Makefile. Dans lequel j’ai découvert qu’on exécutait toujours un docker-compose down pour stopper l’application. Sitôt, les souvenirs de mon erreur évoquée ci-dessus (et expliquée dans la suite de l’article 😉 ) me reviennent et les questions affluent : pourquoi ne pas plutôt utiliser un docker-compose stop ? Est-ce que l’un est meilleur que l’autre ? Finalement dans quel contexte est-il préférable d’utiliser l’un plutôt que l’autre ?
La commande docker-compose down stoppe et supprime les containers, networks, volumes et images définies dans votre docker-compose.yml . Ce fichier yaml permet de décrire les services, les réseaux, les volumes et d'autres configurations nécessaires pour exécuter une application composée de plusieurs conteneurs Docker.
Si on résume, le down reverse les effets de docker-compose up.
.png)
docker-compose up
La commande docker-compose stop elle, arrête les conteneurs associés aux services définis dans le fichier docker-compose.yml sans supprimer les autres ressources telles que les réseaux, les volumes, etc.
Les conteneurs sont arrêtés, mais conservent leur état, ce qui signifie que les données stockées dans les conteneurs (par exemple, dans des volumes Docker) restent intactes. Il faut bien comprendre que ce sont les ressources associées (volume, config réseau) qui gardent leur état. Le conteneur en lui même, en particulier sa mémoire (~RAM), est perdue.
Les conteneurs peuvent être redémarrés ultérieurement en utilisant la commande docker-compose start.
Cette commande est utile lorsque vous souhaitez arrêter temporairement les conteneurs sans perdre les données ou les configurations associées. Les gens utilisent souvent docker-compose stop par défaut car c’est plus rapide (à la fois d’arrêter et remonter le conteneur), surtout s’il y a des gros volumes de fichiers.
docker-compose down peut m’aider ?En cherchant un peu, j’ai trouvé un exemple dans lequel il est intéressant d’utiliser un docker-compose down. Le 15 septembre 2016, @wting poste un message sur github : lors de l'utilisation de docker-compose build, les conteneurs ne sont pas correctement reconstruits, ce qui entraîne des problèmes avec un conteneur Varnish en raison de lock files obsolètes.
@denephin lui répond que l’erreur vient très certainement du fait que le lock file est dans un volume et lui conseille de faire un docker-compose down pour supprimer les anciens containers et leurs volumes avant de relancer un up qui en créera des nouveaux.
Lorsque Docker Compose reconstruit les conteneurs avec docker-compose build, il essaie de réutiliser les conteneurs existants si possible. Donc si la configuration d'un conteneur n'a pas changé, Docker Compose peut simplement redémarrer le conteneur existant au lieu d'en créer un nouveau. Dans ce cas, même si docker-compose build est exécuté, les fichiers persistants dans le container Varnish, tels que les lock files, ne sont pas automatiquement nettoyés. @wting aurait aussi pu utiliser docker-compose up --force-recreate , pour forcer la recréation de tous les conteneurs, même si leur configuration n'a pas changé.
En utilisant docker-compose down, on est assuré que notre environnement est dans un état propre et prêt à être reconstruit à partir de zéro.
docker-compose down peut me porter préjudice ?Vous vous souvenez quand je vous ai dit que j’avais cassé la preprod ? Voilà comment c’est arrivé. Une migration liquidbase avait été faîte récemment et nous voulions finalement changer le nom du fichier de migration car il contenait un caractère spécial qui bloquait les utilisateurs de windows (en l’occurrence un de nos Product Owner).
J’avais pris l’habitude d’utiliser docker-compose down dans mon flux de test en local. J’avais cru le changement de nom de fichier trivial, il ne l’était pas. C’est à dire qu’il ne suffisait pas de changer le nom de fichier et relancer une migration. Or étant donné mon flux de test, je n’ai pas pu m’en rendre compte lors de mon test en local.
En effet, le docker-compose down supprime image et volumes, donc ma DB. Ainsi lorsque j’ai lancé mon application en local pour tester mes changements, ma DB était re-générée localement et donc il n’y avait aucun conflit avec le nom du fichier. Une toute autre histoire quand j’ai mergé en préprod et que j’ai cassé l’environnement…
En conclusion, docker-compose stop est utile lorsque vous souhaitez simplement arrêter les conteneurs sans perdre les données persistantes ou les configurations associées. Cela permet de redémarrer les conteneurs ultérieurement sans avoir à reconstruire entièrement l'environnement.
L'utilisation de docker-compose down peut être dangereuse et il faut bien en comprendre les conséquences. Elle est appropriée lorsque vous avez besoin de nettoyer complètement votre environnement Docker. Par exemple dans le cas où on souhaite supprimer une base de donnée locale ou faire un nettoyage pour changer de projet.
docker-compose up, down, stop start difference
'Docker Compose Down' -- Guide To Stopping and Removing Docker Containers
