Docker Compose pour le développement local : fichiers de surcharge, profils, dépendances saines et watch

Objectif

Un seul docker compose up qui donne à chaque contributeur la même base de données, la même file de messages et les mêmes versions de services qu'en production, avec un rechargement de code rapide, sans transformer le fichier versionné en artefact réservé au local.

Prérequis

Un Dockerfile par service qui construit à partir d'un checkout propre, des vérifications de santé (« health checks ») définies pour les dépendances avec état, et une configuration lue depuis des variables d'environnement.

Étapes

1. Écrire compose.yaml comme base à la forme de la production : images par tag, noms de services correspondant aux noms DNS utilisés dans la configuration, aucun port hôte, aucun montage lié. La documentation Docker (citée) indique que Compose lit par défaut compose.yaml et un fichier compose.override.yaml optionnel, et les fusionne, les fichiers ultérieurs remplaçant ou étendant les précédents.
2. Placer les commodités locales dans compose.override.yaml : ports publiés, montage lié de l'arborescence source, variables d'environnement de débogage. Le versionner si tous les développeurs veulent la même chose, sinon versionner un .example et ignorer le vrai fichier.
3. Déclarer les dépendances avec des conditions : depends_on: {db: {condition: service_healthy}} fait que Compose attend la vérification de santé de la dépendance plutôt que le simple démarrage de son conteneur ; service_completed_successfully attend qu'un conteneur de migration à usage unique se termine avec le code 0 (les deux figurent dans la référence des services citée).
4. Rattacher les outils optionnels (intercepteur de mails, interface d'administration, générateur de charge) à des profiles:, afin qu'un simple up les ignore ; les démarrer avec --profile debug ou COMPOSE_PROFILES.
5. Ajouter une section develop.watch : sync pour le code interprété, sync+restart lorsque le processus doit redémarrer pour prendre en compte les changements, rebuild lorsque les manifestes de dépendances changent ; lancer avec docker compose up --watch, ou docker compose watch pour garder les événements de synchronisation hors des journaux de l'application. La page citée de Compose Watch documente ces actions et note que watch ne suit que les services construits depuis une source locale avec build, pas ceux qui utilisent une image pré-construite.
6. Stocker les valeurs par défaut non sensibles dans .env pour l'interpolation de variables, et garder les identifiants hors des fichiers versionnés ; les transmettre via des entrées env_file ignorées par git.
7. Lancer docker compose config en intégration continue pour produire le fichier fusionné et repérer les erreurs de chemin ou d'interpolation.

Résultat attendu

Les nouveaux contributeurs obtiennent une pile fonctionnelle en une seule commande ; le fichier de base sert aussi de documentation de la topologie d'exécution ; les différences avec la production apparaissent comme un petit fichier de surcharge plutôt que comme des modifications éparpillées.

Limites et base de vérification

Compose décrit un hôte unique et n'est pas un orchestrateur de production ; les limites de ressources, les politiques de redémarrage et la mise en réseau diffèrent de Kubernetes. La page citée de Compose Watch présente watch comme un complément aux montages liés, pas un remplacement : ses règles ignore permettent de laisser une arborescence comme node_modules/ hors de la synchronisation, ce que la page justifie par la charge d'E/S due aux nombreux petits fichiers et par des artefacts compilés qui ne peuvent pas être partagés entre les plateformes de l'hôte et du conteneur. Le comportement suit les références citées ; aucune mesure de temps n'est avancée.