Un seul Dockerfile pour le Dev et la Production ? Oui, et voici pourquoi

Vous voulez simplifier votre configuration Docker et garder vos environnements de développement et de production parfaitement alignés ?
Voici comment j’utilise les multi-stage builds Docker et les Dev Containers de VS Code pour maintenir une source de vérité unique — et éliminer la galère de maintenir plusieurs Dockerfiles.

J’avais l’habitude d’avoir deux Dockerfiles pour mes projets.

L’un était destiné à mon devcontainer, et il contenait tout ce dont un développeur a besoin : linters, débogueurs, frameworks de test, etc.

L’autre était un Dockerfile minimal pour le build de production final, réduit à l’essentiel.

Pour rapprocher au maximum mes environnements de développement et de production, je voulais que l’image de base de mon devcontainer soit identique à celle de mon environnement de build en production.

Mais à chaque fois que j’ajoutais une nouvelle dépendance ou que je modifiais une étape de build, je devais mettre à jour les deux fichiers.

C’était fastidieux, source d’erreurs, et franchement, une duplication frustrante des efforts.

Il devait y avoir une meilleure solution.

Et il y en a une.

La solution ? Les multi-stage builds Docker et l’option puissante --target.

​

Le Problème de la Duplication

Le plus gros problème avec plusieurs Dockerfiles, c’est le risque de divergence entre les environnements.

Si votre devcontainer ne repose pas sur la même image de base que votre environnement de build en production, vous risquez de rencontrer des bugs subtils qui n’apparaissent qu’en production.

Vous avez besoin d’une source de vérité unique — un seul fichier qui définit l’environnement de votre application, du développement jusqu’au déploiement.

Et en utilisant les multi-stage builds Docker, vous évitez complètement ce problème.

​

Comment un Seul Fichier Fonctionne

L’astuce consiste à utiliser un seul Dockerfile avec plusieurs étapes nommées.

Vous pouvez définir une étape de développement complète (devcontainer) avec tous les outils nécessaires, et une étape de production minimale (production) pour l’image finale déployable.

L’option docker build --target permet ensuite à Docker de savoir quelle étape vous voulez construire.

Avec un unique Dockerfile structuré par étapes, votre configuration devient plus propre, plus facile à maintenir, et bien moins sujette aux erreurs. Voici à quoi cela ressemble :

 1# Étape 1 : Environnement de base (toutes les dépendances pour le dev et le build)
 2FROM golang:1.25-trixie AS base
 3
 4# ... configuration de base : copie de go.mod et go.sum ...
 5
 6# Étape 2 : Étape de développement (devcontainer)
 7FROM base AS devcontainer
 8
 9# ... installation des outils de dev et configuration adaptée ...
10
11# Étape 3 : Étape de compilation du binaire
12# Étape dédiée uniquement à la compilation de l'exécutable final.
13FROM base AS binary
14
15# ... copie du code source et exécution de la commande de build ...
16
17# Étape 4 : Étape de production
18# Une image minimale contenant uniquement le binaire final.
19FROM scratch AS production
20
21# ... copie du binaire depuis l'étape 'binary' et exécution ...

​

Intégration Transparente avec VS Code

Les Dev Containers de VS Code rendent tout cela super simple. Dans votre fichier .devcontainer/devcontainer.json, vous ajoutez simplement l’argument "target" pour indiquer l’étape à construire.

1{
2  // ...
3  "build": {
4      "dockerfile": "../Dockerfile",
5      "target": "devcontainer"
6  }
7  // ... autres paramètres du devcontainer ...
8}

VS Code s’occupe du reste ! Il construira et lancera votre conteneur en utilisant l’étape devcontainer, vous offrant un environnement de développement complet et fonctionnel.

​

Points Clés à Retenir

• Source de vérité unique : Un seul Dockerfile pour tous vos environnements, sans duplication.
• Plus de divergence : Dev et prod restent toujours synchronisés.
• Workflow simplifié : Des pipelines CI/CD et une intégration des développeurs plus simples grâce à un processus de build unifié.
• Images plus légères : L’option --target permet de générer une image de production ultra-légère sans maintenir un Dockerfile séparé.

Cette technique est un véritable game-changer pour gérer les environnements Docker de vos projets.

Si vous avez déjà rêvé d’un setup plus simple, robuste et maintenable — c’est la voie à suivre.

Vous souhaitez un guide détaillé adapté à votre langage de programmation ? Dites-le-moi en commentaire ou contactez-moi ici si vous voulez un tutoriel spécifique à votre stack.

Si vous souhaitez me confier la mise en place de cette configuration pour votre projet, n’hésitez pas à me contacter via le formulaire — je serai ravi de vous aider.