beginner25 minby DevFox

Images, Containers and the Difference

An image is a recipe and a container is the meal. Why that distinction explains almost every confusing thing Docker does, plus the commands to inspect both.

Docker

You have already used both words. docker run nginx pulled an image and started a container, and so far you have had no reason to care which was which. That stops being true the moment something surprises you — a file you created inside a container that vanished, an image you cannot delete, a latest tag that turned out not to be the latest.

This is the lesson that makes those surprises stop being surprising. By the end of it you will know precisely what each one is, how to inspect both, and how to clean up the ones you no longer want.

A recipe and a meal

The kitchen metaphor is exact enough to lean on. An image is a recipe: precise, repeatable, and not edible. A container is the meal you cooked from it.

An image

A read-only snapshot on disk.

An operating system's files, a language runtime, your application's code, and a note saying what to run when it starts.

It sits there doing nothing at all.

A container

A live process, running from that snapshot.

It has its own view of the system and uses the image's files as its starting point.

Nothing it does can change the image — which is why the same image produces an identical starting point every time, on your laptop and in production alike.

One recipe makes as many meals as you like, and eating one does not alter the recipe

bash

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

Three containers, three independent processes with three separate filesystems, one image on disk shared between them.

Layers, and why images are cheap

An image is not one solid block. It is a stack of layers, each one a set of filesystem changes on top of the layer below — applied in order and presented to the container as one merged filesystem.

Layers are shared. If you have three different Python images all built on the same Python base, that base exists once on your disk and all three point at it. The next section draws the stack.

You are reading the image's construction history from top to bottom, newest first. The <missing> ids are not an error — they are layers that arrived as part of a pull rather than being built here, so your machine never gave them their own image id.

The writable layer, and the file that vanished

If an image is read-only, how does a container write anything?

When a container starts, Docker adds one more layer on top of the image's stack: a thin writable layer belonging to that container alone.

The container's writable layer
Created when the container starts, deleted when the container is deleted. Every file it creates or modifies goes here.
Your application's code
Read-only, and shared by every container from this image.
Your dependencies
Read-only.
Python, on top of a minimal Debian
Read-only, and shared with every other image built on the same base — which is why eight images totalling "3 GB" cost your disk far less than that.

Reads fall through to the layers below. Writes land in the top one only.

Watch it happen:

Start a new container from the same image and the file is not there:

The file was never in the image. It was in the first container's writable layer, and the second container has its own empty one. Start the original container again and the file is back, because that layer still exists:

Delete that container and the layer goes with it, permanently.

Names, tags and digests

You typed nginx and got an image. The full form of what you asked for is:

Docker filled in the defaults: Docker Hub as the registry, library as the owner for official images, and latest as the tag. A tag you write yourself looks like nginx:1.27 or myapp:v2.

A tag is a human-friendly label pointing at a particular image. It is a pointer, not a name carved into the image, and the thing it points at can be changed by whoever owns the repository.

Underneath every tag is a digest — a sha256: hash of the image's actual content. A digest is immutable by construction: if the content changes at all, it is a different digest.

Bad — the base image can change under you between builds:

Good — pins the version you tested against:

latest is not a promise about newness; it is just the tag applied when nobody specified one. The first version builds against whatever latest happens to point at today, so a build that worked last week can fail this week with no change on your side — and the failure lands on whoever is unlucky, not on the person who changed the tag.

Looking at both

Two families of commands, one for each concept. Images first:

Then containers:

docker exec is worth dwelling on, because it is the difference between looking at a container and looking inside one. It runs a new process in a container that is already running — as opposed to docker run, which creates a whole new container.

docker inspect prints a wall of JSON. Narrow it with a format string when you know what you want:

Cleaning up, in the right order

Now the rule that explains a confusing error message:

You cannot delete an image while a container is using it, because that container's filesystem is built on it. Containers come off first, then images:

Docker also accumulates two kinds of clutter worth knowing by name. Dangling images are layers left behind when a rebuild moved a tag to a new image, leaving the old one nameless — they show as <none> in docker images. The build cache is the stored intermediate layers from your builds, and on a busy machine it can reach tens of gigabytes.

Cheat sheet

Where to go next

You have been running other people's images. The next lesson is where you write your own: a Dockerfile that turns your application into an image you can run, tag and share — the point at which Docker starts being about your code rather than about nginx.

Before that, one experiment worth doing yourself. Start a container from ubuntu, install something inside it with apt, exit, and start a fresh container from the same image. Watch your install disappear. Understanding why that is correct behaviour rather than a bug is the whole content of this lesson.