Docker Image vs Container — Key Difference

Direct Answer

A Docker image is an immutable, content-addressed package of filesystem layers plus configuration. A container is an instance created from an image with runtime configuration and a writable layer; it may be created, running, paused, or stopped. Many containers can use the same image while keeping separate writable state.

Code Example

# Image = blueprint (class). Container = running instance (object).
docker build -t order-service:1.0 .            # create the image once

docker run -d --name order-1 order-service:1.0 # instance 1 from the image
docker run -d --name order-2 order-service:1.0 # instance 2 from the SAME image

docker images    # one image (the class)
docker ps        # two containers (the objects)

docker rm -f order-1   # remove an instance — the image stays, ready to run

Common Mistakes & Pitfalls

• Treating containers as mutable: Freshers often exec into a running container, manually install packages or edit configuration files, then expect those changes to persist. Stopping and starting the same container normally keeps its writable layer; recreating it from the image does not include manual changes because the image layers are read-only — only the thin writable layer is temporary. The fix: rebuild the image with those changes in the Dockerfile.
• Confusing image tags with container names: Running docker run myapp:latest twice creates two separate containers, each with a random name like eloquent_tesla and zen_knuth, both from the same myapp:latest image. Freshers sometimes think the second run replaces the first, but Docker keeps both containers unless you explicitly remove them.
• Not understanding the writable layer: When your Spring Boot app writes logs to /var/log inside the container, that data lives in the container's writable layer and disappears on removal — this is why production apps mount volumes for persistent data.