मल्टि-स्टेज बिल्ड्स के हुन् र तिनलाई किन प्रयोग गर्नुहोस्?

Question

Accepted Answer

**मल्टि-स्टेज बिल्ड्स** एक Dockerfileमा बहुविध `FROM` स्टेजहरू प्रयोग गर्दछन् — अनुप्रयोग एक स्टेजमा बनाउँदछन् (सबै बिल्ड टूलहरूको साथ) र अन्तिम कलाकृतिहरूलाई मात्र एक सफा, न्यूनतम अन्तिम स्टेजमा कपी गर्दछन्। यसले **धेरै सानो, अधिक सुरक्षित** उत्पादन छविहरू उत्पादन गर्दछ।

## समस्या: बिल्ड टूलहरूले छविलाई फुलाउँछन्

```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` ले बिल्ड स्टेजबाट कलाकृतिहरूलाई अन्तिम छविमा कपी गर्दछ। अन्तिम छविले **बिल्ड स्टेजबाट सबै कुरा बाहेक तपाईले स्पष्ट रूपमा कपी गर्नुभएको कुरा हटाउँछ** — त्यसैले बिल्ड टूलहरू, dev निर्भरताहरू, र स्रोत उत्पादनमा समाप्त हुँदैन।

## लाभहरू

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

## यो किन महत्त्वपूर्ण छ

मल्टि-स्टेज बिल्ड्स बुझ्नु **सानो, सुरक्षित उत्पादन छविहरू उत्पादन गर्नका लागि** मूल्यवान छ, त्यसैले उत्पादन-गुणस्तरको Docker छविहरू बनाउनका लागि यो महत्त्वपूर्ण व्यावहारिक ज्ञान हो।

यसले समाधान गर्ने समस्या वास्तविक र सामान्य छ: अनुप्रयोग बनाउनको लागि **बिल्ड टूलहरू** (कम्पाइलरहरू, SDKहरू, dev निर्भरताहरू) चाहिन्छ जुन **अन्तिम उत्पादन छविले समाहित गर्नु हुँदैन** — तिनलाई समाहित गर्दा छविलाई फुलाउँछ (ठूलो साइज, ढिलो तैनाती र ताने), र **आक्रमण सतह** बढाउँछ (अधिक स्थापित सफ्टवेयरको मतलब अधिक सम्भावित कमजोरीहरू)। **मल्टि-स्टेज बिल्ड्स** ले यसलाई सबै टूलहरूको साथ स्टेजमा अनुप्रयोग बनाएर, त्यसपछी मात्र अन्तिम कलाकृतिहरू (`--from=build`) एक सफा, न्यूनतम अन्तिम स्टेजमा कपी गरेर, सबै कुरा बाहेक हटाई, सुन्दर तरिकामा समाधान गर्दछ।

यसले छविहरू उत्पादन गर्दछ जुन **नाटकीय रूपमा सानो** (अक्सर १०x + सानो — मात्र runtime र कलाकृतिहरू) र **अधिक सुरक्षित** (कोई बिल्ड टूलहरू वा अनावश्यक प्याकेजहरू सोमन्न गर्न सक्दैन), जबकि एक Dockerfileमा सबै कुरा राख्दा (कोई अलग बिल्ड स्क्रिप्टहरू नभई)।

यो ढाँचा सङ्कलित भाषाहरूका लागि मानक छ (Go, Rust, Java, जहाँ कम्पाइलर runtime मा आवश्यक छैन) र frontend/Node बिल्डहरूका लागि (जहाँ बिल्ड टूलिङ्ग र स्रोत उत्पादनमा आवश्यक छैन)।

सानो, सुरक्षित उत्पादन छविहरू तैनाती गति, भण्डारण, र सुरक्षाको लागि महत्त्वपूर्ण छन्, र मल्टि-स्टेज बिल्ड्स तिनलाई हासिल गर्नको लागि मानक, प्रभावी तकनीक हुन् (बिल्ड वातावरणलाई दुबला runtime छविबाट अलग गर्दै), मल्टि-स्टेज बिल्ड्स बुझ्नु — bloat/सुरक्षा समस्या तिनले समाधान गर्दछन्, तिनी कसरी काम गर्दछन्, र तिनीको लाभहरू — मूल्यवान, बारम्बार-प्रयोग गरिने ज्ञान उत्पादन-गुणस्तरको Docker छविहरू बनाउनका लागि, एक सर्वश्रेष्ठ अभ्यास वास्तविक-विश्व Dockerfilesहरूमा व्यापक रूपमा प्रयोग गरिन्छ र कुशल, सुरक्षित containerized अनुप्रयोगहरू उत्पादन गर्नको लागि एक मुख्य कौशल हो।