Container Images and Layers

Container images package filesystem layers and runtime configuration for creating containers. A container typically adds a writable layer above the image, while persistent data should live outside that layer.

A container image is a packaged filesystem and runtime configuration used to create containers. In OCI image formats, an image manifest references a configuration object and an ordered set of filesystem layers. The configuration can include settings such as the default command, environment variables, and working directory.

Layers represent filesystem changes, such as adding files or recording deletions. They are commonly distributed as compressed archives, and their content is identified by a digest. Multiple images can reuse identical layer content, reducing storage and transfer when the relevant layers are already available.

When a container starts, its runtime makes the image's filesystem layers available as a combined view. It generally adds a writable layer for that container; writes there do not alter the image or automatically appear in other containers. Data that must outlive a container is usually stored in a volume or another persistent storage system.

Build tools can reuse cached steps and layers when inputs have not changed. A change to an earlier build step may invalidate later cached work, so Dockerfile instruction order and build inputs can affect build efficiency. A layer is a filesystem change set, not a separate virtual machine or a guarantee that every file is copied anew.

Key points

• An image packages filesystem layers and configuration; a container is an instance created from it.
• Image manifests reference configuration and filesystem layer objects.
• Layers record filesystem changes and may be reused when their content matches.
• A container's writable layer is separate from the image and is not durable storage.
• Build-step changes can affect reuse of cached layers.

Interview questions

How can image layer caching influence Dockerfile organization?

Build cache reuse depends on whether a build step and its relevant inputs still match a cached result. If an earlier step changes, later steps may need to run again. Separating relatively stable dependency installation from frequently changing application source can improve reuse, provided the build remains correct and reproducible.

What does an image layer represent?

A layer records filesystem changes that contribute to the final image filesystem. Layers are ordered and combined by the container runtime or its storage implementation to present a unified view. Layers can be shared when their content is identical, which helps reduce repeated storage and downloads.

What is the role of a container image manifest?

A manifest is metadata that points to the image configuration and filesystem layers. The configuration describes runtime defaults, while the layers contain filesystem content and changes. Together these objects describe an image without putting all of their contents into the manifest itself.

Where do filesystem changes made by a running container go, and what happens to them when it is removed?

A container's writable layer holds changes made to its filesystem view after creation. Removing the container normally removes that layer, so it is not a suitable place for data that must persist. A volume or external storage should hold persistent application data instead.

What is the difference between a container image and a container?

An image is a packaged template containing filesystem layers and configuration for starting a container. A container is a runtime instance created from that template. The runtime usually adds a writable layer for the instance, so its filesystem changes do not update the image.