Container Storage

A container starts with a filesystem assembled from image layers. It also gets a thin writable layer for changes made while it runs.

That writable layer makes the container usable. It does not make the container a safe home for durable data.

Container storage is the practice of deciding where each kind of runtime data belongs. The key choice is between container-local state and mounted storage.

The first mental model

Picture a container filesystem as two parts:

mounted storage       selected paths with separate lifecycles
------------------    ---------------------------------------
container view    =   image layers + writable layer + mounts
                      read-only      container-local  external

Image layers supply the starting files. The writable layer records runtime changes. Mounts place other storage at chosen paths inside the container.

All three appear in one directory tree to the application. Their lifecycles and operational properties differ.

The writable layer

Every container gets its own writable layer above the image's read-only layers. New files and changed files appear there.

Storage drivers implement this layered view. Many use copy-on-write. A read can use an unchanged file from a lower image layer.

The first modification copies that file into the writable layer. Later changes affect the copy, not the image layer below it.

This design saves space when many containers share one image. Each container stores only its own changes.

The writable layer follows the container. Removing the container removes that layer. A replacement container starts with a fresh writable layer.