મલ્ટી-સ્ટેજ બિલ્ડ્સ શું છે અને તેનો ઉપયોગ કેમ કરવો?

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` બિલ્ડ સ્ટેજમાંથી આર્ટિફેક્ટ્સને અંતિમ ઇમેજમાં કૉપી કરે છે. અંતિમ ઇમેજ **બિલ્ડ સ્ટેજમાંથી તમે સ્પષ્ટપણે કૉપી કરેલ શું તે સિવાય બધું બાકાત રાખે છે** — તેથી બિલ્ડ ટૂલ્સ, ડેવ ડિપેન્ડેન્સીસ અને સોર્સ પ્રોડક્શનમાં આવતો નથી.

## લાભો

```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 ઇમેજ બિલ્ડ કરવા માટે મહત્વપૂર્ણ વ્યવહારુ જ્ઞાન છે.

તે જે સમસ્યાનો ઉકેલ કરે છે તે વાસ્તવિક અને સામાન્ય છે: એપ્લિકેશન બિલ્ડ કરવા માટે **બિલ્ડ ટૂલ્સ** (કમ્પાઇલર્સ, SDKs, ડેવ ડિપેન્ડેન્સીસ) જરૂરી છે જે **અંતિમ પ્રોડક્શન ઇમેજમાં હોવો જોઈએ નહીં** — તેમને શામેલ કરવાથી ઇમેજ ફૂલી જાય છે (મોટું કદ, ધીમો ડેપ્લોયમેન્ટ અને પુલ્સ) અને **હુમલાની સપાટી** વધે છે (વધુ ઇન્સ્ટોલ કરેલ સોફ્ટવેર માટે વધુ સંભવિત નિર્બળતાઓ). **મલ્ટી-સ્ટેજ બિલ્ડ્સ** આને ભરપૂર રીતે હલ કરે છે બહુવિધ `FROM` સ્ટેજ્સ ઉપયોગ કરીને: તમામ ટૂલ્સ સાથેના સ્ટેજમાં એપ્લિકેશન બિલ્ડ કરીને, તે પછી **અંતિમ આર્ટિફેક્ટ્સ જ કૉપી કરીને** (`--from=build`) સ્વચ્છ, ન્યૂનતમ અંતિમ સ્ટેજમાં જે બધું બાકી છે તેને બાકાત રાખે છે.

આ ઇમેજ બનાવે છે જે **નાટકીય રીતે નાની** હોય (ઘણીવાર 10 ગણી+ નાની — માત્ર runtime અને આર્ટિફેક્ટ્સ) અને **વધુ સુરક્ષિત** (બિલ્ડ ટૂલ્સ અથવા અનુપયોગી પેકેજ્સ નથી શોષણ માટે), જ્યારે બધું એક Dockerfile માં રાખે છે (કોઈ અલગ બિલ્ડ સ્ક્રિપ્ટ્સ નહીં).

તે પેટર્ન કમ્પાઇલ કરેલ ભાષાઓ માટે માનક છે (Go, Rust, Java, જ્યાં કમ્પાઇલર runtime પર જરૂરી નથી) અને frontend/Node બિલ્ડ્સ માટે (જ્યાં બિલ્ડ ટૂલીંગ અને સોર્સ પ્રોડક્શનમાં જરૂરી નથી).

નાની, સુરક્ષિત પ્રોડક્શન ઇમેજ ડેપ્લોયમેન્ટ સ્પીડ, સ્ટોરેજ અને સુરક્ષા માટે મહત્વપૂર્ણ હોવાને કારણે, અને મલ્ટી-સ્ટેજ બિલ્ડ્સ તેમને હાંસલ કરવા માટેની માનક, અસરકારક તકનીક હોવાને કારણે (બિલ્ડ પર્યાવરણને લીન runtime ઇમેજમાંથી અલગ કરીને), મલ્ટી-સ્ટેજ બિલ્ડ્સને સમજવું — તેઓ જે ફૂલવાવટ/સુરક્ષા સમસ્યાનો ઉકેલ કરે છે, તેઓ કેવી રીતે કાર્ય કરે છે અને તેમના લાભો — મૂલ્યવાન, વારંવાર-લાગુ કરવામાં આવતું જ્ઞાન છે પ્રોડક્શન-ક્વોલિટી Docker ઇમેજ બિલ્ડ કરવા માટે, એક બેસ્ટ પ્રેક્ટિસ જે વાસ્તવિક-વિશ્વ Dockerfiles માં વ્યાપક રીતે ઉપયોગમાં આવે છે અને કાર્યક્ષમ, સુરક્ષિત કન્ટેનરાઇઝ્ડ એપ્લિકેશન્સ બનાવવા માટે ચાવીરૂપ કુશળતા છે.