Docker：存储原理

- 镜像
- - 联合文件系统
  - overlay
  - 镜像存储结构
  - 容器存储结构
- 存储卷
- - 绑定挂载
  - 存储卷结构

镜像

联合文件系统

联合文件系统Union File System是一种分层，轻量且高效的文件系统。其将整个文件系统分为多个层，层与层之间进行覆盖，并对外表现为一个一致的文件系统。

在这里插入图片描述

上图有三种操作，A(add)表示新建文件，C(change)表示修改文件，D(delete)表示删除文件。这个文件系统分为三层，但是对外用户只能看到红色这一层。

比如a.txt，在第二层就被删除了，那么用户看不到这个文件，但是其实这个文件依然被存储在文件系统的第一层中。删除文件只是一种标记，表示上层不可见，不会真的删除文件。

再比如b.txt，在第一层创建，在第二层修改，那么第二层的内容就会覆盖掉第一层的内容，用户看到第二层的内容。但是对于b.txt，其实保存了两份在文件系统中，第一份在第一层，第二份在第二层。

在红色层，其实是没有存储任何具体的文件的，而是存储了大量文件的引用。比如访问c.txt，其实访问到的是第二层中的文件，其并没有把文件系统内部的文件再进行一次拷贝。但是如果用户要修改文件，此时触发写时拷贝，那么会把该文件拷贝一份到当前层，然后再修改。比如b.txt在第二层进行了修改，其实就是把第一层的文件拷贝一份到第二层，然后再进行修改。所以先前才说b.txt在文件系统中保存了两份。

overlay

overlay是联合文件系统的一种具体实现，其也是Docker采用的联合系统方案。

在这里插入图片描述

overlay采用三层结构，每一层由一个目录管理。从下往上依次是：

lowerdir：最底层，内部的所有文件都是只读文件
upperdir：中间层，可以读写，可以在该层创建，删除，修改文件
merged：最顶层，也就是用户所看到的层，其基于前两层提供一个统一的视图

除去这三个层，还有一个workdir层，这层并不展示给用户，当upperdir层要修改文件时，会先在workdir层进行修改，只有操作完成后，才会同步到upperdir层。

读取文件：用户读取文件时，可以同时看到upperdir或者lowerdir层，只要文件没有被覆盖，就可以被读取到
写入文件：如果文件在upperdir层，直接进行修改，如果文件在lowerdir层，发生写时拷贝，将文件拷贝到upperdir层再修改
删除文件：如果文件在upperdir层，那么直接删除文件，如果文件在lowerdir层，不会删除文件，而是标记为不可见

对于大部分Linux系统，都是自带overlay文件系统的，可以基于mount命令模拟一下overlay文件系统。

在这里插入图片描述

在overlay中，其实一层就是一个目录，创建四个目录，后续在这四个目录上创建一个overlay文件系统。

写入文件

在这里插入图片描述

往lower和upper目录中写入一些文件，low.txt只在lower层出现，up.txt只在upper层出现，both.txt在两个层都出现。

创建文件系统

mount -t overlay overlay 
-o lowerdir=./lower,upperdir=./upper,workdir=./work ./merged

这个命令，会创建一个overlay文件系统，-t overlay表示文件系统类型，第二个overlay是一个应用程序，表示用这个程序来操控文件系统。

-o指定文件系统的相关参数，用,逗号分隔，可以看出分别代表lowerdir、upperdir、workdir三个层。

最后的./merged不是-o的参数，这是挂载点，表示用户最后通过./merged目录访问整个文件系统。

在这里插入图片描述

执行命令挂载成功后，./merged就被初始化了，其可以看到low.txt、up.txt、both.txt。

此处merged目录中，所有文件都是一个引用，文件都存储在lower和upper中。这可以通过查询inode来证明，如果两个文件的inode一样，那么在硬盘中指向的就是同一块空间，通过ls的-i参数。

在这里插入图片描述

查询merge和upper的up.txt文件，第一栏都是562812，也就是说两者inode相同，就是同一个文件。

借此，可以查看merge/both.txt使用的哪一层的内容：

在这里插入图片描述

可以看到merge/both.txt和upper/both.txt的inode = 562810，相同的，也就是说lower层的both.txt被覆盖了，用户看不到这层的both.txt。

修改merged/low.txt：

在这里插入图片描述

此时不仅仅是merged内部的low.txt改变了，而upper层多出一个low.txt，这是因为写时拷贝。如果修改的文件在lower层，会把文件拷贝到upper层再修改，不会影响原文件。

因此后续cat输出文件内容时，可以看到upper/low.txt是最新写入的内容，而lower/low.txt是一个空文件。

删除merge/low.txt：

在这里插入图片描述

删除文件后，lower层内部的文件还在，在upper目录下，多出一个low.txt，work也多出一个新内容。

看看多出的upper/low.txt：

在这里插入图片描述

其权限为c---------，也就是没有任何权限，这就是一个删除标记，表示这个文件虽然在lower中存在，但是已经被标记为删除了，所以用户看不到这个文件。

删除merge/up.txt：

在这里插入图片描述

此时这个up.txt真的就被删除了，没有任何标记，因为upper层本身就是可以读写的，删除文件并不会被标记。

实验完毕，可以通过umount卸载这个文件系统：

umount 挂载路径

在这里插入图片描述

那么这个联合文件系统，到底和Docker什么关系？

在这里插入图片描述

其实Docker就是使用的overlay结构存储文件，镜像层就是lowerdir层，容器层就是upperdir层，用户看到的是merged层。

一个镜像可以实例化为多个容器，就是因为所有容器都共用一个lowerdir层，因为这个层只读，不会修改镜像的内容，任何容器做的所有修改，都在自己的upperdir中。

镜像存储结构

docker inspect centos查看一个centos镜像的详细信息：

在这里插入图片描述

可以看到，在GraphDriver中，包含了三个熟悉的目录，MergedDir、UpperDir、WorkDir，并且使用的文件系统为overlay2。

查看这个UpperDir的内容：

在这里插入图片描述

这就是操作系统的根目录！所以每当创建一个centos容器时，看到的就是这个目录，让用户感觉自己处于一个新的操作系统中。

由于centos镜像，本身就是一个非常底层的镜像，所以它没有lowerDir，此时可以基于centos镜像再创建一个镜像：

在这里插入图片描述

以上操作，创建了一个centos容器，然后进去创建了三个文件，退出后通过commit创建了一个test:v1镜像。

docker inspect test:v1查看这个镜像的信息：

在这里插入图片描述

这个新建的镜像，就有LowerDir了，查看LowerDir的内容，其实就是centos镜像的内容，说明新的镜像把老的镜像作为了基底。

而在UpperDir中，是之前在容器内部创建的三个文件。

容器存储结构

刚才发现，在一个镜像内部，有upperdir层，lowerdir层，那么容器层去哪里了，不是说upper层是容器吗？为什么镜像也有upper层？

把刚才的test:v1镜像，实例化为一个容器：

docker run -d --name test test:v1

然后再查看容器的详细信息：

docker container inspect test

在这里插入图片描述

可以发现，容器也分为LowerDir、UpperDir等等内容，在LowerDir，有很长一个路径，细看可以看出是由:冒号分隔的三段路径：

/data/var/lib/docker/overlay2/9f8d970f2ece5d2ad7985cad1d12821e0c10355f60846ce5429207788b8b81ed-init/diff
/data/var/lib/docker/overlay2/20c74607fa2b73e5e419e6f2167e4220aa2b3f3e164cbaa928e8ed87421d3051/diff
/data/var/lib/docker/overlay2/ef10e4f37d8b8015c2319620bc8e391a824275741bc50e34bbf92392cb53c474/diff

依次输出这三段路径的内容：

在这里插入图片描述