在上期，小E学习了如何利用namespace机制，拆散了鹿晗和吴亦凡早恋 (划掉) 实现进程之间CPU、RAM、网络、用户、文件系统挂载点和进程IPC的隔离，还学习了利用CGroups机制，为鹿晗和吴亦凡在课桌上划好三八线 (划掉)，来限制进程对资源的使用，如将进程占用的CPU时间片限制为100mCore (100毫核，相当于0.1核)。
有了这两种机制，是不是就可以在宿主机上运行轻量级虚拟化的进程了呢？
我们还需要解决一个问题——对宿主机的文件系统保护。
由于云平台上的宿主机，会提供给不同的租户用于运行自己的应用，那么，有可能面临两个问题：
- 租户恶意篡改操作系统运行所需要的文件；
- 如果租户的应用所依赖的glibc等运行时库版本，和操作系统自带的版本不符，需要更新操作系统带的这些库，如何避免这些更新，与其他租户在宿主机上的依赖库冲突呢？
与方老师差不多年纪的读者们可能记得，大学里面的公共计算机教室，为了保护计算机的系统不会被熊孩子们破坏掉，老师们在计算机上加了一块硬盘保护卡，使得对系统盘的任何写入，在计算机重启后，都会被还原。
(当然，硬盘保护卡是通过接管BIOS的INT13中断实现的，想了解这个机制可以关注我们以后的专题——软硬件融合)
在Linux下，也有类似“硬盘保护卡”的机制。这一机制叫做UnionFS。
UnionFS为操作系统下的不同进程提供了虚拟化的一个文件系统。这如何理解呢？
请看下图。
如图，宿主机上的CentOS有自身的一套操作系统文件(当然，也包括Linux下都有的ld-linux.so.2)，而CentOS上运行的三个应用A，B和C，所依赖的ld-linux.so.2的版本有一定的差异。UnionFS能够为这三个不同的进程，提供各自虚拟化的文件系统，以及存放各自依赖的不同版本的ld-linux.so.2动态链接库。
在进程结束后，UnionFS为这些进程提供的虚拟文件系统也将被销毁，因此，进程对自己虚拟化的文件系统的修改，对宿主机不造成任何影响。
那么，问题来了，我们是不是需要人工为每个应用实例去添加其所需要的依赖库呢？
让我们回忆一下小E用Ghost为其他同学的计算机安装操作系统的场景：
小E在自己的计算机上安装好了Windows ME操作系统(暴露年龄了)，以及Office，Matlab和Visual C# .net，并将计算机安装了操作系统和这些应用程序的C盘(第一个磁盘分区)通过Ghost制作为镜像。然后，小E只需要把这个镜像文件恢复到其他计算机的第一个磁盘分区上，其他计算机就和小E的计算机一样，变成了标准化的运行环境，过程只需要几分钟。
我们在《虚拟化与云计算硬核技术内幕(27) —— 健康码与孙大圣(上)》中提到，在云计算环境中，也可以通过这样的方式来快速批量复制虚拟机，而不需要手工在每台虚拟机中部署应用及应用所依赖的各种运行时库。
那么，我们如果剥离掉hypervisor层，能不能自动化发放利用namespace隔离，设定好CGroups资源配额限制，并通过UnionFS虚拟化出文件系统的一个应用进程实例呢？
这种技术就叫做容器(Container)技术，其中，容器运行时引擎(Container Runtime Engine)技术，就是一个自动化实现以上操作的工具。
关于容器运行时引擎，让我们下期分解。
今日份段子：
方老师有一个朋友，写招聘JD不小心把售前产品经理打错成收钱产潘金莲，而且发出去了。
