Docker Course
Docker Images Explained
You've been pulling and running images since Lesson 1. Now it's time to understand what they actually are — how they're built, how they're stored, and why the same image can produce hundreds of identical containers without any extra disk space.
Images are the foundation of everything in Docker. Every container you'll ever run started as an image. Every Dockerfile you'll ever write produces an image. Every push to Docker Hub is an image. Getting this concept solid now pays off for every lesson that follows.
An Image Is a Read-Only Template
A Docker image is a read-only template that contains everything needed to run a piece of software — the OS filesystem, the application code, the runtime, the libraries, the environment variables, and the default command to run when a container starts.
The key word is read-only. An image itself never changes. You can't modify it by running a container from it. Every container gets its own separate writable layer on top — but the image underneath stays pristine. This is what makes images so powerful: one image can serve as the base for thousands of containers simultaneously, and none of them interfere with each other.
The Stamp and Wax Analogy
A Docker image is like a rubber stamp. The stamp itself never changes — it's a fixed, reusable template. Every time you press it onto wax, you get an identical impression. That impression — the wax — is the container. You can make a thousand impressions from one stamp, each one identical, each one independent. Ruining one wax impression doesn't damage the stamp. Throwing away the wax doesn't remove the stamp. The stamp is your image. The wax is your container.
Images Are Made of Layers
A Docker image isn't a single flat file. It's a stack of read-only layers, where each layer represents a set of filesystem changes. Each instruction in a Dockerfile adds a new layer on top of the previous one.
This layered design is one of Docker's most important optimisations. If two images share the same base layer — say, both start from ubuntu:22.04 — Docker only stores that layer once on disk, no matter how many images use it. Pulling a new image that shares layers with one you already have is almost instant — the Daemon only downloads the layers it doesn't already have.
Image layers — bottom to top
Layers 1–4 are read-only and part of the image. Layer 5 is writable and exists only while the container runs. Delete the container — Layer 5 disappears. The image stays untouched.
Image Tags and Versioning
Every image on Docker Hub has a name and a tag. The tag specifies the version or variant of the image. The full image reference looks like this:
Anatomy of an image reference
When you type docker pull node, Docker expands it to docker.io/library/node:latest automatically.
The latest tag is the default — if you don't specify a tag, Docker pulls latest. In production, never use latest. It changes whenever the image maintainer pushes a new version. Pin to a specific tag like node:18.19-alpine so your builds are reproducible and don't break when an upstream image updates.
The latest Tag Is a Trap
A team deployed their app using node:latest. Six months later, latest pointed to Node 20 — their app was built for Node 18. The pipeline broke overnight with zero code changes. Always pin your image tags. node:18.19-alpine today is node:18.19-alpine in two years.
Official Images vs Community Images
Docker Hub hosts two categories of images worth knowing about.
Official images are maintained by Docker in partnership with the software's creators. They live under the library namespace — so nginx, postgres, node, python are all official images. They're regularly updated, security-scanned, and well-documented. For any well-known software, start here.
Community images are published by individuals and organisations under their own namespace — like bitnami/postgresql or acmecorp/payment-api. These range from excellent to unmaintained. Always check the pull count, star count, and last push date before trusting a community image in production.
Inspecting Images Locally
The scenario: You're a DevOps engineer onboarding onto a project. The team uses a custom Node.js image but nobody documented what's in it. You need to inspect it — see its layers, its size, its exposed ports, and the command it runs by default — before you put it in production.
docker images # list all locally stored images
docker image inspect node:18-alpine # detailed metadata about a specific image
docker history node:18-alpine # show all layers and the command that created each one
REPOSITORY TAG IMAGE ID CREATED SIZE
node 18-alpine b7b849fc9f30 2 weeks ago 127MB
postgres 15-alpine 7e0d9f6e8eca 3 weeks ago 243MB
nginx latest a6bd71f48f68 4 weeks ago 187MB
IMAGE: node:18-alpine
"ExposedPorts": {},
"Env": ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"NODE_VERSION=18.19.0"],
"Cmd": ["node"],
"WorkingDir": "",
"Os": "linux",
"Architecture": "amd64"
IMAGE HISTORY: node:18-alpine
IMAGE CREATED CREATED BY SIZE
b7b849fc9f30 2 weeks ago CMD ["node"] 0B
<missing> 2 weeks ago ENV NODE_VERSION=18.19.0 0B
<missing> 2 weeks ago RUN apk add --no-cache nodejs npm 62MB
<missing> 2 weeks ago FROM alpine:3.18 7.3MB
What just happened?
docker images shows every image cached locally — its repository name, tag, unique image ID, age, and compressed size on disk. docker image inspect returns the full JSON metadata — the environment variables baked in, the default command, the OS, architecture, and exposed ports. This is how you audit an image before trusting it. docker history shows every layer in the image from bottom to top — the exact command that created each layer and how much disk space it added. The <missing> entries are normal for pulled images — those layers were built on a different machine and their build context isn't stored locally.
Teacher's Note
docker history on an image you didn't build is one of the first things a security-conscious engineer checks — it tells you exactly what ran inside the image at build time.
Practice Questions
1. A Docker image is described as a ___ template — meaning running a container from it never modifies the image itself.
2. If you run docker pull nginx without specifying a tag, Docker automatically pulls the tag called what?
3. To see every layer in a Docker image and the command that created each one, which command do you use?
Quiz
1. You have 10 Docker images on your machine, all based on ubuntu:22.04. How does Docker handle the storage of that base layer?
2. A colleague uses node:latest in their production Dockerfile. This is a problem because:
3. A container is running and writing files to its filesystem. Where do those writes go?
Up Next · Lesson 8
Docker Containers Explained
Images are the template — containers are the living, breathing instances. Let's go deep on what a container actually is, how it's isolated, and what happens inside one when it runs.