In our last post, you ran your very first container. You saw how quickly Docker could start an Nginx web server. But what makes containers so fast and lightweight? The answer lies in how Docker builds and manages its core components: Images and Layers.

1. The Relationship: Image vs. Container Think of it like programming:

A Docker Image is the class (the blueprint). It’s a static, read-only set of instructions and components.

A Docker Container is the object (the instance). It’s the running environment created from that image, complete with a thin, writable layer on top.

2. The Magic: The Layered Filesystem The core efficiency of Docker comes from its layered structure.

Docker Images are not monolithic files; they are built up from a stack of read-only layers.

How layers are created: Every instruction in a Dockerfile (which we’ll cover in the next post) generally creates a new layer. For example, installing a package or copying a file creates a layer.

The Union File System: Docker uses a Union File System (like Overlay2) to merge all these read-only layers together, making it look like a single, complete filesystem to the user and the running application.

3. The Efficiency: Image Caching This layering system enables incredible efficiency through caching and sharing:

Sharing Base Images: If you have 10 different applications that all use the same base operating system (e.g., Alpine Linux), the base OS layer is only stored once on your system, even though 10 different images reference it. This saves significant disk space.

Content-Addressable Storage: Every layer is identified by a unique cryptographic hash (SHA256). Docker checks this hash to see if the layer already exists locally. If it does, Docker reuses it instead of pulling it again from the registry. This is the power of image caching.

Fast Updates: When you rebuild an image, Docker only rebuilds the layers after the first command you change. All previous, unchanged layers are pulled directly from the cache, making iteration and rebuilding incredibly fast.

4. The Final Piece: The Container’s Writable Layer When you run an image using docker run, Docker places a final, writable layer on top of the stack of read-only image layers.

Any changes made by the running container (e.g., creating a log file, modifying a setting) are written only to this top writable layer.

This ensures the original image layers remain untouched (immutable). If you stop the container and start a new one, the new container starts with a clean, fresh writable layer, guaranteeing consistency.

The writable layer is ephemeral by default. If you delete the container, you lose the data in this layer. This is why we need Volumes (covered in a future post) for persistent data storage.

5. Inspecting the Layers You can easily see the stack of layers used to build any image on your system using the docker history command.

Let’s inspect the nginx image we used previously:

docker history nginx

You will see output showing the different layers, the size of each, and the command that was executed to create that layer. This gives you direct insight into the image’s construction process, from the base Linux distribution up to the final Nginx configuration.

What’s Next? Now that we understand what an image is and how its efficient, layered structure works, we are ready for the most important part of building applications with Docker: writing our own images!

In Post 4, we will dive deep into the Dockerfile and learn the commands necessary to create efficient, small, and secure images for your own applications.