乐趣区

Docker容器实战五-特殊的进程

jiezi
  • 容器起于 PaaS
  • Docker 项目具有里程碑意义
  • Docker 项目通过“容器镜像”，解决应用打包这个根本难题

容器本身没有价值，有价值的是“容器编排”

正因为如此，容器技术生态才爆发了一场关于“容器编排”的“战争”
而这次战争，最终以 Kubernetes 项目和 CNCF 社区的胜利而告终。

所以会以 Docker 和 Kubernetes 项目为核心，为你详细介绍容器技术的各项实践与其中的原理。

容器，到底是怎么一回事儿？

容器其实是一种沙盒技术
就是能够像一个集装箱一样，把你的应用“装”起来的技术。这样，应用与应用之间，就因为有了边界而不至于相互干扰
而被装进集装箱的应用，也可以被方便地搬来搬去，这不就是 PaaS 最理想的状态嘛。

这两个能力说起来简单，但要用技术手段去实现它们，可能大多数人就无从下手了。
就先来说说这个

“边界”的实现手段

现在要写一个计算加法的程序
输入来自于一个文件
输出到另一个文件中。

由于计算机只认识 0 和 1，所以无论用哪种语言编写这段代码，最后都需要通过某种方式翻译成二进制文件，才能在计算机操作系统中运行起来。
而为了能够让这些代码正常运行，我们往往还要给它提供数据，比如加法程序所需要的输入文件
这些数据加上代码本身的二进制文件，放在磁盘上，就是我们平常所说的一个“程序”，也叫代码的 可执行镜像（executable image）
然后，我们就可以在计算机上运行这个“程序”了。

首先 OS 从“程序”中发现输入数据保存在一个文件中，所以这些数据就被会加载到内存中待命
同时 OS 又读取到了计算加法的指令，这时，它就需要指示 CPU 完成加法操作。而 CPU 与内存协作进行加法计算，又会使用寄存器存放数值、内存堆栈保存执行的命令和变量
同时，计算机里还有被打开的文件，以及各种各样的 I / O 设备在不断地调用中修改自己的状态

一旦“程序”被执行起来，它就从磁盘上的二进制文件，变成了计算机内存中的数据、寄存器里的值、堆栈中的指令、被打开的文件，以及各种设备的状态信息的一个集合
像这样一个程序运起来后的计算机执行环境的总和，就是进程

进程的静态表现就是程序，平常都安安静静地待在磁盘上
而一旦运行起来，它就变成了计算机里的数据和状态的总和，这就是它的动态表现。

而容器技术的核心功能，就是通过约束和修改进程的动态表现，从而为其创造出一个“边界”
对于 Docker 等大多数 Linux 容器来说

  • Cgroups 技术制造约束的主要手段
  • Namespace 技术修改进程视图的主要方法。

你可能会觉得 Cgroups 和 Namespace 这两个概念很抽象，别担心，接下来我们一起动手实践一下，你就很容易理解这两项技术了。

假设你已经有了一个 Linux 操作系统上的 Docker 项目在运行，比如我的环境是 Ubuntu 16.04 和 Docker CE 18.05。

接下来，让我们首先创建一个容器来试试。

$ docker run -it busybox /bin/sh

-it 告诉了 Docker 项目在启动容器后，需要给我们分配一个文本输入 / 输出环境，也就是 TTY，跟容器的标准输入相关联，这样我们就可以和这个 Docker 容器进行交互了。而 /bin/sh 就是我们要在 Docker 容器里运行的程序。
请帮我启动一个容器，在容器里执行 /bin/sh，并且给我分配一个命令行终端跟这个容器交互。

这样机器就变成了一个宿主机，而一个运行着 /bin/sh 的容器，就跑在了这个宿主机里面。

容器里执行一下 ps 指令

# ps
PID  USER   TIME COMMAND
  1 root   0:00 /bin/sh
  10 root   0:00 ps

可以看到，我们在 Docker 里最开始执行的 /bin/sh，就是这个容器内部的第 1 号进程（PID=1）
而这个容器里一共只有两个进程在运行
这就意味着，前面执行的 /bin/sh，以及我们刚刚执行的 ps，已经被 Docker 隔离在了一个跟宿主机完全不同的世界当中。

其实每当我们在宿主机上运行了一个 /bin/sh 程序，操作系统都会给它分配一个进程编号，比如 PID=100
这个编号是进程的唯一标识，就像工号
所以 PID=100，可以粗略地理解为这个 /bin/sh 是我们公司里的第 100 号员工

现在，我们要通过 Docker 把这个 /bin/sh 程序运行在一个容器当中,Docker 就会在这个第 100 号员工入职时给他施一个“障眼法”，让他永远看不到前面的其他 99 个员工
这样，他就会错误地以为自己就是公司里的第 1 号员工。

这种机制，其实就是对被隔离应用的进程空间做了手脚，使得这些进程只能看到重新计算过的进程编号，比如 PID=1
实际上，他们在宿主机的操作系统里，还是原来的第 100 号进程。

这种技术，就是 Linux 里面的 Namespace 机制
它其实只是 Linux 创建新进程的一个可选参数
在 Linux 系统中创建线程的系统调用是 clone()，比如：

int pid = clone(main_function, stack_size, SIGCHLD, NULL);

这个系统调用就会为我们创建一个新的进程，并且返回它的进程号 pid。
而当我们用 clone()系统调用创建一个新进程时，就可以在参数中指定 CLONE_NEWPID 参数，比如：

int pid = clone(main_function, stack_size, CLONE_NEWPID | SIGCHLD, NULL);

这时，新创建的这个进程将会“看到”一个全新的进程空间，在这个进程空间里，它的 PID 是 1
之所以说“看到”，是因为这只是一个“障眼法”，在宿主机真实的进程空间里，这个进程的 PID 还是真实的数值，比如 100。

可以多次执行 clone()，创建多个 PID Namespace，而每个 Namespace 里的应用进程，都会认为自己是当前容器里的第 1 号进程，它们既看不到宿主机里真正的进程空间，也看不到其他 PID Namespace 里的具体情况

除了刚刚用到的 PID Namespace，Linux 操作系统还提供了 Mount、UTS、IPC、Network 和 User 这些 Namespace，用来对各种不同的进程上下文进行“障眼法”操作:

  • Mount Namespace 让被隔离进程只看到当前 Namespace 里的挂载点信息
  • Network Namespace 让被隔离进程看到当前 Namespace 里的网络设备和配置

这就是 Linux 容器最基本的实现原理

所以 Docker 容器是在创建容器进程时，指定了这个进程所需要启用的一组 Namespace 参数
这样，容器就只能“看”到当前 Namespace 所限定的资源、文件、设备、状态，或者配置
而对于宿主机以及其他不相关的程序，它就完全看不到了。

所以容器，其实是一种特殊的进程而已。

总结

谈到为“进程划分一个独立空间”的思想，相信你一定会联想到虚拟机
你应该还看过一张虚拟机和容器的对比图。


左边虚拟机的工作原理
名为 Hypervisor 的软件是虚拟机最主要的部分, 它通过硬件虚拟化功能，模拟出了运行一个操作系统需要的各种硬件，比如 CPU、内存、I/ O 设备等等
然后，它在这些虚拟的硬件上安装了一个新的操作系统，即 Guest OS。

这样，用户的应用进程就可以运行在这个虚拟的机器中，它能看到的自然也只有 Guest OS 的文件和目录，以及这个机器里的虚拟设备。这就是为什么虚拟机也能起到将不同的应用进程相互隔离的作用。

右边, 名为 Docker Engine 的软件替换了 Hypervisor
这也是为什么，很多人会把 Docker 项目称为“轻量级”虚拟化技术的原因
实际上就是把虚拟机的概念套在了容器

可是这样的说法，却并不严谨
跟真实存在的虚拟机不同，在使用 Docker 的时候，并没有一个真正的“Docker 容器”运行在宿主机里面
Docker 项目帮助用户启动的，还是原来的应用进程，只不过在创建这些进程时，Docker 为它们加上了各种各样的 Namespace 参数
这些进程就会觉得自己是各自 PID Namespace 里的第 1 号进程，只能看到各自 Mount Namespace 里挂载的目录和文件，只能访问到各自 Network Namespace 里的网络设备，就仿佛运行在一个个“容器”

参考

  • Github
  • docker 官网
  • Docker 实战
  • 深入剖析 Kubernetes
退出移动版