docker容器云的搭建(docker容器技术基础之联合文件系统OverlayFS)
这篇小作文我们要尝试学习容器的另外一个重要技术之联合文件系统之OverlayFS,在介绍OverlayFS之前我们会学习一下镜像、容器、层的相关知识,然后是OverlayFS及相关实例,最后介绍docker中overlay2驱动即overlayfs在容器中的实现。
一、镜像、容器和层
docker中镜像是层级结构的,即图中的image layers,每一层只是与它之前的层的一组差异。这些层堆叠在彼此的顶部。当我们创建一个新容器时,会在镜像层加一个新的可写层。这一层通常被称为“容器层”。对正在运行的容器所做的所有更改,例如写入新文件、修改现有文件和删除文件,都将写入这个薄的可写容器层。
那么一个镜像创建多个容器时是怎样的景象呢?如下图所示,添加新数据或修改现有数据的所有写入容器都存储在此可写层中。当容器被删除时,可写层也被删除。底层镜像保持不变。因为每个容器都有自己的可写容器层,所有的变化都存储在这个容器层中,所以多个容器可以共享对同一个底层镜像的访问,同时又拥有自己的数据状态。
到这里你可能要问了:镜像为什么要分层啊?乱七八糟的!
其实不然,通过镜像的层级结构主要的一个优点是你可以把你的基础镜像进行共享,什么意思呢?比如你现在需要一个Nginx镜像、一个Tomcat镜像它们都可以通过一个base镜像如centos或者ubuntu制作而成,它看起来是这样的
如此一来通过镜像分层可以大大减少磁盘空间占用,同时降低镜像复构复杂度,何乐而不为。
二、联合文件系统OverlayFS
通过上面我们大概了解了镜像、容器和层的关系,那么又有一个问题了:镜像层和可写容器层的文件或者内容是如何来管理的?明明是分层的又是怎么合并的?
接下来我们将介绍UnionFS(联合文件系统),它的厉害之处在于可以将多个目录挂载到一个根目录。OverlayFS 是linux现代联合文件系统的一个代表,合并于Linux内核的3.18版本。从 docker 18.06后docker为OverlayFS提供了两个存储驱动,原始的overlay及overlay2(改善 inode 利用率),overlay2是目前docker推荐和首选存储驱动,通过它来管理镜像层和可写容器层内容。
我们可以在docker info中查看docker存储驱动版本
[root@i-k9pwet2d ~]# docker info
...
Server Version: 20.10.6
Storage Driver: overlay2
Backing Filesystem: extfs
...
OverlayFS这种堆叠的文件系统,依赖于其他文件系统之上,比如我们在info 中看到的extfs或者xfs等,它的结构如下图:
我们的基础层称为“lowerdir”即原始文件所在的位置。
客户端所做的任何修改都将反映在“upperdir”层上:
- 如果更改文件,新版本将写入其中(file1)。
- 如果删除文件,将在该层上创建一个删除标记(file2)。
- 创建一个新文件(file4)。
最后,“merged”是所有层合并后的最终视图。
假如你有一些数据,需要多个进程来访问和修改它。每个进程都要创建一个独立的数据视图,你要存储多份原始数据,数据量大的话显然这会非常低效的。使用OverlayFS将会是very good!
接下来我们来我们搞个实验看看
我建立如下目录结构,workdir在OverlayFS中需要为空,用作内部临时存储。lowerdir包含3个文件file1、file2、file3
[root@i-k9pwet2d overlayfs_test]# tree .
.
├── client_1
│ ├── upperdir
│ └── workdir
├── client_2
│ ├── upperdir
│ └── workdir
├── lowerdir
│ ├── file1.txt
│ └── file2.txt
│ └── file3.txt
└── merged
├── client_1
└── client_2
10 directories, 3 files
挂载overlay
mount -t overlay overlay
-o lowerdir=/overlaytest/lowerdir
-o upperdir=/overlaytest/client_1/upperdir
-o workdir=/overlaytest/client_1/workdir
/overlaytest/merged/client_1
mount -t overlay overlay
-o lowerdir=/overlaytest/lowerdir
-o upperdir=/overlaytest/client_2/upperdir
-o workdir=/overlaytest/client_2/workdir
/overlaytest/merged/client_2
挂载后查看我们的视图,可以看到三个文件已经被合并到merged区了
[root@i-k9pwet2d overlaytest]# tree .
.
├── client_1
│ ├── upperdir
│ └── workdir
│ └── work
├── client_2
│ ├── upperdir
│ └── workdir
│ └── work
├── lowerdir
│ ├── file1.txt
│ ├── file2.txt
│ └── file3.txt
└── merged
├── client_1
│ ├── file1.txt
│ ├── file2.txt
│ └── file3.txt
└── client_2
├── file1.txt
├── file2.txt
└── file3.txt
下一步我们修改merged/client_1下修改我们的大数据
[root@i-k9pwet2d client_1]# echo "data no.1">>file1.txt
[root@i-k9pwet2d client_1]# rm file2.txt
[root@i-k9pwet2d client_1]# echo "data4" > file4.txt
[root@i-k9pwet2d client_1]# ls
file1.txt file3.txt file4.txt
再看我们的视图,可以看到修改只作用于client_1/upperdir,对我们lowerdir下原始数据以及client_2数据并不影响。
[root@i-k9pwet2d overlaytest]# tree .
.
├── client_1
│ ├── upperdir
│ │ ├── file1.txt
│ │ ├── file2.txt
│ │ └── file4.txt
│ └── workdir
│ └── work
├── client_2
│ ├── upperdir
│ └── workdir
│ └── work
├── lowerdir
│ ├── file1.txt
│ ├── file2.txt
│ └── file3.txt
└── merged
├── client_1
│ ├── file1.txt
│ ├── file3.txt
│ └── file4.txt
└── client_2
├── file1.txt
├── file2.txt
└── file3.txt
12 directories, 12 files
OverlayFS在容器中的实现
下图显示了 在Docker 中镜像和 容器是如何通过OverlayFS分层与互相构造的映射。图像层是lowerdir,容器层是upperdir。统一视图合并到merged目录,该目录实际上是容器安装点。
我们查看一个真正运行容器centos的inspect
docker inspect ca9a9e0a35c7
可以看到OverlayFS对应的目录地址,lowerDir即我们的原始数据包含image的rootfs(根文件)以及init相关文件,关于docker init层可以自行检索一下哈,这里不做介绍了。
"GraphDriver": {
"Data": {
"LowerDir": "/var/lib/docker/overlay2/444808f5d6566eebf4ea73ea593b2c2076d4347ff57bd98cbc179dbac9265968-init/diff:/var/lib/docker/overlay2/0d6b94986ba1af1cc75e7c237f78d7e02d40f5ae5ec3f67ddb699ae6d07a2ca8/diff",
"MergedDir": "/var/lib/docker/overlay2/444808f5d6566eebf4ea73ea593b2c2076d4347ff57bd98cbc179dbac9265968/merged",
"UpperDir": "/var/lib/docker/overlay2/444808f5d6566eebf4ea73ea593b2c2076d4347ff57bd98cbc179dbac9265968/diff",
"WorkDir": "/var/lib/docker/overlay2/444808f5d6566eebf4ea73ea593b2c2076d4347ff57bd98cbc179dbac9265968/work"
},
"Name": "overlay2"
},
到LowerDir下查看原始rootfs
[root@i-k9pwet2d client_1]# ls /var/lib/docker/overlay2/0d6b94986ba1af1cc75e7c237f78d7e02d40f5ae5ec3f67ddb699ae6d07a2ca8/diff
bin dev etc home lib lib64 lost found media mnt opt proc root run sbin srv sys tmp usr var
我们进入容器添加和删除文件看看
[root@i-k9pwet2d ~]# docker exec -it ca9a /bin/bash
[root@ca9a9e0a35c7 /]# echo "newfile" >file
[root@ca9a9e0a35c7 /]# rm /tmp/ks-script-esd4my7v
显然到到LowerDir下查看原始rootfs并不受影响而是把变更写入到了upperdir即容器层
cd /var/lib/docker/overlay2/444808f5d6566eebf4ea73ea593b2c2076d4347ff57bd98cbc179dbac9265968/diff
[root@i-k9pwet2d diff]# tree .
.
├── file
└── tmp
└── ks-script-esd4my7v
1 directory, 2 files
以上的操作也就是docker中所谓的CoW(写时复制)策略。在docker中overlay2驱动对联合文件系统操作的更多场景可以参阅官方文档
这样我们实现容器的三大基础技术Namespace、Cgroup、UnionFS联合文件系统已经介绍完啦,希望这三篇小作文对想了解容器实现原理的读者有些许帮助。
小作文有不足的地方欢迎指出。
感谢收藏、点赞。
,免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。