Alexandre m’a fait découvrir la fonctionnalité Compose Watch ajoutée en septembre 2023 dans la version 2.22.0 de docker compose.
Compose supports sharing a host directory inside service containers. Watch mode does not replace this functionality but exists as a companion specifically suited to developing in containers.
More importantly, watch allows for greater granularity than is practical with a bind mount. Watch rules let you ignore specific files or entire directories within the watched tree.
For example, in a JavaScript project, ignoring the node_modules/ directory has two benefits:
Performance. File trees with many small files can cause high I/O load in some configurations
Multi-platform. Compiled artifacts cannot be shared if the host OS or architecture is different to the container
— from
Je suis très heureux de l’introduction de cette fonctionnalité, même si je n’ai pas encore eu l’occasion de la tester. Bien que je trouve qu’elle arrive un peu tardivement 😉.
Je suis surpris d’observer que cette fonction a généré très peu de réaction sur Hacker News 🤔.
Je n’ai rien trouvé non plus sur Reddit, ni sur Lobster 🤔.
Sans doute pour cela que je n’ai pas vu la sortie de cette fonctionnalité.
Je pense avoir retrouvé la première Pull Request de la fonctionnalité compose watch : [ENV-44] introduce experimental watch command (skeletton) #10163.
Je constate que compose watch est basé sur fsnotify.
Je constate ici qu’un système de “debounce” est implémenté.
Je pense que c’est cette fonction qui effectue la copie des fichiers, mais je n’en suis pas certain et je ai mal compris son fonctionnement.
Entre 2015 et 2019, j’ai rencontré de nombreux problèmes de performance liés aux volumes de type “bind” sous MacOS (et probablement aussi sous MS Windows) :
volumes:
- ./src/:/src/
Les performances étaient désastreuses pour les projets Javascript avec leurs node_modules volumineux.
Exécuter des commandes telles que npm install ou npm run build prenait parfois 10 à 50 fois plus de temps que sur un système natif ! Je précise que ce problème de performance était inexistant sous GNU Linux.
Pour résoudre ce problème pour les utilisateurs de MacOS, j’ai exploré plusieurs stratégies de development environment, comme l’utilisation de Vagrant avec différentes méthodes de montage, dont certaines reposaient sur une approche similaire à celle de Compose Watch, c’est-à-dire la surveillance des fichiers (fsnotify…) et leur copie.
N’ayant trouvé aucune solution pleinement satisfaisante, j’ai finalement adopté la stratégie Asdf, puis Mise, qui me convient parfaitement aujourd’hui.
Cela signifie que, dans mes environnements de développement, je n’utilise plus Docker pour les services sur lesquels je développe, qu’ils soient implémentés en JavaScript, Python ou Golang…
En revanche, j’utilise toujours Docker pour les services complémentaires tels que PostgreSQL, Redis, Elasticsearch, etc.
Est-ce que la fonctionnalité Compose Watch remettra en question ma stratégie basée sur Mise ? Pour l’instant, je ne le pense pas, car je ne rencontre aucun inconvénient majeur avec ma configuration actuelle et l’expérience développeur (DX) est excellente.