另一种虚拟化
docker作为一种将应用及其依赖进行package后发布的容器，就像可以被货轮承载和迁移的集装箱一样。现在的港口的设备当然是很强力了，不过在以前，货物达到码头后，还是需要码头工人来搬运，这似乎就是"docker"一词的原意。
作为一种基于OS的虚拟化技术，和传统的基于hypervisor的虚拟机技术一样，都是需要共享物理主机上的资源。但相比hypervisor中的Virtual Machine（以下简称VM）而言，docker的隔离度更弱，但同时资源消耗更小，相同平台可运行的container数目也更多。
而且，由于docker中的container是共享底层OS的，因此启动非常迅速。而像KVM这样的hypervisor在启动一个VM的时候，需要解压和引导VM所使用的内核，因而耗时更长。
三大支撑技术
docker最初是基于Linux设计的容器技术（现在也可以通过docker toolbox在Windows上做一个模拟层来移植到Windows上），它的实现依赖于Linux中的众多基础机制，包括用于资源限制的cgroup，用于隔离的namespace，以及用于实现docker文件系统的Union FS等。
画土分疆 - Control Group
为什么要有group
"cgroup"代表的是"control group"，这里"group"是进程的集合。“进程的集合”似乎不是一个新鲜的概念，「进程组」不就是吗？
对，但「进程组」的这个集合包括的是协同工作的一组进程（比如作为整体去接收信号），而cgroup这个集合的主要目的在于控制资源的使用：多个进程作为一个整体享有资源的配额（quota），同时接受资源的限制。
在cgroup出现之前，只能对一个进程做一些资源控制，例如通过"nice"值限定对CPU的使用，或者用ulimit限制一个进程的打开文件上限、栈大小等。而cgroup可以对进程进行任意的分组，如何分组是用户自定义的，一个group即对应一个docker container。
控制什么
来看一下"/sys/fs/cgroup"下的目录结构，cgroup支持的资源种类都在这里了，它们被称为cgroup中的subsystem或者resource controller（因为不是所有subsystem都完全具备controller的属性，所以本文接下来将统称"subsystem"）。
分配CPU的时间不难理解，可这里关于CPU的好像不止一个，有cpu, cpuacct和cpuset。额，可能因为CPU对一个系统来说实在太重要了吧。
那它们的区别在哪里呢？"cpu"是限制各个group对CPU的使用时间（比如50%），时间一到，就强制转入睡眠。"cpuacct"中的"acct"是"accouting"的缩写，用于统计每个group消耗的CPU时间（包括user time和system time）。
两者的关系好像非常紧密啊。是的，所以"cpu"和"cpuacct"都是link到"cpu, cpuacct"的：
而cpuset是限制SMP系统中，一个group可以使用哪几个CPU。为什么要做出这种限制，而不是让OS随意调度呢？要回答这个问题，还是先进"cpuset"的目录看一下：
你会发现有很多关于memory的条目，不是有单独的memory cgroup（简称memcg）来管理内存资源么？再想想什么时候CPU和内存在物理上的分布会是个问题？
就是NUMA啦。其实，cpuset主要是用于在NUMA这种有着复杂结构的大型系统中，根据CPU和内存节点的分布情况，更加合理地调度和使用CPU和内存资源。
如何控制
subsystem已经是事先准备好的，那如何创建一个control group呢？很简单，因为这是sysfs文件系统，只需在对应的subsystem（比如"cpu"）目录下，直接"mkdir"新建一个文件夹（比如"c1"）。
然后，"c1"这个group所需的基础实施就分分钟配套完成，只是里面还没有人居住。那process怎么才可以住进来呢？把自己的pid打到"tasks"里面去就好了。
echo [pid] >> /sys/fs/cgroup/cpu,cpuacct/c1/task
