Image, container, Dockerfile: the trinity
Summary: these three words come up constantly as soon as Docker is mentioned, and 8 out of 10 beginners confuse them. This lesson distinguishes them once and for all with a restaurant analogy, then details the complete life cycle — from writing the Dockerfile to the container answering requests.
1. The restaurant analogy
Imagine a restaurant that serves lasagna. This activity involves three very different things:
The mapping with Docker:
| Restaurant object | Docker equivalent |
|---|---|
| The written recipe | Dockerfile — a text file describing how to build the image |
| The cooked dish, ready to serve | Docker image — the result of the build, read-only |
| The plate served to the customer | Docker container — a running instance of the image |
You can serve several plates of the same dish. In the same way, you can launch several containers from the same image — this is how Netflix or Uber run thousands of identical copies of their services.
2. The Dockerfile — the recipe
A Dockerfile is a simple text file describing, step by step, how to build the image. It lives next to the application's source code, versioned in Git.
Ultra-simple example (no need to memorize it, we just want to see what it looks like):
FROM node:20-alpine
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]
Line-by-line decoding, in plain English:
| Instruction | What it tells Docker |
|---|---|
FROM node:20-alpine | Start from the official Node.js version 20 image on Alpine Linux |
WORKDIR /app | Position yourself in the /app folder |
COPY package.json . | Copy my package.json file into the container |
RUN npm install | Install all the dependencies |
COPY . . | Copy all my source code |
EXPOSE 3000 | Signal that the application listens on port 3000 |
CMD ["node", "server.js"] | Run the startup command |
This file is the single source of truth: every person who builds the image from this Dockerfile gets rigorously the same image. End of "it works on my machine".
3. The image — the cooked dish
A Docker image is the result of building a Dockerfile. It is a read-only artifact, like a sealed ZIP file containing everything needed to run the application.
Crucial point to understand well: an image is immutable. Once built, it does not change. If you want to modify the application, you build a new image with a new tag (like myapp:v2.4.0) — the old one remains available.
This immutability is the key to reproducibility. If I tell you "launch the image nginx:1.27.1-alpine", you and I get exactly the same bytes, wherever we are in the world.
4. The layer system — the brilliant find
Docker's cleverest invention is the layer system.
Each Dockerfile instruction creates a layer, stackable like sheets of tracing paper.
Concrete benefits of this architecture:
- Build cache: if you only modify your source code (layer 4), Docker reuses layers 1, 2 and 3 without rebuilding them. The rebuild takes 2 seconds instead of 5 minutes.
- Sharing between images: if ten images use the same Node.js base, that layer is stored only once on disk. Massive savings.
- Efficient distribution: during a download from Docker Hub, only the missing layers are fetched.
This system is what makes Docker so fast and so disk-efficient despite the quantity of images in circulation.
5. The container — the served plate
A container is the living execution of an image. It is what actually runs, uses CPU and RAM, answers requests.
What makes a container unique, if it starts from the same image as the others?
- Its life cycle: it can be started, stopped, restarted, deleted.
- Its volatile state: files created inside it during execution (for example, user uploads) disappear when it is deleted — unless you use a volume to persist them.
- Its identifier: each container has a unique ID and often a readable name (for example
webapp-prod-1). - Its launch configuration: environment variables, mapped ports, mounted volumes, attached network.
Useful analogy: the image is like the class in object-oriented programming. The container is like an instance of that class. You can create many instances from a single class.
6. The complete life cycle
Here is the complete journey, from text to the container answering in production.
This cycle is the foundation of all professional Docker usage. In CI/CD, it is automated: a git push triggers the build of the image, its publication in the registry, and the deployment to the production servers — all without human intervention, in less than 10 minutes.
7. Where images live — the registry
The registry is the central catalog where images are published and fetched.
Docker Hub is to Docker what GitHub is to Git: the place where the community shares its artifacts, where the big open source projects publish their official images (Nginx, PostgreSQL, Redis, Python, Node…), and where your team can publish its private images.
A simple docker pull postgres:16 downloads in a few seconds a ready-to-use PostgreSQL database. It is this accessibility that democratized the deployment of complex infrastructures.
8. The trick question in interviews
"Is an image a stopped container?"
Short answer: no.
Developed answer: an image is a read-only template. It cannot be "started" — it serves as a mold for containers. A stopped container, on the other hand, still exists as an entity with its own state (latest file modifications, logs…). It can be restarted with docker start.
Another trap: "why did my files disappear after a docker run?"
Answer: because files created in a container are lost when it is deleted. To persist data (database, uploads), you must use a volume — one of the key topics of the Premium Docker Course.
Remember in 30 seconds
- Dockerfile = the recipe (text file, versioned in Git).
- Image = the cooked dish (immutable artifact, layered, publishable in a registry).
- Container = the served plate (running instance, with a life cycle).
- A Dockerfile builds an image. An image instantiates a container. A registry shares images.
- The layer system is what makes Docker fast and disk-efficient.
- Docker Hub = "the GitHub of Docker images" — 15 million public images.
Next: Docker vs virtual machine: the comparison that clarifies everything →