Shulou(Shulou.com)06/02 Report--

I. Overview

The docker image is built in a hierarchical design, each layer is called "layer", and the layer is stored in the / data/docker/ storage driver / directory

These storage drivers are, AUFS,OverlayFS, etc., you can view the storage driver through the docker info command, centos7.1+ uses OverlayFS mode by default.

II. Introduction to OverlayFS

OverlayFS is a stacked file system, built on top of other file systems, and does not participate in the underlying partition of the disk. It just "merges" the underlying file system directories, which is actually a pseudo-merge, but presents to the user as if a file system structure, that is, joint mount technology, which is faster and easier to implement than AUFS,OverlayFS, because OverlayFS is only divided into two layers, read-only layer. And the read-write layer, the Linux kernel provides two kinds of OverlayFS drivers for Docker: overlay and overlay2. Overlay2 is an improvement over overlay and is more effective than overlay in terms of inode utilization. But overlay has environmental requirements: docker version 17.06.02, host file system needs to be in ext4 or xfs format.

Joint mount technology:

Overlayfs is implemented through three directories: lower directory, upper directory, and work (do not quite understand how this directory works) directory, in which lower directory can be multiple, work directory is the working basic directory, after mounting, the content will be emptied, and its contents will not be visible to users during use. Finally, the unified view presented to users by joint mount is called merged directory. The following uses mount to demonstrate how it works

Then use mount to jointly mount to / tmp/test:

Mount-t overlay overlay-o lowerdir=A:B,upperdir=C,workdir=worker / tmp/test

After mounting, the three directories will be merged into one, and the files with the same file name will be "overwritten". The overwrite is not a real overwrite, but when the two file names in the directory are the same, the merged (/ tmp/test) layer directory will display the files of the nearest layer (lowerdir=A:B,An is closest to him).

Take a look at the mount:

Overlay driver model of docker official website:

In the above figure, you can see three layer structures, namely: lowerdir, uperdir, and merged, where lowerdir is read-only image layer, which is actually rootfs. Compared with the directories An and B shown above, we know that image layer can be divided into many layers, so the corresponding lowerdir can have multiple directories. Upperdir is a layer above lowerdir, which is the read-write layer, which is created when a container is started, and all changes to the container data occur in this layer. Compare with C in the example. Finally, the merged directory is the mount point of the container, that is, a unified perspective exposed to the user, comparing the / tmp/test in the example. The docker directory layer is stored in / var/lib/docker/overlay2/ or / var/lib/docker/overlay/ (if overlay is used)

Container example:

Create a container:

Docker run-it centos / bin/bash

Check the mount status:

How does overlay work when the container modifies data?

Read:

1. If the file is in the container layer (upperdir), read the file directly

two。 If the file is not in the container layer (upperdir), read from the mirror layer (lowerdir)

Write:

1. Write for the first time: if it does not exist in upperdir, overlay and overlay2 perform the copy_up operation to copy the file from lowdir to upperdir. Since overlayfs is file-level (even if there are only a few modifications to the file, it will produce the behavior of copy_up), subsequent write operations on the same file here will operate on the copy of the file that has been copied to the container. This is often called copy-on-write (copy on write).

two。 Delete files and directories: when files are deleted in the container, create whiteout files in the container layer (upperdir). Files in the mirror layer (lowerdir) will not be deleted because they are read-only, but the without file will prevent them from displaying that when the directory is deleted in the container, there is an opaque directory in the container layer (upperdir), which, like the above whiteout principle, prevents users from continuing access, even if the mirror layer still exists.

Note:

The 1.copy_up operation only occurs when the file is written for the first time, and only the copy is modified later.

two。 The deletion of the file in the container layer is only pseudo-deletion, which is obscured by the whiteout file, but the image layer is not deleted. This is why the image submitted and saved using docker commit will become larger and larger. No matter how the data is deleted in the container layer, the image layer will not change.

Process demonstration:

It is found that the modification occurs only in the C directory, that is, in the upperdir layer.

Third, overlay2 image storage structure

Docker pull ubuntu

Four-tier layer storage location:

There is an extra l directory that contains soft links for all layers, and short links use short names to prevent the parameters from reaching the page size limit when mount (the short directory when viewing the mount command in the demonstration).

The underlying image directory contains a diff and a link file. The diff directory stores the mirror contents of the current layer, and the link file is the corresponding short name.

The image above also includes the work directory and the lower file, the lower file is used to record the short name of the parent layer, and the work directory is used to jointly mount the specified working directory.

The relationship between these directories and mirrors is associated through metadata. Metadata is divided into image metadata and player metadata:

Image mirrors the original data:

The image metadata is stored in the / var/lib/docker/image//imagedb/content/sha256/ directory. The name is a file named after the image ID, and the image ID can be viewed through docker images. These files store the image rootfs information, image creation time, construction history information, containers used, including launched Entrypoint and CMD, and so on, in the form of json:

Ubuntu Mirror id

Enter the mirror metadata directory

Cd / data/docker/image/overlay2/imagedb/content/sha256/

Vim 775349758637aff77bf85e2ff0597e86e3e859183ef0baba8b3e8fc8d3cba51c

The diff_id above corresponds to a mirror layer, which is also arranged sequentially, representing the lowest layer to the top layer of the mirror layer from top to bottom.

Docker uses each diff_id and historical information in rootfs to calculate the corresponding content addressing index (chainID), while chaiID associates the layer layer, which in turn relates to the mirror file of each mirror layer.

Layer metadata:

The mirror layer contains only one specific mirror layer package. After a user downloads a mirror layer on the docker host, docker will build local layer metadata, including diff, parent, size, etc., on the host based on the mirror layer package and image metadata. When docker uploads the new mirror layer generated on the host computer to registry, the metadata on the host associated with the new mirror layer will not be packaged and uploaded with the mirror layer. Layer and RWLayer are defined in Docker, which are used to define some operations of read-only layer and read-write layer respectively, and roLayer and mountedLayer are defined to implement the above two interfaces respectively. Among them, roLayer is used to describe the immutable mirror layer, and mountedLayer is used to describe the container layer that can read and write. Specifically, the contents stored by the roLayer mainly include the chainID indexing the mirror layer, the check code diffID of the mirror layer, the parent mirror layer parent, the cacheID of the current mirror layer file stored by storage_driver, the size of the mirror layer, and so on. This metadata is stored in the

There will be three files cache-id, diff, size in each chainID directory

Cache-id file:

The uuid randomly generated by docker is the directory index that holds the mirror layer, that is, the directory in / var/lib/docker/overlay2/, which is why the corresponding layer directory can be found through chainID. The directory corresponding to chainID as 565879c6effe6a013e0b2e492f182b40049f1c083fc582ef61e49a98dca23f7e is 0b7bbc608eca835ac9bdb31a1794016a8fd1dacc8f58fbcf2763db1dc40d3f32, which is stored in / data/docker/overlay2/0b7bbc608eca835ac9bdb31a1794016a8fd1dacc8f58fbcf2763db1dc40d3f32

Diff file:

Saved the diff_id in the mirror metadata (corresponding to the uuid in the diff_ids in the metadata

Size file:

Saves the size of the mirror layer

Among all the attributes of layer, diffID uses the SHA256 algorithm and is calculated based on the contents of the mirror layer package. ChainID is an index based on content storage, which is calculated based on the diffID of the current layer and all ancestral mirror layers, as follows:

1. If the mirror layer is the lowest layer (there is no parent mirror layer), the diffID of that layer is chainID

two。 The chainID calculation formula of the mirror layer is chainID (n) = SHA256 (chain (nMuth1) diffID (n)), that is, according to the chainID of the parent mirror layer, add a space and the diffID of the current layer, and then calculate the SHA256 check code.

The readable init layer and container mount point information stored in mountedLayer information include: container init layer ID (init-id), ID used for joint mount (mount-id), and chainID (parent) of the parent layer image of the container layer. The related files are located in the / var/lib/docker/image//layerdb/mounts// directory

You can see that initID adds a-init after mountID, and initID is the directory name stored in / var/lib/docker/overlay2/:

To view mountID, you can also view the corresponding mounted mountID directly through the mount command, which corresponds to the / data/docker/overlay2/ directory, which is also the merged directory rendered by overlayfs.

Create a file in the container and you will see it in the merged directory:

About the init layer:

The init layer ends with a uuid+-init, sandwiched between the read-only layer and the read-write layer, and is used to store / etc/hosts, / etc/resolv.conf and other information. The reason for this layer is that when the container starts, these files or directories that should belong to the image layer, such as hostname, need to be modified by the user, but the image layer is not allowed to modify, so a separate init layer is mounted at startup. The purpose of modifying these files is achieved by modifying the files in the init layer. These changes tend to take effect only from the current container, and the init layer will not be committed when the docker commit is submitted as a mirror. The file on this layer is stored in / data/docker/overlay2//diff.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.