原来Docker是这么来的！

Docker内部最核心的两个东西就是cgroup 和namespace。作为一个docker学习者，从此刻起我假装自己是个docker开发者身边的一位密友，来试着追溯下docker的前世今生。

早在2012年的时候，一个叫所罗门 希克斯（Solomon Hykes）的大哥，在法国创立了自己的公司，名字叫做：dotCloud，开始了他的人生梦想旅程。

没过一两年，dotCloud就改名了，叫Docker。公司也全家搬到了美国。从此开始了逆袭。

这位叫所罗门 希克斯的大哥，一心想着能够干点事情。忽然有一天他发现了linux系统中新开发出来个LXC的东东。

这个LXC的东东，可以把一个linux系统隔离成多个linux“系统”（也就是后来广为人知的“container”）。

LXC的底层是通过linux内置的cgroups和namespace来实现的隔离和虚拟化。

LXC

希克斯看到这个新的虚拟化技术很开心，阴吹思婷，表示可以搞。于是他就基于LXC实现了一个虚拟化工具，也就是后来的Docker。而当时只是dotCloud公司里的一个内部项目。

最初的docker就这样诞生了

随着时间的推移，希克斯渐渐的发现，当初的这种纯粹依赖于LXC的做法，现在看起来还是有点紧耦合啊，不行，这样下去不行，我们得搞出自己的一个实现和接口，这样才好适应未来，现在那么多虚拟化技术。

于是他就组织团队开发了一个名字叫做libcontainer的东东，一个目的就是为了替换掉LXC。于是就变成了下面这样：

一个全新的Docker，基于libcontainer的Docker

嗯，事情正在起变化，基于接口和标准的布局已经开始了：

libcontainer的地位

就这样日子平稳的度过。docker自己搞标准这事，被Linux委员会知道了，Linux委员会觉得自己才应该是制定标准的发起者，于是成立了一个叫做OCI（Open Container Initiative）的组织，旨在围绕容器格式和运行时制定一套开放的容器工业标准。由于是大佬成立的组织，迅速得到了一大帮大佬们的拥护，包括谷歌、亚马逊、微软等。

组织成立了，大家商量好了基本的格式诉求，于是就得找几个人来写文档啊，最后他们找到了libcontainer的一位哥和appc的一位哥来负责维护这个标准。

其实还是主要围绕libcontainer来制定标准。当然libcontainer也得根据规范进行少许的修改，让libcontainer符合这个规范。

这个规范的名字叫做Open Container Format (OCF) ，开放的容器格式，名字直抒胸臆。

一个统一的容器标准出现了

大佬就是大佬，强行插入。

标准好了，但这一切都还只是写在纸面上，还是得有一个真实的可对接的接口才行啊。这事最后还是得由Docker来做，于是希克斯的小伙伴们把上面的那个OCF化了的libcontainer进行进一步的标准化，然后取了一个全新的名字，叫runC。

runC出道

runC出道后，越来越强大，慢慢开始有了独立的迹象。如果你使用如今的Docker，那么底层默认就是runC。你也可以独立的去使用runC，把它集成到你自己的定制化平台上。

runC地位如今变成了这样：

runC就这样甚至抢了Docker风头

由于runC是由libcontainer演变而来，并且在Docker上使用了很久，如今的runC已非常成熟和稳定。

runC的单飞，让Docker更加的流行，同时也让其他想要进入这一领域的公司有了可乘之机，人们跃跃欲试，心想着，是时候搞点事情了，阿里巴巴就是其中一位，他们挖走了国内某容器公司的一位大佬，开始了自己的新一代容器之旅，没错，要革命，这个“革命”的项目名字叫做：Pouch，按照Pouch官方的说法也是基于OCI组织的OCF标准来构建的容器化技术，也就是基于runC。

还是回到Docker。

runC让如今的Docker变成了这样：

runC化了的Docker

如今的Docker在Linux委员会的一阵闪转腾挪的神操作之后，变得更加的开放和模块化，也增加了几个概念。比如：containerd、containerd-shim、dockerd。

containerd

希克斯认为动态和静态要分离，特别是有了runC后更应该如此。于是把容器相关的独立出来，叫做containerd，containerd专门负责容器的启动、停止、暂停、销毁。然而containerd并不直接做此事，而是交给runC来运行container。而Docker Engine则依然需要负责管理image，至于image的运行（container）则交给containerd组件来完成。

containerd-shim

另外还有一个containerd-shim组件，这个是用来做什么的呢？他就是一个底层具体负责做事的，一个容器的启动就是一个进程的启动，而containerd-shim就是容器所在的进程。

dockerd

另外还有个概念在上图并没有体现，那就是dockerd。dockerd负责去运行docker daemon，也就是docker server吧。

如果从C/S的角度看的话就是下面这样：

C/S

从调用的角度，整个顺序是下面这样：

各component之间关系

如今的希克斯奔走相告，一再扩大着自己的版图，他想着一直这样为开源做贡献也不是个事情，毕竟要多赚钱啊，于是由过去的一个docker变成了两个docker：社区版和企业版。

一张官方图结束

从LXC起家，然后是libcontainer，如今是runC......

好，假装完毕，谢谢你，希克斯！