Module 2 Lesson 4: Deep Dive into Images and Containers

To use Docker effectively, you need to understand the "Stack of Layers" that makes up every image. This architecture is what makes Docker so fast and storage-efficient.

1. What is an Image composed of?

A Docker Image is actually a stack of multiple Read-Only Layers.

• Layer 1 (Base): A minimal OS (e.g., Alpine Linux).
• Layer 2: System tools and libraries.
• Layer 3: Your application code.
• Layer 4: Configuration and environment variables.

These layers are stored as one file but managed by a Union File System. If two images both use "Alpine Linux" as their base, Docker only stores one copy of that layer on your disk. This is Layer Sharing.

---

2. From Image to Container: The Writable Layer

When you start a container, Docker takes the stack of image layers and adds a thin Writable Layer (often called the "Container Layer") on top.

• The Image Layers: Remain Read-Only. They NEVER change.
• The Container Layer: This is where your app writes logs, creates temp files, or saves user data.
• Copy-on-Write (CoW): If you try to edit a file that exists in the image layer, Docker "Copies" it up to the writable layer first and then edits it. The original file in the image remains untouched.

---

Visualizing the Process

graph TD
    Start[Input] --> Process[Processing]
    Process --> Decision{Check}
    Decision -->|Success| End[Complete]
    Decision -->|Retry| Process

---

3. Why This Architecture Matters

1. Immutability: Since the image layers don't change, you can guarantee that every container started from that image is identical.
2. Efficiency: Starting a container is instant because Docker doesn't "Copy" the whole image; it just adds a tiny writable folder on top.
3. Ephemeral Nature: When you delete a container, the Writable Layer is deleted. Anything you saved there is GONE. (We use Volumes to fix this—covered in Module 4).

---

4. Comparing Images and Containers

Feature	Image	Container
State	Static / Dead (Saved on disk)	Dynamic / Alive (Running in RAM)
Layers	Stack of Read-Only layers	Read-Only layers + 1 Writable layer
Changeable?	No (You must build a NEW image)	Yes (In the writable layer)
Persistence	Permanent until deleted	Temporary (Loss of data on delete)

---

Exercise: The Layer Logic

1. You have two images: web-app:v1 (1GB) and web-app:v2 (1.1GB). They share 900MB of the same base layers. Roughly how much total disk space do both images use? (Hint: 1GB + 0.1GB = 1.1GB).
2. If you delete a container, does it delete its parent image? Why or why not?
3. Why is it a "Best Practice" to NEVER save important data inside the container's writable layer?

---

Summary

Images are the "Blueprints" (Read-only layers), and Containers are the "Running Processes" (Blueprint + Writable layer). This Separation of Concerns allows for massive scaling and predictable deployments.

Next Lesson: We track a container from birth to death: The Container Lifecycle.