Images vs Containers

The single most important distinction in Docker is the difference between an image and a container. Beginners often use the words interchangeably, which leads to confusion when commands behave unexpectedly. This lesson makes the distinction crystal clear and introduces the layered filesystem that makes Docker images so efficient.

The Class and Object Analogy

If you have done any object-oriented programming, the cleanest mental model is this: an image is like a class, and a container is like an object created from that class.

An image is a read-only template. It never changes once built.
A container is a live, running instance created from an image. It has its own writable filesystem, its own process, and its own network identity.
Just as one class can produce many objects, one image can produce many containers, each independent of the others.

Run this to see it in practice:

bash

docker run -d --name web1 nginx
docker run -d --name web2 nginx
docker run -d --name web3 nginx
docker ps

Three containers, one image. Each container can be stopped, restarted, or deleted without affecting the others or the image itself.

Images Are Built From Layers

A Docker image is not one big file. It is a stack of read-only layers, where each layer records the filesystem changes made by one build step. For example, an image might consist of:

A base layer with a minimal Linux filesystem
A layer that installs Node.js
A layer that copies your application code
A layer that installs your npm dependencies

Layers are content-addressed and shared. If ten images on your machine all start from the same base layer, that layer is stored on disk exactly once. This is why pulling a second Node-based image is much faster than the first - Docker only downloads the layers it does not already have.

Inspect the layers of any image with:

bash

docker history nginx

The Container Layer

When Docker starts a container, it does not copy the image. Instead it stacks a thin writable layer on top of the read-only image layers. Every file the container creates or modifies lives in that writable layer, using a copy-on-write strategy.

This has two important consequences:

Starting a container is nearly instant, because nothing is copied.
When you delete a container, its writable layer is destroyed and any data written inside it is lost. Persistent data belongs in volumes, which we cover in lesson 7.

Where Images Come From

You get images in two ways:

bash

docker pull redis:7        # download from a registry
docker build -t myapp .    # build from a Dockerfile

The part after the colon is a tag, a human-readable label for a specific version. If you omit it, Docker assumes latest. Tags like redis:7-alpine indicate both the version and the base variant.

Commands That Target Images vs Containers

Many Docker subcommands come in pairs, and knowing which side you are working on avoids mistakes:

| Task | Image command | Container command | | --- | --- | --- | | List | docker images | docker ps -a | | Remove | docker rmi nginx | docker rm web1 | | Inspect | docker inspect nginx | docker inspect web1 |

You cannot remove an image while containers created from it still exist - Docker will refuse until those containers are removed.

Key Takeaways

An image is a read-only template; a container is a running instance with a thin writable layer.
One image can spawn many independent containers.
Images are stacks of shared, cached layers, which saves disk space and download time.
Data written inside a container disappears when the container is removed - use volumes for persistence.
Tags like redis:7 pin a specific image version; avoid relying on latest in production.

Next up: Running and Managing Containers, where you will master the full container lifecycle - restart policies, resource limits, and interactive sessions.