Docker Containers and Images : Part 2

In last article we figured out that the docker run creates a thin R/W layer on top of underlying image layers and each docker run creates its own thin R/W layer. All the changes that container makes will be written on this thin R/W layer.

Ideally, very little data is written to a container’s writable layer, and we use Docker volumes to write data. However, some workloads require us to be able to write to the container’s writable layer. This is where storage drivers come in.

Docker supports several different storage drivers. The storage driver controls how images and containers are stored and managed on your Docker host. Some of them are overlay2, aufs, devicemapper, btrfs, zfs, vfs. overlay2 is default one that docker uses now a days.

How overlay2 Works

OverlayFS layers two directories on a single Linux host and presents them as a single directory. These directories are called layers and the unification process is referred to as a union mount. OverlayFS refers to the lower directory as lowerdir(image) and the upper directory a upperdir(container). The unified view is exposed through its own directory called merged.

The overlay2 driver natively supports up to 128 lower OverlayFS layers. So Thats why we have seen people using && to combine RUN commands and decrease the number of layers as we already know that each command creates new layer on top of existing one. Run docker info command to check your storage driver.

How container reads and writes work with overlay2

Consider three scenarios where a container opens a file for read access with overlay.

• The file does not exist in the container layer: If a container opens a file for read access and the file does not already exist in the container (upperdir) it is read from the image (lowerdir). This incurs very little performance overhead.
• The file only exists in the container layer: If a container opens a file for read access and the file exists in the container (upperdir) and not in the image (lowerdir), it is read directly from the container.
• The file exists in both the container layer and the image layer: If a container opens a file for read access and the file exists in the image layer and the container layer, the file’s version in the container layer is read. Files in the container layer (upperdir) obscure files with the same name in the image layer (lowerdir).

Modifying files or directories

Consider some scenarios where files in a container are modified.

• Writing to a file for the first time: The first time a container writes to an existing file, that file does not exist in the container (upperdir). The overlay2 driver performs a copy_up operation to copy the file from the image (lowerdir) to the container (upperdir). The container then writes the changes to the new copy of the file in the container layer.
• However, OverlayFS works at the file level rather than the block level. This means that all OverlayFS copy_up operations copy the entire file, even if the file is very large and only a small part of it is being modified. This can have a noticeable impact on container write performance. However, The copy_up operation only occurs the first time a given file is written to. Subsequent writes to the same file operate against the copy of the file already copied up to the container.

Deleting files and directories:

• When a file is deleted within a container, a whiteout file is created in the container (upperdir). The version of the file in the image layer (lowerdir) is not deleted (because the lowerdir is read-only). However, the whiteout file prevents it from being available to the container.
• When a directory is deleted within a container, an opaque directory is created within the container (upperdir). This works in the same way as a whiteout file and effectively prevents the directory from being accessed, even though it still exists in the image (lowerdir).

References

https://docs.docker.com/storage/storagedriver/