本文由 发布，转载请注明出处，如有问题请联系我们！ 发布时间: 2021-07-24docker容器技术基础之联合文件系统OverlayFS
加载中我们在上篇详细介绍了容器技术存储资源防护与限定docker容器技术基本之linux cgroup、namespace
这篇小短文我们要试着学习培训器皿的此外一个关键技术性之协同系统文件之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给予了2个储存推动，初始的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协同系统文件早已详细介绍完啦，期待这三篇小短文对想掌握器皿完成基本原理的阅读者有一丝协助。
参照：
Use the OverlayFS storage driver
Understanding Container Images, Part 3: Working with Overlays
小短文有不够的地区热烈欢迎强调。
谢谢个人收藏、关注点赞。关心顶尖立式饮水机管理人员，除开烧开水，有时候还做些其他。
您的适用就是我烧开水较大 的驱动力...
