🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

👨‍🍳 धडा 07 — Multi-stage builds: स्वयंपाकघरात शिजवा, फक्त अन्न पॅक करा

📍 तुम्ही इथे आहात: 12 पैकी धडा 07 · मागे: lesson-06-docker-compose · पुढे: lesson-08-image-hygiene

📦 या ब्रँचमध्ये काय आहे

धडे 01–06, आणि त्याशिवाय: लहान, सुरक्षित images साठीची एकमेव सर्वोत्तम युक्ती — multi-stage builds. खऱ्या files:

app/Dockerfile.multi — चालणारा दोन-stage build
app/generate.js — नाटकी "build step"

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

जेवण बनवायला मोठे, पसारा असलेले स्वयंपाकघर 👨‍🍳 लागते: ओव्हन, मिक्सर, सगळीकडे पीठ, recipe चे कच्चे मसुदे, खरकटे चमचे.

प्रश्न: डबा भरताना… तुम्ही ओव्हन डब्यात ठेवता का? 🤨

अर्थातच नाही! तरीही साधेभोळे Dockerfiles नेमके हेच करतात: compilers, package managers, source code, build caches — सगळे image च्या आत production ला पाठवले जाते. ग्राहकाने जेवण मागवले; तुम्ही त्याला आपले स्वयंपाकघरच पाठवले.

Multi-stage एकाच recipe मध्ये दोन खोल्या देऊन हे सुधारते:

Stage 1 — स्वयंपाकघर (FROM node:20-alpine AS builder): सगळी tools चालतात, हवा तेवढा पसारा करा, पदार्थ (index.html) तयार करा.
Stage 2 — डबा (FROM nginx:alpine): स्वच्छ छोट्या डब्यापासून सुरुवात करा आणि पलीकडे फक्त पदार्थ घ्या: COPY --from=builder ….

भाजून झाल्यावर स्वयंपाकघर फेकून दिले जाते. फक्त stage 2 पाठवली जाते: इथे ~180MB ऐवजी ~50MB — आणि खऱ्या ॲप्समध्ये 1.2GB → 80MB हे नेहमीचेच आहे. 🤯

🗺️ आकृती

flowchart LR
    subgraph s1["👨‍🍳 stage 1: KITCHEN - thrown away 🗑️"]
        tools["node + tools + source<br/>~180MB of mess"]
        dish["🍲 the dish:<br/>index.html"]
        tools -->|"1 RUN node generate.js"| dish
    end
    subgraph s2["🍱 stage 2: LUNCHBOX - this ships 🚀"]
        clean["nginx:alpine ~50MB<br/>+ index.html<br/>nothing else"]
    end
    dish -->|"2 COPY --from=builder<br/>only the food crosses"| clean

❓ काय

अनेक FROM ओळी = अनेक stages; फक्त शेवटची stage image बनते. आधीच्या stages फक्त त्यांच्यातून copy करण्यासाठी असतात.
COPY --from=builder /path /path — खोल्यांमधला पूल.
खऱ्या जगातले नेहमीचे आकार: Node (npm ci && npm run build → dist/ nginx मध्ये copy), Go (toolchain → एक static binary scratch मध्ये copy), Java (maven → .jar फक्त-JRE image मध्ये copy).
बोनस: अंतिम image मध्ये कमी software = धडा 12 च्या ECR scanner ला तक्रार करायला कमी CVEs. लहान म्हणजे सुरक्षित.

🧠 दोन stages, एक artifact

BUILD STAGE     Node + npm + source + compiler
                          ↓  build
                     build artifact
                          ↓  COPY --from=build
RUNTIME STAGE   minimal runtime + artifact       ← THIS ships

Build dependencies build stage मध्येच राहतात आणि अंतिम image मध्ये असण्याची गरजच नसते. Production मधली परिणामांची साखळी:

लहान image → जलद pull → हल्ल्याची जागा कमी → कमी storage आणि transfer

🤔 का

Image चा आकार हा तुम्ही प्रत्येक push (धडा 11), प्रत्येक pull, प्रत्येक pod start, k8s कोर्समधल्या प्रत्येक autoscale-up वर भरता तो कर आहे. Multi-stage एकदाच्या मेहनतीत हा कर 10–20× ने कमी करते. "आमच्या production image मध्ये compiler आहे" हा security मधला मुद्दाही संपतो — build tools तिथे नसतातच.

🔧 कसे (या repo मध्ये)

app/Dockerfile.multi: स्वयंपाकघर generate.js (आपल्या npm run build ऐवजीचे) चालवून index.html तयार करते; डबा म्हणजे फक्त nginx + ती एक file. Node अंतिम image पर्यंत कधीच पोहोचत नाही — खाली सिद्ध करा.

🧪 करून पाहा

docker build -f app/Dockerfile.multi -t hello-school:static app/
docker run --rm -p 8080:80 hello-school:static
# open http://localhost:8080 — "built inside the BUILDER stage"

# the receipts 🧾:
docker image ls | grep -E "hello-school|node|nginx"   # compare sizes
docker run --rm hello-school:static node --version 2>&1 | tail -1
# → "node: not found" — the kitchen truly did not ship 👨‍🍳🚫

⚠️ नेहमीच्या चुका

संपूर्ण build stage runtime stage मध्ये copy करणे (मुद्दाच हरवतो)
अजूनही compilers/package managers असलेला runtime base — -alpine/-slim/distroless निवडा
CI मध्ये --cache-from विसरणे, आणि मग multi-stage builds हळू का झाले याचा विचार करणे

⏭️ पुढे

लहान ✅. आता ती स्वच्छ करूया: tags, .dockerignore, non-root — हौशी images आणि production images वेगळ्या करणारी hygiene ची यादी.

git checkout lesson-08-image-hygiene

👨‍🍳 Lesson 07 — Multi-stage builds: cook in the kitchen, pack only the food

📍 You are here: Lesson 07 of 12 · Previous: lesson-06-docker-compose · Next: lesson-08-image-hygiene

📦 What's in this branch

Lessons 01–06, plus: the single best trick for small, safe images — multi-stage builds. Real files:

app/Dockerfile.multi — a working two-stage build
app/generate.js — the pretend "build step"

🧒 Explain like I'm 5

To make lunch you need a big messy kitchen 👨‍🍳: oven, mixer, flour everywhere, recipe drafts, dirty spoons.

Question: when you pack the lunchbox… do you put the oven in the box? 🤨

Of course not! Yet that's exactly what naive Dockerfiles do: compilers, package managers, source code, build caches — all shipped to production inside the image. The customer ordered lunch; you mailed them your kitchen.

Multi-stage fixes it with two rooms in one recipe:

Stage 1 — the KITCHEN (FROM node:20-alpine AS builder): all tools allowed, make as much mess as needed, produce the dish (index.html).
Stage 2 — the LUNCHBOX (FROM nginx:alpine): start from a clean tiny box and take only the dish across: COPY --from=builder ….

The kitchen is thrown away after baking. Only stage 2 ships: ~50MB instead of ~180MB here — and in real apps, 1.2GB → 80MB is routine. 🤯

🗺️ Diagram

flowchart LR
    subgraph s1["👨‍🍳 stage 1: KITCHEN - thrown away 🗑️"]
        tools["node + tools + source<br/>~180MB of mess"]
        dish["🍲 the dish:<br/>index.html"]
        tools -->|"1 RUN node generate.js"| dish
    end
    subgraph s2["🍱 stage 2: LUNCHBOX - this ships 🚀"]
        clean["nginx:alpine ~50MB<br/>+ index.html<br/>nothing else"]
    end
    dish -->|"2 COPY --from=builder<br/>only the food crosses"| clean

❓ What

Multiple FROM lines = multiple stages; only the last stage becomes the image. Earlier stages exist just to be copied from.
COPY --from=builder /path /path — the bridge between rooms.
Classic real-world shapes: Node (npm ci && npm run build → copy dist/ into nginx), Go (toolchain → copy one static binary into scratch), Java (maven → copy the .jar into a JRE-only image).
Bonus: less software in the final image = fewer CVEs for lesson 12's ECR scanner to complain about. Small is safe.

🧠 Two stages, one artifact

BUILD STAGE     Node + npm + source + compiler
                          ↓  build
                     build artifact
                          ↓  COPY --from=build
RUNTIME STAGE   minimal runtime + artifact       ← THIS ships

Build dependencies stay in the build stage and never need to exist in the final image. The production chain of consequences:

smaller image → faster pull → smaller attack surface → less storage & transfer

🤔 Why

Image size is a tax you pay on every push (lesson 11), every pull, every pod start, every autoscale-up in the k8s course. Multi-stage cuts the tax by 10–20× for one-time effort. It also ends the "our production image contains the compiler" security finding — build tools simply aren't there.

🔧 How (in this repo)

app/Dockerfile.multi: the kitchen runs generate.js (our stand-in for npm run build) to produce index.html; the lunchbox is pure nginx + that one file. Node never reaches the final image — prove it below.

🧪 Try it

docker build -f app/Dockerfile.multi -t hello-school:static app/
docker run --rm -p 8080:80 hello-school:static
# open http://localhost:8080 — "built inside the BUILDER stage"

# the receipts 🧾:
docker image ls | grep -E "hello-school|node|nginx"   # compare sizes
docker run --rm hello-school:static node --version 2>&1 | tail -1
# → "node: not found" — the kitchen truly did not ship 👨‍🍳🚫

⚠️ Common mistakes

copying the whole build stage into the runtime stage (defeats the point)
a runtime base that still contains compilers/package managers — pick -alpine/-slim/distroless
forgetting --cache-from in CI, then wondering why multi-stage builds got slow

⏭️ Next

Small ✅. Now let's make it clean: tags, .dockerignore, non-root — the hygiene checklist that separates hobby images from production ones.

git checkout lesson-08-image-hygiene

← Previousdocker compose Next →image hygiene

This page is the lesson's README from the lesson-07-multi-stage branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.