技术头条：干货、简洁、多维全面。更多云计算精华知识尽在眼前，get要点、solve难题，统统不在话下！
作为云计算的当红明星docker 来势汹汹,它就像一场森林大火，烧到了我们中间。因为工作的原因，每天都会和容器云打交道。但是，我发现经常会有些新加入的同事在理解Docker命令方面存在一些问题，尤其是在Docker 镜像底层的工作原理和容器与容器镜像的关系上。
通常情况下一项新的技术诞生时往往会伴随着较多的媒体宣传甚至炒作，且在推广产品的过程中往往会出现一些新的技术名词，让人感觉云里雾里。Docker 的诞生和推广正是在这种情况下进行的。
对于产品本身而言媒体的宣传和炒作可以帮助他们快速的在市场中进行推广，但是这种宣传和炒作也会导致很多用户很难看清被宣传产品的技术的本质，不利于用户对技术的掌握，更加不利于用户对产品的深度使用。
一般情况下只有真正理解了某门技术的原理才能真正掌握这一门技术，接下来才能去深入的使用这门技术。下面我们会由浅入深出的带大家了解下Docker 镜像及其相关技术的原理和本质。
容器 VS 容器镜像
在说Docker 镜像的原理知识之前，我们先看下docker 容器和docker 镜像的区别，因为这部分我们后面会涉及到。
简单说来，我们可以将Docker 镜像看成是Docker 容器的静态时，也可将Docker 容器看成是Docker镜像的运行时。
从Docker 的官方文档来看，Docker 容器的定义和 Docker 镜像的定义几乎是相同，Docker 容器和Docker 镜像的区别主要在于docker 容器多出了一个可写层。
容器中的进程就运行在这个可写层，这个可写层有两个状态，即运行态和退出态。当我们docker run 运行容器后，docker 容器就进入了运行态，当我们停止正在运行中的容器时，docker 容器就进入了退出态。
我们将容器从运行态转为退出态时，期间发生的变更都会写入到容器的文件系统中(需要注意的是，此处不是写入到了docker 镜像中)，这方面的变化下文中我们还会再细说。
Docker 存储简介
简单说来Docker 镜像就是一组只读的目录，或者叫只读的 Docker 容器模板，镜像中含有一个Docker 容器运行所需要的文件系统，所以我们说Docker 镜像是启动一个Docker 容器的基础。
如果这样不是很好理解，我们可以通过一个图一起看下：
从图中可以看出除了最上面的一层为读写层之外，下面的其他的层都是只读的镜像层，并且除了最下面的一层外，其他的层都有会有一个指针指向自己下面的一层镜像。
虽然统一文件系统(union file system)技术将不同的镜像层整合成一个统一的文件系统，为构成一个完整容器镜像的层提供了一个统一的视角，隐藏了多个层的复杂性，对用户来说只存在一个文件系统，但图中的这些层并不是不能看到的，如果需要查看的话可以进入运行Docker的机器上进行查看，从这些层中可以看到Docker 内部实现的一些细节，接下来我们一起看下。
一般刚接触Docker 不久的话可能会不太清楚Docker 的存储方式是怎样的，并且可能也不太清楚Docker 容器的镜像到底存储在什么路径下，比较迷茫。
有些同学想了解下Docker 的镜像数据存储在什么位置，然后谷歌了下几篇博文，说是在/var/lib/docker 下有个aufs目录，结果在自己机器上进到这个路径后发现没有aufs相关的目录，然后以为是版本的问题，其实不然。
以Linux服务器为例，其实Docker 的容器镜像和容器本身的数据都存放在服务器的 /var/lib/docker/ 这个路径下。不过不同的linux发行版存储方式上有差别，比如，在ubuntu发行版上存储方式为AUFS，CentOS发行版上的存储方式为device mapper。
/var/lib/docker 路径下的信息在不同的阶段会有变化，从笔者个人经验来看，了解这几个阶段中新增的数据以及容器与镜像的存储结构的变化非常有利于我们对docker容器以及Docker镜像的理解。
接下来我们一起看下Docker运行后、下载镜像后、运行容器后三个阶段中Docker 存储的变化。
环境信息：
系统发行版：CentOS7.2。
内核版本：3.10.0-327.36.1.el7.x86_64
Docker 版本：1.8
启动Docker后
在此我们假设大家已经安装好了Docker环境，具体安装的过程不再赘述。
# 启动Docker 服务
[root@influxdb ~]# systemctl start docker
# 查看/var/lib/docker路径下的文件结构
[root@localhost docker]# tree .
├── containers
├── devicemapper
│ ├── devicemapper
│ │ ├── data
│ │ └── metadata
│ └── metadata
│ ├── base
│ ├── deviceset-metadata
│ └── transaction-metadata
├── graph
├── linkgraph.db
├── repositories-devicemapper
├── tmp
├── trust
└── volumes
8 directories, 7 files
注：必须启动Docker 服务后查看，如果没有启动Docker 进程则路径/var/lib/docker 不存在。
前文中我们已经提到过，CentOS发行版中Docker 服务使用的存储方式为devicemapper，所以我们从前面tree命令的结果中可以看到出现了目录devicemapper。
有些同学可能会问什么是devicemapper？
太阳底下无新鲜事，devicemapper 并不是伴随着Docker 才出现的，早在linux2.6版本的内核时其实就已经引入了devicemapper，且当时是作为一个很重要的技术出现的。
简单说来devicemapper 就是Docker 服务的一个存储驱动，或者叫Docker 服务的存储后端。Devicemapper 其实是一个基于内核的框架，这个框架中对linux上很多的功能进行了增强，比如对linux上高级卷管理功能的增强。
Devicemapper 存储驱动将我们的每个docker镜像和docker容器都存在在自己的虚拟设备中，devicemapper的这些设备相当于我们常见的一般的写时复制快照设备的超配版本。通过上面的介绍，有些同学可能以为devicemapper 存储驱动是工作在块级别的，但是devicempper 实际是工作在文件级别的，也就是说devicemapper 存储驱动和写时复制操作都是直接操作块，而不是对文件进行操作。
以上是我们关于Docker 服务的devicemapper 存储驱动的一个简单的介绍，Docker 官方文档中提供了很多的有关Docker 存储驱动的介绍，感兴趣的同学可以自行查阅。
进一步的查看的话，可以看到路径/var/lib/docker/devicemapper下面有两个目录，分别为devicemapper和data，其中目录devicemapper 下存在两个名为data和metadata的文件，两个文件从名称即可看出一个是镜像数据的存储池，一个为镜像相关的元数据。接下去我们会逐个看下这个路径下的文件。
进入上面提到的目录metadata下，可以看到这个目录中已经存在三个文件，分别为：base、deviceset-metadata和transction-metadata，这三个文分别用来存放上文中我们提到的元数据的id、大小和uuid等信息。
[root@localhost metadata]# pwd
/var/lib/docker/devicemapper/metadata
[root@localhost metadata]# ls
base deviceset-metadata transaction-metadata
除了上面提到的几个目录，上文中tree的结果中还有几个目录，分别为：containers、devicemapper、graph、linkgraph.db、repositories-devicemapper、tmp、trust和volumes。这几个文件对于docker 的镜像存储来说都很重要，我们以文件repositories-devicemapper为例，看下这个文件对于镜像存储所起到的作用。
[root@localhost docker]# pwd
/var/lib/docker
[root@localhost docker]# ls
containers devicemapper graph linkgraph.db repositories-devicemapper tmp trust volumes
我们可以先看下repositories-devicemapper 这个文件中在当前的阶段中有什么：
root@localhost docker]# cat repositories-devicemapper
{"Repositories":{}}[root@localhost docker]#
从上面cat的结果中我们不难看出，文件repositories-devicemapper 中其实记录的就是docker 镜像的属性信息，比如镜像名称、镜像标签、镜像的ID等信息，如果镜像刚好没有标签的话默认会以lastet作为标签。
以上是对Docker 服务运行后pull镜像之前/var/lib/docker 路径下数据的一个简单的解读，相信大家通过上面的描述已经对docker镜像有了一些更深入的认识。下面我们看下在我们pull 自己的第一个docker镜像之后路径/var/lib/docker 之下的数据会发生怎样的变化。
Pull 镜像后
在此我们以一个nginx镜像为例一起看下这个阶段的变化。
# pull 示例镜像
[root@localhost docker]# docker pull nginx
Using default tag: latest
latest: Pulling from library/nginx
22f3bf58cd09: Pull complete
ea2fc476f5f0: Pull complete
81d728438afe: Pull complete
303a6dec1190: Pull complete
d43816b44a22: Pull complete
dc02db50a25a: Pull complete
6f650a34b308: Pull complete
a634e96a9de9: Pull complete
72f3ebe1e4d7: Pull complete
c2c9e418b22c: Pull complete
Digest: sha256:a82bbaf63c445ee9b854d182254c62e34e6fa92f63d7b4fdf6cea7e76665e06e
Status: Downloaded newer image for nginx:latest
# 查看镜像是否已经在本地
[root@localhost docker]# docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
nginx latest c2c9e418b22c 2 weeks ago 109.3 MB
[root@localhost docker]#
在此我们没有指定nginx镜像的tag，因此默认拉去了最新的版本。然后我们看下路径/var/lib/docker 下是否有变化：
[root@localhost docker]# tree .
.
├── containers
├── devicemapper
│ ├── devicemapper
│ │ ├── data
│ │ └── metadata
……
省略若干数据
……
│ │ ├── checksum
│ │ ├── json
│ │ ├── layersize
│ │ ├── tar-data.json.gz
│ │ └── v1Compatibility
│ ├── 303a6dec11900c97f5d7555d31adec02d2e5e4eaa1a77537e7a5ebd45bb7fcd2
│ │ ├── checksum
│ │ ├── json
│ │ ├── layersize
│ │ ├── tar-data.json.gz
│ │ └── v1Compatibility
│ ├── 6f650a34b3083c96cf8b7babc7a391227c0f78e0d07067071c46e31bd834de3a
│ │ ├── checksum
│ │ ├── json
│ │ ├── layersize
│ │ ├── tar-data.json.gz
│ │ └── v1Compatibility
│ ├── 72f3ebe1e4d793a50836d4e070c94ef7497c80111d178e867014981f64696a39
│ │ ├── checksum
│ │ ├── json
│ │ ├── layersize
│ │ ├── tar-data.json.gz
│ │ └── v1Compatibility
│ ├── 81d728438afe98602e2e692c20299ecf41b93173fb12351c1b59820b17fb16b9
│ │ ├── checksum
│ │ ├── json
│ │ ├── layersize
│ │ ├── tar-data.json.gz
│ │ └── v1Compatibility
│ ├── a634e96a9de9f1e280efaecdd43c7273ac43e109a42ab6c76ab2d2261c8cdc50
│ │ ├── checksum
│ │ ├── json
│ │ ├── layersize
│ │ ├── tar-data.json.gz
│ │ └── v1Compatibility
│ ├──
……
省略若干数据
……
│ ├── ea2fc476f5f055f9e44963987903ecfe0cb480b7e387d8b5cb64006832110afc
│ │ ├── checksum
│ │ ├── json
│ │ ├── layersize
│ │ ├── tar-data.json.gz
│ │ └── v1Compatibility
│ └── _tmp
├── linkgraph.db
├── repositories-devicemapper
├── tmp
├── trust
└── volumes
30 directories, 67 files
[root@localhost docker]#
从结尾的目录数和文件数也可以看出，在我们拉取镜像后/var/lib/docker 下多出了很多的文件(拉取镜像之前，只有8个目录，7个文件)，下面我们一步步的分析。
如果这个时候看下路径/var/lib/docker下的文件的话，可以很容易的看到发生变化的主要是下面这三个文件：/var/lib/docker/devicemapper/metadata、/var/lib/docker/devicemapper/mnt以及/var/lib/docker/graph。我们先看下metadata这个文件：
