Shulou(Shulou.com)05/31 Report--

Today, I would like to share with you the relevant knowledge about how to implement the Registr container image server. The content is detailed and the logic is clear. I believe most people still know too much about this, so share this article for your reference. I hope you can get something after reading this article. Let's learn about it.

Related open source projects

Currently, there are two main open source projects related to container image service.

Registry

Harbor

Registry has the basic ability of uploading and downloading images and interfacing with third-party authentication. Harbor has made corresponding enterprise-level expansion projects based on Registry. It provides more permissions, auditing, mirroring and other functions, and is currently one of the CNCF incubation projects. Refer to the relevant articles for other details. This article focuses on the storage details of the Registry project.

Mirror details

Before we look at the server, let's take a look at the storage environment of the client's mirror container.

Federated file system UnionFS (Union File System)

The storage-driven implementation of Docker is based on UnionFS. Briefly list some of the characteristics of storage mirrors under UnionFS.

First, UnionFS is a hierarchical file system. A Docker image may consist of multiple layers (note that they are in order).

Second, only the top layer is writable and the other layers are read-only. The advantage of this mechanism is that the mirror layer can be shared by multiple mirrors. For Docker mirrors, all layers are read-only. When a mirror is running, a container layer is added to the image. Ten identical images are started, only ten container layers are added. When you destroy a container, you only destroy a container layer.

UnionFS is a hierarchical file system. A Docker image may consist of multiple layers (note that they are in order).

Only the top layer is writable and the other layers are read-only. The advantage of this mechanism is that the mirror layer can be shared by multiple mirrors. For Docker mirrors, all layers are read-only. When a mirror is running, a container layer is added to the image. Ten identical images are started, only ten container layers are added. When you destroy a container, you only destroy a container layer.

When the container needs to read the file: start with the top image, look down, find the file, read it and put it in memory. If it is already in memory, use it directly. That is, docker containers running on the same machine share the same files at run time.

When the container needs to add a file: add the file directly to the writeable layer of the top container layer without affecting the mirror layer.

When the container needs to modify the file: look for the file from top to bottom, find it, copy it to the writable layer of the container, and then, for the container, you can see the file in the container layer, but not the file in the mirror layer. The container modifies the file at the container layer.

When the container needs to delete the file: look for the file from the top to the bottom, and record the deletion in the container after finding it. That is, the file is not actually deleted, but soft deleted. This will cause the mirror volume to only increase, not decrease.

As a result, you can think about a lot of security and mirror optimization issues.

Is it safe to record sensitive information in the mirror build and then delete it in the next build instruction? (not safe)

Can installing the package in the image build and then cleaning the package in the next build instruction reduce the image size? (not able to)

Generally speaking, there are two implementation schemes for UnionFS: 1. File-based implementation. Overwrite and rewrite the file as a whole. two。 Based on the block implementation, changes to the file modify only a small number of blocks.

Server storage details of the image

Provide an image meta-information (manifest) for reference:

➜~ docker pull ccr.ccs.tencentyun.com/paas/service-controller:7b1c981c7b1c981c: Pulling from paas/service-controllerDigest: sha256:e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419Status: Image is up to date for ccr.ccs.tencentyun.com/paas/service-controller:7b1c981cccr.ccs.tencentyun.com/paas/service-controller:7b1c981c {"schemaVersion": 2, "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "config": {"mediaType": "application/vnd.docker.container.image.v1+json" "size": 4671, "digest": "sha256:785f4150a5d9f62562f462fa2d8b8764df4215f0f2e3a3716c867aa31887f827"}, "layers": [{"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip", "size": 44144090, "digest": "sha256:e80174c8b43b97abb6bf8901cc5dade4897f16eb53b12674bef1eae6ae847451"}, {"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip" "size": 529, "digest": "sha256:d1072db285cc5eb2f3415891381631501b3ad9b1a10da20ca2e932d7d8799988"}, {"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip", "size": 849, "digest": "sha256:858453671e6769806e0374869acce1d9e5d97f5020f86139e0862c7ada6da621"}, {"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip" "size": 170,170 "digest": "sha256:3d07b1124f982f6c5da7f1b85a0a12f9574d6ce7e8a84160cda939e5b3a1faad"}, {"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip", "size": 8461461, "digest": "sha256:994dade28a14b2eac1450db7fa2ba53998164ed271b1e4b0503b1f89de44380c"}, {"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip" "size": 22178452, "digest": "sha256:60a5bd5c14d0f37da92d2a5e94d6bbfc1e2a942d675aee24f055ced76e8a208f"}, {"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip", "size": 22178452, "digest": "sha256:60a5bd5c14d0f37da92d2a5e94d6bbfc1e2a942d675aee24f055ced76e8a208f"]}

* next is the most important part of this article. Through the understanding of the figure above, we can understand the details of Registry server storage. *

The blue one in the figure is the directory stored on the server side. The text is the directory name, which is fixed.

The purple one in the figure is the file stored on the server side. The text is the name of the file, and the content of the link file is a hash of sha256. Data files store real metafiles and mirror layers.

The orange in the picture is the dynamic directory on the server side. The name of the directory is related to the repository name, image tag, or sha256.

The whole picture is from top to bottom. For example, the manifest we described above is stored on the server side (file hash: sha256:e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419). The path it stores should be: / docker/registry/v2/blobs/sha256/e8/e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419/data. The corresponding picture should be all the way down on the left.

We began to disassemble and analyze the structural details.

On the left is the actual storage of all the mirrored content, which occupies almost most of the storage space, including the mirror layer and mirror meta-information Manifest.

For example, the storage location of the mirror layer sha256:e80174c8b43b97abb6bf8901cc5dade4897f16eb53b12674bef1eae6ae847451 should be in / docker/registry/v2/blobs/sha256/e8/e80174c8b43b97abb6bf8901cc5dade4897f16eb53b12674bef1eae6ae847451/data

On the right is the place where the mirror meta-information is stored. The image meta-information is stored in a two-level directory according to the namespace and warehouse name.

Revisions contains the image meta information of all versions that have been uploaded under the repository.

Tags contains all the tags in the warehouse

Current records the image pointed to by the current label

The index directory records the historical image that the label points to.

Each warehouse is divided into _ layers and _ manifests parts.

_ layers is responsible for recording which mirror layer files are referenced by the repository.

_ manifests is responsible for recording the meta-information of the image

Calculate the sha256 for the manifest provided above, and you will get the hash value sha256:e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419 of the meta-information file, which should be stored in / docker/registry/v2/blobs/sha256/e8/e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419/data.

Take an example of a mirror download:

We want to know how the meta-information of the ccr.ccs.tencentyun.com/paas/service-controller:7b1c981c image can be found in the server storage.

Locate the / docker/registry/v2/paas/service-controller/_manifests/tags/7b1c981c/current/link file. Sha256 information with meta information in it. The content should be sha256:e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419.

Find the actual storage file (/ docker/registry/v2/blobs/sha256/e8/e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419/data). The json content of the file is given earlier.

According to the source file information, the client can download the corresponding file in turn. (reference documentation for authentication process)

ImageConfig

Sha256:785f4150a5d9f62562f462fa2d8b8764df4215f0f2e3a3716c867aa31887f827

ImageLayer

Sha256:e80174c8b43b97abb6bf8901cc5dade4897f16eb53b12674bef1eae6ae847451 sha256:d1072db285cc5eb2f3415891381631501b3ad9b1a10da20ca2e932d7d8799988 sha256:858453671e6769806e0374869acce1d9e5d97f5020f86139e0862c7ada6da621 sha256:3d07b1124f982f6c5da7f1b85a0a12f9574d6ce7e8a84160cda939e5b3a1faad sha256:994dade28a14b2eac1450db7fa2ba53998164ed271b1e4b0503b1f89de44380c sha256:60a5bd5c14d0f37da92d2a5e94d6bbfc1e2a942d675aee24f055ced76e8a208f

Tips:

It is obvious that there will be only one copy of the same mirror layer file in storage. Using the same basic image will save a lot of storage costs.

If you want to calculate the hash value of the above meta-information file, please make sure that there is no EOL at the end of the file you copied. [noeol]

How to optimize the image construction based on several storage problems?

According to the characteristics of UnionFS, targeted optimization:

When building, a build instruction generates a mirror layer to avoid junk files in the mirror layer, such as removing packages after installing the software.

Deleting sensitive resources does not make the content really disappear and avoid the security problems caused by sensitive content. For example, the final deletion of the code in the compiled image is an invalid act of deceiving yourself.

Through multi-stage build, reduce the dependency content in the intermediate product and compilation environment.

Do I need to re-upload it to the server image and then to other warehouses?

* * Yes, in the design of Registry, the warehouse is the minimum unit of permissions, and users manage and isolate permissions according to the warehouse. * * consider that if the design of this part is ignored here and the existence of the image layer avoids repeated upload, the client can obtain the images of other users without authorization by constructing false image meta-information. This is the purpose of recording all mirror layers that the warehouse has permission to access in _ layers.

How to optimize in a mirror replication scenario?

The difference between copying an image and uploading a scenario is that the source image is actually owned by the user. Here, we can optimize the replication through the consideration of the above problems. When the image layer already exists in the destination address, directly mark the repository to own this layer to avoid unnecessary upload.

Mirror historical version

According to the characteristics of the storage structure, this question can be answered more easily. In theory, as long as the Registry GC is not done and the repository meta-information is not deleted, the image of the repository history version will always be saved in the repository.

Storage docking of cloud services

As an open source software, Registry is a standard function to adapt to a variety of cloud storage products. Registry provides a standard storage driver interface, as long as the implementation of this set of interfaces can be adapted to run.

These are all the contents of the article "how to implement the Registr container image server". Thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.

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.