Docker Images vs Docker Containers
New Docker users often confuse images and containers. They sound similar and they are related, but they are completely different things. Understanding this difference is fundamental to everything else in Docker.
The Simple Analogy
A Docker image is like a cookie cutter. A Docker container is like the actual cookie you stamp out from it.
You design the cookie cutter once. You press it into dough ten times and get ten cookies. Each cookie is independent — you can decorate one with chocolate chips and leave another plain. Changing one cookie does not affect the cookie cutter or any other cookie.
You build a Docker image once. You run it ten times and get ten containers. Each container is independent. What happens inside one container does not affect the image or any other container.
What a Docker Image Is
A Docker image is a read-only file that contains:
- A base operating system layer (like Ubuntu or Alpine Linux)
- Your application's runtime (Python, Node.js, Java, etc.)
- All libraries and dependencies your app needs
- Your application code
- Configuration settings
- Instructions on what command to run when started
Images sit on disk. They do not "run." They just exist as a blueprint. You create images using a Dockerfile (covered in the next topic) or pull them from Docker Hub.
What a Docker Container Is
A container is a running instance of an image. The moment you use docker run, Docker takes an image and brings it to life. A container has:
- Its own isolated process running inside it
- Its own network interface with an IP address
- A writable layer on top of the image layers where it can write files
- A state: running, paused, stopped, or exited
Side by Side Comparison
┌─────────────────────────────────────────────────────────────┐ │ IMAGE vs CONTAINER │ ├────────────────────────┬────────────────────────────────────┤ │ IMAGE │ CONTAINER │ ├────────────────────────┼────────────────────────────────────┤ │ Static, not running │ Dynamic, actively running │ │ Read-only │ Has a writable top layer │ │ Stored on disk │ Exists in memory + disk │ │ Like a recipe │ Like the cooked meal │ │ Shared by many │ Each one is independent │ │ Created once │ Created and destroyed often │ │ Versioned with tags │ Has a unique container ID │ │ docker build / pull │ docker run │ └────────────────────────┴────────────────────────────────────┘
One Image, Many Containers
nginx:latest (IMAGE — single file on disk)
│
├──── docker run → Container A (serving port 8080)
│
├──── docker run → Container B (serving port 8081)
│
└──── docker run → Container C (serving port 8082)
All three containers read from the same image.
Each container has its own writable layer for logs, temp files.
Changing Container A does NOT affect B, C, or the image.
Container State — The Lifecycle
A container goes through states during its life:
Created ──→ Running ──→ Stopped ──→ Deleted │ │ │ │ (docker pause) │ │ ↓ │ │ Paused │ │ │ │ │ (docker unpause) │ │ ↓ │ └──────→ Running ────────┘
A stopped container still exists on disk. You can restart it with docker start. A deleted container is gone forever — but the image remains, so you can create a new container anytime.
Practical Commands to See the Difference
List all images on your machine:
docker images
Output shows image name, tag, ID, when created, and size.
List running containers:
docker ps
List all containers (including stopped ones):
docker ps -a
Delete a specific container (must be stopped first):
docker rm container_name_or_id
Delete an image (all containers from that image must be removed first):
docker rmi image_name_or_id
Key Points
- An image is a static blueprint; a container is a running instance of that blueprint.
- One image can create unlimited containers simultaneously.
- Containers have state (running, stopped, deleted); images do not run.
- Deleting a container does not delete the image — you can always create more containers from it.
