Kaj so večstopenjski gradovi in zakaj jih uporabljati?

Question

Accepted Answer

**Večstopenjski gradovi** uporabljajo več `FROM` stopenj v eni Dockerfile datoteki — aplikacija se gradi v eni stopnji (z vsemi gradilnimi orodji) in samo končni artefakti se kopirajo v čisto, minimalno končno stopnjo. To proizvede **veliko manjše, bolj varne** produkcijske slike.

## Problem: gradilna orodja napolnijo sliko

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

## Večstopenjski grad

```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` kopira artefakte iz gradilne stopnje v končno sliko. Končna slika **izključi vse iz gradilne stopnje razen tega, kar eksplicitno kopirate** — tako gradilna orodja, razvojne odvisnosti in izvorni kod se ne končajo v produkciji.

## Prednosti

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

## Zakaj je to pomembno

Razumevanje večstopenjskih gradov je dragoceno za **proizvajanje manjših, varnejših produkcijskih slik**, zato je to pomembno praktično znanje za gradnjo produkcijskih Docker slik.

Problém, ki ga rešuje, je pravi in pogost: gradnja aplikacije zahteva **gradilna orodja** (prevajalnike, SDK-je, razvojne odvisnosti), ki jih **končna produkcijska slika ne sme vsebovati** — njihov vključek napolni sliko (večja velikost, počasnejši razvoji in prejemi) in povečuje **napadalno površino** (več nameščene programske opreme pomeni več možnih ranljivosti). **Večstopenjski gradovi** to elegantno rešijo z uporabo več `FROM` stopenj: gradnja aplikacije v stopnji z vsemi orodji, nato pa **kopiranje samo končnih artefaktov** (`--from=build`) v čisto, minimalno končno stopnjo, ki izključi vse drugo.

To proizvede slike, ki so **dramatično manjše** (pogosto 10-krat in več manjše — samo čas izvajanja in artefakti) in **bolj varne** (brez gradilnih orodij ali nepotrebnih paketov za izkoriščanje), medtem ko ostane vse v eni Dockerfile datoteki (brez ločenih gradilnih skript).

Ta vzorec je standarden za kompilirane jezike (Go, Rust, Java, kjer prevajalni ni potreben med izvajanjem) in za spletne/Node gradnje (kjer gradilna orodja in izvorni kod niso potrebni v produkciji).

Ker manjše, varnejše produkcijske slike bistveno vplivajo na hitrost razvoja, shranjevanje in varnost, in ker so večstopenjski gradovi standardna, učinkovita tehnika za njihovo doseganje (ločevanje gradilnega okolja od vitke slike med izvajanjem), razumevanje večstopenjskih gradov — problem napolnjenosti/varnosti, ki ga rešujejo, kako delujejo in njihove prednosti — je dragoceno, pogosto uporabljeno znanje za gradnjo produkcijskih Docker slik, vzorec najboljše prakse, ki se pogosto uporablja v resničnih Dockerfile datotekah, in ključna spretnost za proizvajanje učinkovitih, varnih aplikacij v kontejnerjih.