共计 3455 个字符，预计需要花费 9 分钟才能阅读完成。
转载请注明出处：葡萄城官网，葡萄城为开发者提供业余的开发工具、解决方案和服务，赋能开发者。
上次咱们说到 PaaS 的倒退历史，从 Cloud Foundry 黯然登场，到 Docker 加冕，正是 Docker“一点点”的改良，掀起了一场蝴蝶效应，鼓动了整个 PaaS 开源我的项目市场风起云涌。
为了让大家更好的了解“容器”这个 PaaS 中最外围的技术，本篇将从一个过程开始，为大家讲述容器到底是什么，Cloud Foundry 等 PaaS“前浪”是如何实现容器的。
过程 vs 容器
以 Linux 操作系统为例，计算机里运行的过程是程序执行之后，从磁盘的二进制文件，到内存、寄存器、堆栈指令等等所用到的相干设施状态的一个汇合，是数据和状态综合的动静体现。而容器技术的指标就是对一个过程的状态和数据进行的隔离和限度。能够说，容器的实质其实就是 Linux 中的一个非凡过程。这个非凡的过程，次要靠 Linux 零碎提供的两个机制来实现，这里先回顾一下。
Namespace
Linux Namespace 是 Linux 内核的一项性能，该性能对内核资源进行分区，以使一组过程看到一组资源，而另一组过程看到另一组资源。该性能通过为一组资源和过程具备雷同的名称空间而起作用，然而这些名称空间援用了不同的资源。资源可能存在于多个空间中。此类资源的示例是过程 ID，主机名，用户 ID，文件名以及与网络拜访和过程间通信相干的某些名称。其品种列举如下：
- Mount namespaces
- UTS namespaces
- IPC namespaces
- PID namespaces
- Network namespaces
- User namespaces
超级过程
在 Linux 操作系统中，PID== 1 的过程被称为超级过程，它是整个过程树的 root，负责产生其余所有用户过程。所有的过程都会被挂在这个过程下，如果这个过程退出了，那么所有的过程都被 kill。
隔离 & 限度
方才咱们提到了隔离和限度，具体指的是什么呢？
隔离
以 Docker 为例（Cloud Foundry 同理，我的机器上没有装置后者），咱们能够执行下列的命令创立一个简略的镜像：
$ docker run -it busybox /bin/sh
这条语句执行的内容是：用 docker 运行一个容器，容器的镜像名称叫 busybox，并且运行之后须要执行的命令是 /bin/sh，而 -it 参数示意须要应用规范输出 stdin 和调配一个文本输入输出环境 tty 与内部交互。通过这个命令，咱们就能够进入到一个容器外部了，别离在容器中和宿主机中执行 top 命令，能够看到以下后果：
（在容器内外执行 top 语句的返回后果）
从中能够发现，容器中的运行过程只剩下了两个。一个是主过程 PID== 1 的 /bin/sh 超级过程，另一个是咱们运行的 top。而宿主机中的其余的所有过程在容器中都看不到了——这就是隔离。
（被隔离的 top 过程，图片来自网络）
本来，每当咱们在宿主机上运行一个 /bin/sh 程序，操作系统都会给它调配一个过程编号，比方 PID==100。而当初，咱们要通过 Docker 把这个 /bin/sh 程序运行在一个容器中，这时候，Docker 就会在这个 PID==100 创立时施加一个“障眼法”，让他永远看不到之前的 99 个过程，这样运行在容器中的程序就会当本人是 PID== 1 的超级过程。
而这种机制，其实就是对被隔离的程序的过程空间做了手脚，尽管在容器中显示的 PID==1，然而在本来的宿主机中，它其实还是那个 PID==100 的过程。所应用到的技术就是 Linux 中的 Namespace 机制。而这个机制，其实就是 Linux 在创立过程时的一个可选参数。在 Linux 中，创立一个线程的函数是（这里没写错就是线程，Linux 中线程是用过程实现的，所以能够用来形容过程）：
int pid = clone(main_function, stack_size, SIGCHLD, NULL);
如果咱们给这个办法增加一个参数比方 CLONE_NEWPID：
int pid = clone(main_function, stack_size, CLONE_NEWPID | SIGCHLD, NULL);
那么这个新的过程就会看到一个全新的过程空间，在这个空间里，因为该空间中仅有这一个过程，所以它本人的 PID 就等于 1 了。
这样一个过程就是 Linux 容器最根本的隔离实现了。
限度
光有 namespace 隔离的容器就和没有电脑的程序员一样，是残缺不全的。
如果咱们只隔离不限度，笼子外面的程序照样占用系统资源，拜访仍旧自在。为了给有了隔离性的程序增加资源限度，就用到了第二个技术：cgroups
cgroups 原本是 google 的工程师在 2006 年开发的一个程序，全称是 Linux Control Group，是 Linux 操作系统中用来限度一个过程组能应用资源的下限，包含 CPU、内存、磁盘、网络带宽等的性能。
通过 Cgroups 给用户裸露的 API 文件系统，用户能够通过批改文件的值来操作 Cgroups 性能。
（被 cgroup 限度的过程，图片来自网络）
在 Linux 零碎（Ubuntu）中能够执行以下命令查看 CgroupsAPI 文件：
mount -t Cgroups
（cgroup 文件系统）
从上图能够看到，零碎中存在包含 cpu、内存、IO 等多个 Cgroups 配置文件。
咱们以 CPU 为例来阐明以下 Cgroups 这个性能。对 CPU 的限度须要引入两个参数 cfs_period 和 cfs_quota，咱们为了给活字格私有云 Docker 内的程序限度 CPU 时，会常常操作这两个参数。这两个参数是组合应用的，意思是在长度为 cfs_period 工夫内，程序组只能分到总量为 cfs_quota 的 CPU 工夫。也就是说 cfs_quota / cfs_period == cpu 应用下限。
要想限度某个过程的 CPU 应用，能够在 /sys/fs/Cgroups/cpu 目录下，执行以下命令创立一个文件夹 container：
/sys/fs/Cgroups/cpu/ > mkdir container
此时，咱们能够发现零碎主动在 container 目录下生成的一系列 CPU 限度的参数文件，这是 Linux 零碎主动生成的，示意咱们胜利为 CPU 创立了一个控制组 container：
（默认的 CPU 资源文件列表）
为了展现 CPU 限度的实际效果，让咱们执行一个用以下脚本创立的死循环：
while : ; do : ; done &
咱们在 top 命令后果中会看到返回的过程为 398，因为死循环，cpu 占用率为 100%：
（死循环的过程占了 100% CPU）
这时，咱们再看下 container 目录下的 cpu.cfs_quota_us 和 cpu.cfs_period_us：
（默认状况下 CPU 的限度参数）
这里是没有做过限度时的样子。cfs_quota_us 为 - 1 阐明并没有限度 CPU 的运行下限。当初咱们改一下这个值：
echo 20000 > /sys/fs/Cgroups/cpu/container/cpu.cfs_quota_us
而后将之前的过程 398 写入这个控制组的 tasks 文件中：
echo 398 > /sys/fs/Cgroups/cpu/container/tasks
这时再 top 一下，发现方才的死循环的 CPU 使用率变成 20% 了，CPU 应用资源限度开始失效。
（应用 cgroup 限度 CPU 使用量的死循环过程）
以上，就是通过 Cgroups 性能对容器做限度的原理了。同理，咱们能够用此办法，对一个过程的内存、带宽等做限度，如果这个过程是一个容器过程，一个资源受控的容器根本就能够展示在你背后了事实上，在云时代的晚期，Cloud Foundry 等“前浪”都是采纳这种形式创立和治理容器。相比于后来者，Cloud Foundry 等在容器的隔离和限度上，虽绝对简略、易于了解，但在一些场景下难免会受到制约。
这里要做一个特地的阐明，只有 Linux 中运行的容器是通过对过程进行限度模仿进去的后果，Windows 和 Mac 下的容器，都是通过 Docker Desktop 等容器软件，操作虚拟机模仿进去的“实在”的虚构容器。
小结
本节从容器的原理和 Linux 下实现容器隔离和限度的技术动手，介绍了在云时代晚期 Cloud Foundry 等 Paas 平台的容器原理。下一节将持续为大家介绍 Docker 在 Cloud Foundry 容器根底之上又做了什么改变，是如何解决 Cloud Foundry 致命短板的。
如果您想理解 Docker 如何搅动风波，Docker 的这个容器又和传统虚拟机有何区别？
敬请期待下篇，咱们持续唠。
