Que sont les builds multi-stages et pourquoi les utiliser ?

Question

Accepted Answer

**Les builds multi-stages** utilisent plusieurs stages `FROM` dans un seul Dockerfile — en construisant l'application dans une stage (avec tous les outils de compilation) et en copiant uniquement les artefacts finaux dans une dernière stage propre et minimale. Cela produit des images de production **beaucoup plus petites et plus sécurisées**.

## Le problème : les outils de compilation gonflent l'image

```text
Building an app needs build tools (compilers, dev dependencies, SDKs), but the
FINAL image shouldn't include them:
  → they bloat the image (larger size, slower deploys)
  → they increase the attack surface (more software = more vulnerabilities)
→ You want only the built artifact + its runtime in the final image.
```

## Build multi-stage

```dockerfile
# STAGE 1: "build" — has all the build tools (compile/bundle the app)
FROM node:20 AS build
WORKDIR /app
COPY package*.json ./
RUN npm install              # includes dev dependencies, build tools
COPY . .
RUN npm run build            # produces /app/dist

# STAGE 2: final — a clean, minimal image with ONLY the built artifact
FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html   # copy ONLY the build output
# → the final image has NO build tools, no dev dependencies — just nginx + the built files
```

Le `--from=build` copie les artefacts de la stage de compilation dans l'image finale. L'image finale **exclut tout ce qui provient de la stage de compilation sauf ce que vous copiez explicitement** — ainsi les outils de compilation, les dépendances de développement et les sources ne se retrouvent pas en production.

## Bénéfices

```text
✓ SMALLER images — only the runtime + artifacts (often 10x+ smaller)
✓ More SECURE — fewer packages = smaller attack surface (no compilers/build tools)
✓ Faster deploys/pulls (smaller images transfer faster)
✓ One Dockerfile — build and final image together (no separate build scripts)
→ Common for compiled languages (Go, Rust, Java) and Node/frontend builds.
```

## Pourquoi c'est important

Comprendre les builds multi-stages est précieux pour **produire des images de production petites et sécurisées**, c'est donc une connaissance pratique importante pour construire des images Docker de qualité production.

Le problème qu'il résout est réel et courant : la compilation d'une application nécessite des **outils de compilation** (compilateurs, SDKs, dépendances de développement) que **l'image de production finale ne devrait pas contenir** — les inclure gonfle l'image (taille plus grande, déploiements et téléchargements plus lents) et augmente la **surface d'attaque** (plus de logiciels installés signifie plus de vulnérabilités potentielles). **Les builds multi-stages** résolvent cela élégamment en utilisant plusieurs stages `FROM` : en construisant l'application dans une stage avec tous les outils, puis en **copiant uniquement les artefacts finaux** (`--from=build`) dans une dernière stage propre et minimale qui exclut tout le reste.

Cela produit des images **dramatiquement plus petites** (souvent 10x+ plus petites — juste le runtime et les artefacts) et **plus sécurisées** (pas d'outils de compilation ou de paquets inutiles à exploiter), tout en gardant tout dans un seul Dockerfile (pas de scripts de compilation séparés).

Ce pattern est standard pour les langages compilés (Go, Rust, Java, où le compilateur n'est pas nécessaire à l'exécution) et pour les builds frontend/Node (où les outils de compilation et les sources ne sont pas nécessaires en production).

Puisque les images de production petites et sécurisées importent pour la vitesse de déploiement, le stockage et la sécurité, et puisque les builds multi-stages sont la technique standard et efficace pour les réaliser (en séparant l'environnement de compilation de l'image runtime allégée), comprendre les builds multi-stages — le problème de gonflage/sécurité qu'ils résolvent, comment ils fonctionnent et leurs bénéfices — est une connaissance précieuse et fréquemment appliquée pour construire des images Docker de qualité production, une meilleure pratique largement utilisée dans les Dockerfiles du monde réel et une compétence clé pour produire des applications conteneurisées efficaces et sécurisées.