Docker自2013年问世以来，已经发展成为技术同学人尽皆知的工具。但是不少同学对镜像和容器的存储结构了解甚少，甚至不少Docker Client 玩的很溜的老司机也是如此，这对于应用的管理并不是一件好事。
花20分钟了解一下镜像的存储结构，也许可以提升应用的构建效率和运行时效率。如果你觉得这很划算，请耐心往下看。
容器和镜像的关系
容器和镜像是Docker的两大核心概念。如果你用过Docker，下面的这些操作应该会很熟悉:
- 从镜像中心下载镜像到本地 ——
docker pull - 基于下载好的镜像启动一个容器 ——
docker run - 进入容器内部，执行一些命令，进行调试 ——
docker exec - 构建自己的镜像 ——
docker build
这些操作可以让你直观感受到镜像和容器的用法与区别。
镜像就像一个模板， 它是固定的，可任意复制的，并且你可以用它来生成无数的实例。
容器就是镜像的一个实例。它是动态的，你可以在上面调试，或者运行自己的应用程序。
这样的理解当然可以，但不够精确。再往下深入，可以问问自己下面的问题是否清楚。
- 镜像和容器在宿主机上是以何种形式存储的？
- 不同的镜像为什么能共用一些部分？
- 容器中的修改会不会破坏镜像的内容？
- 为什么容器启动的速度那么快？
- 在容器中进行大量读写操作是否存在性能瓶颈？
其实，第一个问题是上述所有问题的关键。即搞清楚镜像和容器的存储形式。我们先来看镜像。
镜像的存储结构模型
上图描述了镜像的存储结构，镜像由一堆只读层(Read Layer) 构成，每一层只存放增量的内容。联合文件系统(Unioned File System)技术将这些层整合为一个文件系统，为用户提供了一个统一的视角。
以多层的形式存储镜像有两个好处：
- 可以从任何一层创建容器
- 不同的镜像可以复用相同的层
- 上传和下载镜像可以采用并行的方式，减少时间开销
关于第二点，举一个实际的应用场景。
如果你以官方提供的centos7镜像为基础镜像(base image), 制作了一些包含软件部署环境的镜像，例如centos7_jdk8, centos7_mysql5u7 等等。利用docker的镜像分层管理模式，基础镜像只需要在宿主机上保存一份即可。这个设定极大的方便了镜像的复用。
那么容器是如何存储的呢，容器如何获得镜像的数据，我们接着往下看。
容器的存储结构模型
容器的存储结构非常简单，它其实就是在镜像的多层结构之上又叠加了一层。只不过这一层是可写的。
用一个简单的公式来表达：
Container = Image + RW Layer (容器 = 镜像 + 可写层)
这就解释了为什么容器的创建速度可以达到毫秒级，因为创建容器仅仅是创建一个空的读写层。
平时我们常用的
docker run命令包括了docker create和docker start两个步骤。容器的定义并不包括容器是否在运行，这个概念非常重要。从存储的角度看，容器的创建非常轻量。
我们可以在一台宿主机上基于一个镜像创建多个容器，如下图所示：
这些容器各自拥有自己的读写层，因此互相并不冲突。（实际上，容器内的进程也做了隔离，这个是基于
Linux namespace实现的）
存储结构
接下来我们结合实战，深入了解镜像的存储形式。在这之前，有一个很重要的概念（写时修改策略）需要介绍
写时修改策略（copy-on-write [Cow]）
“写时修改”策略最大化的提升了“文件共享”和"文件拷贝"的性能。它的原理并不复杂：
- 当上层需要读取下层的文件时，就直接读下层的文件。
- 当上层需要修改下层的文件时，会把该文件拷贝到自己所在的层，并进行修改
使用这个策略，就可以做到增量存储镜像层。
在容器中修改文件内容同样采取了这样的策略。如果你基于镜像启动了一个容器，并希望修改某个文件的内容时，Docker的实现步骤如下图所示:
- 沿着最新的一层镜像逐层向下搜索文件的位置，一旦找到文件，会将文件的寻址添加到缓存，以便于加速后续的操作。
- 将该文件拷贝到容器的读写层。
- 修改文件内容。此时，容器不再能看到镜像中的该文件。
有一个很有意思的误区：
有些同学嫌弃基础镜像的体积大，就自己构建了一个精简版的镜像。在基础镜像的基础上删除了一些文件和目录。Dockerfile写成下面的形式:
FROM base_image
RUN rm -rf /var/log/*
这样能生效吗？我们做个实验:
准备一个工作空间，存放Dockerfile和一个20MB大小的文件
ll -h
-rw-r--r-- 1 root root 56 Mar 24 02:54 Dockerfile
-rw-r--r-- 1 root root 20M Jun 21 2018 test
Dockerfile的内容如下所示:
FROM docker.io/ubuntu:15.04
COPY test /
RUN rm -f /test
我们在第二层将test文件拷入镜像中，第三层再把文件删除。
执行docker build -t my_image:1.0 .命令构建
Step 1/3 : FROM docker.io/ubuntu:15.04
---> d1b55fd07600
Step 2/3 : COPY test /
---> 3c237abb3ad8
Removing intermediate container 4fed737bc47d
Step 3/3 : RUN rm -f /test
---> Running in 6240d6bb3dd4
---> 2b57089fbf01
Removing intermediate container 6240d6bb3dd4
Successfully built 2b57089fbf01
镜像的体积会怎么变化呢， 我们首先用docker images 命令直观的看一下:
REPOSITORY TAG IMAGE ID CREATED SIZE
my_image 1.0 2b57089fbf01 9 seconds ago 152 MB
docker.io/ubuntu 15.04 d1b55fd07600 3 years ago 131 MB
可以看出，在Dockerfile中删除文件并不能减小镜像的体积。因为根据CoW策略机制，在新的一层删除老的一层的文件， 是先把文件拷贝到新的一层再删除的。老的镜像层的文件是固化下来无法改变的。
因此，如果你真的嫌弃基础镜像太大， 正确的做法应该是重新制作你的基础镜像。
存储驱动和数据卷
正如上面所提到的，存储驱动用来管理所有镜像层和容器层，提供临时文件系统的能力。Docker不止拥有一种存储驱动，目前已知的存储驱动有AUFS, Btrfs, Device mapper, OverlayFS, ZFS等（Docker 企业版提供了比社区版更好的支持）。不同的存储驱动有不同的适用场景，具体的细节就不在这里展开了。
存储驱动的设定为：当容器销毁时, 可写层的内容也随着在宿主机上删除了。 如果你想持久化容器中的数据，可以使用数据卷(Docker Volume)的功能(命令为docker run -v)。将宿主机上的目录或文件挂载在容器内，就形成了数据卷。
数据卷和容器的数量关系:
- 一个容器可以拥有0个或多个数据卷
- 一个数据卷可以被多个容器共享
下图给出了一个适用数据卷的例子：
左边是宿主机上的目录结构。存储驱动操作的目录存放在/var/lib/docker下面。而/data目录则用于数据卷。两个容器共用了同一个数据卷，在容器中可以直接修改宿主机的/data目录下的内容。
Docker的存储驱动虽然在性能上做了很多优化，但还是无法和直接使用宿主机的存储驱动相比。因此，当涉及到频繁的写操作时（例如应用程序输出大量log），比较推荐的做法是使用数据卷的功能。
总结
以上便是容器和镜像的存储结构方面的内容。了解存储结构可以帮助我们更好的管理自己的应用。在构建Docker镜像的时候，要精简镜像的体积，只取应用需要的内容，尤其要控制单层镜像的体积（因为多层镜像的上传和下载是并发的，存在短板效应）。在启动容器的时候，要注意把高频读写的部分以数据卷的形式映射到宿主机上，以提高性能。
本文还提到了5种Docker的存储驱动，关于这5种存储驱动的优缺点和使用场景，以及它们的实现细节，因为内容比较多，所以放到下一篇文章介绍。
参考资料
About storage drivers
Visualizing Docker Containers and Images
