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 4月 17 17:03 a
-rw-r--r-- 1 root root 2 4月 17 17:10 b
-rw-r--r-- 1 root root 2 4月 17 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 4月 17 17:02 a
-rw-r--r-- 1 root root 2 4月 17 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 4月 17 17:03 a
-rw-r--r-- 1 root root 6 4月 17 17:25 b
-rw-r--r-- 1 root root 6 4月 17 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月