Multi-aşamalı yapılar (multi-stage builds) nedir ve neden kullanılır?

Question

Accepted Answer

**Multi-aşamalı yapılar**, bir Dockerfile içinde birden fazla `FROM` aşamasını kullanır — uygulamayı bir aşamada (tüm derleme araçlarıyla) derler ve final yapıtları temiz, minimal bir son aşamaya kopyalarlar. Bu, **çok daha küçük, daha güvenli** production imajları üretir.

## Sorun: derleme araçları imajı şişirir

```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-aşamalı yapı

```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` derleme aşamasındaki yapıtları son imaja kopyalar. Son imaj **derleme aşamasından açıkça kopyaladığınız şeyler hariç her şeyi içermez** — bu nedenle derleme araçları, dev bağımlılıkları ve kaynak kod production'da yer almaz.

## Faydaları

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

## Neden önemli

Multi-aşamalı yapıları anlamak, **küçük, güvenli production imajları üretmek** için değerlidir, bu nedenle production-kalitesi Docker imajları oluştururken önemli pratik bilgidir.

Çözdüğü sorun gerçek ve yaygındır: bir uygulamayı derlemek **derleme araçları** (derleyiciler, SDK'lar, dev bağımlılıkları) gerektirir, ancak **final production imajı içermemelidir** — bunları dahil etmek imajı şişirir (daha büyük boyut, daha yavaş dağıtımlar ve çekişler) ve **saldırı yüzeyini** artırır (daha fazla yüklenmiş yazılım daha fazla potansiyel güvenlik açığı anlamına gelir). **Multi-aşamalı yapılar** bunu zarif bir şekilde çözer: birden fazla `FROM` aşaması kullanarak, uygulamayı tüm araçları içeren bir aşamada derler, ardından **yalnızca final yapıtları** (`--from=build`) tüm diğer şeyleri hariç tutan temiz, minimal bir son aşamaya kopyalarlar.

Bu, **dramatik olarak daha küçük** imajlar (genellikle 10x+ daha küçük — sadece runtime ve yapıtlar) ve **daha güvenli** imajlar (yararlanılacak derleme araçları veya gereksiz paketler yok) üretirken, her şeyi tek bir Dockerfile'da tutar (ayrı derleme betikleri gerek yoktur).

Bu desen, derlenmiş diller (Go, Rust, Java; derleyici runtime'da gerekli değildir) ve frontend/Node derlemeleri (derleme araçları ve kaynak production'da gerekli değildir) için standarttır.

Küçük, güvenli production imajları dağıtım hızı, depolama ve güvenlik için önemli olduğundan ve multi-aşamalı yapılar bunlara ulaşmak için standart, etkili teknik olduğundan (derleme ortamını yalın runtime imajından ayırarak), multi-aşamalı yapıları anlamak — çözdüğü şişirme/güvenlik sorunu, nasıl çalıştığı ve faydaları — production-kalitesi Docker imajları oluştururken değerli, sık uygulanan bilgidir, gerçek dünya Dockerfile'larında yaygın olarak kullanılan en iyi uygulama ve verimli, güvenli kapsayıcılı uygulamalar üretmek için temel bir beceridir.