17.认识下Docker之docker的核心原理（2）

本文介绍: 不知道大家看没看过小说《完美时间》，里面石昊经常进入一个小世界在里面与世隔绝的修炼或者战斗，总之就是在一个完全封闭的空间里做他想做的事情而与外界隔离，不受侵扰。通过前面的分析我们知道，Na m e p ace让应用进程只能看到该 Na m e space 内的“小世界”；而 Cgroup s 的作用是“限制”，它给这个“小世界”围上了一圈看不见的封印。

1.容器-我的小世界

不知道大家看没看过小说《完美时间》，里面石昊经常进入一个小世界在里面与世隔绝的修炼或者战斗，总之就是在一个完全封闭的空间里做他想做的事情而与外界隔离，不受侵扰。通过前面的分析我们知道，Na m e p ace让应用进程只能看到该 Na m e space 内的“小世界”；而 Cgroup s 的作用是“限制”，它给这个“小世界”围上了一圈看不见的封印。在小说中的“小世界”，不仅仅是这么一个空间，里面如同一个真实世界一样，有大地及大地上的各种物品，对比到容器，那么容器这个小世界还缺少文件系统，比如启动一个 ubuntu或者centos 容器，里面我们看到是一份完整的操作系统目录，这个文件系统就是通过Mo u n t Na mes cp ace来实现的。当我们启动容器进程时，先启用Mou n t Name space,然后挂载指定的目录。
下面是我启动的一个 centos的容器，然后进入到容器，
在这里插入图片描述
我们看到，根目录下我们看到的真实的操作系统一样，是一个完整的操作系统文件。这是为了让容器这个根目录看起来更真实，一般会在容器的根目录下挂载一个完整操作系统的文件系统，我们把这个文件系统就是所谓的“容器镜像 image”,学名rootfs(根文件系统)。由于Mon u t Name space的存在，这个挂载对宿主机不可见，只对当前容器进程起作用，这样就可以随便在容器内部折腾了。那这是怎么做到的呢？
其实在 Lin u x 操作系统里，有一个名为 ch root 的命令,可以在 shell 中方便地完成这个工作。它的作用就是帮我们“change root file system”，即改变进程的根目录到你指定的位置。
所以，docker 运行容器，就是在宿主机上运行一个特殊的进程，dock er为这个进程启动Lin u x Na mes p ace 配置，设置指定的Cg roups 参数、切换进程的根目录（Cha n g e Root）。
虽然这里的root fs根文件系统包含了一个操作系统完整的文件、目录和配置，但是却没系统内核，操作系统只有在开机的时候才会加载指定版本的内核镜像。也就是说，root fs很像一完美时间小说中仙体，只有躯壳，没有灵魂。
部署在同一台机器上的所有容器，都共享宿主机操作系统的内核。

2.镜像-对环境 一致性的理解

在开始的一掌节，我也介绍了dock er的好处，就是保持环境的一致性，这里再加深一下理解。拿java 项目来说，这里所说的环境一致性，不仅仅是说用的jar包的版本一致、jdk的版本一致，更重要的是，来操作系统都一致，正式这种深入到操作系统级别的运行环境一致性，才打通了应用在本地开发和远端执行环境之间难以逾越的鸿沟。

3.镜像-联合文件系统

对于联合文件系统，之前我也提过，但并不是太详情，这里我以示例的方式说名一下，从根本上理解这个东西。

现在doc k er 使用的联合文件系统时overlay,这里我们先简单说一下overlay fs。overlay fs联合文件系统可让你使用2个目录挂载文件系统：“下层”目录和“上层”目录。文件系统的下层目录是只读的，文件系统的上层目录可以读写。当进程“读取”文件时，overlay fs文件系统驱动将优先在上层目录up per dir中查找并从该目录中读取文件，找不到则在下层目录low er dir中查找。当进程”写入“文件时，overla y fs会将其写入上层目录up per dir。

3.2 联合文件系统-overla y fs 演示 示例

这里我就以overlay来演示一下。

首先创建几个目录：在my file下创建 low e r、up per、work、merge d

mkdir -p myfile/lower myfile/upper myfile/work myfile/merged

然后，我在up per目录下创建a.txt,m.txt 两个文件，在lower目录下，创建b.txt,m.txt
在这里插入图片描述
 执行挂载命令：

mount -t overlay overlay -o lowerdir=lower,upperdir=upper,workdir=work /myfile/merged

解释下这个命令
 lowerdir参数：下层目录，可以挂载多个下层目录，多个目录之间采用分号分隔，如下所示：

mount -t overlay overlay -o lowerdir=/dir1:/dir2:/dir3 ./merged

up perdir参数：上层目录；
merged目录：lower和up per合并后的虚拟目录。同时也是容器挂载点，lo werdir和up perdir整合起来提供统一的视图给容器，作为根文件系统；
查看 merged目录下的文件
在这里插入图片描述
我们看到，x.txt 显示的是upper目录的内容。

3.3联合文件系统-overlay f s合并规则

我这里就不一一演示了，把合并和读写规则说一下；
合并规则整理如下：
1.读规则：

upper没有, 而lo wer有的文件时，需从lower读；
只在upper有的文件时，则直接从 upper 读
lower 和 upper 都有的文件时，则直接从 upper 读。

2.写规则：

对只在 upper 有的文件时，则直接在 upper 写
对在lower 和 upper 都有的文件时，则直接在 upper 写。
对只在 lower 有的文件写时，则会做一个拷贝的操作，先从 lower将文件拷贝一份到upper,写的操作只对从lower 复制到 upper 的文件生效，而 lower 还是原文件。

3.删除规则：

lower 和 upper 都有的文件，upper 的会被删除，在 upper 目录下创建一个 ‘wi thout’ 文件，而 lower 的不会被删除。
lower 有而 upper 没有的文件时，会为被删除的文件在 upper 目录下创建一个 ‘wi thout’ 文件，而 lower 的不会被删除。
lower 和 upper 都有的目录时，upper 的会被删除，在 upper 目录下创建一个类似‘wi thout’ 文件的 ‘op aq ue’ 目录，而 lower 的不会被删除

3.镜像–分层

之前我们介绍过，镜像制作是分层的，Doc kerfile中的每一个命令都是一个层。那么为什么要分层呢？其实就是考虑镜像的复用性。·
加入我现在在用 Centos7.6操作系统做了一个 image，然后又在里面安装了 Java 环境，用来部署我的 Java 应用。这时其他人也希望能够直接使用我安装过 Java 环境的 image，而不是重复这个流程。那怎么办号呢？
我想到的比较简单的方法是在制作镜像的时候，每做一步“有意义”的操作，就保存一个镜像出来，这样其他人就可以按需求去用他需要的 root f s 了。可一旦其他人修改了这个镜像，新旧两个新旧两个镜像之间就没有任何关系了。这样做的结果就会产生非常的没有任何关联的镜像，也就是碎片化严重。那么，既然这些修改都基于一个旧的 image，我们能不能以增量的方式去做这些修改呢？这样做的好处是，所有人都只需要维护相对于 base root f s 修改的增量内容，而不是每次修改都制造一个“fork”。由此，产生了分层的概念。Docker 在镜像的设计中，引入了层（layer）的概念。即用户制作镜像的每一步操作，都会生成一个层，也就是一个增量镜像。镜像主要分为三个层：只读层、可读写层、init层。

3.1镜像-只读层

只读层，位于联合文件系统的最下层，对应overlay f s中的lower目录；

3.2镜像-可读写层

可读写层，位于联合文件系统的最上层，对应overlay f s中的upper目录中。他也称为容器层，在没有写入文件之前，这个目录是空的。而一旦在容器里做了写操作，你修改产生的内容就会以增量的方式出现在这个层中。
所以，最上面这个可读写层的作用，就是专门用来存放你修改 rootfs 后产生的增量，无论是增、删、改，都发生在这里。

3.3镜像-init层

它是一个以“-init”结尾的层，夹在只读层和读写层之间。In it 层是 Docker 项目单独生成的一个内部层，专门用来存放 /etc/hosts、/etc/res ol v.conf 等信息。

3.4.镜像分层–copy–on–write

这里还有一个c opy-on–write 机制，这里简单说一下。
我们知道，最上面的可读写层也被称为容器层，下面的只读层称为镜像层，所有的增删查改操作都只会作用在容器层，相同的文件上层会覆盖掉下层。比如修改一个文件的时候，首先会从上到下查找有没有这个文件，找到，就复制到容器层中，然后在容器层中修改，修改的结果就会作用到下层的文件，这种方式也被称为c opy-on–write。