Hvad er multi-stage builds, og hvorfor bruges de?

Question

Accepted Answer

**Multi-stage builds** bruger flere `FROM`-stadier i en enkelt Dockerfile — applikationen bygges i et stadium (med alle build-værktøjerne) og kun de endelige artefakter kopieres til et rent, minimalt finalt stadium. Dette producerer **meget mindre, mere sikre** produktionsbilleder.

## Problemet: build-værktøjer udvider billedets størrelse

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

## Multi-stage 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
```

`--from=build` kopierer artefakter fra build-stadiet til det endelige billede. Det endelige billede **ekskluderer alt fra build-stadiet undtagen det, du eksplicit kopierer** — så build-værktøjer, dev-afhængigheder og kildekode ender ikke i produktion.

## Fordele

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

## Hvorfor det betyder noget

At forstå multi-stage builds er værdifuldt for at **producere små, sikre produktionsbilleder**, så det er vigtig praktisk viden for at bygge produktionskvalitet Docker-billeder.

Problemet det løser, er reelt og almindeligt: byggelse af en applikation kræver **build-værktøjer** (compilere, SDK'er, dev-afhængigheder), som det **endelige produktionsbillede ikke skal indeholde** — hvis de inkluderes, udvides billedet (større størrelse, langsommere deployments og pulls) og øges **angrebsfladen** (mere installeret software betyder flere potentielle sårbarheder). **Multi-stage builds** løser dette elegant ved at bruge flere `FROM`-stadier: applikationen bygges i et stadium med alle værktøjerne, derefter **kopieres kun de endelige artefakter** (`--from=build`) til et rent, minimalt finalt stadium der ekskluderer alt andet.

Dette producerer billeder der er **dramatisk mindre** (ofte 10x+ mindre — kun runtime og artefakter) og **mere sikre** (ingen build-værktøjer eller unødvendige pakker at udnytte), samtidig med at alt holdes i en enkelt Dockerfile (ingen separate build-scripts).

Dette mønster er standard for kompilerede sprog (Go, Rust, Java, hvor compileren ikke behøves ved runtime) og for frontend/Node-builds (hvor build-værktøjer og kildekode ikke behøves i produktion).

Da små, sikre produktionsbilleder betyder noget for deployment-hastighed, lagring og sikkerhed, og da multi-stage builds er den standard, effektive teknik til at opnå dem (adskillelse af build-miljøet fra det slanke runtime-billede), er forståelse af multi-stage builds — forståelsen af det bloat/sikkerhedsproblem de løser, hvordan de virker, og deres fordele — værdifuld, hyppigt anvendt viden for at bygge produktionskvalitet Docker-billeder, en best practice der er udbredt i virkelige Dockerfiles, og en vigtig færdighed for at producere effektive, sikre containeriserede applikationer.