Docker 镜像读写层核心概念：rootfs、Union mount、image以及layser原理详解-CSDN博客

rootfs

Rootfs 代表一个 Docker Container 在启动时而非运行后其内部进程可见的文件系统视角或者是 Docker Container 的根目录。当然该目录下含有 Docker Container 所需要的系统文件、工具、容器文件等。

上面这张图展示了Linux系统中的两个重要的文件系统。

• bootfs 是指 Linux 系统启动时使用的文件系统**通常包含操作系统内核、启动加载程序和其他引导文件。**Linux 刚启动时会加载 bootfs 文件系统在Docker 镜像的最底层是引导文件系统 bootfs。这一层与我们典型的 Linux/Unix 系统是一样的包含 boot 加载器和内核。当 boot 加载完成之后整个内核就都在内存中了此时内存的使用权已由 bootfs 转交给内核此时系统也会卸载 bootfs。
• rootfs 是指 Linux 系统的根文件系统是系统的主要文件系统包含所有的文件和目录比如典型 Linux 系统中的 /dev, /proc, /bin, /etc 等标准目录和文件。rootfs 是一个虚拟的文件系统它由内核挂载并提供给用户空间。在 Linux 系统启动时内核会将 rootfs 挂载为根文件系统并将其作为所有其他文件系统的基础。

在Docker镜像中镜像是由不同的镜像层堆叠而成的我们常说镜像层都是只读的容器层是可写的。当容器启动时一个新的可写层被加载到镜像的顶部。 这一层通常被称作“容器层”“容器层”之下的都叫“镜像层”。所有对容器的改动无论添加、删除、还是修改文件都只会发生在容器层中。

如何理解这句话背后的原理是什么呢为什么要这样设计的呢

传统来说Linux 操作系统内核启动时内核首先会挂载一个只读read-only的 rootfs当系统检测其完整性之后决定是否将其切换为读写read-write模式或者最后在 rootfs 之上另行挂载一种文件系统并忽略 rootfs。 Docker 架构下依然沿用 Linux 中 rootfs 的思想。当 Docker Daemon 为 Docker Container 挂载 rootfs 的时候与传统 Linux 内核类似将其设定为只读read-only模式。在 rootfs 挂载完毕之后和 Linux 内核不一样的是Docker Daemon 没有将 Docker Container 的文件系统设为读写read-write模式而是利用 Union mount 的技术在这个只读的 rootfs 之上再挂载一个读写read-write的文件系统挂载时该读写read-write文件系统内空无一物。

正如 read-only 和 read-write 的含义那样该容器中的进程对 rootfs 中的内容只拥有读权限对于 read-write 读写文件系统中的内容既拥有读权限也拥有写权限。容器虽然只有一个文件系统但该文件系统由“两层”组成分别为读写文件系统和只读文件系统。

Union mount

Union mount 代表一种文件系统挂载的方式允许同一时刻多种文件系统挂载在一起并以一种文件系统的形式呈现多种文件系统内容合并后的目录。

一般情况下通过某种文件系统挂载内容至挂载点的话挂载点目录中原先的内容将会被隐藏。而 Union mount 则不会将挂载点目录中的内容隐藏反而是将挂载点目录中的内容和被挂载的内容合并并为合并后的内容提供一个统一独立的文件系统视角。 通常来讲被合并的文件系统中只有一个会以读写read-write模式挂载而其他的文件系统的挂载模式均为只读read-only。 实现这种 Union mount 技术的文件系统一般被称为 Union Filesystem较为常见的有 UnionFS、AUFS、OverlayFS 等。

假设在我们使用镜像 ubuntu 创建的容器中可以暂且将该容器整个 rootfs 当成是一个文件系统。上文也提到挂载时读写read-write文件系统中空无一物。既然如此从用户视角来看容器内文件系统和 rootfs 完全一样用户完全可以按照往常习惯无差别的使用自身视角下文件系统中的所有内容然而从内核的角度来看两者在有着非常大的区别。追溯区别存在的根本原因那就不得不提及 AUFS 等文件系统的 COWcopy-on-write特性。

COW 文件系统和其他文件系统最大的区别就是从不覆写已有文件系统中已有的内容。 由于通过 COW 文件系统将两个文件系统rootfs 和 read-write filesystem合并最终用户视角为合并后的含有所有内容的文件系统然而在 Linux 内核逻辑上依然可以区别两者那就是用户对原先 rootfs 中的内容拥有只读权限而对 read-write filesystem 中的内容拥有读写权限。

既然对用户而言全然不知哪些内容只读哪些内容可读写这些信息只有内核在接管那么假设用户需要更新其视角下的文件 /etc/hosts而该文件又恰巧是 rootfs 只读文件系统中的内容内核是否会抛出异常或者驳回用户请求呢答案是否定的。当此情形发生时COW 文件系统首先不会覆写 read-only 文件系统中的文件即不会覆写 rootfs 中 /etc/hosts其次反而会将该文件拷贝至读写文件系统中即拷贝至读写文件系统中的 /etc/hosts最后再对后者进行更新操作。 如此一来纵使 rootfs 与 read-write filesystem 中均由 /etc/hosts诸如 AUFS 类型的 COW 文件系统也能保证用户视角中只能看到 read-write filesystem 中的 /etc/hosts即更新后的内容。

当然这样的特性同样支持 rootfs 中文件的删除等其他操作。例如用户通过 apt-get 软件包管理工具安装 Golang所有与 Golang 相关的内容都会被安装在读写文件系统中而不会安装在 rootfs。此时用户又希望通过 apt-get 软件包管理工具删除所有关于 MySQL 的内容恰巧这部分内容又都存在于 rootfs 中时删除操作执行时同样不会删除 rootfs 实际存在的 MySQL而是在 read-write filesystem 中删除该部分内容导致最终 rootfs 中的 MySQL 对容器用户不可见也不可访。

了解了上面容器启动时的rootfs和文件挂载方式我们不禁要发出疑问即为什么docker要将容器这样设计在只读层上添加一个读写层的意义在哪儿去掉读写层的话会有什么问题

为什么镜像层都是只读的

1. 在Docker镜像的设计中一个镜像是由多个镜像层堆叠而成的。这样设计的好处是之一是有利于镜像层的复用从而节省存储空间。而可复用就要保证某个镜像的容器在运行中对该镜像层是不能修改的也就是只有当镜像层是只读的条件时才能保证多个容器可以同享某些镜像层。
2. 提高应用程序的可移植性。由于容器层是可写的容器中的应用程序可以在容器内部进行读写操作而不会影响到宿主机的文件系统。这样就可以使应用程序更加容易地移植到不同的环境中。

去掉读写层的话会有什么问题

如果在没有可写层的情况下那么容器对内部文件的任何更改操作都会直接影响到底层镜像层的内容。举个例子来说假设我们有一个基于Ubuntu操作系统的Docker镜像并且该镜像中已经包含了一个名为/etc/nginx/nginx.conf的Nginx配置文件。现在我们使用该镜像启动了一个容器并在容器中修改了/etc/nginx/nginx.conf文件将默认的Nginx欢迎页面修改为自定义的欢迎页面。如果这个容器使用的是没有可写层的配置那么对/etc/nginx/nginx.conf文件的修改会直接影响到镜像层中的该文件从而影响到所有基于该镜像构建的容器。也就是说所有从这个镜像启动的容器都将使用这个自定义的欢迎页面。

这种情况下如果仍然将镜像层共享复用的话就会导致以该本地nginx镜像层为基础创建的其他容器下的/etc/nginx/nginx.conf也被修改为自定义的欢迎页从而对其他镜像造成了影响。

为此为了避免容器对镜像层内容的影响通常都会使用可写层。可写层提供了一个可写的文件系统容器中的任何更改都会被记录在可写层中而不会直接影响到镜像层的内容。这种设计可以实现容器与镜像的分离容器层中的任何更改都不会影响到原始镜像的内容。

掌握 Docker 中 rootfs 以及 Union mount 的概念之后再来理解 Docker 镜像就会变得水到渠成。

Docker镜像image

Docker 中 rootfs 的概念起到容器文件系统中基石的作用。对于容器而言其只读的特性也是不难理解。神奇的是实际情况下 Docker 的 rootfs 设计与实现比上文的描述还要精妙不少。

继续以 ubuntu 为例虽然通过 AUFS 可以实现 rootfs 与 read-write filesystem 的合并但是考虑到 rootfs 自身接近 200MB 的磁盘大小如果以这个 rootfs 的粒度来实现容器的创建与迁移等是否会稍显笨重同时也会大大降低镜像的灵活性。而且若用户希望拥有一个 ubuntu 的 rootfs那么是否有必要创建一个全新的 rootfs毕竟 ubuntu 和 ubuntu 的 rootfs 中有很多一致的内容。

Docker 中 image 的概念非常巧妙的解决了以上的问题。最为简单的解释 image就是 Docker 容器中只读文件系统 rootfs 的一部分。换言之实际上 Docker 容器的 rootfs 可以由多个 image 来构成。多个 image 构成 rootfs 的方式依然沿用 Union mount 技术。

多个 Image 构成 rootfs 的示意图。图中rootfs 中每一层 image 中的内容划分只为了阐述清楚 rootfs 由多个 image 构成并不代表实际情况中 rootfs 中的内容划分。

从上图可以看出举例的容器 rootfs 包含 4 个 image其中每个 image 中都有一些用户视角文件系统中的一部分内容。4 个 image 处于层叠的关系除了最底层的 image每一层的 image 都叠加在另一个 image 之上。另外每一个 image 均含有一个 image ID用以唯一的标记该 image。

基于以上的概念Docker Image 中又抽象出两种概念Parent Image 以及 Base Image。除了容器 rootfs 最底层的 image其余 image 都依赖于其底下的一个或多个 image而 Docker 中将下一层的 image 称为上一层 image 的 Parent Image。imageID_0 是 imageID_1 的 Parent ImageimageID_2 是 imageID_3 的 Parent Image而 imageID_0 没有 Parent Image。对于最下层的 image即没有 Parent Image 的镜像在 Docker 中习惯称之为 Base Image。

通过 image 的形式原先较为臃肿的 rootfs 被逐渐打散成轻便的多层。Image 除了轻便的特性同时还有上文提到的只读特性如此一来在不同的容器、不同的 rootfs 中 image 完全可以用来复用。

多 image 组织关系与复用关系如图下图图中镜像名称的举例只为将 image 之间的关系阐述清楚并不代表实际情况中相应名称 image 之间的关系

Docker镜像层layer

Docker 术语中layer 是一个与 image 含义较为相近的词。容器镜像的 rootfs 是容器只读的文件系统rootfs 又是由多个只读的 image 构成。于是rootfs 中每个只读的 image 都可以称为一层 layer。

除了只读的 image 之外Docker Daemon 在创建容器时会在容器的 rootfs 之上再 mount 一层 read-write filesystem而这一层文件系统也称为容器的一层 layer常被称为 top layer。

因此总结而言Docker 容器中的每一层只读的 image以及最上层可读写的文件系统均被称为 layer。如此一来layer 的范畴比 image 多了一层即多包含了最上层的 read-write filesystem。

有了 layer 的概念大家可以思考这样一个问题容器文件系统分为只读的 rootfs以及可读写的 top layer那么容器运行时若在 top layer 中写入了内容那这些内容是否可以持久化并且也被其它容器复用

上文对于 image 的分析中提到了 image 有复用的特性既然如此再提一个更为大胆的假设容器的 top layer 是否可以转变为 image

答案是肯定的。Docker 的设计理念中top layer 转变为 image 的行为Docker 中称为 commit 操作大大释放了容器 rootfs 的灵活性。Docker 的开发者完全可以基于某个镜像创建容器做开发工作并且无论在开发周期的哪个时间点都可以对容器进行 commit将所有 top layer 中的内容打包为一个 image构成一个新的镜像。 Commit 完毕之后用户完全可以基于新的镜像进行开发、分发、测试、部署等。不仅 docker commit 的原理如此基于 Dockerfile 的 docker build其核心的思想也是不断将容器的 top layer 转化为 image。

Docker 镜像下载

Docker Image 作为 Docker 生态中的精髓下载过程中需要 Docker 架构中多个组件的协作。Docker 镜像的下载流程如图

1、docker client发送镜像的tag到registry。
2、registry根据镜像tag得到镜像的manifest文件返回给docker client。
3、docker client拿到manifest文件后根据其中的config的digest也就是image ID检查下镜像在本地是否存在。
4、如果镜像不存在则下载config文件并根据config文件中的diff_ids得到镜像每一层解压后的digest。
5、然后根据每层解压后的digest文件检查本地是否存在如果不存在则通过manifest文件中的6、layer的digest下载该层并解压然后校验解压后digest是否匹配。
7、下载完所有层后镜像就下载完毕。

Docker 镜像存储

Docker Daemon 执行镜像下载任务时从 Docker Registry 处下载指定镜像之后仍需要将镜像合理地存储于宿主机的文件系统中。更为具体而言存储工作分为两个部分

(1) 存储镜像内容

(2) 在 graph 中注册镜像信息。

说到镜像内容需要强调的是每一层 layer 的 Docker Image 内容都可以认为有两个部分组成镜像中每一层 layer 中存储的文件系统内容这部分内容一般可以认为是未来 Docker 容器的静态文件内容另一部分内容指的是容器的 json 文件json 文件代表的信息除了容器的基本属性信息之外还包括未来容器运行时的动态信息包括 ENV 等信息。

存储镜像内容意味着 Docker Daemon 所在宿主机上已经存在镜像的所有内容除此之外Docker Daemon 仍需要对所存储的镜像进行统计备案以便用户在后续的镜像管理与使用过程中可以有据可循。为此Docker Daemon 设计了 graph使用 graph 来接管这部分的工作。graph 负责记录有哪些镜像已经被正确存储供 Docker Daemon 调用。