💬 Très bon conseil ! La duplication des fichiers docker-compose.yml est un piège courant — on croit gagner du temps, mais on finit par gérer des divergences et des bugs difficiles à tracer. L’approche avec Docker Compose Override est bien plus élégante : un fichier de base solide, et des extensions ciblées pour chaque environnement 🔧🐳. C’est exactement le genre de pratique qui améliore la collaboration en équipe et la fiabilité des déploiements. Bravo pour ce partage clair et utile !

Plus simple pour les variables d'environnement, docker compose charge automatiquement un fichier .env existant dans le même répertoire le docker-compose.yml. Une syntaxe existe pour l'interpolation $APP_PORT entre les valeurs de ce fichier et le docker-compose.yml. Autant je pige l'intérêt d'un docker compose pour le dev, autant je reste sceptique quand a sa pertinence pour les tests, surtout avec l'existence de TestContainer. C'est plus intéressant de garder l'Infra du test dans les setup et teardown par test ou suite de test. Enfin docker compose en prod (et même Swarm Mode), meh. Tant qu'à utiliser des containers, autant partir sur Kubernetes, sinon un Container-As-A-Service. Si c'est pas faisable un bon vieux service linux est tjrs aussi fiable. On peut aussi la jouer hipster avec un Nomad mais je ne l'ai jamais rencontré dans la nature.

À quoi sert un docker-compose hors dev ? 🤔 Pour moi le docker-compose sert en dev (et avec le starter spring boot pour bootstraper les dépendances lors du run en dev) ou pour les tests IT docker-compose.