之前讲过，Linux最基本的两个技术：Namespace 和 Cgroups，使我们理解容器的本质是一种特殊的进程
Namespace的作用是“隔离”，它让应用进程只能看到该 Namespace 内的“世界”，Cgroups的作用是“限制”，它给这个“世界”围上一圈看不见的墙，如此一来进程就被装在了一个与世隔绝的“房子”里。
但是容器里的进程看到的文件系统又是什么样子的呢？
你可能会想到Mount Namespace，容器里的应用进程，理应看到一份完全独立的文件系统。这样，它就可以在自己的容器目录（比如 /tmp）下进行操作，而完全不会受宿主机以及其他容器的影响。
真实情况是这样吗？
“左耳朵耗子”大神，之前写过一篇博客DOCKER基础技术，这里面曾经介绍过一段小程序，这段小程序的作用是，在创建子进程时开启指定的 Namespace。
#define _GNU_SOURCE
#include <sys/mount.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <stdio.h>
#include <sched.h>
#include <signal.h>
#include <unistd.h>
#define STACK_SIZE (1024 * 1024)
static char container_stack[STACK_SIZE];
char* const container_args[] = {
"/bin/bash",
NULL
};
int container_main(void* arg)
{
printf("Container - inside the container!\n");
execv(container_args[0], container_args);
printf("Something's wrong!\n");
return 1;
}
int main()
{
printf("Parent - start a container!\n");
int container_pid = clone(container_main, container_stack+STACK_SIZE, CLONE_NEWNS | SIGCHLD , NULL);
waitpid(container_pid, NULL, 0);
printf("Parent - container stopped!\n");
return 0;
}
这段代码的意思是：在 main 函数里，通过 clone() 系统调用创建了一个新的子进程 container_main，并且声明要为它启用 Mount Namespace（即：CLONE_NEWNS 标志）。而这个子进程执行的，是一个“/bin/bash”程序，也就是一个 shell。所以这个 shell 就运行在了 Mount Namespace 的隔离环境中。
编译代码
$ gcc -o ns ns.c
$ ./ns
Parent - start a container!
Container - inside the container!
这样，我们就进入了这个“容器”当中。可是，如果在“容器”里执行一下 ls 指令的话，我们就会发现一个有趣的现象： /tmp 目录下的内容跟宿主机的内容是一样的。
即使开启了 Mount Namespace，容器进程看到的文件系统也跟宿主机完全一样。
这其实并不难理解：Mount Namespace 修改的是容器进程对文件系统“挂载点”的认知，只有在“挂载”这个操作完成之后，进程的视图才会被修改，在此之前，新创建的容器会直接继承宿主机的每个挂载点。
这就是 Mount Namespace 跟其他 Namespace 的使用略有不同的地方：它对容器进程视图的改变，一定是伴随着挂载操作（mount）才能生效。
作为一个普通用户，我们希望的是一个更友好的情况：每当创建一个新容器时，我希望容器进程看到的文件系统就是一个独立的隔离环境，而不是继承自宿主机的文件系统。一个解决办法是：在容器进程启动之前重新挂载它的更目录“/”，而由于 Mount Namespace 的存在，这个挂载对宿主机不可见，所以容器进程就可以在里面随便折腾了。
在 Linux 操作系统里，有一个名为 chroot 的命令可以帮助你在 shell 中方便地完成这个工作。顾名思义，它的作用就是帮你“change root file system”，即改变进程的根目录到你指定的位置。它的用法非常简单
首先，创建一个 test 目录和几个 lib 文件夹：
$ mkdir -p $HOME/test
$ mkdir -p $HOME/test/{bin,lib64,lib}
然后，把 bash 命令拷贝到 test 目录对应的 bin 路径下：
$ cp -v /bin/{bash,ls} $HOME/test/bin
接下来，把 bash 命令需要的所有 so 文件，也拷贝到 test 目录对应的 lib 路径下。找到 so 文件可以用 ldd 命令：
root@482569f770eb:~/test/bin# ldd /bin/bash
linux-vdso.so.1 => (0x00007ffd50da3000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f587d272000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f587d06e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f587cca4000)
/lib64/ld-linux-x86-64.so.2 (0x00007f587d49b000)
为了简化流程，直接拷贝/lib到$HOME/test下
cp -r /lib $HOME/test/
cp /lib64/ld-linux-x86-64.so.2 lib64/
最后，执行 chroot 命令，告诉操作系统，我们将使用 $HOME/test 目录作为 /bin/bash 进程的根目录：
chroot $HOME/test /bin/bash
此时执行 "ls /"，就会看到，它返回的都是 $HOME/test 目录下面的内容，而不是宿主机的内容。
更重要的是，对于被 chroot 的进程来说，它并不会感受到自己的根目录已经被“修改”成 $HOME/test 了。
实际上，Mount Namespace 正是基于对 chroot 的不断改良才被发明出来的，它也是 Linux 操作系统里的第一个 Namespace。
为了能够让容器的这个根目录看起来更加“真实”，我们一般会在这个容器的根目录下挂载一个完整操作系统的文件系统。比如 Ubuntu16.04 的 ISO
而这个挂载在容器根目录上、用来为容器进程提供隔离后执行环境的文件系统，就是所谓的“容器镜像”。它还有一个更为专业的名字，叫作：rootfs（根文件系统）。
所以对Docker项目来说，它最核心的原理实际上就是为待创建的用户进程：
- 启用 Linux Namespace 配置
- 设置指定的 Cgroups 参数
- 切换进程的根目录（Change Root）
这样，一个完整的容器就诞生了。不过，Docker 项目在最后一步的切换上会优先使用 pivot_root 系统调用，如果系统不支持，才会使用 chroot。
另外，需要明确的是，rootfs 只是一个操作系统所包含的文件、配置和目录，并不包括操作系统内核。在 Linux 操作系统中，这两部分是分开存放的，操作系统只有在开机启动时才会加载指定版本的内核镜像。
所以说，rootfs 只包括了操作系统的“躯壳”，并没有包括操作系统的“灵魂”。那么，对于容器来说，这个操作系统的“灵魂”又在哪里呢？
实际上，同一台机器上的所有容器，都共享宿主机操作系统内核
这就意味着，如果你的应用程序需要配置内核参数、加载额外的内核模块，以及跟内核进行直接的交互，你就需要注意了：这些操作和依赖的对象，都是宿主机操作系统的内核，它对于该机器上的所有容器来说是一个“全局变量”，牵一发而动全身。
这也是容器相比于虚拟机的主要缺陷之一：毕竟后者不仅有模拟出来的硬件机器充当沙盒，而且每个沙盒里还运行着一个完整的 Guest OS 给应用随便折腾。
不过，正是由于 rootfs 的存在，容器才有了一个被反复宣传至今的重要特性：一致性。
对于大多数开发者而言，他们对应用依赖的理解，一直局限在编程语言层面。比如 Golang 的 Godeps.json。但实际上，一个一直以来很容易被忽视的事实是，对一个应用来说，操作系统本身才是它运行所需要的最完整的“依赖库”。
由于 rootfs 里打包的不只是应用，而是整个操作系统的文件和目录，也就意味着，应用以及它运行所需要的所有依赖，都被封装在了一起。
有了容器镜像“打包操作系统”的能力，这个最基础的依赖环境就变成了应用沙盒的一部分。这就赋予了容器所谓的一致性：无论在本地、云端，还是在一台任何地方的机器上，用户只需要解压打包好的容器镜像，那么这个应用运行所需要的完整的执行环境就被重现出来了。
这种深入到操作系统级别的运行环境一致性，打通了应用在本地开发和远端执行环境之间难以逾越的鸿沟。
Docker 在镜像的设计中，引入了层（layer）的概念。用户制作镜像的每一步操作，都会生成一个层，也就是一个增量 rootfs。这样我们就是以增量的方式去做修改，其好处是，所有人都只需要维护相对于 base rootfs 修改的增量内容，而不是每次修改都制造一个“fork”。
这样的做法是用到了一种叫作联合文件系统（Union File System）的能力。
Union File System 也叫 UnionFS，最主要的功能是将多个不同位置的目录联合挂载（union mount）到同一个目录下。比如，我现在有两个目录 A 和 B，它们分别有两个文件：
tree
.
├── A
│ ├── a.txt
│ └── x.txt
└── B
├── b.txt
└── x.txt
2 directories, 4 files
然后，我使用联合挂载的方式，将这两个目录挂载到一个公共的目录 C 上：
$ mkdir C
$ mount -t aufs -o dirs=./A:./B none ./C
此时，再查看C的目录：
$ tree ./C
./C
├── a
├── b
└── x
可以看到，在这个合并后的目录 C 里，有 a、b、x 三个文件，并且 x 文件只有一份。这，就是“合并”的含义。此外，如果你在目录 C 里对 a、b、x 文件做修改，这些修改也会在对应的目录 A、B 中生效。
注：笔者所用的docker 版本 19.03.8 默认存储驱动是overlay2，有兴趣的朋友可以自行谷歌overlay2
我们启动一个容器：
$ docker run -d ubuntu:latest sleep 3600
这时候，Docker 就会从 Docker Hub 上拉取一个 Ubuntu 镜像到本地。这个所谓的“镜像”，实际上就是一个 Ubuntu 操作系统的 rootfs，它的内容是 Ubuntu 操作系统的所有文件和目录。不过，与之前我们讲述的 rootfs 稍微不同的是，Docker 镜像使用的 rootfs，往往由多个“层”组成：
$ docker image inspect ubuntu:16.04
...
"RootFS": {
"Type": "layers",
"Layers": [
"sha256:f577d0e0bf70117...",
"sha256:06859de2f3e3d88...",
"sha256:c4d7b15878d0538...",
"sha256:e27729ee6e59f1a..."
]
可以看到，这个 Ubuntu 镜像，实际上由四个层组成。这四个层就是四个增量 rootfs，每一层都是 Ubuntu 操作系统文件与目录的一部分；而在使用镜像时，Docker 会把这些增量联合挂载在一个统一的挂载点上（等价于前面例子里的“/C”目录）。
容器的 rootfs 由如下图所示的三部分组成:
第一部分，只读层 （镜像层）
这个容器的 rootfs 最下面的五层，对应的正是 ubuntu:latest 镜像的五层。它们的挂载方式都是只读的（ro+wh，即 readonly+whiteout）。这些层，都以增量的方式分别包含了 Ubuntu 操作系统的一部分。
第二部分，可读写层 （容器层）
它是这个容器的 rootfs 最上面的一层（6e3be5d2ecccae7cc），它的挂载方式为：rw，即 read write。在没有写入文件之前，这个目录是空的。而一旦在容器里做了写操作，你修改产生的内容就会以增量的方式出现在这个层中。
如果我们要删除只读层里的一个文件，AuFS 会在可读写层创建一个 whiteout 文件，把只读层里的文件“遮挡”起来。
比如，你要删除只读层里一个名叫 foo 的文件，那么这个删除操作实际上是在可读写层创建了一个名叫.wh.foo 的文件。这样，当这两个层被联合挂载之后，foo 文件就会被.wh.foo 文件“遮挡”起来，“消失”了。这个功能，就是“ro+wh”的挂载方式，即只读 +whiteout 的含义。
所以，最上面这个可读写层的作用，就是专门用来存放你修改 rootfs 后产生的增量，无论是增、删、改，都发生在这里。而当我们使用完了这个被修改过的容器之后，还可以使用 docker commit 和 push 指令，保存这个被修改过的可读写层，并上传到 Docker Hub 上，供其他人使用；而与此同时，原先的只读层里的内容则不会有任何变化。这，就是增量 rootfs 的好处。
所有的增删改操作都只会作用在容器层，相同的文件上层会覆盖掉下层。知道这一点，就不难理解镜像文件的修改，比如修改一个文件的时候，首先会从上到下查找有没有这个文件，找到，就复制到容器层中，修改，修改的结果就会作用到下层的文件，这种方式也被称为copy-on-write。
第三部的，Init层
它是一个以“-init”结尾的层，夹在只读层和读写层之间。Init 层是 Docker 项目单独生成的一个内部层，专门用来存放 /etc/hosts、/etc/resolv.conf 等信息。
需要这样一层的原因是，这些文件本来属于只读的 Ubuntu 镜像的一部分，但是用户往往需要在启动容器时写入一些指定的值比如 hostname，所以就需要在可读写层对它们进行修改。
可是，这些修改往往只对当前的容器有效，我们并不希望执行 docker commit 时，把这些信息连同可读写层一起提交掉。
所以，Docker 做法是，在修改了这些文件之后，以一个单独的层挂载了出来。而用户执行 docker commit 只会提交可读写层，所以是不包含这些内容的。最终，这 7 个层都被联合挂载到 /var/lib/docker/aufs/mnt 目录下，表现为一个完整的 Ubuntu 操作系统供容器使用。
总结
我们经常提到的容器镜像，也叫做"rootfs"，它只是一个操作系统的所有文件和目录，并不包含内核，最多也就几百兆。相比之下，传统虚拟机的镜像大多是一个磁盘的“快照”，磁盘有多大，镜像就至少有多大。
通过结合使用 Mount Namespace 和 rootfs，容器就能够为进程构建出一个完善的文件系统隔离环境（也包括chroot 和 pivot_root 这两个系统调用切换进程根目录的功能）
通过“分层镜像”的设计，每次镜像拉取、推送的内容，比原本多个完整的操作系统的大小要小得多；而共享层的存在，可以使得所有这些容器镜像需要的总空间，也比每个镜像的总和要小。这样就使得基于容器镜像的团队协作，要比基于动则几个 GB 的虚拟机磁盘镜像的协作要敏捷得多。
更重要的是，一旦这个镜像被发布，那么你在全世界的任何一个地方下载这个镜像，得到的内容都完全一致，可以完全复现这个镜像制作者当初的完整环境。这就是容器技术“强一致性”的重要体现。
