Painless Docker - 2nd Edition

Images are Layers

Docker images are built in a layered fashion, where each layer represents a distinct piece of the application or its environment. These layers come together to form the final image, but they remain independent and can be reused across different images.

For example, image A has the layers:

• Layer 1: Base OS (e.g., Ubuntu)
• Layer 2: Application dependencies (e.g., Python, libraries)
• Layer 3: Application code (e.g., your Python application)

Image B has the following layers:

• Layer 1: Base OS (e.g., Ubuntu)
• Layer 2: Different application dependencies (e.g., Node.js, libraries)
• Layer 3: Application code (e.g., your Node.js application)

The base OS layer (Layer 1) is shared between images A and B. Even though the application dependencies and code are different, they rely on the same underlying operating system layer. This sharing of layers is one of the key features of Docker, as it allows for optimized storage, faster image builds, pulling and pushing, and reduced redundancy.

In practice, all Docker images are a union of layers. All layers are stacked on top of each other and the base layer is at the bottom (usually a minimal Linux distribution like Alpine, Debian, or Ubuntu). Each layer reflects some change or addition to the layer below it, and is described by a specific instruction in the Dockerfile used to build the image.

The Dockerfile is a text file that contains all the commands a user could call on the command line to assemble an image. Each instruction in the Dockerfile creates a new layer in the image.

An important characteristic of these layers is that once created, they're immutable, meaning they cannot be altered. At runtime, Docker combines these layers into a single unified view to form the complete filesystem for the container. It then adds a writable layer on top of the final layered image to give the container a space where it can write data when needed.

Docker manages these layers using a smart build cache. The cache decision for each Dockerfile instruction depends on the instruction itself and its inputs. If any of those inputs change, the cache for that instruction and all subsequent instructions is invalidated and those layers are rebuilt.

For example, to create the final image A mentioned above, the build process would treat each layer as follows:

• Layer 1: Base OS (e.g., Ubuntu) => Pulled from the cache or registry if not present locally
• Layer 2: Application dependencies (e.g., Python, libraries) => Built or pulled from the cache if unchanged
• Layer 3: Application code (e.g., your Python application) => Built from the latest code changes