Docker——镜像原理之联合文件系统和分层理解

文章目录

  • Docker——镜像原理之联合文件系统和分层理解
    • 1、联合文件系统
    • 2、分层结构
    • 3、分层实践——commit 提交镜像

Docker——镜像原理之联合文件系统和分层理解

1、联合文件系统

UnionFS( 联合文件系统)

UnionFS( 联合文件系统):Union文件系统(UnionFS )是一种分层、轻量级并且高性能的文件系统,它支持对文件系统的修改作为一次提交来一层层的叠加,同时可以将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtualfilesystem)。Union文件系统是Docker镜像的基础。镜像可以通过分层来进行继承,基于基础镜像(没有父镜像),可以制作各种具体的应用镜像。

另外,不同 Docker 容器就可以共享一些基础的文件系统层,同时再加上自己独有的改动层,大大提高了存储的效率。

Docker 中使用的 AUFS(AnotherUnionFS)就是一种联合文件系统。 AUFS 支持为每一个成员目录(类似 Git 的分支)设定只读(readonly)、读写(readwrite)和写出(whiteout-able)权限, 同时 AUFS 里有一个类似分层的概念, 对只读权限的分支可以逻辑上进行增量地修改(不影响只读部分的)。

Docker 目前支持的联合文件系统种类包括 AUFS, btrfs, vfs 和 DeviceMapper。

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

base 镜像

base 镜像简单来说就是不依赖其他任何镜像,完全从0开始建起,其他镜像都是建立在他的之上,可以比喻为大楼的地基,docker镜像的鼻祖。

base 镜像有两层含义:(1)不依赖其他镜像,从 scratch 构建;(2)其他镜像可以之为基础进行扩展。

所以,能称作 base 镜像的通常都是各种 Linux 发行版的 Docker 镜像,比如 Ubuntu, Debian, CentOS 等。

Docker 镜像加载原理

docker的镜像实际上由一层一层的文件系统组成,这种层级的文件系统就是UnionFS。

典型的 Linux 启动到运行需要两个FS,bootfs + rootfs:

Docker——镜像原理之联合文件系统和分层理解_第1张图片

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

rootfs (root file system),在bootfs之上。包含的就是典型Linux系统中的/dev, /proc, /bin, /etc等标准目录和文件。roots就是各种不同的操作系统发行版,比如Ubuntu,Centos等等。

Docker 镜像中为什么没有内核

从镜像大小上面来说,一个比较小的镜像只有1KB多点,或几MB,而内核文件需要几十MB, 因此镜像里面是没有内核的,镜像在被启动为容器后将直接使用宿主机的内核,而镜像本身则只提供相应的rootfs,即系统正常运行所必须的用户空间的文件系统,比如/dev/,/proc,/bin,/etc等目录,所以容器当中基本是没有/boot目录的,而/boot当中保存的就是与内核相关的文件和目录。

由于容器启动和运行过程中是直接使用了宿主机的内核,不会直接调用过物理硬件,所以也不会涉及到硬件驱动,因此也用不上内核和驱动。而如果虚拟机技术,对应每个虚拟机都有自已独立的内核

2、分层结构

Docker 镜像是一种分层结构,每一层构建在其他层之上,从而实现增量增加内容的功能,Docker 镜像下载的时候也是分层下载,以下载redis镜像为例:

Docker——镜像原理之联合文件系统和分层理解_第2张图片

Docker——镜像原理之联合文件系统和分层理解_第3张图片

可以看到,新镜像是从 base 镜像一层一层叠加生成的。每安装一个软件,就在现有镜像的基础上增加一层。

为什么 Docker 镜像要采用这种分层结构呢?

最大的好处,莫过于是资源共享了。比如有多个镜像都从相同的Base镜像构建而来,那么宿主机只需在磁盘上保留一份base镜像,同时内存中也只需要加载一份base镜像,这样就可以为所有的容器服务了,而且镜像的每一层都可以被共享。

可写的容器层

Docker 镜像都只是可读(read-only)的,当容器启动时,一个新的可写层被加载到镜像顶部。

这新的一层就是可写的容器层,容器之下都叫镜像层。

Docker——镜像原理之联合文件系统和分层理解_第4张图片

Docker通过一个修改时复制策略copy-on-write来保证base镜像的安全性,以及更高的性能和空间利用率。

  • 当容器需要读取文件的时候

从最上层的镜像层开始往下找,找到后读取到内存中,若已经在内存中,可以直接使用。换句话说,运行在同一台机器上的Docker容器共享运行时相同的文件。

  • 当容器需要修改文件的时候

从上往下查找,找到后复制到容器层,对于容器来说,可以看到的是容器层的这个文件,看不到镜像层里的文件,然后直接修改容器层的文件。

  • 当容器需要删除文件的时候

从上往下查找,找到后在容器中记录删除,并不是真正的删除,而是软删除。这导致镜像体积只会增加,不会减少。

  • 当容器需要增加文件的时候

直接在最上层的容器可写层增加,不会影响镜像层。

所有对容器的改动,无论添加、删除、还是修改文件都只会发生在容器层中。只有容器层是可写的,容器层下面的所有镜像层都是只读的,所以镜像可以被多个容器共享。

3、分层实践——commit 提交镜像

通过镜像创建容器,然后对容器层进行操作,镜像层不动,再把操作后的容器层和镜像层打包成一个新的镜像提交。

docker commit:用容器创建一个新的镜像。

语法:

docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]]

OPTIONS说明:

  • **-a *提交的镜像作者;
  • **-c *使用Dockerfile指令来创建镜像;
  • **-m *提交时的说明文字;
  • **-p *在commit时,将容器暂停。

使用实例:通过镜像创建容器,然后对容器层进行操作,再把操作后的容器层和镜像层打包成一个新的镜像提交。

1、先下载 tomcat 镜像

2、通过tomcat 镜像创建运行tomcat 容器:

docker run -d --name="tomcat01" tomcat

3、进入正在运行的tomcat容器:

docker exec -it tomcat01 /bin/bash

4、把tomcat容器 webapps.dist目录下的文件拷贝到webapps目录下:

cp -r webapps.dist/* webapps

5、docker commit 提交镜像

将容器 dc904437d987 保存为新的镜像,并添加提交人信息和说明信息,提交后的镜像名为tomcatplus,版本为1.0:

docker commit -a="wanli" -m="add webapps files" dc904437d987 tomcatplus:1.0

在这里插入图片描述

可以看到commit提交后的新 tomcat 镜像大小比原来的tomcat镜像要大一点,因为我们在容器层中进行了复制文件操作。

Docker——镜像原理之联合文件系统和分层理解_第5张图片

你可能感兴趣的:(Docker,Docker,ufs,分层结构,bootfs,rootfs)