Neuf Dockerfiles, et le retour à deux

À un moment, j'ai levé les yeux et il y avait neuf Dockerfiles.

Aucune mauvaise décision isolée. Le back-end a besoin de son propre fichier — d'accord. Le dev a besoin d'arguments de build différents de la prod, alors on ajoute une variante .dev — d'accord. Répète maintenant ça pour web, admin, super-admin, mobile et back-end, et le moindre changement de logique de build partagée implique d'en toucher la moitié, et le temps de build en CI reflète tout le bazar.

C'est comme ça que ça se passe toujours : plusieurs décisions individuellement raisonnables qui se cumulent. Chaque ajout a l'air justifié au moment où tu le fais. La prolifération ne devient visible qu'une fois que tu en fixes neuf du regard.

Consolider à deux

Backend/Dockerfile et Frontend/Dockerfile, avec un argument de build pour sélectionner quelle application du monorepo est construite :

ARG APP_NAME=web

Ça marche parce que les trois applications front-end partagent la grande majorité de leur build — même version de Node, même gestionnaire de paquets, même structure de monorepo, même étape de build des paquets partagés. La différence entre elles s'exprime comme un argument de build, pas comme une raison pour un fichier séparé.

Les cibles dev et prod diffèrent encore de façon notable — le dev veut le hot-reload et les dépendances de dev, la prod veut une image minimale durcie. Les builds multi-étapes gèrent les deux dans un seul fichier, en branchant seulement à l'étape finale :

FROM node AS build
# ...
FROM node:alpine AS production

La règle

Dans un monorepo où plusieurs applications partagent l'essentiel de leur pipeline, prends par défaut un Dockerfile paramétré par composant logique, pas un par application déployable. Réserve un fichier vraiment séparé à quelque chose de structurellement différent — un autre runtime, un build fondamentalement différent — pas juste une autre application vivant à côté de frères similaires.

Reconnaître « ce sont surtout le même build avec une cible différente » avant que les fichiers ne se multiplient est la version peu coûteuse de cette leçon. Consolider après est du vrai retravail évitable — et ça découle de la même erreur que j'ai faite avec l'infrastructure en général, la faire pousser de façon réactive au lieu d'en concevoir la forme d'entrée.

Une note de bas de page Windows : la surveillance de fichiers de Docker pour le hot-reload peut manquer des éditions de l'hôte. Un changement back-end qui « ne s'applique pas » dans le conteneur n'est pas forcément un bug — l'événement de surveillance peut juste ne jamais l'avoir atteint, et le conteneur a besoin d'un redémarrage manuel. Ça vaut la peine de vérifier avant de déboguer du code qui est en fait correct.