Czym są kompilacje wieloetapowe i dlaczego ich używać?

Question

Accepted Answer

**Kompilacje wieloetapowe** wykorzystują wiele etapów `FROM` w jednym Dockerfile — budując aplikację w jednym etapie (ze wszystkimi narzędziami do kompilacji) i kopiując tylko ostateczne artefakty do czystego, minimalnego etapu końcowego. Tworzy to **znacznie mniejsze, bezpieczniejsze** obrazy produkcyjne.

## Problem: narzędzia do kompilacji powiększają obraz

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

## Kompilacja wieloetapowa

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

Polecenie `--from=build` kopiuje artefakty z etapu kompilacji do ostatecznego obrazu. Ostateczny obraz **wyklucza wszystko z etapu kompilacji, z wyjątkiem tego, co jawnie skopiujesz** — więc narzędzia do kompilacji, zależności deweloperskie i kod źródłowy nie trafiają do produkcji.

## Korzyści

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

## Dlaczego to ważne

Rozumienie kompilacji wieloetapowych jest wartościowe dla **tworzenia małych, bezpiecznych obrazów produkcyjnych**, dlatego jest to ważna praktyczna wiedza dla budowania produkcyjnych obrazów Docker.

Problem, który rozwiązuje, jest rzeczywisty i powszechny: budowanie aplikacji wymaga **narzędzi do kompilacji** (kompilatory, SDK, zależności deweloperskie), które **ostateczny obraz produkcyjny nie powinien zawierać** — ich włączenie powiększa obraz (większy rozmiar, wolniejsze wdrożenia i pobierania) i zwiększa **powierzchnię ataku** (więcej zainstalowanego oprogramowania oznacza więcej potencjalnych luk w bezpieczeństwie). **Kompilacje wieloetapowe** elegancko rozwiązują ten problem, wykorzystując wiele etapów `FROM`: budowanie aplikacji w etapie ze wszystkimi narzędziami, a następnie **kopiowanie tylko ostatecznych artefaktów** (`--from=build`) do czystego, minimalnego etapu końcowego, który wyklucza wszystko inne.

Tworzy to obrazy, które są **dramatycznie mniejsze** (często 10x+ mniejsze — tylko środowisko uruchomieniowe i artefakty) i **bezpieczniejsze** (brak narzędzi do kompilacji lub niepotrzebnych pakietów do eksploatacji), jednocześnie utrzymując wszystko w jednym Dockerfile (bez oddzielnych skryptów kompilacji).

Ten wzorzec jest standardem dla języków kompilowanych (Go, Rust, Java, gdzie kompilator nie jest potrzebny w czasie uruchomienia) i dla kompilacji frontend/Node (gdzie narzędzia do kompilacji i kod źródłowy nie są potrzebne w produkcji).

Ponieważ małe, bezpieczne obrazy produkcyjne są ważne dla szybkości wdrażania, przechowywania i bezpieczeństwa, oraz ponieważ kompilacje wieloetapowe są standardową, efektywną techniką ich osiągania (oddzielanie środowiska kompilacji od szczupłego obrazu uruchomieniowego), zrozumienie kompilacji wieloetapowych — problemu powiększania/bezpieczeństwa, który rozwiązują, sposobu ich działania i ich korzyści — jest wartościową, często stosowaną wiedzą dla budowania produkcyjnych obrazów Docker, najlepszą praktyką szeroko używaną w rzeczywistych Dockerfile'ach i kluczową umiejętnością dla tworzenia efektywnych, bezpiecznych aplikacji konteneryzowanych.