Docker:存储原理
镜像
联合文件系统
联合文件系统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
依次输出这三段路径的内容:
熟悉的目录出现了,依次是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
,两个文件系统彻底隔离。
标签:文件,存储,容器,文件系统,镜像,挂载,原理,Docker,txt From: https://blog.csdn.net/fsdfafsdsd/article/details/143367388