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

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

🎂 धडा 02 — Images आणि थर: केक आणि cache

📍 तुम्ही इथे आहात: 12 पैकी धडा 02 · मागे: lesson-01-why-containers · पुढे: lesson-03-dockerfile

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

धडा 01, आणि त्याशिवाय: image आतून नक्की काय असते — एकावर एक रचलेले थर — आणि हे समजल्यावर तुमचे builds 100× जलद का होतात. खरी file:

app/Dockerfile — खालची प्रत्येक ओळ एक थर बनवते

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

Image हा एक भरीव ठोकळा नाही — तो थरांचा केक 🎂 आहे, खालून वर भाजलेला, Dockerfile च्या प्रत्येक ओळीचा एक थर:

सर्वात खालचा थर: छोटे Linux + Node (FROM node:20-alpine) — बेकरीतून आलेला आधीच भाजलेला थर. हा तुम्ही स्वतः कधीच भाजत नाही.
मधले थर: तुमची settings (WORKDIR, ENV, USER).
वरचा थर: तुमचा कोड (COPY server.js).

आणि बेकरीचा जादुई नियम: न बदललेला थर पुन्हा कधीच भाजला जात नाही — तो cache च्या फळीवरून लगेच घेतला जातो.

म्हणून तुम्ही server.js बदलून पुन्हा build करता तेव्हा:

खालचे + मधले थर → cache मधून, 0 सेकंद ⚡
फक्त COPY थर आणि त्यावरचे → पुन्हा भाजले जातात 🔨

म्हणूनच अनुभवी लोक क्वचित बदलणाऱ्या ओळी तळाशी आणि कोड वर ठेवतात — म्हणजे रोजच्या rebuild ला फक्त वरचा पातळ थर लागतो. केकची रचना म्हणजेच build चा वेग. 🎂⚡

🗺️ आकृती

flowchart LR
    subgraph cake["🎂 image = layer cake, bottom-up"]
        l4["CMD node server.js"]
        l3["COPY server.js ← your code, changes often"]
        l2["WORKDIR / ENV / USER"]
        l1["FROM node:20-alpine ← pre-baked, huge, never changes"]
        l4 --- l3 --- l2 --- l1
    end
    edit["✏️ edit server.js<br/>+ docker build"]
    edit -->|"1 bottom layers: CACHE ⚡"| l1
    edit -->|"2 only COPY + above rebaked 🔨"| l3

❓ काय

Image = read-only थरांचा क्रमवार ढीग + metadata (काय चालवायचे, कोणते ports, कोणता user). गोठलेली; build नंतर कधीच बदलत नाही.
Layer (थर) = एका Dockerfile instruction ने तयार झालेला filesystem मधला फरक (diff). थर content-addressed असतात आणि images मध्ये वाटले जातात — node:20-alpine वरच्या दहा images तो base disk वर एकदाच साठवतात.
Build cache: instruction आणि त्याचे inputs बदलले नसतील तर Docker तो थर पुन्हा वापरतो. पहिली बदललेली ओळ तिच्यावरचे सगळे अवैध करते.
Container = गोठलेल्या ढिगावरचा एक पातळ writable थर — म्हणूनच एका image मधून 100 containers स्वस्त पडतात.

🧠 Image विरुद्ध container — आणि image ची तीन नावे

IMAGE      = read-only template (the layer cake, frozen)
                 ↓ docker run
CONTAINER  = a running instance of that image (+ a thin writable layer)

प्रत्येक image ला तीन handles असतात:

handle	उदाहरण	बदलते का?
image ID	`sha256:3f2a…` (local, content वर आधारित)	तोच content असेल तर कधीच नाही
tag	`hello-school:v1`, `:latest`	mutable — कोणीही हलवू शकेल असे स्टिकर
digest	`sha256:9c1e…` (registry, content ची ओळख)	immutable — ठसा

हीच गोष्ट चित्ररूपात — एक repository, अनेक handles:

Repository  hello-school
   ├── tag: v1
   ├── tag: latest
   └── digest: sha256:abc123...

tag     = human-friendly name
digest  = immutable content identifier
latest  = just another mutable tag

Image चा content immutable असतो: एक byte बदला, नवा ID/digest मिळतो. latest हे फक्त default tag चे नाव आहे — ते "सर्वात नवे" ही नाही आणि स्थिर ही नाही. Tag विरुद्ध digest हा मुद्दा धडा 11 (ECR) मध्ये आणि Kubernetes deployments मध्ये जोरात परत येतो.

🤔 का

Cache ला अनुकूल Dockerfiles म्हणजे 2 सेकंदांचा आणि 5 मिनिटांचा rebuild यातला फरक — आठवड्याला शेकडो वेळा. आणि वाटलेल्या थरांमुळेच तुमचे दहावे Node ॲप pull करणे लगेच होते: जाड base थर आधीच मशीनवर असतो. (धडा 11: push फक्त registry कडे नसलेले थर upload करतो — तीच कल्पना.)

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

app/Dockerfile मुद्दाम cache च्या क्रमाने लिहिले आहे: FROM → WORKDIR → COPY server.js → ENV/EXPOSE/USER/CMD. मोठ्या ॲप्समध्ये नेहमीची चाल अशी: COPY . . च्या आधी COPY package.json + RUN npm ci — म्हणजे कोड बदलला तरी dependency install पुन्हा चालत नाही.

🧪 करून पाहा

docker build -t hello-school:v1 app/     # first build: every layer baked
docker build -t hello-school:v1 app/     # again: ALL "CACHED" — ~1 second ⚡

echo "// tweak" >> app/server.js
docker build -t hello-school:v1 app/     # watch: FROM/WORKDIR cached, COPY rebuilt
git checkout app/server.js               # undo the tweak

docker history hello-school:v1           # 🎂 the actual layers + sizes
docker image ls | head -3                # images on your shelf

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

:latest म्हणजे "सर्वात नवा build" असे मानणे — तो इतर tags सारखाच एक tag आहे, आणि तो हलतो
चालू container च्या आत files बदलून image बदलेल अशी अपेक्षा करणे (ती बदलत नाही)
cache ची शिस्त न पाळता rebuild करणे — dependency च्या ओळींच्या वर कोड copy च्या ओळी = हळू builds

⏭️ पुढे

आता recipe card स्वतःच ओळ-ओळ वाचूया: Dockerfile.

git checkout lesson-03-dockerfile

🎂 Lesson 02 — Images & layers: the cake and the cache

📍 You are here: Lesson 02 of 12 · Previous: lesson-01-why-containers · Next: lesson-03-dockerfile

📦 What's in this branch

Lesson 01, plus: what an image actually is inside — stacked layers — and why understanding this makes your builds 100× faster. Real file:

app/Dockerfile — each line below bakes one layer

🧒 Explain like I'm 5

An image isn't one solid block — it's a layer cake 🎂, baked bottom-up, one Dockerfile line per layer:

Bottom layer: tiny Linux + Node (FROM node:20-alpine) — a pre-baked layer from the bakery. You never bake this yourself.
Middle layers: your settings (WORKDIR, ENV, USER).
Top layer: your code (COPY server.js).

And the magic rule of the bakery: a layer that didn't change is never baked again — it's taken from the cache shelf, instantly.

So when you edit server.js and rebuild:

bottom + middle layers → from cache, 0 seconds ⚡
only the COPY layer and above → rebaked 🔨

That's why pros put rarely-changing lines at the bottom and code at the top — so daily rebuilds touch only the thin top layer. Cake architecture is build speed. 🎂⚡

🗺️ Diagram

flowchart LR
    subgraph cake["🎂 image = layer cake, bottom-up"]
        l4["CMD node server.js"]
        l3["COPY server.js ← your code, changes often"]
        l2["WORKDIR / ENV / USER"]
        l1["FROM node:20-alpine ← pre-baked, huge, never changes"]
        l4 --- l3 --- l2 --- l1
    end
    edit["✏️ edit server.js<br/>+ docker build"]
    edit -->|"1 bottom layers: CACHE ⚡"| l1
    edit -->|"2 only COPY + above rebaked 🔨"| l3

❓ What

Image = an ordered stack of read-only layers + metadata (what to run, which ports, which user). Frozen; never changes after build.
Layer = the filesystem diff produced by one Dockerfile instruction. Layers are content-addressed and shared between images — ten images on node:20-alpine store that base once on disk.
Build cache: Docker reuses a layer if the instruction AND its inputs are unchanged. First changed line invalidates everything above it.
Container = a thin writable layer on top of the frozen stack — that's why 100 containers from one image are cheap.

🧠 Image vs container — and the three names of an image

IMAGE      = read-only template (the layer cake, frozen)
                 ↓ docker run
CONTAINER  = a running instance of that image (+ a thin writable layer)

Every image has three handles:

handle	example	changes?
image ID	`sha256:3f2a…` (local, content-based)	never for the same content
tag	`hello-school:v1`, `:latest`	mutable — a sticker someone can move
digest	`sha256:9c1e…` (registry, content identity)	immutable — the fingerprint

The same thing as a picture — one repository, many handles:

Repository  hello-school
   ├── tag: v1
   ├── tag: latest
   └── digest: sha256:abc123...

tag     = human-friendly name
digest  = immutable content identifier
latest  = just another mutable tag

Image content is immutable: change one byte, get a new ID/digest. latest is just the default tag name — it is neither "newest" nor stable. Tag vs digest returns with force in lessons 11 (ECR) and in Kubernetes deployments.

🤔 Why

Cache-friendly Dockerfiles are the difference between 2-second and 5-minute rebuilds — hundreds of times a week. And shared layers are why pulling your tenth Node app is instant: the fat base layer is already on the machine. (Lesson 11: pushes upload only layers the registry doesn't have — same idea.)

🔧 How (in this repo)

app/Dockerfile is cache-ordered on purpose: FROM → WORKDIR → COPY server.js → ENV/EXPOSE/USER/CMD. In bigger apps the classic move is: COPY package.json + RUN npm ci before COPY . . — so editing code never re-runs dependency install.

🧪 Try it

docker build -t hello-school:v1 app/     # first build: every layer baked
docker build -t hello-school:v1 app/     # again: ALL "CACHED" — ~1 second ⚡

echo "// tweak" >> app/server.js
docker build -t hello-school:v1 app/     # watch: FROM/WORKDIR cached, COPY rebuilt
git checkout app/server.js               # undo the tweak

docker history hello-school:v1           # 🎂 the actual layers + sizes
docker image ls | head -3                # images on your shelf

⚠️ Common mistakes

believing :latest means "the newest build" — it's a tag like any other, and it moves
editing files inside a running container and expecting the image to change (it doesn't)
rebuilding without cache discipline — code-copy lines above dependency lines = slow builds

⏭️ Next

Time to read the recipe card itself, line by line: the Dockerfile.

git checkout lesson-03-dockerfile

← Previouswhy containers Next →dockerfile

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