Stage 2 - Docker Images
A Docker image is the first object that makes Docker feel different from a simple script. It is not a running application. It is a versioned package that can create containers again and again.
Image anatomy
An image is built from layers. Each layer is a read-only filesystem change: install packages, copy files, set metadata, or add application artifacts. Docker reuses layers when their content is identical, which saves download time and disk space.
Base OS layer
Runtime layer
Dependencies layer
Application layer
Image metadata
The lifecycle is simple: find or build an image, tag it, push or pull it through a registry, run containers from it, then replace it with a newer image when the application changes. The old image is not edited in place. That immutable model is important for rollback and repeatability.
Registry and tags
Docker Hub is a public registry. Official images such as postgres, nginx, redis, and eclipse-temurin are better starting points than random images because they have documented conventions. They still need explicit tags. The tag latest is a moving label, not a stable version.
Layers are a cache and a history
Every image layer answers the question: what changed in the filesystem or metadata after this build step? This is why docker history is useful. It lets you see whether an image contains large package installs, copied application files, or commands that should have been cleaned up.
Layer reuse is also why Docker builds can be fast. If the dependency layer did not change, Docker can reuse it. If you copy the whole project too early, every small code change can invalidate later layers and make the build slow.
This is not only a performance topic. Layers can also accidentally keep sensitive files. If a secret is copied in one layer and deleted in a later layer, it may still be recoverable from the image history.
Tags, digests, and trust
A tag is a human-friendly pointer. It is useful because people can remember postgres:16, but it is not the strongest identity. A digest is tied to exact content. In strict production workflows, teams may record digests to know precisely what ran.
Trust also depends on the image source. An official image is not automatically perfect, but it is usually documented and maintained with clearer conventions. A random image from an unknown publisher may work today and become a supply-chain risk tomorrow.
For learning, explicit tags are enough. For production, the team should also know where images come from, how they are scanned, and how updates are approved.
Where images are stored and used
When you run docker pull nginx:1.27, the command is typed on your machine, but it contacts a remote registry. The registry sends image layers to your local Docker daemon. The layers are stored in Docker’s local storage area, not in your project folder.
When you later run a container from that image, Docker does not download it again if the required layers already exist locally. This is why the first run can be slower and later runs can be almost instant.
On a server, the same idea applies. The server pulls images into its own local Docker storage. Your laptop image cache and the server image cache are separate. Pushing an image to a registry is what lets another machine pull the same artifact.
Commands to run and inspect
Run these commands in a terminal on the machine where Docker is installed. For local learning, that is your laptop terminal. For a VPS, first connect to the server with SSH, then run the commands there. Do not paste commands blindly: run one command, inspect what changed, then run the next one.
docker search nginx
docker pull nginx:1.27
docker image ls
docker image inspect nginx:1.27
docker history nginx:1.27
Reference table
| Topic | What it means | Practical consequence |
|---|---|---|
| Layer | Read-only filesystem change | Cache and reuse between images |
| Tag | Readable pointer like postgres:16 | Can move; pin versions deliberately |
| Digest | Exact content identity | Use when exact reproducibility matters |
Image audit
Pick one image used in a project and answer three questions: who maintains it, which tag is used, and whether the tag can move. If the answer is unclear, the image is not documented well enough for a team workflow.
Also inspect the image history. You do not need to understand every layer yet, but you should see that an image is built from a sequence of filesystem and metadata changes.
Checkpoint
Move on when you can explain layers, tags, digests, and why latest is risky outside a quick experiment.
Practical image exercise
Pull one official image and inspect it. Look at its tag, creation date, environment variables, exposed ports, and layer history. Then ask what would break if the tag silently changed. This is how image versioning becomes a practical concern: not because tags are interesting by themselves, but because a moving base image can change runtime behavior without changing your application code.
Short takeaway
Main orientation: an image should be a repeatable artifact. If you cannot say which tag it uses and why that base image was selected, later build and deployment problems will be hard to investigate.