multi-stage builds क्या हैं और इनका उपयोग क्यों करें?

Question

Accepted Answer

**Multi-stage builds** एक Dockerfile में कई `FROM` stages का उपयोग करते हैं — एक stage में application को build करना (सभी build tools के साथ) और केवल अंतिम artifacts को एक स्वच्छ, न्यूनतम final stage में copy करना। यह **बहुत छोटी, अधिक सुरक्षित** 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` build stage से artifacts को final image में copy करता है। final image में **build stage की हर चीज़ को छोड़कर वही शामिल होता है जिसे आप स्पष्ट रूप से copy करते हैं** — इसलिए 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 बनाने के लिए महत्वपूर्ण व्यावहारिक ज्ञान है।

यह जिस समस्या को हल करता है वह वास्तविक और सामान्य है: एक application को build करने के लिए **build tools** (compilers, SDKs, dev dependencies) की आवश्यकता होती है जिन्हें **final production image में नहीं होना चाहिए** — उन्हें शामिल करना image को फुलाता है (बड़ा size, धीमे deployments और pulls) और **attack surface** बढ़ाता है (अधिक स्थापित software का अर्थ है अधिक संभावित vulnerabilities)। **Multi-stage builds** कई `FROM` stages का उपयोग करके इसे शानदार ढंग से हल करते हैं: सभी tools वाले एक stage में application को build करना, फिर केवल अंतिम artifacts (`--from=build`) को एक स्वच्छ, न्यूनतम final stage में copy करना जो बाकी सब कुछ छोड़ देता है।

यह ऐसी images उत्पन्न करता है जो **नाटकीय रूप से छोटी** होती हैं (अक्सर 10x+ छोटी — केवल runtime और artifacts) और **अधिक सुरक्षित** (exploit करने के लिए कोई build tools या अनावश्यक packages नहीं), जबकि सब कुछ एक ही Dockerfile में रखती हैं (कोई अलग build scripts नहीं)।

यह pattern compiled languages (Go, Rust, Java, जहाँ compiler की runtime पर आवश्यकता नहीं) और frontend/Node builds (जहाँ build tooling और source की production में आवश्यकता नहीं) के लिए मानक है।

चूँकि छोटी, सुरक्षित production images deployment गति, storage, और security के लिए मायने रखती हैं, और चूँकि multi-stage builds उन्हें प्राप्त करने की मानक, प्रभावी तकनीक है (build environment को lean runtime image से अलग करना), multi-stage builds को समझना — वह bloat/security समस्या जिसे वे हल करते हैं, वे कैसे काम करते हैं, और उनके लाभ — production-quality Docker images बनाने के लिए मूल्यवान, बार-बार लागू होने वाला ज्ञान है, एक सर्वोत्तम प्रथा जो वास्तविक-दुनिया के Dockerfiles में व्यापक रूप से उपयोग की जाती है और efficient, सुरक्षित containerized applications उत्पन्न करने के लिए एक मुख्य कौशल है।