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.