走进docker(05)：docker在本地如何管理image（镜像）?
docker里面可以通过docker pull、docker build、docker commit、docker load、docker import等方式得到一个image，得到image之后docker在本地是怎么存储的呢？本篇将以git pull为例，简述image的获取和存储方式。
镜像相关的配置
docker里面和image有关的目录为/var/lib/docker，里面存放着image的所有信息，可以通过下面这个dockerd的启动参数来修改这个目录的路径。
--graph, -g /var/lib/docker Root of the Docker runtime
镜像的引用方式
在需要引用image的时候，比如docker pull的时候，或者运行容器的时候，都需要指定一个image名称，引用一个镜像有多种方式，下面以ubuntu为例进行说明.
由于sha256码太长，所以用bcdef...来表示完整的sha256，节约空间
docker hub上的官方镜像
ubuntu： 官方提供的最新ubuntu镜像，对应的完整名称为docker.io/library/ubuntu:latest
ubuntu:16.04： 官方提供的ubuntu 16.04镜像，对应的完整名称为docker.io/library/ubuntu:16.04
ubuntu:@sha256:abcdef...： 官方提供的digest码为sha256:abcdef...的ubuntu镜像，对应的完整名称为docker.io/library/ubuntu@sha256:abcdef...
docker hub上的非官方（个人）镜像
引用方式和官方镜像一样，唯一不同的是需要在镜像名称前面带上用户前缀，如：
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、overlay2、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
└── sha256diffid-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:6a8bf8c8edbd705f67cdc062eee3911470a38a763258c81c05da1f28d6eec896layer的元数据
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信息就放在这里，后续在介绍容器的时候，会专门介绍这个目录的内容。