Docker底层unionfs(overlayfs)、rootfs和镜像分层的内含

Docker unionfs(overlayfs) 实现 rootfs

前提理论******
unionfs联合文件系统
Docker 中的文件存储驱动叫做 storage driver。

Docker 最早支持的stotage driver是 AUFS,它实际上由一层一层的文件系统组成,这种层级的文件系统叫UnionFS。

联合文件系统(UnionFS):Union 文件系统,是一种分层、轻量级并且高性能的文件系统,它支持对文件系统的修改作为一次提交来一层层的叠加,同时可以将不同目录挂载到同一个虚拟文件系统下(unite serveral directories into a single virtual filesystem)。

Union文件系统是Docker镜像的基础。镜像可以通过分层来进行集成,基于基础镜像可以制作具体的应用镜像。

特性:一次同时加载多个文件系统,但从外面看起来,只能看到一个文件系统,联合加载会把各层文件系统叠加起来,这样最终的文件系统会包含所有底层的文件和目录。

后来出现的docker版本中,除了AUFS,还支持OverlayFS、Btrfs、Device Mapper、VFS、ZFS等storage driver。

rootfs定位

置于整个容器的最底层。
在这里插入图片描述

bootfs和rootfs

bootfs(boot file system)主要包含 bootloader 和 kernel,bootloader主要是引导加载 kernel,Linux刚启动时会加载bootfs文件系统。

在Docker镜像的最底层是引导文件系统bootfs。这一层与我们典型的Linux/Unix系统是一样的,包含boot加载器和内核。当boot加载完成之后整个内核就都在内存中了,此时内存的使用权已经由 bootfs 转交给内核,此时系统也会卸载 bootfs。

rootfs(root file system),在bootfs之上,包含的就是典型Linux系统中的 /dev 、 /proc 、 /bin 、 /etc 等标准目录和文件。rootfs就是各种不同的操作系统发行版,比如Ubuntu、CentOS等,是copy-on-write资管管理技术叫写时复制的产物。
在这里插入图片描述

常用实现

AUFS

AUFS 只是 Docker 使用的存储驱动的一种,除了 AUFS 之外,Docker 还支持了不同的存储驱动,包括 aufs、devicemapper、overlay2、zfs 和 vfs 等等,在最新的 Docker 中,overlay2 取代了 aufs 成为了推荐的存储驱动,但是在没有 overlay2 驱动的机器上仍然会使用 aufs 作为 Docker 的默认驱动。

overlayfs

Overlayfs 是一种堆叠文件系统,它依赖并建立在其它的文件系统之上(例如 ext4fs 和 xfs 等等),并不直接参与磁盘空间结构的划分,仅仅将原来底层文件系统中不同的目录进行“合并”,然后向用户呈现。

简单的总结为以下3点:

(1)上下层同名目录合并;

(2)上下层同名文件覆盖;

(3)lower dir文件写时拷贝。

操作步骤

[root@master ~]# mkdir ovs
[root@master ~]# cd ovs/
[root@master ovs]# ll
总用量 0
[root@master ovs]# mkdir lower
[root@master ovs]# echo a > lower/a
[root@master ovs]# echo c > lower/c
[root@master ovs]# mkdir upper
[root@master ovs]# echo a1 > upper/a
[root@master ovs]# echo b > upper/b
[root@master ovs]# mkdir merged
[root@master ovs]# mkdir work
#初始内容如下
[root@master ovs]# tree ./
./
├── lower
│   ├── a
│   └── c
├── merged
├── upper
│   ├── a
│   └── b
└── work
    └── work
[root@master ovs]# mount -t overlay overlay -o lowerdir=./lower,upperdir=./upper,workdir=./work ./merged
[root@master ovs]# tree ./
./
├── lower
│   ├── a
│   └── c
├── merged
│   ├── a
│   ├── b
│   └── c
├── upper
│   ├── a
│   └── b
└── work
    └── work

merged 目录已经可以同时看到 lower和upper中的文件了,而由于文件a同时存在于lower和upper中,因此被覆盖了,只显示了一个a。现在可以查看下merged中a文件的值,发现是upper中的值,mount挂载的时候指定lower为lowerdir类型,upper为upperdir类型。
在这里插入图片描述

[root@master ovs]# cat merged/a
a1

lowerdir是限制为只读,无法进行任何写的操作。

upperdir支持可读可写,可以进行写的操作。

观察下面步骤,可以推出upper跟lower出现同名文件,在merged目录下同名文件内的值是upper目录文件的内容。

[root@master ovs]# echo a2 lower/a
a2 lower/a
[root@master ovs]# cat lower/a
a
[root@master ovs]# cat merged/a
a1

生成的/merged可以作为container的rootfs

思考??????

1、若是对merged目录下文件进行操作,lower、upper目录下文件内容会不会变化呢?

[root@master merged]# ll
总用量 12
-rw-r--r-- 1 root root 3 417 17:03 a
-rw-r--r-- 1 root root 2 417 17:10 b
-rw-r--r-- 1 root root 2 417 17:02 c
[root@master merged]# cat *
a1
b
c
[root@master merged]# echo testb > b
[root@master merged]# echo testc > c
[root@master merged]# cat *
a1
testb
testc

lower目录

[root@master lower]# ll
总用量 8
-rw-r--r-- 1 root root 2 417 17:02 a
-rw-r--r-- 1 root root 2 417 17:02 c
[root@master lower]# cat c
c
[root@master lower]#

upper目录

[root@master upper]# ll
总用量 12
-rw-r--r-- 1 root root 3 417 17:03 a
-rw-r--r-- 1 root root 6 417 17:25 b
-rw-r--r-- 1 root root 6 417 17:25 c
[root@master upper]# cat b c
testb
testc

出现了一个有意思的地方,upper目录本身就只有a和b俩个文件,突然就多了一个c文件,对比前面mount tree后的目录架构,这是在操作merged文件的时候生成的,而且lower值没有变动,却都生成在了upper下。

原因:因为lower不可进行写操作,所以采用了 CoW 技术,在对 c 进行修改时,复制了一份数据到 overlay 的 upperdir,从 lower copy 到 upper,也叫做 copy_up。

2、删除文件会发生事情呢?
现在lower目录生成一个f文件。

[root@master lower]# echo f > f
[root@master lower]# ll
总用量 12
-rw-r--r-- 1 root root 2 4
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值