Docker：存储原理

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层。

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

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

1. 创建四个目录，表示不同层

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

2. 写入文件

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

3. 创建文件系统

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

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

熟悉的目录出现了，依次是centos层，test:v1新增的层，以及一个init层。

原先镜像的所有层，在容器实例化后，都变成了容器的LowerDir。

此处的init层，内部包含两个目录dev和etc，这在centos层中也有。其实这个init层，是容器初始化时的层，因为初始化时修改了dev和etc，由于写时拷贝，会把文件拷贝到init层再修改。

docker通过overlay来对容器分层，而镜像本身也被overlay分层了，所以这里使用了两次联合文件系统。

对于容器来说，将镜像作为LowerDir进行处理。而对于镜像来说，镜像本身的资源结构也被分层管理了，镜像的所有层，都作为容器的LowerDir层。

存储卷

绑定挂载

存储卷是基于绑定挂载实现的，绑定挂载是Linux中的一种挂载操作，它允许将一个文件或目录挂载到文件系统的另一个位置，从而在两个不同的路径下访问相同的文件或目录。这种挂载方式不会复制文件，而是创建一个指向原始文件或目录的引用。

可以使用mount命令来执行绑定挂载：

mount --bind <source> <target>

• source：要挂载的原始文件或目录的路径
• target：挂载点，即你希望文件或目录出现在的位置

要卸载绑定挂载，可以使用umount命令：

umount 挂载点

这将卸载/mnt/data的挂载点，但不会删除/data目录或其内容。

试验一下：

首先创建两个目录，在第一个目录中有三个文件，第二个目录是一个空目录。

把dir2绑定挂载到dir1：

此时dir2也出现了这三个文件，并且查询1.txt，可以发现两个文件的inode是一样的。

存储卷结构

Docker的存储卷，就是使用了绑定挂载，把宿主机的文件，与容器内部的文件进行绑定，此时两个文件其实是同一个文件，互相操作都是可以看到的。

那么问题来了，容器是有文件系统隔离的，在mount --bind时要指定两个文件，宿主机看不到容器内部的文件，容器内看不到宿主机的文件，如何才能mount --bind同时指定处于不同环境下的两个文件？

其实这是不可行的，被文件隔离的两个环境，是无法mount --bind绑定挂载两个文件的，因此要在容器创建后，文件隔离开启前，进行绑定挂载存储卷。

在容器创建后，会经过一段时间的初始化，文件隔离很早就会开启，但是开启文件隔离后，还要chroot命令，容器与宿主机的文件系统才相互不可见。

所以要在执行chroot命令之前，就进行绑定挂载：

顺便说一下，联合文件系统中，容器也是要访问宿主机中的镜像底层文件的，这也要在choroot之前完成挂载，让容器可以看到宿主机中的镜像文件，这基于联合挂载，是一种和绑定挂载不同的挂载方式，也是联合文件系统依赖的挂载方式。

联合挂载完毕后，就是存储卷的绑定挂载，最后执行chroot，两个文件系统彻底隔离。