个人网站页面设计素材,优秀的定制网站建设,公司广告推广,网站改版的原因前面我们知道了容器是通过对一个普通的linux进程进行隔离和限制实现的一种特殊视角下的进程表现。而隔离和限制的实现技术分别是Namespace和“Cgroups”,在这两种机制的控制下#xff0c;我们需要知道容器的本质是一种特殊的进程。
我们现在有了这个认知之后Namespace和“Cgroups”,在这两种机制的控制下我们需要知道容器的本质是一种特殊的进程。
我们现在有了这个认知之后我们再来思考一个问题容器在自己的进程视角下看到了一堆自己控制下的资源那么他看到的文件系统又是啥样的呢 我们很自然就想到这其实和容器的Mount Namespace的问题我们理解中在容器内部通过限制容器进程看到的是完全独立的文件系统这样它就能在自己的容器目录下进行操作而不用受到宿主机或者其他容器进程的影响。也就是说他是不是实现了文件系统级别的限制。
一、限制之下文件系统的表现
实际上我们上面说的不是对的即便你开启了Mount Namespace容器进程看到的文件系统和宿主机的文件系统是一模一样的。 这句话的意思就是实际上文件系统层面实际上没发生任何隔离和限制Mount Namespace修改的是容器进程对于文件系统挂载点的认知也就是说只有挂载这个操作发生之后进程的视图才会改变在这之前新创建的容器只会直接继承宿主机的各个挂载点。 换言之就是说我们需要在容器进程中先挂载对应的文件目录然后你的Mount Namespace才有效果。
这就是Mount Namespace和其他Namespace的使用略有不同他对于容器进程视图的改变一定是伴随挂载操作mount才能生效。 但是在用户视角下我们希望的是上手就操作屏蔽后面多的这一步我们就希望创建一个新的容器的时候创建好了就完事了不用我们自己去做挂载这一步。所以我们可以在容器进程启动之前重新挂载容器的整个根目录 / 即可然后进行Mount Namespace那么这个挂载就对其他容器和宿主机都是不可见的了。 在Linux操作系统中有一个名为chroot的命令就可以实现这个能力他的全称是change root file system翻译过来就是改变进程的根目录到你指定的位置。
二、chroot
我们来实际操作一下来使用一下这个命令。 假设我们现在有一个$HOME/test目录也就是家目录下的test目录我们想要把他作为一个/bin/bash进程的根目录。 1、首先创建一个test目录和几个lib文件夹 T$HOME/test
mkdir -p $HOME/test
mkdir -p $HOME/test/{bin,lib64,lib}
cd $T2、然后把 bash 命令拷贝到 test 目录对应的 bin 路径下 # 此时就把bin下面的bash 和 ls拷贝到了家目录下的test下的bin下面
# 后面我们进程挂载到这个test/bin下面就能直接使用bash和ls了
cp -v /bin/{bash,ls} $HOME/test/bin3、接下来把 bash 命令需要的所有 so 文件也拷贝到 test 目录对应的 lib64 路径下。找到 so 文件可以用 ldd 命令 T$HOME/test
list$(ldd /bin/ls | egrep -o /lib.*\.[0-9])
for i in $list; do cp -v $i ${T}${i}; done4、最后执行 chroot 命令告诉操作系统我们将使用 $HOME/test 目录作为 /bin/bash 进程的根目录此时就实现了这个挂载 chroot $HOME/test /bin/bash这时你如果执行 “ls /”就会看到它返回的都是 $HOME/test 目录下面的内容而不是宿主机的内容。更重要的是对于被 chroot 的进程来说它并不会感受到自己的根目录已经被“修改”成 $HOME/test 了。这种视图被修改的原理和之前介绍的 Linux Namespace 很类似实际上Mount Namespace 正是基于对 chroot 的不断改良才被发明出来的它也是 Linux 操作系统里的第一个 Namespace。
当然为了能够让容器的这个根目录看起来更“真实”我们一般会在这个容器的根目录下挂载一个完整操作系统的文件系统比如 Ubuntu16.04 的 ISO。这样在容器启动之后我们在容器里通过执行 “ls /” 查看根目录下的内容就是 Ubuntu 16.04 的所有目录和文件。 而这个挂载在容器根目录上、用来为容器进程提供隔离后执行环境的文件系统就是所谓的“容器镜像”。它还有一个更为专业的名字叫作rootfs根文件系统。所以一个最常见的 rootfs或者说容器镜像会包括如下所示的一些目录和文件比如 /bin/etc/proc 等等
$ ls /
bin dev etc home lib lib64 mnt opt proc root run sbin sys tmp usr var而你进入容器之后执行的 /bin/bash就是 /bin 目录下的可执行文件与宿主机的 /bin/bash 完全不同。现在你应该可以理解对 Docker 项目来说它最核心的原理实际上就是为待创建的用户进程 1、启用 Linux Namespace 配置 2、设置指定的 Cgroups 参数 3、切换进程的根目录Change Root。 这样一个完整的容器就诞生了。不过Docker 项目在最后一步的切换上会优先使用 pivot_root 系统调用如果系统不支持才会使用 chroot。这两个系统调用虽然功能类似但是也有细微的区别这一部分小知识就交给你课后去探索了。另外需要明确的是rootfs 只是一个操作系统所包含的文件、配置和目录并不包括操作系统内核。在 Linux 操作系统中这两部分是分开存放的操作系统只有在开机启动时才会加载指定版本的内核镜像。
三、 rootfs
上面我们引出了rootfs的概念但是我们也得知他就是一个文件系统不包括内核。 所以说rootfs 只包括了操作系统的“躯壳”并没有包括操作系统的“灵魂”。那么对于容器来说这个操作系统的“灵魂”又在哪里呢实际上同一台机器上的所有容器都共享宿主机操作系统的内核。这就意味着如果你的应用程序需要配置内核参数、加载额外的内核模块以及跟内核进行直接的交互你就需要注意了这些操作和依赖的对象都是宿主机操作系统的内核它对于该机器上的所有容器来说是一个“全局变量”牵一发而动全身。这也是容器相比于虚拟机的主要缺陷之一毕竟后者不仅有模拟出来的硬件机器充当沙盒而且每个沙盒里还运行着一个完整的 Guest OS 给应用随便折腾。不过正是由于 rootfs 的存在容器才有了一个被反复宣传至今的重要特性一致性。什么是容器的“一致性”呢
有了容器之后更准确地说有了容器镜像即 rootfs之后这个问题被非常优雅地解决了。由于 rootfs 里打包的不只是应用而是整个操作系统的文件和目录也就意味着应用以及它运行所需要的所有依赖都被封装在了一起。事实上对于大多数开发者而言他们对应用依赖的理解一直局限在编程语言层面。比如 Golang 的 Godeps.json。但实际上一个一直以来很容易被忽视的事实是对一个应用来说操作系统本身才是它运行所需要的最完整的“依赖库”。有了容器镜像“打包操作系统”的能力这个最基础的依赖环境也终于变成了应用沙盒的一部分。这就赋予了容器所谓的一致性无论在本地、云端还是在一台任何地方的机器上用户只需要解压打包好的容器镜像那么这个应用运行所需要的完整的执行环境就被重现出来了。这种深入到操作系统级别的运行环境一致性打通了应用在本地开发和远端执行环境之间难以逾越的鸿沟。
四、关于增量rootfs和Union File System
不过这时引出另一个非常棘手的问题难道我每开发一个应用或者升级一下现有的应用都要重复制作一次 rootfs 吗 比如我现在用 Ubuntu 操作系统的 ISO 做了一个 rootfs然后又在里面安装了 Java 环境用来部署我的 Java 应用。那么我的另一个同事在发布他的 Java 应用时显然希望能够直接使用我安装过 Java 环境的 rootfs而不是重复这个流程。类似于实现一种共享公共镜像的操作不用每个人做重复性的工作。
一种比较直观的解决办法是我在制作 rootfs 的时候每做一步“有意义”的操作就保存一个 rootfs 出来这样其他同事就可以按需求去用他需要的 rootfs 了。但是这个解决办法并不具备推广性。原因在于一旦你的同事们修改了这个 rootfs新旧两个 rootfs 之间就没有任何关系了因为产生了一个新的rootfs。这样做的结果就是极度的碎片化。那么既然这些修改都基于一个旧的 rootfs我们能不能以增量的方式去做这些修改呢这样做的好处是所有人都只需要维护相对于 base rootfs 修改的增量内容而不是每次修改都制造一个“fork”。我们只保存一份基础的每个人不同内容的自己维护一份增量就行了这样我们只每个人维护增量的内容。
答案当然是肯定的。这也正是为何Docker 公司在实现 Docker 镜像时并没有沿用以前制作 rootfs 的标准流程而是做了一个小小的创新Docker 在镜像的设计中引入了层layer的概念。也就是说用户制作镜像的每一步操作都会生成一个层也就是一个增量 rootfs。当然这个想法不是凭空臆造出来的而是用到了一种叫作联合文件系统Union File System的能力。Union File System 也叫 UnionFS最主要的功能是将多个不同位置的目录联合挂载union mount到同一个目录下。比如我现在有两个目录 A 和 B它们分别有两个文件A目录下面有a和x文件B目录下面有b和x两个文件。
$ tree
.
├── A
│ ├── a
│ └── x
└── B├── b└── x然后使用联合挂载的方式将这两个目录挂载到一个公共的目录 C 上
$ mkdir C
$ mount -t aufs -o dirs./A:./B none ./C这时再查看目录 C 的内容就能看到目录 A 和 B 下的文件被合并到了一起
$ tree ./C
./C
├── a
├── b
└── x可以看到在这个合并后的目录 C 里有 a、b、x 三个文件并且 x 文件只有一份。这就是“合并”的含义。此外如果你在目录 C 里对 a、b、x 文件做修改这些修改也会在对应的目录 A、B 中生效。那么在 Docker 项目中又是如何使用这种 Union File System 的呢 我的环境是CentOS Linux release 7.8.2003和Docker Engine - Community 20.10.14这对组合默认使用的是 overlay2这个联合文件系统的实现。你可以通过 docker info 命令查看到这个信息其栏目就是docker info中的Storage Driver: overlay2。 对于 overlay2 来说它最关键的目录结构在 /var/lib/docker 路径下的overlay2 目录
/var/lib/docker/overlay2/layer_id而这个目录的作用我们不妨通过一个具体例子来看一下。现在我们启动一个容器比如
$ docker run -d redis:latest sleep 3600这时候Docker 就会从 Docker Hub 上拉取一个redis镜像到本地。这个所谓的“镜像”实际上就是一个 redis的 rootfs它的内容是 Uredis的所有文件和目录。不过与之前我们讲述的 rootfs 稍微不同的是Docker 镜像使用的 rootfs往往由多个“层”组成
$ docker image inspect redis:latest
...RootFS: {Type: layers,Layers: [sha256:8553b91047dad45bedc292812586f1621e0a464a09a7a7c2ce6ac5f8ba2535d7,sha256:a29f3c086730b523ac2e1c55da793a9d63fc4c7167fa7196500011f4d0e5df05,sha256:bee68ae43a83b10c9f490448abb719304af02a834f3557fda199c6e408ae8cc7,sha256:df132c87bdb2ed2662fbcab6e9ecce353f6e8fe257797f442bc50bf70a78a089,sha256:c4afa995e3ec19959c6f9768d7ef6d8614717301ea4997b624de7aeaa2ff3690,sha256:47998e638469ca465758350e8f2a24675d6ae02600ac00baae447c3900ee337f]},可以看到这个 redis镜像实际上由六个层组成。这六个层就是六增量 rootfs每一层都是redis文件与目录的一部分而在使用镜像时Docker 会把这些增量联合挂载在一个统一的挂载点上等价于前面例子里的“/C”目录。这个挂载点就是 /var/lib/docker/overlay2/比如
/var/lib/docker/overlay2/8cfeca51edf8dab2e19ce574dbf1fc6d845ca38880b026bafdcc514c83d94e8b那么前面提到的五个镜像层又是如何被联合挂载成这样一个完整的 redis文件系统的呢
五、三层划分
我们说容器镜像是以多层划分开的一共分为三层从上到下分别是:
可读写层(RW):
它是容器的 rootfs 最上面的一层它的挂载方式为rw即 read write。
在没有写入文件之前这个目录是空的。而一旦在容器里做了写操作
你修改产生的内容就会以增量的方式出现在这个层中。可是你有没有想到这样一个问题
如果我现在要做的是删除只读层里的一个文件呢为了实现这样的删除操作
AuFS 会在可读写层创建一个 whiteout 文件把只读层里的文件“遮挡”起来。比如
你要删除只读层里一个名叫 foo 的文件那么这个删除操作实际上是在可读写层创建了一个名叫.wh.foo 的文件。
这样当这两个层被联合挂载之后foo 文件就会被.wh.foo 文件“遮挡”起来“消失”了。
这个功能就是“rowh”的挂载方式即只读 whiteout 的含义称之为隔档。
所以最上面这个可读写层的作用就是专门用来存放你修改 rootfs 后产生的增量
无论是增、删、改都发生在这里。而当我们使用完了这个被修改过的容器之后
还可以使用 docker commit 和 push 指令保存这个被修改过的可读写层并上传到 Docker Hub 上
供其他人使用而与此同时原先的只读层里的内容则不会有任何变化。这就是增量 rootfs 的好处。
说白了就是下面的基础层是不变的假如A用户做了修改变得只是A用户操作的部分以增量的方式写入可读写层
这样就其他用户的基础的只读层还是不变的。只有A自己的镜像发生了可读写层的改变
A自己维护就好了大家共享的只读层是不变的。
问题1、而且被whiteout遮挡的文件需要清除否则镜像就膨胀了。这个需要对镜像做压缩。网上很多方案。
问题2、如果对docker原始镜像进行修改 比如在ubuntu镜像上安装Java 那么修改的是可读写层。提交后变成只读层的最上面一层。原本已有的只读层不会变并再此基础上新增层 而不是整个只读层不会变即commit后就会将读写层的内容合并到只读层的最上层。init层(ROWH):
他的挂载方式是RO只读和WH隔档也就是这里的修改是会产生隔档的但是我们知道隔档是放在读写层的。
它是一个以“-init”结尾的层夹在只读层和读写层之间。Init 层是 Docker 项目单独生成的一个内部层
专门用来存放 /etc/hosts、/etc/resolv.conf 等信息。需要这样一层的原因是
这些文件本来属于只读的镜像的一部分但是用户往往需要在启动容器时写入一些指定的值比如 hostname
所以就需要在可读写层对它们进行修改。可是这些修改往往只对当前的容器有效
我们并不希望执行 docker commit 时把这些信息连同可读写层一起提交掉。
所以Docker 做法是在修改了这些文件之后以一个单独的层挂载了出来。
而用户执行 docker commit 只会提交可读写层所以是不包含这些内容的。
修改只对当前容器生效镜像提交只有可读写层没有这一层。换了容器这个修改就废了。
问题1、这一层中的文件的修改到底由谁以及什么时候触发的如果是在容器启动阶段修改的结果不是应该放到容器读写层吗是docker引擎做的在容器启动之前就做好这个层和其他层一起挂载好。然后容器才会创建。只读层(ROWH):
他的挂载方式是RO只读和WH隔档也就是这里的修改是会产生隔档的但是我们知道隔档是放在读写层的。
它是这个容器的 rootfs 最下面的五层对应的正是 镜像的五层。
它们的挂载方式都是只读的rowh即 readonlywhiteout。
可以看到这些层都以增量的方式分别包含了应用的一部分。最终这 7 个层(可读写五层加上init和只读层)都被联合挂载到 /var/lib/docker/overlay2/mnt 目录下表现为一个完整的应用供容器使用。
六、总结
Linux 容器文件系统的实现机制正是我们经常提到的容器镜像也叫作rootfs。它只是一个操作系统的所有文件和目录并不包含内核最多也就几百兆。 而相比之下传统虚拟机的镜像大多是一个磁盘的“快照”磁盘有多大镜像就至少有多大。通过结合使用 Mount Namespace 和 rootfs容器就能够为进程构建出一个完善的文件系统隔离环境。当然这个功能的实现还必须感谢 chroot 和 pivot_root 这两个系统调用切换进程根目录的能力。 而在 rootfs 的基础上Docker 公司创新性地提出了使用多个增量 rootfs 联合挂载一个完整 rootfs 的方案这就是容器镜像中“层”的概念。通过“分层镜像”的设计以 Docker 镜像为核心来自不同公司、不同团队的技术人员被紧密地联系在了一起。而且由于容器镜像的操作是增量式的这样每次镜像拉取、推送的内容比原本多个完整的操作系统的大小要小得多而共享层的存在可以使得所有这些容器镜像需要的总空间也比每个镜像的总和要小。这样就使得基于容器镜像的团队协作要比基于动则几个 GB 的虚拟机磁盘镜像的协作要敏捷得多。 更重要的是一旦这个镜像被发布那么你在全世界的任何一个地方下载这个镜像得到的内容都完全一致可以完全复现这个镜像制作者当初的完整环境。这就是容器技术“强一致性”的重要体现。
本文有些问题因为环境切换导致不太正确但是基本理论的学习本文主要是实际操作下篇开始。
现在docker新版本存储驱动都是layerfs的overlay2,我看官方文档也没说明怎么切换到aufs,要想切换在启动参数里指定即可因为我没指定所以其实是overlay2导致有些结果不一样。可以参考这篇文章https://blog.csdn.net/u010566813/article/details/117783220
