Docker Image

Docker Image — The Blueprint for Every Container

What Is a Docker Image in Simple Terms?

A Docker image is a read-only package that contains everything needed to run an application — the code, the runtime, the libraries, the configuration files, and the operating system files. When you run an image, Docker creates a container from it. The image never changes — it is the template. The container is the running instance.

Think of an image like a cooking recipe. The recipe itself never changes — it tells you exactly what ingredients and steps to use. Every time you follow the recipe, you create a new meal (the container). Multiple chefs can follow the same recipe simultaneously to create multiple identical meals.

How Images Are Layered — The Union Filesystem

A Docker image is not a single monolithic file. It is a stack of layers. Each layer represents the filesystem changes made by one Dockerfile instruction. Understanding this is the key to understanding build speed, image size, and storage efficiency.

Layers are immutable — once created, they never change. When Docker builds a new image, it only creates new layers for instructions that changed. Everything else is reused from the cache.

OverlayFS — How Layers Stack Into a Filesystem

Docker uses OverlayFS (Overlay Filesystem) to merge multiple read-only layers into a single unified view. When you run a container, Docker adds one writable layer on top:

When a container modifies a file that exists in a read-only layer, OverlayFS copies the file up to the writable layer and modifies it there — leaving the original layer untouched. This is called copy-on-write.

Image Naming and Tagging

Working With Images

Image ID vs Image Digest

Dangling Images — Cleaning Up Build Artifacts

Every time you rebuild an image with the same tag, the old image loses its tag and becomes dangling — it still exists on disk but has no name.

Troubleshooting Reference

PLACEMENT PRO TIP

**Tip:** Run `docker history your-image:tag --no-trunc` to see the full Dockerfile instruction that created each layer. This is the fastest way to understand what is taking up space in a large image — each layer shows its size and the exact command that created it.

REMEMBER THIS

**Remember:** Image layers are shared between images on the same host. If you have 10 containers all running from `node:20-alpine`, the Alpine base layers are stored once on disk — not 10 times. This storage efficiency is a major reason container images are so much more practical than VMs for running many services on the same host.

COMMON MISTAKE / WARNING

**Common Mistake:** Using the `:latest` tag in production. The `latest` tag is just a convention — it means whatever was last pushed with that tag. If someone pushes a broken build and tags it `latest`, every deployment that pulls `latest` will get the broken build. Always tag images with an immutable identifier like a git SHA or a semantic version.

COMMON MISTAKE / WARNING

**Security:** Base images inherit CVEs (known vulnerabilities) from the operating system packages they include. An `ubuntu:22.04` base typically has 200+ known CVEs. An `alpine:3.18` base has 0-5. Always scan your images with Trivy (`trivy image your-image:tag`) before pushing to production and fail CI if CRITICAL severity CVEs are found.