Kas yra kelių etapų konstruktai ir kodėl juos naudoti?

Question

Accepted Answer

**Kelių etapų konstruktai** naudoja kelis `FROM` etapus viename Dockerfile — sukurdami programą viename etape (su visomis kompiliacijos priemonėmis) ir kopijuodami tik galutinį artefaktą į švarų, minimalų galutinį etapą. Tai sukuria **daug mažesnius, saugesnius** gamybos vaizdus.

## Problema: kompiliacijos priemonės padidina vaizdo dydį

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

## Kelių etapų konstruktas

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

Vokas `--from=build` kopijuoja artefaktus iš kompiliacijos etapo į galutinį vaizdą. Galutinis vaizdas **apima visą iš kompiliacijos etapo, išskyrus tai, ką jūs aiškiai kopijuojate** — todėl kompiliacijos priemonės, programavimo priklausomybės ir šaltinis nepatenka į gamybą.

## Privalumai

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

## Kodėl tai svarbu

Supratimas apie kelių etapų konstruktus yra vertingas **kuriant mažus, saugius gamybos vaizdus**, todėl tai svarbi praktinė žinias, skirta gamybai paruoštiems Docker vaizdams kurti.

Problemą, kurią jis sprendžia, yra reali ir bendra: programos kūrimas reikalauja **kompiliacijos priemonių** (kompiliatoriaus, SDK, programavimo priklausomybių), kurių **galutinis gamybos vaizdas neturėtų turėti** — jų įtraukimas padidina vaizdą (didesnis dydis, lėtesni diegimas ir atsisiuntimas) ir padidina **atakos paviršių** (daugiau įdiegtos programinės įrangos reiškia daugiau galimų pažeidžiamumų). **Kelių etapų konstruktai** elegantiškai tai sprendžia naudodami kelis `FROM` etapus: kuriant programą etape su visomis priemonėmis, tada **kopijuojant tik galutinius artefaktus** (`--from=build`) į švarų, minimalų galutinį etapą, kuris neapima nieko kito.

Tai sukuria vaizdus, kurie yra **dramatiškai mažesni** (dažnai 10x+ mažesni — tik paleidimo aplinka ir artefaktai) ir **saugesni** (nėra kompiliacijos priemonių ar nereikalingų paketų, kuriais būtų galima pasinaudoti), o tuo pačiu laiku viskas likę viename Dockerfile (nereikia atskirų sukūrimo scenarijų).

Šis šablonas yra standartinis kompiliuotiems kalboms (Go, Rust, Java, kur kompiliatorius nėra reikalingas vykdymo metu) ir kelioms priešakinėms/Node konstruktoms (kur sukūrimo įrankiai ir šaltinis nereikalingi gamyboje).

Kadangi maži, saugūs gamybos vaizdai yra svarbūs diegimo greičiui, saugojimui ir saugumui, o kelių etapų konstruktai yra standartinė, veiksminga jų pasiekimo metodika (atskyriant sukūrimo aplinką nuo lenktinos vykdymo aplinkos), supratimas apie kelių etapų konstruktus — problemos, kurią jie sprendžia, kaip jie veikia ir jų privalumų — yra vertinga, dažnai taikoma žinias, skirta gamybai paruoštiems Docker vaizdams kurti, geroji praktika, plačiai naudojama realiuose Dockerfile failuose ir svarbus įgūdis, skirtas veiksmingoms, saugios sudėtiems programoms pagaminti.