DOCKER - 4 7 Launch of build Docker

In this lesson we look at image layers — one of the most fundamental concepts behind Docker. Internally, images use a Union File System that stacks a sequence of filesystem changes into what looks like a single coherent filesystem. We'll use docker image history and docker image inspect to peek under the hood, then see why a running container is really just one extra layer on top of an image.

Layers, history and inspect

When you run docker pull, you've probably noticed messages saying parts of the image are already cached. That's because images aren't monolithic blobs — they're built from layers tracked by the Union File System. Let's list our local images with docker image ls (Nginx, for instance, may appear under multiple tags sharing the same image ID) and then ask for its history:

docker image history nginx

This is not a list of things that happened inside a container — it's the history of the image's layers. Every image starts from an empty layer called scratch; every subsequent filesystem change adds another layer on top. Some layers add lots of files (the base distro, ~80 MB), others are zero-byte metadata changes recorded by Dockerfile instructions like CMD or EXPOSE. Running history on another image (say Mongo) reveals a totally different stack of layers with their own timestamps, showing when each layer was last rebuilt on Docker Hub.

The label <missing> next to some layers is just a UI quirk — it doesn't mean anything is wrong, only that intermediate layers don't carry their own image ID, they only exist inside this image. To dive deeper into metadata, use:

docker image inspect nginx

This returns the metadata side of the image: the image ID and tags, the default CMD and entrypoint, environment variables, exposed ports, the author, and the architecture (e.g. amd64). Many of these defaults can be overridden at run time with docker container run options.

  • Layers are stored once per host — shared between images that reuse them, saving disk space and bandwidth
  • Each Dockerfile instruction creates a new layer
  • A running container is itself just a thin writable layer on top of the image stack
  • history shows the layer story; inspect shows the metadata

In short: images aren't as opaque as they seem. They're an ordered set of filesystem deltas plus metadata. The same layer reused by ten images still only occupies disk space once, and a container only adds one cheap writable layer at the top. That's what makes pulls, pushes and container starts so fast.

Summary

This lesson explores Docker image layers and composition using the UnionFS (Union File System) concept. You'll learn how Docker images are built from multiple layers of file system modifications and metadata, and how the docker history and docker inspect commands reveal this structure. Containers are presented as an additional write layer on top of an existing image, enabling efficient storage and transfer.

Key points

  • Docker images are composed of layers representing successive modifications to a file system, starting from a blank base layer called scratch
  • The UnionFS allows Docker to present multiple layer modifications as a single unified file system
  • docker history displays all layers that make up an image, including metadata-only changes like entrypoint commands
  • docker inspect reveals image metadata such as environment variables, default commands, architecture (amd64), and author information
  • Each layer is stored only once on the system, allowing significant space savings and efficient image transfers between registries
  • Containers function as a writable layer on top of existing images, making them typically very small compared to the underlying image

FAQ

What is the UnionFS and why does Docker use it?

UnionFS (Union File System) is a technology that layers multiple file system modifications and presents them as a single unified file system. Docker uses it to efficiently compose images from multiple layers, saving storage space since each layer is stored only once on the system, and enabling fast transfer of images between registries.

What is the difference between docker history and docker inspect?

docker history shows a chronological list of all layers that make up an image, displaying which modifications were made at each layer and their sizes. docker inspect reveals the metadata and configuration details of an image, including environment variables, default commands, and how the image should be executed.

Why are containers much smaller than the images they are based on?

Containers are just a writable layer of modifications on top of an existing image. Since the base image is already available and stored, the container only needs to store the changes made within it, making it typically very small compared to the entire image.