რა არის multi-stage builds და რატომ გამოიყენება ისინი?

Question

Accepted Answer

**Multi-stage builds** იყენებს რამდენიმე `FROM` stages-ს ერთ Dockerfile-ში — აპლიკაციის აგება ხდება ერთ stage-ში (ყველა build tools-ის შესაბამისად) და მხოლოდ საბოლოო artifacts-ები კოპირდება სუფთა, მინიმალური საბოლოო stage-ში. ეს აწარმოებს **ბევრად უფრო მცირე, უფრო დაცულ** production images-ებს.

## პრობლემა: build tools-ები აკეთებს image-ს დიდს

```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` აკოპირებს artifacts-ებს build stage-დან საბოლოო image-ში. საბოლოო image **გამორიცხავს ყველაფერს build stage-დან გარდა იმისა, რაც თქვენ აშკარად კოპირებთ** — ამიტომ build tools-ები, dev dependencies-ები და source არ ხვდება production-ში.

## სარგებელი

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

## რატომ მნიშვნელოვანი

Multi-stage builds-ის გაგება ღირებულია **მცირე, დაცული production images-ების შექმნისთვის**, ამიტომ ეს მნიშვნელოვანი პრაქტიკული ცოდნაა production-quality Docker images-ების აგებისთვის.

მის მიერ გადაწყვეტილი პრობლემა რეალური და გავრცელებულია: აპლიკაციის აგება მოითხოვს **build tools-ებს** (compilers-ები, SDKs, dev dependencies-ები), რომელთა **საბოლოო production image არ უნდა შეიცავდეს** — მათი შედგომა აკეთებს image-ს დიდს (უფრო დიდი ზომა, ნელი deployments და pulls) და აზრდის **attack surface**-ს (უფრო ბევრი installed software ნიშნავს უფრო მეტ პოტენციურ취약성ს). **Multi-stage builds** აღმოფხვრის ამას ელეგანტურად რამდენიმე `FROM` stages-ის გამოყენებით: აპლიკაციის აგება ხდება stage-ში ყველა tools-ის შესაბამისად, შემდეგ **მხოლოდ საბოლოო artifacts-ები კოპირდება** (`--from=build`) სუფთა, მინიმალური საბოლოო stage-ში, რომელიც გამორიცხავს ყველაფერ სხვას.

ეს აწარმოებს image-ებს, რომელთაც სჩვენდებათ **დრამატულად უფრო მცირე** (ხშირად 10x+ უფრო მცირე — მხოლოდ runtime და artifacts-ები) და **უფრო დაცული** (არ არის build tools ან არასაჭირო packages-ები რომ გამოიყენო), იმ დროს რაც ყველაფერი ერთ Dockerfile-ში რჩება (არა ცალკე build scripts-ები).

ეს pattern სტანდარტულია compiled languages-ებისთვის (Go, Rust, Java, სადაც compiler არ დაჭირდება runtime-ზე) და frontend/Node builds-ებისთვის (სადაც build tooling და source არ დაჭირდება production-ში).

ვინაიდან მცირე, დაცული production images-ები მნიშვნელოვანია deployment speed-ის, storage-ის და security-ის თვალსაზრისით, და ვინაიდან multi-stage builds არის სტანდარტული, ეფექტური ტექნიკა მათი მიღწევისთვის (build environment-ის გამოყოფა lean runtime image-დან), multi-stage builds-ის გაგება — bloat/security problem-ის, რომელსაც ისინი აღმოფხვრიან, თუ როგორ მუშაობენ ისინი და მათი სარგებელი — ღირებულია, ხშირად გამოყენებული ცოდნა production-quality Docker images-ების აგებისთვის, best practice რომელიც ფართოდ გამოიყენება real-world Dockerfile-ებში და საკვანძო უნარი ეფიკური, დაცული containerized აპლიკაციების შექმნის თვალსაზრისით.