Co jsou vícestupňové buildy a proč je používat?

Question

Accepted Answer

**Vícestupňové buildy** používají více `FROM` stupňů v jednom Dockerfile — aplikace se vytváří v jednom stupni (se všemi build nástroji) a do čistého, minimálního finálního stupně se kopírují pouze konečné artefakty. To vytváří **mnohem menší, bezpečnější** produkční image.

## Problém: build nástroje přidělují velikost 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.
```

## Vícestupňový build

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

Příkaz `--from=build` kopíruje artefakty z build stupně do finálního image. Finální image **vylučuje vše z build stupně kromě toho, co explicitně zkopírujete** — build nástroje, dev závislosti a zdrojový kód se tedy neobjeví v produkci.

## Výhody

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

## Proč to záleží

Rozumění vícestupňovým buildům je cenné pro **vytváření malých, bezpečných produkčních image**, takže je to důležité praktické znalost pro vytváření produkčních Docker image.

Problém, který řeší, je skutečný a běžný: vytváření aplikace vyžaduje **build nástroje** (kompilátory, SDK, dev závislosti), které **by finální produkční image neměl obsahovat** — jejich zahrnutí zvětšuje image (větší velikost, pomalejší nasazení a stahování) a zvyšuje **útočnou plochu** (více nainstalovaného software znamená více potenciálních zranitelností). **Vícestupňové buildy** to elegantně řeší použitím více `FROM` stupňů: aplikace se vytváří v stupni se všemi nástroji, pak se **kopírují pouze konečné artefakty** (`--from=build`) do čistého, minimálního finálního stupně, který vylučuje vše ostatní.

To vytváří image, které jsou **dramaticky menší** (často 10x+ menší — pouze runtime a artefakty) a **bezpečnější** (žádné build nástroje ani zbytečné balíčky k zneužití), přičemž zůstává vše v jednom Dockerfile (bez oddělených build skriptů).

Tento vzor je standardní pro kompilované jazyky (Go, Rust, Java, kde se kompilátor běhově nepotřebuje) a pro frontend/Node buildy (kde se build tooling a zdrojový kód v produkci nepotřebují).

Protože malé, bezpečné produkční image jsou důležité pro rychlost nasazení, storage a bezpečnost, a protože vícestupňové buildy jsou standardní, efektivní technikou jejich dosažení (oddělení build prostředí od štíhlého runtime image), pochopení vícestupňových buildů — problém s přídavnou váhou a bezpečností, který řeší, jak fungují a jejich výhody — je cenné, často používané znalosti pro vytváření produkčních Docker image, best practice широко používané v reálných Dockerfile a klíčová dovednost pro vytváření efektivních, bezpečných kontejnerizovaných aplikací.