Registry 容器镜像服务端细节

时间 2021-05-20

标签 html git github docker json api 安全 app 优化 spa 栏目 HTML 繁體版

原文原文链接

引言

一般咱们在使用集群或者容器的时候，都会接触到存储在本地的镜像，也或多或少对本地镜像存储有必定的了解。可是服务端的镜像存储细节呢？本文主要介绍容器镜像的服务端存储结构，对于自建镜像服务或是对容器镜像底层原理或优化有兴趣的同窗能够了解一下。html

镜像细节

在了解服务端以前，咱们来了解一下客户端的镜像容器的存储环境。docker

联合文件系统 UnionFS(Union File System)

Docker的存储驱动的实现是基于UnionFS。简单列举一下UnionFS下存储镜像的一些特色。json

首先，UnionFS是一个分层的文件系统。一个Docker镜像可能有多个层组成（注意他们是有顺序的）。api

其次，只有顶层是可写的，其它层都是只读的。这样的机制带来的好处是镜像层能够被多个镜像共享。对于Docker镜像来讲，全部层都是只读的。当一个镜像运行时，会在该镜像上增长一个容器层。十个相同的镜像启动，仅仅是增长十个容器层。销毁容器时也仅仅是销毁一个容器层而已。安全

UnionFS是一个分层的文件系统。一个Docker镜像可能有多个层组成（注意他们是有顺序的）。
只有顶层是可写的，其它层都是只读的。这样的机制带来的好处是镜像层能够被多个镜像共享。对于Docker镜像来讲，全部层都是只读的。当一个镜像运行时，会在该镜像上增长一个容器层。十个相同的镜像启动，仅仅是增长十个容器层。销毁容器时也仅仅是销毁一个容器层而已。
- 当容器须要读取文件的时候：从最上层镜像开始查找，往下找，找到文件后读取并放入内存，若已经在内存中了，直接使用。(即，同一台机器上运行的docker容器共享运行时相同的文件)。
- 当容器须要添加文件的时候：直接在最上面的容器层可写层添加文件，不会影响镜像层。
- 当容器须要修改文件的时候：从上往下层寻找文件，找到后，复制到容器可写层，而后，对容器来讲，能够看到的是容器层的这个文件，看不到镜像层里的文件。容器在容器层修改这个文件。
- 当容器须要删除文件的时候：从上往下层寻找文件，找到后在容器中记录删除。即，并不会真正的删除文件，而是软删除。这将致使镜像体积只会增长，不会减小。

由此能够思考不少安全和镜像优化上的问题。app

在镜像构建中记录敏感信息而后再下一个构建指令中删除安全吗？（不安全）
在镜像构建中安装软件包而后再下一个构建指令中清理软件包能减少镜像体积吗？（并不能）

UnionFS通常有两种实现方案：1. 基于文件实现。文件总体的覆盖重写。2. 基于块实现，对文件的修改只修改少许块。优化

镜像的服务端存储细节

提供一个镜像元信息(manifest)用于参考：spa

➜  ~ 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,         "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"      }   ]}

*接下来是本文最为重要的内容，经过对上面这张图的理解，咱们就能够了解到Registry服务端存储的细节。*

图中蓝色的是服务端存储的目录。文字是目录名称，这个名称是固定的。
图中紫色的是服务端存储的文件。文字是文件名称，link文件的内容都是一个sha256的哈希值。data文件存储了真正的元文件和镜像层。
图中橙色的是服务端的动态目录。目录的名称和仓库名、镜像标签或者sha256有关的。

整个图是从上往下的。举个例子，咱们上面描述的manifest若是是存储在服务端的话（文件哈希:sha256:e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419）。它存储的路径应该是：/docker/registry/v2/blobs/sha256/e8/e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419/data。对应图上应该是沿着左侧一直向下。

咱们开始拆解分析其结构细节。

左侧是镜像全部内容的实际存储，其几乎占据的绝大部分储存的空间，包括了镜像层和镜像元信息Manifest。
- 例如镜像层sha256:e80174c8b43b97abb6bf8901cc5dade4897f16eb53b12674bef1eae6ae847451的存储位置，应该在/docker/registry/v2/blobs/sha256/e8/e80174c8b43b97abb6bf8901cc5dade4897f16eb53b12674bef1eae6ae847451/data

右侧是镜像元信息存储的地方。镜像元信息是按照命名空间和仓库名称分两级目录存储的。
- 每个仓库下面又分为_layers、_manifests两个部分
- _layers负责记录该仓库引用了哪些镜像层文件。
- _manifests负责记录镜像的元信息
- - revisions包含了仓库下曾经上传过的全部版本的镜像元信息
  - tags包含了仓库中的全部标签
  - - current记录了当前标签指向的镜像
    - index目录则记录了标签指向的历史镜像。
- 对上述提供的manifest计算sha256，会获得元信息文件的哈希值sha256:e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419，这个元信息的存储位置应该在/docker/registry/v2/blobs/sha256/e8/e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419/data

举个镜像下载的例子：

咱们想要知道ccr.ccs.tencentyun.com/paas/service-controller:7b1c981c这个镜像如今的元信息，如何在服务端存储中找到。

找到/docker/registry/v2/paas/service-controller/_manifests/tags/7b1c981c/current/link文件。里面有元信息的sha256信息。内容应该是sha256:e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419
找到实际存储文件（/docker/registry/v2/blobs/sha256/e8/e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419/data）。前文中给出了该文件的json内容。
根据源文件信息，客户端依次下载对应文件就能够了。（鉴权过程参考参考文档）

ImageConfig
sha256:785f4150a5d9f62562f462fa2d8b8764df4215f0f2e3a3716c867aa31887f827
ImageLayer
sha256:e80174c8b43b97abb6bf8901cc5dade4897f16eb53b12674bef1eae6ae847451 sha256:d1072db285cc5eb2f3415891381631501b3ad9b1a10da20ca2e932d7d8799988 sha256:858453671e6769806e0374869acce1d9e5d97f5020f86139e0862c7ada6da621 sha256:3d07b1124f982f6c5da7f1b85a0a12f9574d6ce7e8a84160cda939e5b3a1faad sha256:994dade28a14b2eac1450db7fa2ba53998164ed271b1e4b0503b1f89de44380c sha256:60a5bd5c14d0f37da92d2a5e94d6bbfc1e2a942d675aee24f055ced76e8a208f

Tips:

很明显一样的镜像层文件在存储中只会有一个副本。使用相同基础镜像将节省大量的存储成本。
若是想要算上述元信息文件的哈希值，请保证你复制的文件内容尾部没有EOL。[noeol]

基于存储的几个问题

镜像构建如何优化？

根据UnionFS的特性，针对性的进行优化：

构建时，一个构建指令会生成一个镜像层，尽可能避免在镜像层中出现垃圾文件，例如在安装软件以后删除软件包。
删除敏感资源并不能使得该内容真正消失，避免敏感内容形成的安全问题。例如编译镜像最后删除代码是无效的欺骗本身的行为。
经过多阶段构建，减小中间产物以及编译环境中的依赖内容。

上传到服务端镜像，再上传到其余仓库须要从新上传吗？

须要，在Registry的设计中仓库是权限的最小单位，用户是根据仓库进行权限管理与隔离的。考虑若是这里忽略了这一块的设计，镜像层存在就避免重复上传的话，客户端能够经过构造虚假镜像元信息的方式，越权获取到其余用户的镜像。_layers中记录了仓库有权限获取的全部镜像层的目的就在于此。

镜像复制场景下如何优化？

复制镜像的场景和上传场景的区别在于，源镜像是用户确实已经拥有的。这里能够经过上述问题的思考进行复制的优化，当镜像层在目的地址已经存在时，直接标记仓库拥有该层避免没必要要的上传。

镜像历史版本

根据存储结构的特色，能够较为轻松的回答这个问题。理论上只要不作Registry GC，不删除仓库元信息，仓库历史版本的镜像都会在仓库中一直保存的。

怎么拿到镜像的元信息？

这里不作详细讲解了，有兴趣的同窗能够参考如下文档：

DockerRegistry API V2——https://docs.docker.com/regis...
Docker Registry TokenAuthentication Specification——https://docs.docker.com/regis...
DockerImage Manifests V2 Schema2——https://docs.docker.com/regis...

云服务的存储对接

Registry做为一个开源软件，适配各类云存储产品属于标配功能了。Registry提供了标准的存储驱动接口，只要实现了这一套接口就能适配运行起来了。

为何有了Docker registry还须要Harbor？——https://cloud.tencent.com/dev...
理解Docker镜像分层——https://www.cnblogs.com/woshi...
Docker Registry 存储驱动——https://docs.docker.com/regis...

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！