Images vs Containers

Two words show up together the moment you meet containers, and they trip up nearly everyone at first: image and container. They sound interchangeable, but they name two different things, and keeping them straight makes everything afterward click into place.

Here's the whole distinction in one line. An image is the sealed package — the blueprint, sitting on disk, doing nothing. A container is that image actually running. One recipe, many meals: the recipe just sits in the book until you cook from it.

An Image: The Built, Frozen Package

An image is your app and its whole environment built and sealed into one finished package, then frozen. It doesn't run on its own — it sits in storage, complete and unchanging, like a meal prepped and put in the freezer. Building the Pageturn image is how Maya turns "the code plus its surroundings" into one shippable thing.

Because it's frozen, an image is reliable: the same image is byte-for-byte identical wherever it goes. That's what makes it the unit teams build once and then move around — to a server, to the cloud, to a teammate's laptop — with confidence that it's the exact same package every time.

A Container: The Image Running

A container is what you get when you take an image and actually start it. It's the live, running form of the frozen package — the meal taken out of the freezer and heated up and served. The image is the noun at rest; the container is the image in motion.

This mirrors an idea from Computing Foundations: code sitting in a file versus a program actually running. The image is the at-rest package on disk; the container is the running thing doing work for users right now.

One Image, Many Containers

Here's where the distinction earns its keep. From one image you can start as many containers as you like, and every one is an identical copy. Run the Pageturn image ten times and you get ten Pageturn containers, all the same, each handling its share of readers.

Think of a cookie cutter and recipe as the image, and the actual cookies as the containers — one cutter stamps out as many identical cookies as you want. This is the foundation of scaling, which the next chapter is about: handling more users by running more containers from the one image.

How an Image Is Built: The Recipe

So where does an image come from? You write a short recipe file — by convention called a Dockerfile — that lists the steps to build it. A typical one is only a few lines. The first line picks a starting point: an existing base image with a programming language already inside, so you don't begin from nothing. The next line copies your app's files into the package. The line after that runs a setup command to install the app's dependencies — the outside tools it needs. The last line records the command that should run when the image is later started as a container. Read it top to bottom and it's just: start from this base, add my files, set it up, and here's how to launch it.

FROM python:3.12
COPY . /app
RUN pip install -r /app/requirements.txt
CMD ["python", "/app/app.py"]

That's a real recipe, not a sketch — four lines that say exactly what the paragraph above described, in order. You don't need to write or memorize it here; it's shown only so the artifact is concrete. You'll write files like this yourself in the Docker Deep Dive course, where building, tagging, and running images is the hands-on work. Connects to: the Docker Deep Dive, and Chapter 6 (orchestration), where many containers from one image are run and managed together.