মাল্টি-স্টেজ বিল্ডস কী এবং কেন সেগুলি ব্যবহার করবেন?

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`) একটি পরিষ্কার, ন্যূনতম চূড়ান্ত স্টেজে যা বাকি সবকিছু বাদ দেয়।

এটি **নাটকীয়ভাবে ছোট** ইমেজ তৈরি করে (প্রায়শই 10x+ ছোট — শুধুমাত্র রানটাইম এবং আর্টিফ্যাক্টস) এবং **আরও সুরক্ষিত** (কোন বিল্ড টুলস বা অপ্রয়োজনীয় প্যাকেজ নেই), একটি একক Dockerfile-এ সবকিছু রেখে (কোন আলাদা বিল্ড স্ক্রিপ্ট নেই)।

এই প্যাটার্নটি সংকলিত ভাষার জন্য মান (Go, Rust, Java, যেখানে কম্পাইলার রানটাইমে প্রয়োজন নেই) এবং ফ্রন্টএন্ড/Node বিল্ডের জন্য (যেখানে বিল্ড টুলিং এবং সোর্স প্রোডাকশনে প্রয়োজন নেই)।

ছোট, সুরক্ষিত প্রোডাকশন ইমেজ স্থাপনার গতি, স্টোরেজ এবং নিরাপত্তার জন্য গুরুত্বপূর্ণ কারণ, এবং মাল্টি-স্টেজ বিল্ডগুলি সেগুলি অর্জনের জন্য মান, কার্যকর কৌশল (বিল্ড পরিবেশকে পাতলা রানটাইম ইমেজ থেকে আলাদা করা), মাল্টি-স্টেজ বিল্ডগুলি বোঝা — ব্লোট/নিরাপত্তা সমস্যা যা তারা সমাধান করে, তারা কীভাবে কাজ করে এবং তাদের সুবিধা — মূল্যবান, ঘন ঘন প্রয়োগ করা জ্ঞান প্রোডাকশন-মানের Docker ইমেজ তৈরি করার জন্য, একটি সর্বোত্তম অনুশীলন যা বাস্তব-বিশ্বের Dockerfiles-এ ব্যাপকভাবে ব্যবহৃত হয় এবং দক্ষ, সুরক্ষিত containerized অ্যাপ্লিকেশন তৈরির জন্য একটি মূল দক্ষতা।