Images - what are they?

A Docker image is a lightweight, standalone, and executable software package that includes everything needed to run a piece of software: the code, runtime, libraries, environment variables, and configuration files. Think of it as a blueprint for creating containers — a portable, reproducible unit of software that can run reliably in any environment where Docker is installed.

At its core, a Docker image is an immutable snapshot of a file system. When you run a Docker image, Docker creates a container, which is a running instance of that image. You can run many containers from the same image, and they will behave identically unless you explicitly configure them differently.

Layers

A Docker image is made up of a number of layers. The base layer usually contains all the files needed to be a working operating system. eg. you could have the base layer as a full version of Ubuntu. The next layers are records of what files are added, updated or deleted in that layer. This then gets repeated each layer so that when you have the final image, the files available are a combination of the base layer and then each layers changes one by one on top.

Example Docker layers showing file changes

When this image is ran as a container:

• All layers are stacked together into a single merged filesystem.
• The topmost container layer (writable) sits on top of the read-only image layers and allows changes at runtime.

Notes about this image:

• The old.json file that is deleted, is not deleted from layer 2 or layer 3 and still exists in these layers, however it records a "whiteout" of that file to hide it from view in layer 4, so the file isn't available in the full unionised file system, but the size of the layers 2 and 3 do not get reduced.
• Each layer only records the added files, edits to files and deleted files, that have changed between then and the layer below it.
• These layers stack together to create the final read-only filesystem used by the container.
• Each layer is a compressed tarball of changes. When Docker builds the image, it:
• • Caches each layer.
  • Stores them in /var/lib/docker/ (or similar) under a unique hash.
  • Reuses layers if nothing in that step has changed.

This is what makes Docker builds so fast and efficient — if layer 3 doesn’t change (the unique hash is the same), Docker reuses it and skips rebuilding everything after that. Also when pulling or pushing to/from remote images, if Docker already has a local copy of a hashed layer, only the changed layers are transferred.

Key Components of a Docker Image

1. Base Image: Most Docker images are built on top of a base image, such as alpine, ubuntu, or node. This base provides the minimal operating system libraries and utilities.
2. Layers: Docker images are built in layers, with each command in a Dockerfile adding a new layer. Layers are cached and reused, which makes builds more efficient and saves storage.
3. Filesystem Snapshot: Every image layer adds or modifies files in the image. These could be application source code, dependencies, or compiled binaries.
4. Metadata: Docker images include configuration metadata like default environment variables, the command to run when the container starts (CMD), ports to expose, and working directory.

Why Docker Images Matter

Docker images solve one of the oldest problems in software development: "It works on my machine." Because the image contains everything required to run the app, the runtime environment is consistent everywhere — whether it’s your laptop, a CI/CD pipeline, or a production server.

Some key benefits:

• Portability: Images can run on any system with Docker installed, regardless of the host OS.
• Reproducibility: Same image, same behaviour every time.
• Version control: Images are versioned and tagged, making rollbacks and deployments traceable.
• Security and isolation: Images run in isolated containers, minimising risk to the host system.

Sharing layers

Multiple images can share the same layers in order to be more efficient, save space and be more performant when pulling images.

If you have an image (image 1) that is made up of layers A, B and C, and another image (image 2) that is made up of layers A, B and D. Docker will know through the unique hashes that when it needs to pull image 2, that because it already has a local copy of image 1, that it only needs to pull the D layer and reuse the layers A and B.

Tagging Images

In Docker, image tagging is a way to assign human-readable labels (tags) to specific image versions. Images are typically tagged at build time using the -t flag with docker build, and can have multiple tags pointing to the same image ID. Common practice is to tag images with a version number (e.g., myapp:1.2.3) and also with the latest tag to indicate the default or most recent version. However, the latest tag is not automatically updated — it must be manually applied during the build or push process. When you tag a new image as latest, Docker simply updates the pointer so that latest now refers to the new image, and the previous image no longer holds that tag (though it still exists with any other version tags it has). It's important to note that latest doesn’t always mean the newest version — it just refers to the image that was most recently tagged with latest. When pulling an image without specifying a tag (e.g., docker pull myapp), Docker defaults to myapp:latest. If no image is tagged as latest, the pull will fail. This makes consistent tagging and version management essential for reliable deployments.

Multi-architecture images

By default, when you build a Docker image, it is built for the architecture of the system where the build takes place.

For example, if you're building on an M1 Mac, the image will typically be built for ARM64 (linux/arm64). On a typical Intel/AMD machine, it will build for x86_64 (linux/amd64).

This means that the resulting image may not run properly on machines with a different CPU architecture.

However, by using multi-architecture builds (with tools like docker buildx), you can produce a single image tag that supports multiple architectures, such as:

• linux/amd64 (Intel/AMD PCs, most servers)
• linux/arm64 (Apple Silicon, Raspberry Pi, AWS Graviton)
• Others like arm/v7, s390x, or even windows/amd64

Docker uses a manifest list to map these builds to a single image tag (e.g. myapp:latest). When someone pulls that image, Docker automatically fetches the correct variant for their system.

Windows and Linux Docker images

You can create images based off both Windows file systems and Linux based file systems, although Windows based images are a lot less common.

Windows and Linux Docker images are fundamentally different due to the distinct nature of their underlying operating systems. While they share the same Docker tooling and concepts (images, containers, volumes, etc.), their execution environments and image contents diverge significantly.

The biggest difference is that Docker containers rely on the host system’s kernel, because containers are not full virtual machines — they share the host OS kernel to run isolated processes.

• Linux containers use the Linux kernel and depend on Linux system libraries, filesystems, and tooling.
• Windows containers require the Windows kernel, and can only run on Windows systems (with very specific version matching, especially for process-isolated containers).

Because of this kernel dependency, you cannot run a Windows container on a Linux host, and vice versa — unless you're using virtualisation or an abstraction layer like WSL2 on Windows.

A Linux Docker image might include:

• A stripped-down Linux filesystem (e.g., Alpine, Debian, Ubuntu)
• POSIX-compatible utilities
• Package managers like apt, apk, or yum

A Windows Docker image, by contrast, includes:

• A minimal Windows base image (like mcr.microsoft.com/windows/servercore)
• PowerShell or CMD-based tooling
• Windows-specific binaries and DLLs

Because Windows images must ship more OS components (and due to the size of Windows itself), they are often much larger than Linux images — sometimes several GBs compared to just MBs for something like Alpine Linux.

You can use Docker Desktop on windows to run standard Linux based containers though. It does so by running a Linux VM behind the scenes.