Images vs Containers

In one line

An image is a class; a container is an object. This single analogy resolves 90% of beginner confusion about Docker.

0/4 · 0%

Think of it like this

A cookie cutter (the image) and the actual cookies you cut from dough (the containers). One cutter can stamp out unlimited identical cookies. Cutting a new cookie doesn't change the cutter. If you damage one cookie, the cutter — and every other cookie — is unaffected.

Key ideas

01
An IMAGE is a read-only, immutable template containing everything an app needs: the code, a runtime (like a JVM), libraries, environment variables, and default startup command. Images never change once built — they're versioned and identified by a name + tag, like nginx:1.25 or myapp:v2.
02
A CONTAINER is a running (or stopped) INSTANCE of an image, with its own writable layer stacked on top of the image's read-only layers. You can start many containers from the same image, and they're fully independent of each other.
03
The class/object analogy for Java developers: an image is like a compiled .class file — a template. A container is like an object created with new — a live instance with its own state, that you can create many of from the same class, and that doesn't affect the class definition when it changes.
04
Changes made INSIDE a running container (writing a file, installing a package) live in that container's own writable layer and are LOST when the container is deleted — unless you either commit those changes into a new image, or use a volume (Phase 3) to persist data outside the container's lifecycle.
05
Key commands: docker images (or docker image ls) lists images on your machine. docker ps -a lists containers. docker run <image> creates AND starts a new container FROM an image. docker start/stop <container> starts/stops an EXISTING container (doesn't create a new one).

In your stack

→
Class-to-object mapping made explicit: OrderService.class (the compiled definition) is like a Docker image; new OrderService() (a live object in memory) is like a container. You can new up 50 OrderService objects from one class file, exactly as you can run 50 containers from one image.

Code & diagrams

image-vs-container.shmarkdown

Run two containers from the SAME image and watch them behave completely independently.

# Start container #1 from the nginx image, name it "web1"
docker run -d --name web1 nginx

# Start container #2 from the SAME image, name it "web2"
docker run -d --name web2 nginx

# Both are running, independently, from one image:
docker ps
# CONTAINER ID   IMAGE   NAMES
# abc123...      nginx   web1
# def456...      nginx   web2

# Only ONE image exists on disk, no matter how many containers you run from it
docker images
# REPOSITORY   TAG       IMAGE ID
# nginx        latest    a6bd71f4...

# Deleting one container never touches the image or the other container
docker rm -f web1
docker images   # nginx image is still there
docker ps       # web2 is still running

Explain it without notes

Using the class/object analogy, explain why deleting a container never deletes the image it came from.

You install a package with apt-get install INSIDE a running container. You then delete that container and start a brand-new one from the same original image. Is the package still there? Why?

Practice

Run 3 containers from the nginx image with 3 different --name values. Confirm with docker ps that all 3 are running, then confirm with docker images that only ONE nginx image exists.

Start a container, exec into it (docker exec -it <name> bash), create a file inside it, exit, then delete the container and start a new one from the same image — confirm the file is gone.

Trade-offs

↔
Treating containers as disposable (immutable infrastructure) is the whole point of Docker's design — fighting this by manually patching running containers instead of rebuilding images is a common anti-pattern that leads to 'snowflake' containers nobody can reproduce.

Done when you can

I can explain images vs containers using the class/object analogy without hesitation.
I understand that changes inside a container don't persist to the image or survive container deletion.

Command Palette