一 背景

本文针对镜像的本质从文件系统到内部结构，已经相关开发库进行研究，为后期相关定制性操作进行技术预研。

二 镜像本质

1.1 Base镜像

base镜像的两层含义

• 不依赖其他镜像，从 scratch 构建。
• 其他镜像可以之为基础进行扩展。

所以，能称作 base 镜像的通常都是各种 Linux 发行版的 Docker 镜像，比如 Ubuntu, Debian, CentOS 等，docker pull centos获取一个CentOS的镜像。

• 内核空间是 kernel，Linux 刚启动时会加载 bootfs 文件系统，之后 bootfs 会被卸载掉。
• 用户空间的文件系统是 rootfs，包含我们熟悉的 /dev, /proc, /bin 等目录。

对于Docker的 base 镜像来说，底层直接用 Host 的 kernel，自己只需要提供 rootfs 就行了。

而对于一个精简的 OS，rootfs 可以很小，只需要包括最基本的命令、工具和程序库就可以了。

所以，base 镜像提供的是最小安装的 Linux 发行版。

1.2 不同的镜像

不同的Base镜像，区别在于，支持运行不同的 Linux OS，就是其中rootfs不同

比如 Ubuntu 14.04 使用 upstart 管理服务，apt 管理软件包；而 CentOS 7 使用 systemd 和 yum。这些都是用户空间上的区别，Linux kernel 差别不大

所以 Docker 可以同时支持多种 Linux 镜像，模拟出多种操作系统环境。Debian 和 BusyBox（一种嵌入式 Linux）上层提供各自的 rootfs，底层共用 Docker Host 的 kernel。

查看镜像信息

mkdir /registry
docker run -p 5000:5000  --restart=always --name registry -v /registry/:/var/lib/registry -d registry
[root@img-tools registry]# docker pull centos:latest
[root@img-tools registry]# docker tag centos:latest 127.0.0.1:5000/mycentos:latest
[root@img-tools registry]# docker push 127.0.0.1:5000/mycentos:latest
The push refers to repository [127.0.0.1:5000/mycentos]
2653d992f4ef: Pushed
latest: digest: sha256:dbbacecc49b088458781c16f3775f2a2ec7521079034a7ba499c8b0bb7f86875 size: 529
[root@img-tools registry]# curl -X GET http://127.0.0.1:5000/v2/_catalog -k
{"repositories":["mycentos"]}
// 查看获取到镜像的Digest
[root@img-tools harbor]# curl -I -H "Accept: application/vnd.docker.distribution.manifest.v2+json" localhost:5000/v2/mycentos/manifests/latest
HTTP/1.1 200 OK
Content-Length: 529
Content-Type: application/vnd.docker.distribution.manifest.v2+json
Docker-Content-Digest: sha256:dbbacecc49b088458781c16f3775f2a2ec7521079034a7ba499c8b0bb7f86875
Docker-Distribution-Api-Version: registry/2.0
Etag: "sha256:dbbacecc49b088458781c16f3775f2a2ec7521079034a7ba499c8b0bb7f86875"
X-Content-Type-Options: nosniff
Date: Fri, 11 Jun 2021 09:15:55 GMT
// 查看宿主机信息
[root@img-tools ~]# tree /registry/docker/
/registry/docker/
└── registry
    └── v2
        ├── blobs
        │   └── sha256
        │       ├── 30
        │       │   └── 300e315adb2f96afe5f0b2780b87f28ae95231fe3bdd1e16b9ba606307728f55
        │       │       └── data
        │       ├── 7a
        │       │   └── 7a0437f04f83f084b7ed68ad9c4a4947e12fc4e1b006b38129bac89114ec3621
        │       │       └── data
        │       └── db
        │           └── dbbacecc49b088458781c16f3775f2a2ec7521079034a7ba499c8b0bb7f86875
        │               └── data
        └── repositories
            └── mycentos
                ├── _layers
                │   └── sha256
                │       ├── 300e315adb2f96afe5f0b2780b87f28ae95231fe3bdd1e16b9ba606307728f55
                │       │   └── link
                │       └── 7a0437f04f83f084b7ed68ad9c4a4947e12fc4e1b006b38129bac89114ec3621
                │           └── link
                ├── _manifests
                │   ├── revisions
                │   │   └── sha256
                │   │       └── dbbacecc49b088458781c16f3775f2a2ec7521079034a7ba499c8b0bb7f86875
                │   │           └── link
                │   └── tags
                │       └── latest
                │           ├── current
                │           │   └── link
                │           └── index
                │               └── sha256
                │                   └── dbbacecc49b088458781c16f3775f2a2ec7521079034a7ba499c8b0bb7f86875
                │                       └── link
                └── _uploads
27 directories, 8 files

三 镜像的唯一性

• 镜像仓库的功能

对于镜像仓库，其核心功能主要由镜像分发和存储两部分构成。

* 镜像分发：并对外提供一套,[HTTP API V2](https://docs.docker.com/registry/spec/api/)
* 镜像存储：镜像仓库中的所有镜像，都是以数据块 (Blob) 的方式存储在文件系统中。[文件系统](https://docs.docker.com/registry/storage-drivers/#provided-drivers)

通过测试，目前知道一下结论。

* 通过 Registry API 获得的两个镜像仓库中相同镜像的 manifest 信息完全相同。
* 两个镜像仓库中相同镜像的 manifest 信息的存储路径和内容完全相同。
* 两个镜像仓库中相同镜像的 blob 信息的存储路径和内容完全相同。

• 镜像的两部分构成：
  • 一个json manifest清单
  • blobs层叠文件组成。
• 镜像拉去过程
  • pull镜像的过程就是检索这两个组件的过程。拉去镜像的第一步就是获取清单。
  • 当获取清单之后，客户端需要验证前面(signature)，以确保名称和fsLayers层是有效的。确认后，客户端可以使用digest去下载各个fs层。在V2 api中，层存储在blobs中已digest作为键值。
• 具体过程
  • 首先拉取镜像清单(pulling an Image Manifest)

  $ HEAD /v2/<image/manifests/<reference>#检查镜像清单是否存在
  $ GET /v2/<image>/manifests/<reference>#拉取镜像清单

* 开始拉取每个层(pulling a Layer)

$ GET /v2/<image>/blobs/<digest>

digest是镜像每个fsLayer层的唯一标识。存在于清单的fsLayers里面。

四 相关API

五 其他

• 核心依赖库

github.com/containers/image/v5/image
github.com/containers/image/v5/docker

了解的镜像底层，可以利用核心库对镜像进行定制性操作等，去满足特定业务需求。

参考链接

• https://github.com/containers/image
• https://docs.docker.com/registry/spec/api/