Docker挂了，数据如何找回

docker在实际使用中，让运维人员诟病的，除了安全问题外，大概就是数据的问题了

很多人在初用docker的时候，很多时候都忘记或不知道docker中需要保留的数据需要挂载到宿主机文件夹到容器内部对应目录（当然除了挂载宿主机目录，还有其他解决方案，我们后面会有文章介绍）

当容器因为某些原因挂掉、无法重新启动的时候，他们就认为数据丢失了，找不回了，这也是很多人对docker的一个认识误区，网上没有一篇文章说docker数据的问题，今天详细解释下，docker数据在哪里

首先说一下这边以docker-ce 19.03.4版本举例，GraphDriver是overlay2

这里说明下，overlay技术是一种虚拟网络技术，这里说的overlay是overlayfs，是一种联合文件系统

我们通过docker info简单查看Storage Driver

也可以通过docker inspect 查看镜像或容器的详细信息

在GraphDriver部分可以看到使用的是什么文件系统，之前旧内核的系统中的docker的GraphDriver是使用DeviceMapper，由于overlay2性能比devicemapper好，而且新版本docker-ce默认采用，所以这里只研究overlay2

从上面的截图可以看到GraphDriver的data部分有四部分，分别是LowerDir、MergerDir、UpperDir、WorkDir，解释这几个概念之前，先来回顾下docker的镜像的分层原理

docker镜像是一种轻量可执行的独立软件包，用来打包软件运行的环境和基于运行环境开发的软件，它包含运行某个软件所需要的所有内容，包括代码、运行时的库、环境变量和配置文件

docker的镜像实际上由一层一层的文件系统组成，这种层级的文件系统称为联合文件系统(unionFS)

UnionFS（联合文件系统）：union文件系统（unionFS）是一种分层、轻量级并且高性能的文件系统，它支持对文件系统的修改作为一次提交来一层层的叠加，同时可以将不同的目录挂载到同一个虚拟文件系统下。union文件系统是docker镜像的基础。镜像可以通过分层来进行继承。基于基础镜像（没有父镜像），可以制作各种的应用镜像

这种分层最大的好处就是资源共享

很多时候，你pull镜像的时候，如果是来源于相同的base镜像，你可以看到，pull的时候，底下的层是已经pulled，而且base64加密id是一样的，这就是因为base镜像资源已经下载，可以共享使用，不需要重复下载

在容器中，伴随联合文件系统的一个技术就是写时复制(CoW)，该技术是linux内核的一个技术，为了避免不必要的进程间复制操作，在父进程fork子进程后，父子进程共享同一副本，当子进程需要调用exec写入的时候，数据才会被复制，从而父子进程各自有自己的副本

结合容器技术来看，当处于镜像态的时候，所有的层级都是只读的，但是当docker run启动为容器态的时候，在基础镜像上添加了一层可读写层，这时肯定会在最上层，可读写层进行文件写入，就需要将要写入的文件从它存在的层复制到可读写层，然后进行读写，并隐藏只读层的旧文件，这个就是利用了写时复制技术

回顾了这些基础之后，接着看下overlay2的基础概念及原理

overlayfs在linux主机上只有两层，一个目录在下层，用来保存镜像(docker)，另外一个目录在上层，用来存储容器信息。在overlayfs中，底层的目录叫做lowerdir，顶层的目录称之为upperdir，对外提供统一的文件系统为merged。当需要修改一个文件时，使用CoW将文件从只读的Lower复制到可写的Upper进行修改，这个复制出来的临时目录就是Workdir，结果也保存在Upper层

以上就是GraphDriver的data部分的四部分，可以从前面的图中看到lowerdir，包含多个层，因为它就是rootfs，容器镜像，也就是我们pull镜像的时候看到的层级

overlay2存储在/var/lib/docker/overlay2目录中，如果你只有少数镜像，比较好查看，多个镜像的时候，就只能通过docker inspect的方式查找对应镜像的层级id，然后通过这个id去overlay2目录去找对应的overlayfs目录

在该目录下有个“l”目录，这个目录是存放所有overlayfs目录的短名称的，通过软连接的方式与overlyafs目录下的所有目录链接，这个是为了在mount挂载的时候避免参数太长，达到页面大小限制

接着我们分别看下LowerDir、MergerDir、UpperDir、WorkDir

我这里通过个redis容器来说明，首先是lowerdir，lowerdir因为有多个，你可以一个一个进去看一下，就能够看明白它每个层级存储的东西，如下：

"LowerDir": "/var/lib/docker/overlay2/3d56c8ea55a05f092442c3cdf01c49556a71b8f089a5772413ef566ec68bca31-init/diff

:/var/lib/docker/overlay2/7e6a11d051174f5a71ce038268e6fa8a310d046032ed435b10ed7846f9eb2d92/diff

:/var/lib/docker/overlay2/bbcd520d1d0d62323bcac4a66328164b99fa1704974ceffc412d348c6f7b55e9/diff

/var/lib/docker/overlay2/dee456318494848b5ea4182ddb8f67f25969b121580afa9ff8aa73cf9c0d256e/diff

:/var/lib/docker/overlay2/a45bb32d7cd7d2386d12826e4d8e524b410616d06cf1ec29f2eab03ba3eb80b2/diff

:/var/lib/docker/overlay2/085f1022334a3727171e3d038ed59f69cb0c6199b93a84afeb1e0b1b8674abf1/diff"

从上面可以看出来，diff就是存储该层rootfs的目录，而每个层级里面的link文件里面存储的就是l文件夹下的短名称的超链接，除了最底层，上层都有一个lower文件，该文件里面就存储了它上层的短名称

而work目录，用来联合挂载指定的工作目录

接着看MergedDir、UpperDir、WorkDir其实是指向一个层级id，只是目录不同，是不是觉得这个id这么熟悉，其实在LowerDir的最上层的id就是这个，只不过它最后面有个init，这个init稍后介绍，先来看下这三个目录

mergedir对外提供统一的视图，这里可以看到整合了所有lowerdir层级的文件

因为是新启动的容器，upperdir目录没有内容，workdir目录因为写时复制很快，所以通常也无法看到，后面进入容器写入文件进行会在upperdir目录看到内容

关于init层

init层是以一个uuid+-init结尾表示，夹在只读层和读写层之间，作用是专门存放/etc/hosts、/etc/resolv.conf等信息，需要这一层的原因是当容器启动时候，这些本该属于image层的文件或目录，比如hostname，用户需要修改，但是image层又不允许修改，所以启动时候通过单独挂载一层init层，通过修改init层中的文件达到修改这些文件目的。而这些修改往往只在当前容器生效，而在docker commit提交为镜像时候，并不会将init层提交。该层文件存放的目录为/var/lib/docker/overlay2/<init_id>/diff

从上面这部分可以看到，所有容器或者镜像的层级目录都存在overlay2目录下，那么一个容器或者镜像是怎么把这些整合起来的？答案是元数据关联，元数据分为image元数据和layer元数据

镜像元数据存储在了/var/lib/docker/image/<storage_driver>/imagedb/content/sha256/目录下，名称是以镜像ID命名的文件，镜像ID可通过docker images查看，这些文件以json的形式保存了该镜像的rootfs信息、镜像创建时间、构建历史信息、所用容器、包括启动的Entrypoint和CMD等等，比如刚才的redis镜像

打开该文件，是一个json格式文件，但是没有vim默认没有格式化，通过:%!python -m json.tool工具转换成json格式查看

其中rootfs部分

可以看到对应前面的6层overlayfs，其排列也是有顺序的，从上到下依次表示镜像层的最低层到最顶层

diff_id如何关联进行层？具体说来，docker 利用 rootfs 中的每个diff_id 和历史信息计算出与之对应的内容寻址的索引(chainID) ，而chaiID则关联了layer层，进而关联到每一个镜像层的镜像文件

layer元数据中layer对应镜像层的概念，在 docker 1.10 版本以前，镜像通过一个 graph 结构管理，每一个镜像层都拥有元数据，记录了该层的构建信息以及父镜像层 ID，而最上面的镜像层会多记录一些信息作为整个镜像的元数据。graph 则根据镜像 ID(即最上层的镜像层 ID) 和每个镜像层记录的父镜像层 ID 维护了一个树状的镜像层结构。

在 docker 1.10 版本后，镜像元数据管理巨大的改变之一就是简化了镜像层的元数据，镜像层只包含一个具体的镜像层文件包。用户在 docker 宿主机上下载了某个镜像层之后，docker 会在宿主机上基于镜像层文件包和 image 元数据构建本地的 layer 元数据，包括 diff、parent、size 等。而当 docker 将在宿主机上产生的新的镜像层上传到 registry 时，与新镜像层相关的宿主机上的元数据也不会与镜像层一块打包上传。　　

Docker 中定义了 Layer 和 RWLayer 两种接口，分别用来定义只读层和可读写层的一些操作，又定义了 roLayer 和 mountedLayer，分别实现了上述两种接口。其中，roLayer 用于描述不可改变的镜像层，mountedLayer 用于描述可读写的容器层。具体来说，roLayer 存储的内容主要有索引该镜像层的 chainID、该镜像层的校验码 diffID、父镜像层 parent、storage_driver 存储当前镜像层文件的 cacheID、该镜像层的 size 等内容。这些元数据被保存在 /var/lib/docker/image/<storage_driver>/layerdb/sha256/<chainID>/ 文件夹下

每个chainID目录下会存在三个文件cache-id、diff、zize：

cache-id文件：

docker随机生成的uuid，内容是保存镜像层的目录索引，也就是/var/lib/docker/overlay2/中的目录，这就是为什么通过chainID能找到对应的layer目录

如图对应的overlay目录为/var/lib/docker/overlay2/e701317468246c6188f1bff4f9b9c159648d86108bb02e0ef5f224fd49efd1f0

diff文件：

保存了镜像元数据中的diff_id（与元数据中的diff_ids中的uuid对应）

size文件：

保存了镜像层的大小

在 layer 的所有属性中，diffID 采用 SHA256 算法，基于镜像层文件包的内容计算得到。而 chainID 是基于内容存储的索引，它是根据当前层与所有祖先镜像层 diffID 计算出来的，具体算如下：

如果该镜像层是最底层(没有父镜像层)，该层的 diffID 便是 chainID。
该镜像层的 chainID 计算公式为 chainID(n)=SHA256(chain(n-1) diffID(n))，也就是根据父镜像层的 chainID 加上一个空格和当前层的 diffID，再计算 SHA256 校验码。

综合上述一个完整的容器层如下图：