Ce sunt build-urile multi-stage și de ce să le folosești?

Question

Accepted Answer

**Build-urile multi-stage** utilizează multiple etape `FROM` într-un singur Dockerfile — construind aplicația într-o etapă (cu toate instrumentele de build) și copiind doar artefactele finale într-o etapă finală curată și minimală. Aceasta produce **imagini mult mai mici și mai sigure** pentru producție.

## Problema: instrumentele de build umflă imaginea

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

`--from=build` copiază artefactele din etapa de build în imaginea finală. Imaginea finală **exclude totul din etapa de build cu excepția a ceea ce copiezi explicit** — deci instrumentele de build, dependențele de dezvoltare și codul sursă nu ajung în producție.

## Beneficii

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

## De ce conteaza

Înțelegerea build-urilor multi-stage este valoroasă pentru **producerea unor imagini mici și sigure de producție**, deci este cunoaștere practică importantă pentru construirea unor imagini Docker de calitate producție.

Problema pe care o rezolvă este reală și frecventă: construirea unei aplicații necesită **instrumente de build** (compilatoare, SDK-uri, dependențe de dezvoltare) pe care **imaginea finală de producție nu ar trebui să le conțină** — includerea lor umflă imaginea (dimensiune mai mare, deploymente și pull-uri mai lente) și crește **suprafața de atac** (mai mult software instalat înseamnă mai multe potențiale vulnerabilități). **Build-urile multi-stage** rezolvă aceasta elegant folosind multiple etape `FROM`: construind aplicația într-o etapă cu toate instrumentele, apoi **copiind doar artefactele finale** (`--from=build`) într-o etapă finală curată și minimală care exclude totul altceva.

Aceasta produce imagini care sunt **dramatic mai mici** (adesea 10x+ mai mici — doar runtime-ul și artefactele) și **mai sigure** (fără instrumente de build sau pachete inutile de exploatat), menținând totul într-un singur Dockerfile (fără scripturi de build separate).

Acest șablon este standard pentru limbaje compilate (Go, Rust, Java, unde compilatorul nu este necesar la runtime) și pentru build-uri frontend/Node (unde tooling-ul de build și codul sursă nu sunt necesare în producție).

Fiind că imaginile mici și sigure de producție contează pentru viteza de deployment, stocare și securitate, și fiind că build-urile multi-stage sunt tehnica standard și eficace pentru a le realiza (separând mediul de build de imaginea runtime ușoară), înțelegerea build-urilor multi-stage — problema de umflare/securitate pe care o rezolvă, cum funcționează și beneficiile lor — este cunoaștere valoroasă și frecvent aplicată pentru construirea unor imagini Docker de calitate producție, o best practice utilizată pe scară largă în Dockerfile-urile din lumea reală și o competență cheie pentru producerea unor aplicații containerizate eficiente și sigure.