Images, Containers, and the Dockerfile Explained

A Dockerfile is a recipe, an image is the prepared meal, and a container is a plate served from it.

Before you write pipeline configuration, you need a clear mental model of the three Docker primitives. They are easy to mix up because they describe the same application at different stages. This lesson defines each one and shows how they relate.

The three primitives

Dockerfile: a text file of instructions describing how to assemble an image.
Image: a read-only, layered snapshot built from a Dockerfile -- the shippable artifact.
Container: a running (or stopped) instance of an image with its own writable layer.

Layers and the union filesystem

Each instruction in a Dockerfile creates a layer. Layers stack to form the image, and Docker reuses unchanged layers from its cache. When you run an image, Docker adds a thin writable layer on top -- that is the container. Discarding the container throws away only the writable layer; the image is untouched.

From file to running process

You docker build a Dockerfile into an image, then docker run the image to start a container. In CI you usually build the image, run your test command inside a container, and discard the container afterward.

Terminal

docker build -t myapp:ci .
docker run --rm myapp:ci npm test

Why the distinction matters in CI

CI configuration often references all three. You write a Dockerfile, build a tagged image, and run ephemeral containers for each test job. Knowing which is immutable (the image) and which is throwaway (the container) tells you what to cache, what to push to a registry, and what to deploy.

Key takeaways

A Dockerfile builds an image; an image runs as one or more containers.
Images are immutable and layered; containers add a disposable writable layer on top.
In CI you push and deploy images, and run throwaway containers from them.