ملٹی سٹیج بلڈز کیا ہیں اور ان کا استعمال کیوں کریں؟

Question

Accepted Answer

**ملٹی سٹیج بلڈز** ایک Dockerfile میں متعدد `FROM` سٹیجز استعمال کرتے ہیں — ایک سٹیج میں ایپلیکیشن کو بنایا جاتا ہے (تمام بلڈ ٹولز کے ساتھ) اور صرف حتمی artifacts کو ایک صاف، کم سے کم حتمی سٹیج میں کاپی کیا جاتا ہے۔ یہ **بہت چھوٹی، زیادہ محفوظ** پروڈکشن images تیار کرتا ہے۔

## مسئلہ: بلڈ ٹولز 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.
```

## ملٹی سٹیج بلڈ

```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 کو حتمی image میں کاپی کرتا ہے۔ حتمی image **بلڈ سٹیج سے سب کچھ نکال دیتی ہے سوائے اس کے جو آپ صراحت سے کاپی کریں** — اس طرح بلڈ ٹولز، dev dependencies، اور source پروڈکشن میں شامل نہیں ہوتے۔

## فوائل

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

## یہ اہم کیوں ہے

ملٹی سٹیج بلڈز کو سمجھنا **چھوٹی، محفوظ پروڈکشن images تیار کرنے** کے لیے قیمتی ہے، اس لیے یہ Docker images کو پروڈکشن معیار کے ساتھ بنانے کے لیے اہم عملی علم ہے۔

جس مسئلے کو یہ حل کرتا ہے وہ حقیقی اور عام ہے: ایک ایپلیکیشن بنانے کے لیے **بلڈ ٹولز** (compilers، SDKs، dev dependencies) درکار ہیں جو **حتمی پروڈکشن image میں نہیں ہونے چاہیں** — ان کو شامل کرنے سے image بھاری ہو جاتی ہے (بڑا سائز، سست deployments اور pulls) اور **حملے کی سطح** بڑھ جاتی ہے (زیادہ installed software کا مطلب زیادہ ممکنہ vulnerabilities ہے)۔ **ملٹی سٹیج بلڈز** اس کو خوبصورتی سے حل کرتے ہیں متعدد `FROM` سٹیجز استعمال کر کے: ایک سٹیج میں تمام ٹولز کے ساتھ ایپلیکیشن بناتے ہوئے، پھر **صرف حتمی artifacts** کو (`--from=build`) ایک صاف، کم سے کم حتمی سٹیج میں کاپی کرتے ہیں جو باقی سب کچھ نکال دیتا ہے۔

یہ images تیار کرتا ہے جو **ڈرامائی طور پر چھوٹی** ہیں (اکثر 10x+ چھوٹی — صرف runtime اور artifacts) اور **زیادہ محفوظ** ہیں (بلڈ ٹولز یا غیر ضروری packages نہیں جو exploit کیے جا سکیں)، جبکہ سب کچھ ایک Dockerfile میں رکھتے ہوئے (کوئی علیحدہ بلڈ scripts نہیں)۔

yeh pattern compiled languages (Go, Rust, Java، جہاں compiler runtime میں ضروری نہیں ہے) اور frontend/Node builds کے لیے معیاری ہے (جہاں بلڈ tooling اور source پروڈکشن میں ضروری نہیں ہیں)۔

چونکہ چھوٹی، محفوظ پروڈکشن images deployment speed، storage، اور security کے لیے اہم ہیں، اور چونکہ ملٹی سٹیج بلڈز انہیں حاصل کرنے کے لیے معیاری، موثر تکنیک ہیں (بلڈ ماحول کو لین runtime image سے الگ کرنا)، ملٹی سٹیج بلڈز کو سمجھنا — bloat/security مسئلہ جو وہ حل کرتے ہیں، یہ کیسے کام کرتے ہیں، اور ان کے فوائل — قیمتی، بار بار استعمال ہونے والا علم ہے پروڈکشن معیار کی Docker images بنانے کے لیے، ایک best practice جو حقیقی دنیا کی Dockerfiles میں وسیع پیمانے پر استعمال ہوتا ہے اور efficient، محفوظ containerized applications تیار کرنے کے لیے ایک اہم مہارت۔