Mik azok a többlépcsős buildek (multi-stage builds) és miért használjuk őket?

Question

Accepted Answer

**A többlépcsős buildek** egy Dockerfile-ban több `FROM` szakaszt használnak — az alkalmazást az egyik szakaszban (az összes build eszközzel) építik meg, és csak a végső artifaktumokat másolják át egy tiszta, minimális végső szakaszba. Ez **sokkal kisebb, biztonságosabb** production képeket hoz létre.

## A probléma: a build eszközök felduzzadják a képet

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

## Többlépcsős 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
```

A `--from=build` a build szakaszból másolja az artifaktumokat a végső képbe. A végső kép **kizár mindent a build szakaszból, kivéve azt, amit explicit módon másolsz** — így a build eszközök, fejlesztési függőségek és forráskód nem kerülnek be a production képbe.

## Előnyei

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

## Miért fontos

A többlépcsős buildek megértése értékes az **egyedi, biztonságos production képek előállítása** szempontjából, ezért fontos gyakorlati tudás a production minőségű Docker képek építéséhez.

Az az egyszerűen megoldható valós probléma: az alkalmazás felépítéséhez **build eszközök szükségesek** (fordítók, SDK-k, fejlesztési függőségek), amelyeket a **végső production kép nem tartalmazhat** — ha benne vannak, felduzzasztják a képet (nagyobb méret, lassabb deploymentek és letöltések) és növelik a **támadási felületet** (több telepített szoftver több lehetséges sebezhetőséget jelent). **A többlépcsős buildek** ezt elegánsan oldják meg több `FROM` szakasz használatával: az alkalmazást egy szakaszban építik meg az összes eszközzel, majd **csak a végső artifaktumokat** másolják (`--from=build`) egy tiszta, minimális végső szakaszba, amely kizár mindent mást.

Ez **drámaian kisebb** képeket eredményez (gyakran 10x+ kisebb — csak a runtime és az artifaktumok) és **biztonságosabbak** (nincs build eszköz vagy szükségtelen csomag, amit kihasználhatnának), miközben mindent egyetlen Dockerfile-ban tartanak (nincs szükség külön build scriptekre).

Ez a minta standard a lefordított nyelvekhez (Go, Rust, Java, ahol a fordító nem szükséges futtatás közben) és a frontend/Node buildekhez (ahol a build eszközök és forráskód nem szükséges a productionben).

Mivel a kis, biztonságos production képek fontosak a telepítés sebességéhez, tároláshoz és biztonsághoz, és mivel a többlépcsős buildek a standard, hatékony technika ezek eléréséhez (a build környezet elválasztása a lean runtime képtől), a többlépcsős buildek megértése — az a bloat/biztonsági probléma, amit megoldanak, az működésük és az előnyeik — értékes, gyakran alkalmazott tudás a production minőségű Docker képek építéséhez, egy széleskörűen használt best practice valós Dockerfile-ekben, és a kulcsfontosságú képesség a hatékony, biztonságos containerizált alkalmazások előállításához.