Docker Image vs Container

Learn how Docker images and containers differ, how image layers and the writable layer work, and how a container's lifecycle behaves.

An image is a read-only template that contains your application, its dependencies, and metadata. A container is a running (or stopped) instance created from that image. The relationship is similar to a class and an object, or a program on disk and a running process. Interviewers ask about this difference constantly, so it is worth understanding the details.

Side-by-Side Comparison

Aspect Image Container
Nature Immutable template Running or stopped instance
Contains Layers, config, default command, environment Image layers plus a writable layer and runtime state
Created by docker build, docker pull docker run, docker create
Mutable No, layers are read-only Yes, through the writable layer
Stored as Layers in the local image store or registry Process plus a writable layer on the host
Quantity One image Many containers can come from one image
Removed with docker rmi docker rm

Image Layers

An image is a stack of read-only layers. Each filesystem-changing Dockerfile instruction adds one layer. Layers are identified by content hashes and shared between images, so pulling a second image based on the same base only downloads the new layers.

docker pull nginx:1.27
# 1.27: Pulling from library/nginx
# a480a496ba95: Pull complete
# ...
# Digest: sha256:...
# Status: Downloaded newer image for nginx:1.27

docker history nginx:1.27
# IMAGE          CREATED       CREATED BY                                      SIZE
# <hash>         2 weeks ago   CMD ["nginx" "-g" "daemon off;"]                0B
# <hash>         2 weeks ago   COPY 30-tune-worker-processes.sh ...            4.62kB
# ...

docker history shows each layer, the instruction that created it, and its size. Metadata-only instructions such as CMD and ENV have a size of 0B.

The Container Writable Layer

When a container starts, Docker adds a thin writable layer on top of the image layers. Writes go there using copy-on-write: if the container modifies a file from a lower layer, the file is first copied up into the writable layer and then changed.

docker run -d --name demo nginx:1.27
docker exec demo sh -c 'echo hello > /tmp/note.txt'

docker diff demo
# A /tmp/note.txt      (A = added, C = changed, D = deleted)
# C /run
# ...

docker rm -f demo     # the writable layer, and note.txt, are gone

Because the writable layer is deleted with the container, anything that must survive needs a volume (see the Docker Volumes lesson).

Container Lifecycle

State Meaning Typical command
Created Container exists but has not started docker create
Running Main process is executing docker start, docker run
Paused Processes frozen docker pause / docker unpause
Exited Main process finished or was stopped docker stop
Removed Container and writable layer deleted docker rm

docker run is shorthand for docker create followed by docker start. A container lives only as long as its main process: when PID 1 exits, the container exits.

docker run --name once alpine echo "done"
# done
docker ps -a --filter name=once
# STATUS: Exited (0) 3 seconds ago
docker start once    # runs the same command again in the same container

Tags and Digests

An image name has the form [registry/][namespace/]repository[:tag]. A tag such as 1.27 is a movable label. A digest (sha256:...) identifies exact content and never changes.

docker pull nginx:1.27
docker image inspect nginx:1.27 --format '{{index .RepoDigests 0}}'
# nginx@sha256:...
docker pull nginx@sha256:<digest>    # exact, reproducible reference

Creating an Image from a Container

You can capture a container's state with docker commit, but this is for experiments only:

docker commit demo my-nginx:snapshot

It creates an image that is not reproducible and has no documented build steps. Use a Dockerfile for anything that matters.

Common Mistakes

  • Expecting container changes to modify the image. Edits in a container never change the source image; they live in the container's writable layer.
  • Storing important data in the container filesystem. Removing the container deletes it.
  • Deleting an image that containers still use. Docker refuses (image is being used by stopped container) unless forced; remove the containers first.
  • Using docker commit as a build process. The result is undocumented and cannot be reviewed or rebuilt.
  • Relying on the latest tag. It is just a default tag name, not necessarily the newest version.

Best Practices

  • Treat images as immutable artifacts and containers as disposable.
  • Tag images with explicit versions (and optionally a Git commit SHA).
  • Use digests when you need exact reproducibility.
  • Keep writable-layer usage small by mounting volumes for data and tmpfs for scratch space.

Interview Questions

1. What is the difference between a Docker image and a container?

An image is a read-only, layered template containing the application and its dependencies. A container is a runtime instance of an image with an added writable layer and its own process, network, and filesystem view. Many containers can run from the same image.

2. What are image layers and why do they matter?

Layers are read-only filesystem changes produced by Dockerfile instructions. They are content-addressed, cached, and shared between images, which saves disk space, bandwidth, and build time.

3. What happens to data written inside a container when it is removed?

It is lost, because it lives in the container's writable layer. To persist data, use a volume or a bind mount.

4. What is copy-on-write in Docker?

When a container modifies a file that exists in a lower read-only layer, Docker copies the file into the writable layer and modifies the copy. Unchanged files stay shared, which keeps containers cheap to create.

5. What is the difference between a tag and a digest?

A tag is a mutable human-readable label that can be re-pointed to a different image. A digest is a cryptographic hash of the image content and is immutable, so it guarantees you get exactly the same image.

6. Why does a container exit immediately after starting?

A container runs only while its main process runs. If the command finishes, fails, or runs in the background (daemonizes), the container stops. Check docker logs and the exit code with docker ps -a.

Summary

  • An image is an immutable layered template; a container is a running instance with a writable layer.
  • Layers are shared and cached; the writable layer uses copy-on-write and disappears with the container.
  • Containers live as long as their main process; docker run equals create plus start.
  • Use tags for readability and digests for exact reproducibility.

Continue Learning

Previous: Dockerfile Basics | Next: Docker Commands

Was this guide helpful?

CodeWithVenu is free to read, with no paywall. If this guide saved you time or helped you prepare, a small voluntary contribution helps me write more practical tutorials, architecture guides, and interview-prep content.