Images vs Containers — The Crucial Distinction

Let’s try another analogy to reinforce this distinction.

A recipe is instructions for making a meal. It lists ingredients, steps, cooking times, and temperatures. You can read a recipe, copy it, share it, but you can’t eat it. It’s just information.

A meal is what you get when you follow the recipe. It’s a real, physical thing. You can eat it, taste it, modify it (add salt), and eventually it’s gone.

The relationship between images and containers is similar:

Image = Recipe

• Instructions and ingredients
• Read-only
• Can be stored and shared
• Doesn’t “run” or “execute”
• One recipe can make many meals

Container = Meal

• The real, running thing
• Can be modified (changes stay in the meal, not the recipe)
• Temporary — when it’s gone, it’s gone
• Each meal is independent

The distinction matters: If you add too much salt to your meal, you don’t ruin the recipe. The recipe is still valid. You only ruined this particular meal. Same with containers — if you break something in a container, the image is still fine. Just throw away the container and make a new one.

If you have any programming background, this comparison might help.

An image is like a class definition. A container is like an instance of that class.

# This is like an IMAGE - a definition, a template
class WebServer:
    def __init__(self):
        self.port = 8080
        self.files = ['/index.html', '/style.css']

    def handle_request(self):
        # do something
        pass

# These are like CONTAINERS - running instances
server1 = WebServer()  # First container
server2 = WebServer()  # Second container
server3 = WebServer()  # Third container

Each instance (server1, server2, server3) is independent. If server1 crashes, server2 and server3 keep running. If you modify server1.port = 9000, only that instance changes. The class definition (WebServer) remains unchanged.

The Practical Differences:

Aspect	Image	Container
State	Static, unchanging	Dynamic, changing
Storage	Saved on disk	Exists while running (or stopped)
Creating	Built with docker build	Created with docker run
Removing	docker image rm	docker rm
Listing	docker images	docker ps
Can run?	No — it’s just a template	Yes — it’s a running process

When you run docker run nginx:

1. Docker looks for an image named nginx locally
2. If not found, Docker pulls it from a registry
3. Docker creates a new container from that image
4. Docker starts the container

At this point, you have:

• One image (nginx) — stored, read-only
• One container — running, writable

If you run docker run nginx again, you get:

• Still one image (nginx) — same as before
• Two containers — both running independently

The Writable Layer

When Docker creates a container from an image, it adds a thin “writable layer” on top of the image layers. This is where all container changes go.

┌─────────────────────────────┐
│    Container's Writable     │  ← Changes go here
│         Layer               │    (new files, modifications)
├─────────────────────────────┤
│                             │
│    Image Layers             │  ← Read-only
│    (shared by all           │    (never modified)
│     containers from         │
│     this image)             │
│                             │
└─────────────────────────────┘

Containers are disposable. Images are valuable.

Because containers can be recreated from images instantly, you should treat them as disposable. Something wrong with a container? Delete it and create a new one.

But images are different. An image represents significant work — building the right environment, installing dependencies, configuring everything correctly. You should:

• Save images you’ve built
• Version them properly
• Push them to registries for safekeeping

Data persistence requires explicit action.

If you create important data inside a container (a database, uploaded files, logs), that data lives in the container’s writable layer. When the container is deleted, that data is gone.

This is why Docker has volumes — we’ll cover them in Module 10. Volumes let you persist data outside the container’s writable layer.

---