Mitä ovat multi-stage-rakennukset ja miksi niitä käytetään?

Question

Accepted Answer

**Multi-stage-rakennukset** käyttävät useita `FROM`-vaiheita yhdessä Dockerfilessa — sovellusta rakennetaan yhdessä vaiheessa (kaikilla rakennustyökaluilla) ja vain lopulliset artefaktit kopioidaan puhtaaseen, minimalistiseen loppuvaiheeseen. Tämä tuottaa **paljon pienempiä ja turvallisempia** tuotantokuvia.

## Ongelma: rakennustyökalujen paisuminen

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

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

Komento `--from=build` kopioi artefaktit rakennusvaiheesta loppukuvaan. Loppukuva **sulkee pois kaiken rakennusvaiheesta paitsi ne, jotka kopioitavat eksplisiittisesti** — joten rakennustyökalut, kehitysriippuvuudet ja lähdekoodi eivät päädy tuotantoon.

## Hyödyt

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

## Miksi sillä on merkitystä

Multi-stage-rakennusten ymmärtäminen on arvokasta **pienten, turvallisten tuotantokuvien tuottamiselle**, joten se on tärkeää käytännöllistä tietoa tuotantokvaliteetin Docker-kuvien rakentamiselle.

Ongelma, jonka se ratkaisee, on todellinen ja yleinen: sovelluksen rakentaminen vaatii **rakennustyökaluja** (kääntäjiä, SDK:ita, kehitysriippuvuuksia), joita **lopullinen tuotantokuva ei saisi sisältää** — niiden sisällyttäminen paisuttaa kuvaa (suurempi koko, hitaammat käyttöönotot ja vedot) ja lisää **hyökkäyspintaa** (asennettu ohjelmisto tarkoittaa enemmän mahdollisia haavoittuvuuksia). **Multi-stage-rakennukset** ratkaisevat tämän tyylikkäästi käyttämällä useita `FROM`-vaiheita: sovellusta rakennetaan vaiheessa, jossa on kaikki työkalut, sitten **vain lopulliset artefaktit** (`--from=build`) kopioidaan puhtaaseen, minimalistiseen loppuvaiheeseen, joka sulkee pois kaiken muun.

Tämä tuottaa kuvia, jotka ovat **huomattavasti pienempiä** (usein 10x+ pienempiä — vain runtime ja artefaktit) ja **turvallisempia** (ei rakennustyökaluja tai tarpeettomia paketteja hyödynnettäviksi), samalla kun kaikki pysyy yhdessä Dockerfilessa (ei erillisiä rakennuskäytäntöjä).

Tämä malli on vakio käännetyille kielille (Go, Rust, Java, joissa kääntäjää ei tarvita ajonaikana) ja frontend/Node-rakentamiselle (joissa rakennustyökalut ja lähdekoodi eivät ole tarpeen tuotannossa).

Koska pienet, turvalliset tuotantokuvat ovat tärkeitä käyttönoton nopeudelle, tallennukselle ja turvallisuudelle, ja koska multi-stage-rakennukset ovat vakio, tehokas tekniikka niiden saavuttamiselle (rakennusympäristön erottaminen kevyestä runtime-kuvasta), multi-stage-rakennusten ymmärtäminen — paisumisen/turvallisuusongelman, jonka ne ratkaisevat, kuinka ne toimivat ja niiden hyödyt — on arvokasta, usein sovellettavaa tietoa tuotantokvaliteetin Docker-kuvien rakentamiselle, laajalti käytössä oleva paras käytäntö todellisissa Dockerfileissa ja keskeinen taito tehokkaiden, turvallisten containerisoiduista sovelluksista.