Cosa sono i build multi-stage e perché usarli?

Question

Accepted Answer

**I build multi-stage** utilizzano più stage `FROM` in un unico Dockerfile — costruendo l'applicazione in uno stage (con tutti i tool di build) e copiando solo gli artefatti finali in uno stage finale pulito e minimalista. Questo produce immagini di produzione **molto più piccole e sicure**.

## Il problema: i tool di build gonfiano l'immagine

```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
```

Il `--from=build` copia gli artefatti dallo stage di build nell'immagine finale. L'immagine finale **esclude tutto dallo stage di build tranne ciò che copi esplicitamente** — quindi i tool di build, le dipendenze di sviluppo e il codice sorgente non finiscono in produzione.

## Vantaggi

```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.
```

## Perché è importante

Comprendere i build multi-stage è prezioso per **produrre immagini di produzione piccole e sicure**, quindi è una conoscenza pratica importante per costruire immagini Docker di qualità produttiva.

Il problema che risolve è reale e comune: costruire un'applicazione richiede **tool di build** (compilatori, SDK, dipendenze di sviluppo) che **l'immagine di produzione finale non dovrebbe contenere** — includerli gonfia l'immagine (dimensioni maggiori, deployamenti e pull più lenti) e aumenta la **superficie di attacco** (più software installato significa più vulnerabilità potenziali). **I build multi-stage** risolvono questo elegantemente utilizzando più stage `FROM`: costruendo l'applicazione in uno stage con tutti i tool, quindi **copiando solo gli artefatti finali** (`--from=build`) in uno stage finale pulito e minimalista che esclude tutto il resto.

Questo produce immagini che sono **drasticamente più piccole** (spesso 10x+ più piccole — solo il runtime e gli artefatti) e **più sicure** (nessun tool di build o pacchetto non necessario da sfruttare), mantenendo tutto in un unico Dockerfile (nessun script di build separato).

Questo pattern è standard per i linguaggi compilati (Go, Rust, Java, dove il compilatore non è necessario a runtime) e per i build frontend/Node (dove i tool di build e il codice sorgente non sono necessari in produzione).

Poiché immagini di produzione piccole e sicure contano per la velocità di deployment, lo storage e la sicurezza, e poiché i build multi-stage sono la tecnica standard ed efficace per raggiungerli (separando l'ambiente di build dall'immagine runtime snella), comprendere i build multi-stage — il problema di gonfiore/sicurezza che risolvono, come funzionano e i loro vantaggi — è una conoscenza preziosa e frequentemente applicata per costruire immagini Docker di qualità produttiva, una best practice ampiamente utilizzata nei Dockerfile del mondo reale e un'abilità chiave per produrre applicazioni containerizzate efficienti e sicure.