• 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
    芝兰生于空谷，不以无人而不芳。
  • 相关阅读:
    前端面试题汇总
    前端学习计划汇总
    idea修改项目名导致无法找到主类
    idea run dashbord使用
    记git提交异常
    关于META-INF下的spring.factories文件
    lombok注解
    springcloud-ribbon&feign
    CAP定理
    git文件锁定不更新和忽略
  • 原文地址：https://www.cnblogs.com/xingzheanan/p/14746121.html
Copyright © 2020-2023  润新知