之所以在之前没有讲什么是镜像和容器是因为如果你没有一个最初的认识，那么你就很难理解镜像和容器以及它们的区别。我相信在前面一章中的讲述中，你应该稍有体会容器是基于镜像构建的，同时构建了容器之后如果不删除就会一直存在，而且我们下载的镜像还可以继续构建更多容器。构建容器并不是把镜像放进容器里，而是容器基于这个镜像产生，容器体积很小，镜像会大一点，你就算本地没有镜像也可以运行容器，因为它会从HUB中下载。在容器中的所有的修改都不会影响镜像。

先用通俗易懂但是不太严谨的例子说明一下，我们用光盘镜像安装一台虚拟机，那个镜像是只读的，这一点和Docker的镜像一样，安装操作系统的过程就可以想象成用镜像构建一个容器。这里不要去拿原理对号入座，而是只要想象一下这个过程，因为毕竟底层不是一个东西。容器就类似装好的电脑，可以让你去操作，也可以写入数据，安装软件、配置网络环境等等，同时也可以保存你修改的数据。从上面这个描述来看和普通的虚拟机也没有区别，大体上你可以这么理解。不过你要知道，安装操作系统镜像会展开到磁盘上，运行容器的话镜像则不会。

顺便提一下，Docker上面的容器是共享宿主机内核的，普通虚拟化的虚拟机是独享内核的。

上面你有了对镜像和容器的大体认识，下面我们来说一下镜像和容器的具体内容。

镜像：

镜像是由文件系统叠加组成的，最底层是一个引导文件系统（bootfs这个用于操作系统引导、加载内核等等功能和真实Linux一样），用户不会和这个文件系统有什么交集，当容器启动以后容器会被移动到内存中，这个引导文件系统就会被卸载。

镜像的第二层是root文件系统（rootfs即根文件系统就是Linux系统中我们看到的/usr、/dev等这些目录结构）,这个文件系统可以是一种或多种操作系统。在正常的Linux系统中rootfs只有在引导的时候是只读的，当系统启动以后它就是读写的，而在Dokcer里rootfs文件系统都是只读的，而且一般会在rootfs之上再叠加多个只读镜像，这是通过联合文件系统实现的。

也就是说镜像是由一堆的只读层组成的。任何人都可以基于现有镜像再封装一个只读层上去。下层只读层是上层的只读层的父镜像，但是最底层的镜像叫做基础镜像。

联合文件系统的机制，支持将不同目录挂载到同一个虚拟文件系统下，然后实现层这个概念。因为每一层都是只读的，而且都是叠加的，联合文件系统中的联合挂载机制让这么多叠加曾看起来就像一个文件系统，所以把这种叠加起来并且看起来像一个文件系统的只读文件系统叫做镜像。

镜像分层，每一层都是只读的，所以整体镜像也是只读的。

基于镜像运行一个容器，那每一层都运行的是什么这个由什么来决定呢？答案就是镜像的json文件，每生成一个镜像层就会有一个对应的json文件存在，不过在你使用Devicemapper或者overlay不同文件系统的时候是有区别的，使用overlay文件系统那么就只有2层，下面我们以overlay为例：

我们通过看cento:6.6这个官方基础镜像就可以发现，这个镜像有几层组成：

下载的镜像到底存放在哪里呢？：

注意不同的存储驱动会导致/var/lib/docker目录下的结构有所不同。

进入到这个目录，我这里使用的是overlay存储驱动，如果你使用的devicemapper，则会有devicemapper目录和graph目录等。关于devicemapper的目录结构参见：Devicemapper目录结构

containers：容器运行起来会在这里显示

overlay：构建的容器和下载的镜像都会存在这里

overlay文件系统结构：

镜像层：lowerdir、容器层：upperdir，统一的视图通过"merged"目录暴露给挂载点。

如果镜像层和容器层有相同的文件夹或者文件时，合并到merged目录时显示的规则如下：

1. 文件名及目录不相同，则镜像层(lowerdir)和容器层(upperdir)按照各自的结构展现在merged目录中

2. 文件名相同，只显示容器层(upperdir)的文件。

3. 目录名相同，对目录进行统一合并按照原目录名进行显示，里面的文件名如果相同则按第二条处理，如果文件名不同则按第一条处理。

overlay只支持两层，容器层(upperdir)文件系统是可写的，镜像层(lowerdir)是只读的，如果对文件系统做出任何变更，只会修改容器层文件系统的文件，下面是一写读写删除规则：

overlay目录：

进入到docker的overlay目录然后运行，这里的work是空目录，用于在容器执行从镜像层拷贝到容器层使用的。

这里放的其实就是下载的镜像，但是你会发现这里和history里面看的不同ID号不一样，我们知道下载的镜像每一层都有一个自己的ID，每个镜像都有自己的目录，但是在overlay中却不是这样。因为比如在AUFS是多层，在Devicemapper里面是通过JSON表达，这里overlay如何通过两层表达？

从上图可以看到它里面有3个文件夹和一个lower-id文件，而这个文件保存的就是上层镜像的ID，看下图：

所以对于容器来说还是两层。

注意：容器和下载的镜像都在overlay目录中。如果删除所有容器，那么这里就只剩下镜像文件了，看下图，我们把建立的2个容器都删除掉：

我们再构建一个容器然后运行，看一下overlay目录里面运行中和容器退出后的变化，当容器运行起来之后，你进入目录，在merged目录中就可以看到文件系统，在这里写入就相当于在容器里写入。

不过要注意，如果多个容器基于同一个镜像启动，那么你这里看到的就只有一个容器的体积比较大，其他都很小。

containers目录：

这个目录是存放生成的容器，构建一个容器这里就有一个已容器ID命名的目录无论该容器是否在运行。这里面存放的都是容器的信息，其实这些信息通过docker inspect 容器ID或者名称 命令也可以看到。

容器：

容器是基于镜像构建的，但是容器本身并不包括镜像，这一点要注意。所以这又是一点和虚拟机的区别。我运行了一个容器，然后试图删除构建容器的镜像，得到如下提示：

它提示有容器正在使用该镜像，但是其实你把容器停止，默认也是无法删除的，因为一旦基于某个镜像建立过容器，那么他们之间就有关联关系，所以无法删除，你只有先删除容器，再删除镜像。如下图：

容器就是镜像上面再加上一个读写层。容器在运行的时候是使用镜像的（在建立的容器的时候会指定要使用的镜像），当它停止的时候就是一个读写层，并不包括镜像。

关于在容器中的写入操作：我们之前说到容器就是一个读写层（停止的容器），容器运行起来就是镜像加读写层，当我们需要修改只读层中的某些数据的时候，联合文件系统会把我们要修改的内容复制到读写层，然后进行修改，修改之后会被保存在读写层，而原来只读层中的数据会被隐藏，这样保证只读层中的数据永远不会被修改，这种机制叫做写时复制。

在镜像层和读写层直接还有一个容器初始化层，这就是要加载一下容器独有的东西，如下图：这个也就是上面提到的containers目录。

主机名、hosts表、还有DNS服务器配置都在容器自己的目录下。

总结：

镜像属于静态内容因为是只读的，容器属于动态内容，容器其实就是一个进程，只是它有点特殊，它运行的时候会基于镜像去构建，那么就会根据镜像的JSON来完成每一层镜像需要做什么，这部分工作完成以后就是容器的初始化层和读写层，以后的读写操作就会在读写层层进行。基于同一个镜像创建的多个容器共享一个文件系统（也就是底层镜像），通过命名空间的隔离，这样它们就从逻辑上进行了隔离，因为它们共享rootfs所以看起来都是完整的操作系统，再通过写时复制技术保障了每个容器都可以拥有自己单独的修改部分而不会影响其他容器，同时也不会因为产生100容器而产生100个镜像副本。

附加说明：存储驱动（Storage Driver）

Docker上目前可以使用多种存储驱动，比如devicemapper、aufs、btrfs、zfs、overlay、overlay2等。如何查看当前使用的那种存储驱动呢？

记得前面的章节我们特意在安装前看过系统是否有devicemap这个驱动，但是为什么这里没用呢？因为Docker默认使用overlay，不过我们可以更换。使用--storage-driver参数

首先停止服务

建立devicemapper设备

过程略，其实就是建立一个逻辑卷。

修改配置文件

一般设置这三项内容，我这里以修改daemon.json为例。/dev/sdb1是你的物理磁盘，通常存放镜像和容器的都需要使用单独磁盘或者分区。

或者通过修改docker.service文件进行设置

在/etc/docker/下建立daemon.json文件

如何查找你的可用devicemapper设备？

我这里只有一个根分区和交换分区

启动服务

我这里并没有真正改变，只是演示一下过程。使用Devicemapper

使用overlay

首先要确保系统安装并加装了overlay的驱动

aufs：已经过时了不推荐使用

devicemapper：提供写时复制快照。为每一个devicemapper定义一个位置。

overlay：一个非常稳定的联合文件系统，它现在已经被植入到Linux内核中，从3.18.0内核版本开始。它也支持内存页缓存共享，这就是意味着多个容器访问相同文件可以共享一个单一缓存条目。

overlay2：在内核版本4.0开始提供

本文转自linuxjavachen  51CTO博客，原文链接：http://blog.51cto.com/littledevil/1863970，如需转载请自行联系原作者