走进docker(05)：docker在本地如何管理image（镜像）?

时间  2019-11-08
标签 走进 docker 本地 如何 管理 image 镜像 栏目 Docker 繁體版
原文   原文链接

docker里面能够经过docker pull、docker build、docker commit、docker load、docker import等方式获得一个image，获得image以后docker在本地是怎么存储的呢？本篇将以git pull为例，简述image的获取和存储方式。python

镜像相关的配置

docker里面和image有关的目录为/var/lib/docker，里面存放着image的全部信息，能够经过下面这个dockerd的启动参数来修改这个目录的路径。git

--graph, -g /var/lib/docker Root of the Docker runtime

镜像的引用方式

在须要引用image的时候，好比docker pull的时候，或者运行容器的时候，都须要指定一个image名称，引用一个镜像有多种方式，下面以ubuntu为例进行说明.github

因为sha256码太长，因此用bcdef...来表示完整的sha256，节约空间docker

docker hub上的官方镜像

  • ubuntu： 官方提供的最新ubuntu镜像，对应的完整名称为docker.io/library/ubuntu:latestjson

  • ubuntu:16.04： 官方提供的ubuntu 16.04镜像，对应的完整名称为docker.io/library/ubuntu:16.04ubuntu

  • ubuntu:@sha256:abcdef...： 官方提供的digest码为sha256:abcdef...的ubuntu镜像，对应的完整名称为docker.io/library/ubuntu@sha256:abcdef...segmentfault

docker hub上的非官方（我的）镜像

引用方式和官方镜像同样，惟一不一样的是须要在镜像名称前面带上用户前缀，如：api

  • user1/ubuntu： 由user1提供的最新ubuntu镜像， 对应的完整名称为docker.io/user1/ubuntu:latest安全

user1/ubuntu:16.04 和 user1/ubuntu:@sha256:abcdef...这两种方式也是和上面同样，等同于docker.io/user1/ubuntu:16.04和docker.io/user1/ubuntu:@sha256:abcdef...服务器

本身搭建的registry里的镜像

引用方式和docker hub同样，惟一不一样的是须要在镜像名称最前面带上地址，如：

  • localhost:5000/ubuntu： 本地本身搭建的registry（localhost:5000）里面的官方ubuntu的最新镜像，对应的完整名称为localhost:5000/library/ubuntu:latest

  • localhost:5000/user1/ubuntu@sha256:a123def...： 本地本身搭建的registry（localhost:5000）里面由用户user1提供的digest为sha256:a123def的ubuntu镜像

其它的几种状况和上面的相似。

为何须要镜像的digest？

对于某些image来讲，可能在发布以后还会作一些更新，好比安全方面的，这时虽然镜像的内容变了，但镜像的名称和tag没有变，因此会形成先后两次经过一样的名称和tag从服务器获得不一样的两个镜像的问题，因而docker引入了镜像的digest的概念，一个镜像的digest就是镜像的manifes文件的sha256码，当镜像的内容发生变化的时候，即镜像的layer发生变化，从而layer的sha256发生变化，而manifest里面包含了每个layer的sha256，因此manifest的sha256也会发生变化，即镜像的digest发生变化，这样就保证了digest能惟一的对应一个镜像。

docker pull的大概过程

若是对Image manifest，Image Config和Filesystem Layers等概念不是很了解，请先参考image(镜像)是什么。

取image的大概过程以下：

  • docker发送image的名称+tag（或者digest）给registry服务器，服务器根据收到的image的名称+tag（或者digest），找到相应image的manifest，而后将manifest返回给docker

  • docker获得manifest后，读取里面image配置文件的digest(sha256)，这个sha256码就是image的ID

  • 根据ID在本地找有没有存在一样ID的image，有的话就不用继续下载了

  • 若是没有，那么会给registry服务器发请求（里面包含配置文件的sha256和media type），拿到image的配置文件（Image Config）

  • 根据配置文件中的diff_ids（每一个diffid对应一个layer tar包的sha256，tar包至关于layer的原始格式），在本地找对应的layer是否存在

  • 若是layer不存在，则根据manifest里面layer的sha256和media type去服务器拿相应的layer（至关去拿压缩格式的包）。

  • 拿到后进行解压，并检查解压后tar包的sha256可否和配置文件（Image Config）中的diff_id对的上，对不上说明有问题，下载失败

  • 根据docker所用的后台文件系统类型，解压tar包并放到指定的目录

  • 等全部的layer都下载完成后，整个image下载完成，就可使用了

注意： 对于layer来讲，config文件中diffid是layer的tar包的sha256，而manifest文件中的digest依赖于media type，好比media type是tar+gzip，那digest就是layer的tar包通过gzip压缩后的内容的sha256，若是media type就是tar的话，diffid和digest就会同样。

dockerd和registry服务器之间的协议为Registry HTTP API V2。

image本地存放位置

这里以ubuntu的image为例，展现docker的image存储方式。

先看看debian的image id和digest，而后再分析image数据都存在哪里

dev@debian:~$ docker images --digests
REPOSITORY  TAG     DIGEST            MAGE ID       CREATED      SIZE
ubuntu      latest  sha256:ea1d85...  7b9b13f7b9c0  4 weeks ago  118 MB
......

对于本地生成的镜像来讲，因为没有上传到registry上去，因此没有digest，由于镜像的manifest由registry生成

repositories.json

repositories.json中记录了和本地image相关的repository信息，主要是name和image id的对应关系，当image从registry上被pull下来后，就会更新该文件：

#这里目录中的aufs为docker后台所采用的存储文件系统名称，
#若是是其余的文件系统的话，名字会是其余的，好比btrfs、overlay二、devicemapper等。
root@debian:~# cat /var/lib/docker/image/aufs/repositories.json|python -m json.tool
{
    "Repositories": {
        "ubuntu": {
            "ubuntu:latest": "sha256:7b9b13f7b9c086adfb6be4d2d264f90f16b4d1d5b3ab9f955caa728c3675c8a2",
            "ubuntu@sha256:ea1d854d38be82f54d39efe2c67000bed1b03348bcc2f3dc094f260855dff368": "sha256:7b9b13f7b9c086adfb6be4d2d264f90f16b4d1d5b3ab9f955caa728c3675c8a2"
        }
        ......
    }
}

  • ubuntu： repository的名称，前面没有服务器信息的表示这是官方registry(docker hub)里面的repository，里面包含的都是image标识和image ID的对应关系

  • ubuntu:latest和debian@sha256:ea1d85...： 他们都指向同一个image（sha256:7b9b13...）

配置文件（image config）

docker根据第一步获得的manifest，从registry拿到config文件，而后保存在image/aufs/imagedb/content/sha256/目录下，文件名称就是文件内容的sha256码，即image id：

root@debian:~# sha256sum /var/lib/docker/image/aufs/imagedb/content/sha256/7b9b13f7b9c086adfb6be4d2d264f90f16b4d1d5b3ab9f955caa728c3675c8a2
7b9b13f7b9c086adfb6be4d2d264f90f16b4d1d5b3ab9f955caa728c3675c8a2  /var/lib/docker/image/aufs/imagedb/content/sha256/7b9b13f7b9c086adfb6be4d2d264f90f16b4d1d5b3ab9f955caa728c3675c8a2

#这里咱们只关注这个image的rootfs，
#从diff_ids里能够看出ubuntu:latest这个image包含了5个layer，
#从上到下依次是从底层到顶层，6a8bf8...是最底层，d8b353...是最顶层
root@debian:~# cat /var/lib/docker/image/aufs/imagedb/content/sha256/7b9b13f7b9c086adfb6be4d2d264f90f16b4d1d5b3ab9f955caa728c3675c8a2|python -m json.tool
......
    "rootfs": {
        "diff_ids": [
            "sha256:6a8bf8c8edbd705f67cdc062eee3911470a38a763258c81c05da1f28d6eec896",
            "sha256:fe9a3f9c4559684b75bba751883fa084d34e418c018d687ddc25c3f23f13f657",
            "sha256:fc9e1e5e38f700997585295bd65a47e58f3da7b2f0e6a971e14a6104f199de1f",
            "sha256:f2e85bc0b7b17ab33f9060d2f24824defe600e189b05a895d60b2e8a6a7bd0d7",
            "sha256:d8b353eb3025c49e029567b2a01e517f7f7d32537ee47e64a7eac19fa68a33f3"
        ],
        "type": "layers"
    }

......

layer的diff_id和digest的对应关系

layer的diff_id存在image的配置文件中，而layer的digest存在image的manifest中，他们的对应关系被存储在了image/aufs/distribution目录下：

root@debian:~# tree -d /var/lib/docker/image/aufs/distribution/
/var/lib/docker/image/aufs/distribution/
├── diffid-by-digest
│   └── sha256
└── v2metadata-by-diffid
    └── sha256

  • diffid-by-digest： 存放digest到diffid的对应关系

  • v2metadata-by-diffid： 存放diffid到digest的对应关系

#这里以最底层layer(6a8bf8...)为例，查看其digest信息
root@debian:~# cat /var/lib/docker/image/aufs/distribution/v2metadata-by-diffid/sha256/6a8bf8c8edbd705f67cdc062eee3911470a38a763258c81c05da1f28d6eec896|python -m json.tool
[
    {
        "Digest": "sha256:bd97b43c27e332fc4e00edf827bbc26369ad375187ce6eee91c616ad275884b1",
        "HMAC": "",
        "SourceRepository": "docker.io/library/ubuntu"
    }
]

#根据digest获得diffid
root@debian:~# cat /var/lib/docker/image/aufs/distribution/diffid-by-digest/sha256/bd97b43c27e332fc4e00edf827bbc26369ad375187ce6eee91c616ad275884b1
sha256:6a8bf8c8edbd705f67cdc062eee3911470a38a763258c81c05da1f28d6eec896

layer的元数据

layer的属性信息都放在了image/aufs/layerdb目录下，目录名称是layer的chainid，因为最底层的layer的chainid和diffid相同，因此这里咱们用第二层（fe9a3f...）做为示例：

计算chainid时，用到了全部祖先layer的信息，从而能保证根据chainid获得的rootfs是惟一的。好比我在debian和ubuntu的image基础上都添加了一个一样的文件，那么commit以后新增长的这两个layer具备相同的内容，相同的diffid，但因为他们的父layer不同，因此他们的chainid会不同，从而根据chainid能找到惟一的rootfs。计算chainid的方法请参考image spec

#计算chainid
#这里fe9a3f...是第二层的diffid，而6a8bf8...是fe9a3f...父层的chainid，
#因为6a8bf8...是最底层，它没有父层，因此6a8bf8...的chainid就是6a8bf8...
dev@debian:~$ echo -n "sha256:6a8bf8c8edbd705f67cdc062eee3911470a38a763258c81c05da1f28d6eec896 sha256:fe9a3f9c4559684b75bba751883fa084d34e418c018d687ddc25c3f23f13f657"|sha256sum -
67b5e1df1b671d4751794767b20f6973d77e91528ab475ee1118ce8dab796193  -

#根据chainid来看看相应目录的内容
root@debian:/var/lib/docker/image/aufs/layerdb/sha256/67b5e1df1b671d4751794767b20f6973d77e91528ab475ee1118ce8dab796193# ls
cache-id  diff  parent  size  tar-split.json.gz
#每一个layer都有这样一个对应的文件夹

#cache-id是docker下载layer的时候在本地生成的一个随机uuid，
#指向真正存放layer文件的地方
root@debian:/var/lib/docker/image/aufs/layerdb/sha256/67b5e1df1b671d4751794767b20f6973d77e91528ab475ee1118ce8dab796193# cat cache-id
b656bf5f0688069cd90ab230c029fdfeb852afcfd0d1733d087474c86a117da3

#diff文件存放layer的diffid
root@debian:/var/lib/docker/image/aufs/layerdb/sha256/67b5e1df1b671d4751794767b20f6973d77e91528ab475ee1118ce8dab796193# cat diff
sha256:fe9a3f9c4559684b75bba751883fa084d34e418c018d687ddc25c3f23f13f657

#parent文件存放当前layer的父layer的diffid，
#注意：对于最底层的layer来讲，因为没有父layer，因此没有这个文件
root@debian:/var/lib/docker/image/aufs/layerdb/sha256/67b5e1df1b671d4751794767b20f6973d77e91528ab475ee1118ce8dab796193# cat parent
sha256:6a8bf8c8edbd705f67cdc062eee3911470a38a763258c81c05da1f28d6eec896

#当前layer的大小，单位是字节
root@debian:/var/lib/docker/image/aufs/layerdb/sha256/67b5e1df1b671d4751794767b20f6973d77e91528ab475ee1118ce8dab796193# cat size
745

#tar-split.json.gz，layer压缩包的split文件，经过这个文件能够还原layer的tar包，
#在docker save导出image的时候会用到
#详情可参考https://github.com/vbatts/tar-split
root@debian:/var/lib/docker/image/aufs/layerdb/sha256/67b5e1df1b671d4751794767b20f6973d77e91528ab475ee1118ce8dab796193# ls -l tar-split.json.gz
-rw-r--r-- 1 root root 1429 May 28 22:57 tar-split.json.gz

layer数据

docker根据后台所采用的文件系统不一样，在/var/lib/docker目录下建立了不一样的子目录，对于debian来讲，默认文件系统是aufs，因此全部layer的文件都放在了/var/lib/docker/aufs目录下。

root@dev:~# tree -d -L 1 /var/lib/docker/aufs
/var/lib/docker/aufs
├── diff
├── layers
└── mnt

该目录下有三个子目录，layers里面存放的layer的父子关系，diff目录存放的是每一个layer的原始数据，mnt存储的是layer和祖先layer叠加起来的数据。

注意：因为docker所采用的文件系统不一样，/var/lib/docker/<storage-driver>目录下的目录结构及组织方式也会不同，要具体文件系统具体分析，本文只介绍aufs这种状况。
关于aufs和btrfs的相关特性能够参考Linux文件系统之aufs和Btrfs文件系统之subvolume与snapshot

仍是以刚才的第二层layer（fe9a3f...）为例，看看实际的数据：

#从上面layerdb中，咱们已经找到了第二层layer对应的cache id为b656bf...
#先看看layers目录下的这个文件,里面存放的是当前layer的祖先layer的cacheid
root@dev:~# cat /var/lib/docker/aufs/layers/b656bf5f0688069cd90ab230c029fdfeb852afcfd0d1733d087474c86a117da3
1e83d2ea184e08eed978127311cc96498e319426abe2fb5004d4b1454598bd76

#再来看看diff目录下的内容，看这一层包含了哪些文件，从下面的输出能够看出，这一层包含的文件不多
root@dev:~# tree /var/lib/docker/aufs/diff/b656bf5f0688069cd90ab230c029fdfeb852afcfd0d1733d087474c86a117da3/
/var/lib/docker/aufs/diff/b656bf5f0688069cd90ab230c029fdfeb852afcfd0d1733d087474c86a117da3/
├── etc
│   ├── apt
│   │   └── apt.conf.d
│   │       ├── docker-autoremove-suggests
│   │       ├── docker-clean
│   │       ├── docker-gzip-indexes
│   │       └── docker-no-languages
│   └── dpkg
│       └── dpkg.cfg.d
│           └── docker-apt-speedup
├── sbin
│   └── initctl
├── usr
│   └── sbin
│       └── policy-rc.d
└── var
    └── lib
        └── dpkg
            ├── diversions
            └── diversions-old

#再来看看这一层和上一层合并后的文件目录
root@dev:~# tree /var/lib/docker/aufs/mnt/b656bf5f0688069cd90ab230c029fdfeb852afcfd0d1733d087474c86a117da3/
/var/lib/docker/aufs/mnt/b656bf5f0688069cd90ab230c029fdfeb852afcfd0d1733d087474c86a117da3/

0 directories, 0 files
#为何是空的呢？这和aufs文件系统有关，
#它只有在运行容器的时候，才会将多层合并起来，提供一个统一的视图，
#因此这里看不到这两层合并以后的效果。

manifest文件去哪了？

从前面介绍docker pull的过程当中得知，docker是先获得manifest，而后根据manifest获得config文件和layer。

前面已经介绍了config文件和layer的存储位置，但惟独不见manifest，去哪了呢？

manifest里面包含的内容就是对config和layer的sha256 + media type描述，目的就是为了下载config和layer，等image下载完成后，manifest的使命就完成了，里面的信息对于image的本地管理来讲没什么用，因此docker在本地没有单独的存储一份manifest文件与之对应。

结束语

本篇介绍了image在本地的存储方式，包括了/var/lib/docker/image和/var/lib/docker/aufs这两个目录，但/var/lib/docker/image下面有两个目录没有涉及：

  • /var/lib/docker/image/aufs/imagedb/metadata：里面存放的是本地image的一些信息，从服务器上pull下来的image不会存数据到这个目录，下次有机会再补充这部份内容。

  • /var/lib/docker/image/aufs/layerdb/mounts: 建立container时，docker会为每一个container在image的基础上建立一层新的layer，里面主要包含/etc/hosts、/etc/hostname、/etc/resolv.conf等文件，建立的这一层layer信息就放在这里，后续在介绍容器的时候，会专门介绍这个目录的内容。

参考

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程