Docker的前世今生

1

什么是 LXC

在引入 Docker之前，或许有必要先聊聊 LXC。在 Linux使用过程中，大家很少会接触到LXC，因为 LXC对于大多数人来说仍然是一个比较陌生的词汇。那为什么我们要在开篇之时，先聊这个陌生的概念呢？这是因为LXC是整个 Docker运行的基础。

众所周知， CPU、内存、 I/O、网络等都称之为系统资源，而 Linux内核有一套机制来管理其所拥有的这些资源，这套机制的核心被称之为CGroups和 Namespaces。

CGroups可以限制、记录、调整进程组所使用的物理资源。比如说：使用 CGroups可以给某项进程组多分配一些CPU使用周期。同样也可以通过 CGroups限制某项进程组可使用的内存上限，一旦达到上限，内核就会发出 Out Of Memory错误。同时 CGroups也具有记录物理资源使用情况的功能，比如CGroups调用 cpuacct子系统就可以记录每个进程所使用的内存数量、 CPU时间等数据。正因为 Linux有了 CGroups资源管理机制，内核虚拟化才变成了可能。

Namespaces则是另外一个重要的资源隔离机制。 Namespaces将进程、进程组、IPC、网络、内存等资源都变得不再是全局性资源，而是将这些资源从内核层面属于某个特定的 Namespace。在不同的 Namespace之间，这些资源是相互透明、不可见的。比如说， A用户登录系统后，可以查看到 B用户的进程 PID。虽说A用户不能杀死 B用户的进程，但 A和 B却能相互感知。但假如 A用户在 Namespace-A中，B用户在 Namespace-B中，虽然 A和 B仍然共存于同一个 Linux操作系统当中，但 A却无法感知到B。在这种情况下， Linux内核不但将 Namespace相互隔离，而且将所分配的资源牢牢固定在各自空间之中。

而 LXC就是基于 Linux内核通过调用 CGroups和 Namespaces，来实现容器轻量级虚拟化的一项技术，与此同时， LXC也是一组面向 Linux内核容器的用户态 API接口。用户通过LXC提供的资源限制和隔离功能，可以创建一套完整并且相互隔离的虚拟应用运行环境。

本书后续章节提到的 Docker，就是采用 LXC技术来创建容器的工具，因此才说：LXC是 Docker运行的基础，而 Docker则是LXC的杀手级应用。

2

Docker为什么选择了AUFS

Docker为什么选择了 AUFS？

回答这个问题，需要从AUFS的起源谈起。

AUFS原名为 Another UnionFS，从名称可以看出，AUFS是对 UnionFS的补充。 UnionFS是一个堆栈式的联合文件系统，打包在 Linux发行版中。但 UnionFS很久不进行更新，同时也存在一些不稳定的问题，因此在 UnionFS的基础之上进行功能完善，推出了一个新版本，名为 AUFS。

当 AUFS发布之后，昀新版的 UnionFS又吸收了 AUFS的很多功能，并随之发布在昀新的UnionFS版本之中。AUFS也同步更名为 Advanced Multi Layered UnificationFilesystem。

虽然名称发生了变更，但 AUFS本质上仍是堆栈式的联合文件系统。 AUFS的功能简单说就是，可以将分布在不同地方的目录挂载到同一个虚拟文件系统当中。

这句话不长，但理解起来颇需一些脑力。没关系，我们慢慢来分析这句话。

首先我们将思路切换到 Linux启动阶段。典型的 Linux启动时，首先加载 bootfs（Boot File System）目录。这个目录里面包括 Bootloader和kerenl。Bootloader用来加载启动 kerenl。当kerenl成功加载到内存中后， bootfs就会释放掉， kerenl随之开始加载rootfs。

rootfs（Root FileSystem）包含的是 Linux系统中标准的 /dev、/proc、/bin、/etc等文件。因为 rootfs是后续kerenl启动的基础，对于 kerenl来说异常重要，因此此时 kerenl将 Rootfs加锁—设为 readonly。在只读权限下， kerenl进行一系列的检查操作。当kerenl确认 rootfs包含的文件正确无误后，将 readonly改为readwrite（可读可写），以后用户就可以按照正确的权限对这些目录进行操作了。

说到这里，就轮到到 AUFS登场了。当 Docker利用 LXC虚拟化出来一个容器之后，就相当于购买了一台裸机，有内存、CPU、硬盘，但没有操作系统。 Docker参考 Linux的启动过程，将一个readonly权限的 bootfs挂载到容器文件系统中，然后通过 AUFS，再将readonly权限的 rootfs添加到 bootfs之上，当rootfs检查完毕之后，再将用户所要使用的文件内容挂载到 rootfs之上，同样是readonly权限。每次挂载一个 FS文件层，并且每层之间只会挂载增量（在这里大家可以借助于 SVN进行理解，相当每个 FS层都是 SVN提交上去的数据增量）。

这些文件层就是堆栈式文件系统中所保存的数据。将不同的文件层挂载到同一个文件系统中的文件系统，就是联合文件系统；而AUFS就是用来管理、使用这些文件层的文件系统，因此也称之为高级多层次统一文件系统（ Advanced Multi Layered Unification Filesystem）。

但是每个 FS层都是 readonly权限，那么容器内部如何向这些文件写入数据呢？其实当 Docker利用 AUFS加载完昀高一层之后，会在昀上面再添加一个 FS层，而这个层是 readwrite权限。容器内部的应用，对当前文件系统所有的写操作（包括删除）都会保存在这个 FS层当中，而当容器向 Docker发出 commit命令后，Docker会将这个 FS层中的数据作为单独一个文件层保存到 AUFS之中。

而一个镜像（ image）就可以理解为：特定 FS层的集合。所以可以看出镜像的层次关系，处于下层的 image是上层 image的父类，而没有父类 image的就是baseimage。因此需要从 image启动 container时，Docker会依次加载 baseimage和父类 image，而用户所有的操作就都保存在昀高层的readwrite的 layer中。

通过将镜像“分隔”为 AUFS的文件层，使得所有容器都可以共享文件层，且不会发生写冲突。但在 Docker中，所有的镜像都是只读的，所有的镜像也都不保存用户信息，只会用于新建和复制。而对于容器而言，其所看到的所有文件都是可读写的，只不过所有的写操作都被保存在昀上层的文件层当中。

Docker正是通过 AUFS的这些特性，解决了容器初始化和写时复制问题，所以Docker选择 AUFS作为其第二个核心组件。

3

Docker是如何产生的

在前两节中，我们介绍了 LXC和 AUFS两项技术，这两项技术是 Docker运行的基础。本节我们就开始介绍 Docker。

Docker昀初诞生于 dotCloud公司，这是一家于2010年成立的，专注于 PAAS（Platform as a Service）平台的创业型公司。 PAAS概念可以说是 SAAS概念的升级版，而且直接面向广大程序员，旨在减少软件开发周期中昀烦琐、昀耗时的环境准备环节。所以这个概念一经推出，就立刻得到了程序员的热捧。

但在 2010年的时候，市面上已经有一些科技巨头进入了 PAAS这个领域，比如 IBM、Amazon、 Google、VMWare和微软。这些巨头纷纷推出了自己的产品，比如 Amazon的 EC2、google的 GAE、 VMWare的 Cloud Foundry、IBM的 Blue Mix以及微软的 Azure。所以在2010年的时候， dotCloud的日子并不是很好过，它虽然拿到了 1000万美元的风投，但仍然举步维艰。在经过深思熟虑之后，dotCloud创始人 Solomon Hykes提议，将他们的核心虚拟化产品 Docker开源。

山穷水尽疑无路，柳暗花明又一村。

Docker一经开源，马上得到业界程序员的热烈吹捧。这个基于Linux Container技术的虚拟化产品大大降低了容器技术的使用门槛，程序员所希望的免费、轻量级、可移植、虚拟化和与语言无关、封装后的镜像可以随处部署和迁移等各种苛刻的要求，在Docker上面都一一得到了满足。

哇！开发界，测试界和生产环境三界统一了！

Docker得到了极大的关注度，大有席卷市场的意思。这时，各大科技巨头也马上改变策略，先后宣布将在各自的云平台中支持Docker，就连微软都宣布一定会在 Windows环境中原生支持 Docker。

至此，Docker在市场上站稳了脚跟。而dotCloud公司也顺势在 2014年 8月卖给了德国的cloudControl公司，Solomon Hykes等人也全职开始维护Docker开源社区，为广大使用 Docker的公司提供技术支持。

Docker经过多个版本的迭代发展，到目前为止，已经成为云计算领域昀受欢迎的开源项目。理论上说，只要有Linux的地方，就能运行 Docker。