前言
简单介绍一下一些容器的操作原理。
正文
docker exec 是怎么做到进入容器里的呢。
比如说：
这里有一个容器，我们可以exec 进去:
docker exec -it b265 /bin/sh
我们为什么能看到和容器内部一样的场景呢？
首先我们知道了为什么容器进程只能看到规定的namespace了，那么如果我们能拿到这个namespace的信息，那么我们就能看到容器进程一样的场景了。
docker inspect --format '{{ .State.Pid }}' b26585ee826b
上面可以查看容器进程。
可以查看namespace信息。
#define _GNU_SOURCE
#include <fcntl.h>
#include <sched.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#define errExit(msg) do { perror(msg); exit(EXIT_FAILURE);} while (0)
int main(int argc, char *argv[]) {
int fd;
fd = open(argv[1], O_RDONLY);
if (setns(fd, 0) == -1) {
errExit("setns");
}
execvp(argv[2], &argv[2]);
errExit("execvp");
}
写入到文件中，然后编译:
tee exectest.c <<- 'EOF'
> #define _GNU_SOURCE
> #include <fcntl.h>
> #include <sched.h>
> #include <unistd.h>
> #include <stdlib.h>
> #include <stdio.h>
>
> #define errExit(msg) do { perror(msg); exit(EXIT_FAILURE);} while (0)
>
> int main(int argc, char *argv[]) {
> int fd;
>
> fd = open(argv[1], O_RDONLY);
> if (setns(fd, 0) == -1) {
> errExit("setns");
> }
> execvp(argv[2], &argv[2]);
> errExit("execvp");
> }
> EOF
gcc -o exectest exectest.c
然后运行./exectest:
./exectest /proc/17240/ns/mnt /bin/sh
那么看下这个进程看到的信息是啥：
./exectest /proc/17240/ns/mnt /bin/sh
看到的信息：
这段代码的的核心操作，则是通过 open() 系统调用打开了指定的 Namespace 文件，并把
这个文件的描述符 fd 交给 setns() 使用。在 setns() 执行后，当前进程就加入了这个文件
对应的 Linux Namespace 当中了
你也可以将网络带进去:
正如上所示，当我们执行 ifconfig 命令查看网络设备时，我会发现能看到的网卡“变
少”了：只有两个。而我的宿主机则至少有四个网卡。这是怎么回事呢？
实际上，在 setns() 之后我看到的这两个网卡，正是我在前面启动的 Docker 容器里的网
卡。也就是说，我新创建的这个 /bin/bash 进程，由于加入了该容器进程（PID=25686）
的 Network Namepace，它看到的网络设备与这个容器里是一样的，即：/bin/bash 进程
的网络设备视图，也被修改了。
而一旦一个进程加入到了另一个 Namespace 当中，在宿主机的 Namespace 文件上，也
会有所体现。
其实就是将自己的namespace 指向了原来容器进程的namespace。
查看进程号:
发现和原来的17240进程的net一样。
此外，Docker 还专门提供了一个参数，可以让你启动一个容器并“加入”到另一个容器的
Network Namespace 里，这个参数就是 -net，比如:
docker run -it --net container:4ddf4638572d busybox ifconfig
而如果我指定–net=host，就意味着这个容器不会为进程启用 Network Namespace。这
就意味着，这个容器拆除了 Network Namespace 的“隔离墙”，所以，它会和宿主机上
的其他普通进程一样，直接共享宿主机的网络栈。这就为容器直接操作和使用宿主机网络提
供了一个渠道。
docker commit 干了啥？ 比如我们提交一个容器。
docker commit，实际上就是在容器运行起来后，把最上层的“可读写层”，加上原先容
器镜像的只读层，打包组成了一个新的镜像。当然，下面这些只读层在宿主机上是共享的，
不会占用额外的空间。
而由于使用了联合文件系统，你在容器里对镜像 rootfs 所做的任何修改，都会被操作系统
先复制到这个可读写层，然后再修改。这就是所谓的：Copy-on-Write。
而正如前所说，Init 层的存在，就是为了避免你执行 docker commit 时，把 Docker 自己
对 /etc/hosts 等文件做的修改，也一起提交掉。
前面我已经介绍过，容器技术使用了 rootfs 机制和 Mount Namespace，构建出了一个同
宿主机完全隔离开的文件系统环境。这时候，我们就需要考虑这样两个问题：
- 容器里进程新建的文件，怎么才能让宿主机获取到？
- 宿主机上的文件和目录，怎么才能让容器里的进程访问到？
这正是 Docker Volume 要解决的问题：Volume 机制，允许你将宿主机上指定的目录或
者文件，挂载到容器里面进行读取和修改操作。
在 Docker 项目里，它支持两种 Volume 声明方式，可以把宿主机目录挂载进容器的 /test
目录当中：
docker run -v /test ...
docker run -v /home:/test ...
而这两种声明方式的本质，实际上是相同的：都是把一个宿主机的目录挂载进了容器的/test 目录。
只不过，在第一种情况下，由于你并没有显示声明宿主机目录，那么 Docker 就会默认在宿
主机上创建一个临时目录 /var/lib/docker/volumes/[VOLUME_ID]/_data，然后把它挂载
到容器的 /test 目录上。而在第二种情况下，Docker 就直接把宿主机的 /home 目录挂载
到容器的 /test 目录上
当容器进程被创建之后，尽管开启了 Mount Namespace，但是在它执行 chroot（或者 pivot_root）之前，容器进程一直可以看到宿主机上的整个文件系统
而宿主机上的文件系统，也自然包括了我们要使用的容器镜像。这个镜像的各个层，保存在
/var/lib/docker/aufs/diff 目录下，在容器进程启动后，它们会被联合挂载在
/var/lib/docker/aufs/mnt/ 目录中，这样容器所需的 rootfs 就准备好了。
所以，我们只需要在 rootfs 准备好之后，在执行 chroot 之前，把 Volume 指定的宿主机
目录（比如 /home 目录），挂载到指定的容器目录（比如 /test 目录）在宿主机上对应的
目录（即 /var/lib/docker/aufs/mnt/[可读写层 ID]/test）上，这个 Volume 的挂载工作
就完成了。
更重要的是，由于执行这个挂载操作时，“容器进程”已经创建了，也就意味着此时
Mount Namespace 已经开启了。所以，这个挂载事件只在这个容器里可见。你在宿主机
上，是看不见容器内部的这个挂载点的。这就保证了容器的隔离性不会被 Volume 打破。
注意：这里提到的 " 容器进程 "，是 Docker 创建的一个容器初始化进程
(dockerinit)，而不是应用进程 (ENTRYPOINT + CMD)。dockerinit 会负责
完成根目录的准备、挂载设备和目录、配置 hostname 等一系列需要在容器
内进行的初始化操作。最后，它通过 execv() 系统调用，让应用进程取代自
己，成为容器里的 PID=1 的进程。
而这里要使用到的挂载技术，就是 Linux 的绑定挂载（bind mount）机制。它的主要作
用就是，允许你将一个目录或者文件，而不是整个设备，挂载到一个指定的目录上。并且，
这时你在该挂载点上进行的任何操作，只是发生在被挂载的目录或者文件上，而原挂载点的
内容则会被隐藏起来且不受影响
所以，在一个正确的时机，进行一次绑定挂载，Docker 就可以成功地将一个宿主机上的目
录或文件，不动声色地挂载到容器中。
这样，进程在容器里对这个 /test 目录进行的所有操作，都实际发生在宿主机的对应目录
（比如，/home，或者 /var/lib/docker/volumes/[VOLUME_ID]/_data）里，而不会影响
容器镜像的内容。
那么，这个 /test 目录里的内容，既然挂载在容器 rootfs 的可读写层，它会不会被 docker
commit 提交掉呢？
也不会。
这个原因其实我们前面已经提到过。容器的镜像操作，比如 docker commit，都是发生在
宿主机空间的。而由于 Mount Namespace 的隔离作用，宿主机并不知道这个绑定挂载的
存在。所以，在宿主机看来，容器中可读写层的 /test 目录
（/var/lib/docker/aufs/mnt/[可读写层 ID]/test），始终是空的。
不过，由于 Docker 一开始还是要创建 /test 这个目录作为挂载点，所以执行了 docker
commit 之后，你会发现新产生的镜像里，会多出来一个空的 /test 目录。毕竟，新建目录
操作，又不是挂载操作，Mount Namespace 对它可起不到“障眼法”的作用。
实验:
docker run -d -v /test nginx
查看挂载信息:
那么是哪一个呢？
docker inspect a9c79
直接看这个好了。
docker exec -it a9c79 /bin/bash
然后运行一下:
在里面写了一下文件.
然后看下这个目录里面有不。
然后我们看下读写层有不:
有一个test 目录，但是是空的。
可以确认，容器 Volume 里的信息，并不会被 docker commit 提交掉；但这个挂载点目录 /test 本身，则会出现在新的镜像当中。
如果你执行 docker run -v /home:/test 的时候，容器镜像里的 /test 目录下本来就有内容的话，你会发现，在宿主机的 /home 目录下，也会出现这些内容。这是怎么回事？为什么它们没有被绑定挂载隐藏起来呢？（提示：Docker 的“copyData”功能）
结
下一节k8s的本质。