ਮਲਟੀ-ਸਟੇਜ ਬਿਲਡਸ ਕੀ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਿਉਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ?

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 ਇਮੇਜਾਂ ਬਣਾਉਣ ਲਈ ਮਹੱਤਵਪੂਰਨ ਵਿਵਹਾਰਕ ਗਿਆਨ ਹੈ।

ਜੋ ਸਮੱਸਿਆ ਇਹ ਹੱਲ ਕਰਦਾ ਹੈ ਉਹ ਅਸਲ ਅਤੇ ਆਮ ਹੈ: ਐਪਲੀਕੇਸ਼ਨ ਬਿਲਡ ਕਰਨ ਲਈ **ਬਿਲਡ ਟੂਲਸ** (ਕੰਪਾਈਲਰਜ, SDKs, dev ਡਿਪੈਂਡੈਂਸੀਆਂ) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ **ਅੰਤਿਮ ਪ੍ਰੋਡਕਸ਼ਨ ਇਮੇਜ ਵਿੱਚ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ** — ਉਹਨਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਇਮੇਜ ਨੂੰ ਭਾਰੀ ਕਰਦਾ ਹੈ (ਵੱਡਾ ਸਾਈਜ਼, ਹੌਲੀ ਡਿਪਲੌਇਮੈਂਟ ਅਤੇ ਪੁੱਲ) ਅਤੇ **ਅਟੈਕ ਸਤ੍ਹਾ** ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ (ਵਧੇਰੇ ਇਨਸਟਾਲ ਕੀਤਾ ਗਿਆ ਸਾਫਟਵੇਅਰ ਮਤਲਬ ਅਧਿਕ ਸੰਭਾਵੀ ਖ਼ਤਰੇ)। **ਮਲਟੀ-ਸਟੇਜ ਬਿਲਡਸ** ਇਸ ਨੂੰ ਕਈ `FROM` ਸਟੇਜਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੁੰਦਰ ਤਰੀਕੇ ਨਾਲ ਹੱਲ ਕਰਦੇ ਹਨ: ਸਾਰੀਆਂ ਟੂਲਸ ਦੇ ਨਾਲ ਇੱਕ ਸਟੇਜ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਬਿਲਡ ਕਰਦੇ ਹਨ, ਫਿਰ **ਸਿਰਫ ਅੰਤਿਮ ਆਰਟਿਫੈਕਟਸ** (`--from=build`) ਨੂੰ ਇੱਕ ਸਾਫ, ਨਿਊਨਤਮ ਅੰਤਿਮ ਸਟੇਜ ਵਿੱਚ ਕਾਪੀ ਕਰਦੇ ਹਨ ਜੋ ਬਾਕੀ ਸਭ ਕੁਝ ਨੂੰ ਛੱਡ ਦਿੰਦੀ ਹੈ।

ਇਹ ਇਮੇਜਾਂ ਬਣਾਦੇ ਹਨ ਜੋ **ਬਹੁਤ ਛੋਟੀਆਂ** ਹਨ (ਅਕਸਰ 10x+ ਛੋਟੀ — ਸਿਰਫ runtime ਅਤੇ ਆਰਟਿਫੈਕਟਸ) ਅਤੇ **ਵਧੇਰੇ ਸੁਰੱਖਿਅਤ** (ਕੋਈ ਬਿਲਡ ਟੂਲਸ ਜਾਂ ਅਨਾਵਸ਼ਕ ਪੈਕੇਜਾਂ ਦੀ ਘੁਸਪੈਠ ਨਹੀਂ), ਜਦਕਿ ਸਭ ਕੁਝ ਇੱਕ Dockerfile ਵਿੱਚ ਰਖਦੇ ਹਨ (ਕੋਈ ਵੱਖਰੀ ਬਿਲਡ ਸਕ੍ਰਿਪਟ ਨਹੀਂ)।

ਇਹ ਪੈਟਰਨ ਕੰਪਾਈਲ ਕੀਤੀ ਗਈ ਭਾਸ਼ਾਵਾਂ ਲਈ ਮਾਨਕ ਹੈ (Go, Rust, Java, ਜਿੱਥੇ ਕੰਪਾਈਲਰ runtime 'ਤੇ ਦੀ ਲੋੜ ਨਹੀਂ) ਅਤੇ frontend/Node ਬਿਲਡਸ ਲਈ (ਜਿੱਥੇ ਬਿਲਡ ਟੂਲਿੰਗ ਅਤੇ ਸ੍ਰੋਤ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਦੀ ਲੋੜ ਨਹੀਂ)।

ਕਿਉਂਕਿ ਛੋਟੀਆਂ, ਸੁਰੱਖਿਅਤ ਪ੍ਰੋਡਕਸ਼ਨ ਇਮੇਜਾਂ ਡਿਪਲੌਇਮੈਂਟ ਗਤੀ, ਸਟੋਰੇਜ, ਅਤੇ ਸੁਰੱਖਿਆ ਲਈ ਮਾਇਨੇ ਰੱਖਦੀਆਂ ਹਨ, ਅਤੇ ਕਿਉਂਕਿ ਮਲਟੀ-ਸਟੇਜ ਬਿਲਡਸ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਮਾਨਕ, ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਕਨੀਕ ਹਨ (ਬਿਲਡ ਵਾਤਾਵਰਣ ਨੂੰ ਲੀਨ runtime ਇਮੇਜ ਤੋਂ ਵੱਖ ਕਰਦੇ ਹਨ), ਮਲਟੀ-ਸਟੇਜ ਬਿਲਡਸ ਨੂੰ ਸਮਝਣਾ — ਬਲੋਟ/ਸੁਰੱਖਿਆ ਸਮੱਸਿਆ ਜੋ ਉਹ ਹੱਲ ਕਰਦੇ ਹਨ, ਉਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਫਾਇਦੇ — ਪ੍ਰੋਡਕਸ਼ਨ-ਗੁਣਵੱਤਾ Docker ਇਮੇਜਾਂ ਬਣਾਉਣ ਲਈ ਮੁੱਲਵਾਨ, ਅਕਸਰ-ਲਾਗੂ ਕੀਤਾ ਜਾਣ ਵਾਲਾ ਗਿਆਨ, ਅਸਲ-ਸੰਸਾਰ Dockerfiles ਵਿੱਚ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤੀ ਗਈ ਸਰਵੋਤਮ ਪ੍ਰਥਾ, ਅਤੇ ਕੁਸ਼ਲ, ਸੁਰੱਖਿਅਤ containerਜ਼ਡ ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਣਾਉਣ ਲਈ ਮੁੱਖ ਹੁਨਰ ਹੈ।