docker 镜像管理之 overlay2 最佳实践
1. Docker 镜像
Docker 镜像是个只读的容器模板,它组成了 Docker 容器的静态文件系统运行环境 rootfs,是启动 Docker 容器的基础。
Docker 镜像是容器的静态视角,容器是镜像的运行状态。那么,怎么构建 Docker 镜像呢?这就不得不提 Liunx 的联合文件系统(union filesystem)了。
1.1 联合文件系统
联合文件系统是实现联合挂载技术的文件系统。联合挂载技术可以实现在一个挂载点同时挂载多个文件系统,将挂载点的原目录与被挂载内容进行整合,使得最终可见的文件系统包含整合之后的各层文件和目录。
以 aufs(advanced multi layered unification filesystem) 联合文件系统为例。首先创建 aufs 联合文件系统如下:
root@chunqiu:~/chunqiu/docker# ls -R
.:
beautifulGirl handsomeBoy mnt
./beautifulGirl:
chunqiu_girlfriend root
./beautifulGirl/root:
baby
./handsomeBoy:
chunqiu root
./handsomeBoy/root:
baby
./mnt:
root@chunqiu:~/chunqiu/docker# mount -t aufs -o dirs=./beautifulGirl/:./handsomeBoy/ none ./mnt
root@chunqiu:~/chunqiu/docker# df -hT | grep aufs
none aufs 150G 143G 840M 100% /root/chunqiu/docker/mnt
root@chunqiu:~/chunqiu/docker# ls -R ./mnt/
./mnt/:
chunqiu chunqiu_girlfriend root
./mnt/root:
baby
可以看到,目录 beautifulGirl 和 handsomeBoy 的内容被联合挂载到 mnt 目录下,修改 mnt 目录下的文件:
root@chunqiu:~/chunqiu/docker/mnt# echo 'who?' > chunqiu_girlfriend
root@chunqiu:~/chunqiu/docker/mnt# echo 'chunqiu' > chunqiu
root@chunqiu:~/chunqiu/docker/mnt# echo 'who?' > root/baby
root@chunqiu:~/chunqiu/docker# ls -R ./beautifulGirl/ handsomeBoy/
./beautifulGirl/:
chunqiu chunqiu_girlfriend root
./beautifulGirl/root:
baby
handsomeBoy/:
chunqiu root
handsomeBoy/root:
baby
root@chunqiu:~/chunqiu/docker# cat beautifulGirl/chunqiu beautifulGirl/chunqiu_girlfriend
chunqiu
who?
root@chunqiu:~/chunqiu/docker# cat handsomeBoy/chunqiu
root@chunqiu:~/chunqiu/docker# cat beautifulGirl/root/baby
who?
root@chunqiu:~/chunqiu/docker# cat handsomeBoy/root/baby
看起来很奇怪,修改 mnt 下 chunqiu 的内容会将改动写到 beautifulGirl 目录下,而修改 root 目录下的 baby 修改只显示在 beautifulGirl 目录下。
这是因为 mount aufs 命令未指定目录的权限,默认第一个出现的目录是可读写目录,而后面出现的目录是只读目录。所以,写入文件实际上都是写到可读写目录 beautifulGirl 目录下。
那如果删除文件呢?这里介绍一种特殊的删除联合文件系统的特性,称为 whiteout 如下:
root@chunqiu:~/chunqiu/docker/handsomeBoy# touch whiteout
root@chunqiu:~/chunqiu/docker/handsomeBoy# ls
chunqiu root whiteout
root@chunqiu:~/chunqiu/docker/mnt# ls
chunqiu chunqiu_girlfriend root whiteout
root@chunqiu:~/chunqiu/docker/mnt# rm -rf whiteout
root@chunqiu:~/chunqiu/docker/handsomeBoy# ls
chunqiu root whiteout
root@chunqiu:~/chunqiu/docker/beautifulGirl# ls -al
total 28
drwxr-xr-x 5 root root 4096 May 8 06:11 .
drwxr-xr-x 5 root root 4096 May 8 05:43 ..
-rw-r--r-- 1 root root 8 May 8 05:56 chunqiu
-rw-r--r-- 1 root root 5 May 8 05:56 chunqiu_girlfriend
drwxr-xr-x 2 root root 4096 May 8 05:44 root
-r--r--r-- 2 root root 0 May 8 05:45 .wh.whiteout
在只读目录 handsomeBoy 下创建文件 whiteout,这个文件被映射到 mnt 目录下。在 mnt 目录下删除该文件,会发现 handsomeBoy 下这个文件还是存在(因为它是只读目录),而在可读写目录 beautifulGril 下多了个隐藏文件 .wh.whiteout。这就是 whiteout 的特性,它是上层目录覆盖下层相同名字目录,用于隐藏低层分支的机制。
这里简要介绍了联合文件系统,可以发现它将目录以层级的形式表现出来。相比于联合文件系统,容器文件系统利用联合挂载技术将可读写层(read-write layer 以及 volumes),init-layer,只读层组合在一起呈现给容器内的进程,进程是感受不到这些层级结构的。那么,让我们开始容器文件系统的学习吧。
1.2 Docker overlay2 最佳实践
容器文件系统有多种存储驱动实现方式,aufs,devicemapper,overlay,overlay2 等。这里选其中一种 overlay2 加以介绍。
在介绍 overlay2 之前需要先介绍下 docker 镜像相关概念,理解它们是后续介绍的基础:
- registry/repository: registry 是 repository 的集合,repository 是镜像的集合。
- image:image 是存储镜像相关的元数据,包括镜像的架构,镜像默认配置信息,镜像的容器配置信息等等。它是“逻辑”上的概念,并无物理上的镜像文件与之对应。
- layer:layer(镜像层) 组成了镜像,单个 layer 可以被多个镜像共享。
使用 docker info 命令查看宿主机上使用的存储驱动是否是 overlay2 (配置 overlay2 可看 这里):
[root@k8s-master-node-1 centos]# docker info | grep overlay
Storage Driver: overlay2
宿主机上已经配置好了 overlay2 存储驱动,使用 docker pull 下载 ubuntu 镜像:
[root@k8s-master-node-1 overlay2]# docker pull ubuntu
Using default tag: latest
latest: Pulling from library/ubuntu
345e3491a907: Pull complete
57671312ef6f: Pull complete
5e9250ddb7d0: Pull complete
Digest: sha256:cf31af331f38d1d7158470e095b132acd126a7180a54f263d386da88eb681d93
Status: Downloaded newer image for ubuntu:latest
docker.io/library/ubuntu:latest
可以看到 ubuntu 镜像分为三层,那怎么找到这三层呢?
首先查看 ubuntu 镜像:
[root@k8s-master-node-1 centos]# docker image ls | grep ubuntu
ubuntu latest 7e0aa2d69a15 2 weeks ago 72.7MB
镜像的短 ID 为 7e0aa2d69a15,通过它可以查找到镜像的三层结构。查看目录:
[root@k8s-master-node-1 centos]# cd /var/lib/docker/image/overlay2/
distribution/ imagedb/ layerdb/ repositories.json
这个目录是查找的入口,非常重要。它存储了镜像管理的元数据。其中, repositories.json 记录了 repo 与镜像 ID 的映射关系。imagedb 记录了镜像架构,操作系统,构建镜像的容器 ID 和配置以及 rootfs 等信息。layerdb 记录了每层镜像层的元数据。
通过短 ID 查找 repositories.json 文件,找到镜像 ubuntu 的长 ID,通过长 ID 在 imagedb 中找到该镜像的元数据:
[root@k8s-master-node-1 overlay2]# cat repositories.json | grep 7e0aa2d69a15
...
{"ubuntu:latest":"sha256:7e0aa2d69a153215c790488ed1fcec162015e973e49962d438e18249d16fa9bd"}
[root@k8s-master-node-1 overlay2]# cat imagedb/content/sha256/7e0aa2d69a153215c790488ed1fcec162015e973e49962d438e18249d16fa9bd
"rootfs": {
"type": "layers",
"diff_ids": [
"sha256:ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439",
"sha256:63c99163f47292f80f9d24c5b475751dbad6dc795596e935c5c7f1c73dc08107",
"sha256:2f140462f3bcf8cf3752461e27dfd4b3531f266fa10cda716166bd3a78a19103"]
}
...
这里仅保留我们想要的元数据 rootfs。在 rootfs 中看到 layers 有三层,这三层即对应镜像的三层镜像层。并且,自上而下分别映射到容器的底层到顶层。找到了镜像的三层,接下来的问题是每层的文件内容在哪里呢?
layerdb 元数据会给我们想要的信息,通过底层 diff-id: ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439 我们查到最底层镜像层的 cache_id,通过 cache_id 即可查找到镜像层的文件内容:
[root@k8s-master-node-1 ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439]# ls
cache-id diff size tar-split.json.gz
[root@k8s-master-node-1 ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439]# cat cache-id
1c3b24824b7026813cc6e62b1f217f5b5bf17d67c2bc30a90bc68d286348b7b7
[root@k8s-master-node-1 ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439]# cat diff
sha256:ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439
[root@k8s-master-node-1 ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439]# pwd
/var/lib/docker/image/overlay2/layerdb/sha256/ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439
// 使用 cacheID 查找文件内容
[root@k8s-master-node-1 ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439]# cd /var/lib/docker/overlay2/1c3b24824b7026813cc6e62b1f217f5b5bf17d67c2bc30a90bc68d286348b7b7/
[root@k8s-master-node-1 1c3b24824b7026813cc6e62b1f217f5b5bf17d67c2bc30a90bc68d286348b7b7]# ls
committed diff link
[root@k8s-master-node-1 1c3b24824b7026813cc6e62b1f217f5b5bf17d67c2bc30a90bc68d286348b7b7]# cd diff/
[root@k8s-master-node-1 diff]# ls
bin boot dev etc home lib lib32 lib64 libx32 media mnt opt proc root run sbin srv sys tmp usr var
[root@k8s-master-node-1 1c3b24824b7026813cc6e62b1f217f5b5bf17d67c2bc30a90bc68d286348b7b7]# cat link
5OLEHO4UPBPTXSVUTVZ2JB2WJR
上示例中,镜像元数据和镜像层内容是分开存储的。因此通过 cache-id 我们需要到 /var/lib/docker/overlay2 目录下查看镜像层内容,它就存在 diff 目录下,其中 link 存储的是镜像层对应的短 ID,后面会看到它的用场。
找到了镜像层的最底层,接着查找镜像层的“中间层”,发现在 layerdb 目录下没有 diff-id 63c99163f47292f80f9d24c5b475751dbad6dc795596e935c5c7f1c73dc08107 的镜像层:
[root@k8s-master-node-1 layerdb]# cd sha256/63c99163f47292f80f9d24c5b475751dbad6dc795596e935c5c7f1c73dc08107
bash: cd: sha256/63c99163f47292f80f9d24c5b475751dbad6dc795596e935c5c7f1c73dc08107: No such file or directory
[root@k8s-master-node-1 layerdb]#
这是因为 docker 引入了内容寻址机制,该机制会根据文件内容来索引镜像和镜像层。docker 利用 rootfs 中的 diff_id 计算出内容寻址的 chainID,通过 chainID 获取 layer 相关信息,最终索引到镜像层文件内容。
对于最底层镜像层其 diff_id 即是 chainID。因此我们可以查找到它的文件内容。除最底层外,chainID 需通过公式 chainID(n) = SHA256(chain(n-1) diffID(n)) 计算得到,计算“中间层” chainID:
[root@k8s-master-node-1 layerdb]# echo -n "sha256:ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439 sha256:63c99163f47292f80f9d24c5b475751dbad6dc795596e935c5c7f1c73dc08107" | sha256sum -
8d8dceacec7085abcab1f93ac1128765bc6cf0caac334c821e01546bd96eb741 -
根据 “中间层” chainID 查找文件内容:
[root@k8s-master-node-1 8d8dceacec7085abcab1f93ac1128765bc6cf0caac334c821e01546bd96eb741]# ls
cache-id diff parent size tar-split.json.gz
[root@k8s-master-node-1 8d8dceacec7085abcab1f93ac1128765bc6cf0caac334c821e01546bd96eb741]# cat cache-id
4d615a437c68f0853db7749bf3d7d268efaebbe045a2af4d8b8e1148fc1acd91
[root@k8s-master-node-1 8d8dceacec7085abcab1f93ac1128765bc6cf0caac334c821e01546bd96eb741]# cat diff
sha256:63c99163f47292f80f9d24c5b475751dbad6dc795596e935c5c7f1c73dc08107
[root@k8s-master-node-1 8d8dceacec7085abcab1f93ac1128765bc6cf0caac334c821e01546bd96eb741]# cat parent
sha256:ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439
[root@k8s-master-node-1 4d615a437c68f0853db7749bf3d7d268efaebbe045a2af4d8b8e1148fc1acd91]# ls
committed diff link lower work
[root@k8s-master-node-1 4d615a437c68f0853db7749bf3d7d268efaebbe045a2af4d8b8e1148fc1acd91]# ls diff/
etc usr var
// 镜像层文件内容
[root@k8s-master-node-1 4d615a437c68f0853db7749bf3d7d268efaebbe045a2af4d8b8e1148fc1acd91]# cat link
GALK5TGULR45FL2NKY54EPAQ3C
// 镜像层文件内容短 ID
[root@k8s-master-node-1 4d615a437c68f0853db7749bf3d7d268efaebbe045a2af4d8b8e1148fc1acd91]# cat lower
l/5OLEHO4UPBPTXSVUTVZ2JB2WJR
// “父”镜像层文件内容短 ID
找到最底层文件内容和“中间层”文件内容,再去找最顶层文件内容就变的不难了,这里就不多做赘述啦~
这一节知道了如何去查找镜像的镜像层文件内容,那么 docker 容器是怎么将镜像和容器结合起来的呢?为什么说“镜像是容器的静态视角,容器是镜像的运行状态”呢?接着往下看。
1.2.1 docker 容器与镜像
通过 docker run 命令启动一个镜像为 ubuntu 的容器:
[root@k8s-master-node-1 centos]# docker ps | grep ubuntu
156d4506b7ae ubuntu "/bin/bash" 24 hours ago Up 23 hours great_williamson
[root@k8s-master-node-1 centos]# mount | grep overlay
overlay on /var/lib/docker/overlay2/5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d/merged type overlay
(rw,relatime,lowerdir=/var/lib/docker/overlay2/l/Q6HPGILSGOQG5JGUURP2357S4X:/var/lib/docker/overlay2/l/Y2WW3FGR4WZDFTNZTTLGI7L24E:/var/lib/docker/overlay2/l/GALK5TGULR45FL2NKY54EPAQ3C:/var/lib/docker/overlay2/l/5OLEHO4UPBPTXSVUTVZ2JB2WJR,upperdir=/var/lib/docker/overlay2/5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d/diff,workdir=/var/lib/docker/overlay2/5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d/work)
可以看到,启动容器会 mount 一个 overlay 的联合文件系统到容器内。这个文件系统由三层组成:
- lowerdir:只读层,即为镜像的镜像层。
- upperdir:读写层,该层是容器的读写层,对容器的读写操作将反映在读写层。
- workdir: overlayfs 的内部层,用于实现从只读层到读写层的 copy_up 操作。
- merge:容器内作为同一视图联合挂载点的目录。
这里需要着重介绍的是容器的 lowerdir 镜像只读层,查看只读层的短 ID:
Q6HPGILSGOQG5JGUURP2357S4X
Y2WW3FGR4WZDFTNZTTLGI7L24E
GALK5TGULR45FL2NKY54EPAQ3C
5OLEHO4UPBPTXSVUTVZ2JB2WJR
镜像层只有三层这里的短 ID 却有四个?
在 /var/lib/docker/overlay2/l 目录下我们找到了答案:
[root@k8s-master-node-1 l]# pwd
/var/lib/docker/overlay2/l
[root@k8s-master-node-1 l]# ls -l Q6HPGILSGOQG5JGUURP2357S4X
lrwxrwxrwx 1 root root 77 May 7 08:47 Q6HPGILSGOQG5JGUURP2357S4X -> ../5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d-init/diff
[root@k8s-master-node-1 l]# ls -l Y2WW3FGR4WZDFTNZTTLGI7L24E
lrwxrwxrwx 1 root root 72 May 7 08:13 Y2WW3FGR4WZDFTNZTTLGI7L24E -> ../7e27874bb1acb324bf692d0fb53ad0ebaed0837cfe650eab42cd9f8c2c592c85/diff
[root@k8s-master-node-1 l]# ls -l GALK5TGULR45FL2NKY54EPAQ3C
lrwxrwxrwx 1 root root 72 May 7 08:13 GALK5TGULR45FL2NKY54EPAQ3C -> ../4d615a437c68f0853db7749bf3d7d268efaebbe045a2af4d8b8e1148fc1acd91/diff
[root@k8s-master-node-1 l]# ls -l 5OLEHO4UPBPTXSVUTVZ2JB2WJR
lrwxrwxrwx 1 root root 72 May 7 08:13 5OLEHO4UPBPTXSVUTVZ2JB2WJR -> ../1c3b24824b7026813cc6e62b1f217f5b5bf17d67c2bc30a90bc68d286348b7b7/diff
[root@k8s-master-node-1 l]# ls -R ../5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d-init/diff
../5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d-init/diff:
dev etc
../5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d-init/diff/dev:
console pts shm
../5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d-init/diff/dev/pts:
../5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d-init/diff/dev/shm:
../5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d-init/diff/etc:
hostname hosts mtab resolv.conf
镜像层 Y2WW3FGR4WZDFTNZTTLGI7L24E / GALK5TGULR45FL2NKY54EPAQ3C / 5OLEHO4UPBPTXSVUTVZ2JB2WJR 分别对应镜像的三层镜像层文件内容,它们分别映射到镜像层的 diff 目录。而 Q6HPGILSGOQG5JGUURP2357S4X 映射的是容器的初始化层 init,该层内容是和容器配置相关的文件内容,它是只读的。
启动了容器,docker 将镜像的内容 mount 到容器中。那么,如果在容器内写文件会对镜像有什么影响呢?
1.2.2 容器内写文件
不难理解,镜像层是只读的,在容器中写文件其实是将文件写入到 overlay 的可读写层。
这里有几个 case 可以测试:
- 读写层不存在该文件,只读层存在。
- 读写层存在该文件,只读层不存在。
- 读写层和只读层都不存在该文件。
我们简单构建一种读写层和只读层都不存在的场景:
root@156d4506b7ae:/etc# touch temp.txt
root@156d4506b7ae:/etc# ls
temp.txt ...
查看读写层是否有该文件:
[root@k8s-master-node-1 diff]# cd /var/lib/docker/overlay2/5d0cbbdeb08f0b3087d6635f764aa51654eb6b9fbdc7265248fd9815855c2a4d/diff
[root@k8s-master-node-1 diff]# ls
etc
[root@k8s-master-node-1 diff]# ls etc/
temp.txt
1.2.3 docker commit
上节提到容器内写文件会反映在 overlay 的可读写层,那么读写层的文件内容可以做成镜像吗?
可以。docker 通过 commit 和 build 操作实现镜像的构建。commit 将容器提交为一个镜像,build 在一个镜像的基础上构建镜像。
使用 commit 将上节的容器提交为一个镜像:
[root@k8s-master-node-1 diff]# docker commit 156d4506b7ae
sha256:71cf2c4aad14d18e9d0ee8bfb2cdd16ea5216f68c6d4d81062143fe58fbe48a4
[root@k8s-master-node-1 diff]# docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> 71cf2c4aad14 9 seconds ago 72.7MB
image 短 ID 71cf2c4aad14 即为容器提交的镜像,查看镜像的 imagedb 元数据:
[root@k8s-master-node-1 diff]# cat /var/lib/docker/image/overlay2/imagedb/content/sha256/71cf2c4aad14d18e9d0ee8bfb2cdd16ea5216f68c6d4d81062143fe58fbe48a4
"rootfs": {
"type": "layers",
"diff_ids": [
"sha256:ccdbb80308cc5ef43b605ac28fac29c6a597f89f5a169bbedbb8dec29c987439",
"sha256:63c99163f47292f80f9d24c5b475751dbad6dc795596e935c5c7f1c73dc08107",
"sha256:2f140462f3bcf8cf3752461e27dfd4b3531f266fa10cda716166bd3a78a19103",
"sha256:7dd12b1505cdc6bebe28cf63d5b374890908dcc9b1a23ca4dcc21e9de033c209"]
}
...
可以看到镜像层自上而下的前三个镜像层 diff_id 和 ubuntu 镜像层 diff_id 是一样的,说明每层镜像层可以被多个镜像共享。而多出来的一层镜像层内容即是上节我们写入文件的内容:
[root@k8s-master-node-1 diff]# echo -n "sha256:3dd8c8d4fd5b59d543c8f75a67cdfaab30aef5a6d99aea3fe74d8cc69d4e7bf2 sha256:7dd12b1505cdc6bebe28cf63d5b374890908dcc9b1a23ca4dcc21e9de033c209" | sha256sum -
0f3060e8fee611c68417fecbfc52734563ddea02157eaa7624fa23043af0bfb6 -
[root@k8s-master-node-1 diff]# cd /var/lib/docker/image/overlay2/layerdb/sha256/0f3060e8fee611c68417fecbfc52734563ddea02157eaa7624fa23043af0bfb6/
[root@k8s-master-node-1 0f3060e8fee611c68417fecbfc52734563ddea02157eaa7624fa23043af0bfb6]# ls
cache-id diff parent size tar-split.json.gz
[root@k8s-master-node-1 48e27ff2ff5302bd2dfd244610a61cc5032ec88b79b0953eb2c933a1f4146a36]# ls
diff link lower work
[root@k8s-master-node-1 48e27ff2ff5302bd2dfd244610a61cc5032ec88b79b0953eb2c933a1f4146a36]# cd diff/
[root@k8s-master-node-1 diff]# ls etc/
temp.txt