线上分享关于Docker1.11架构的重大变革！

Posted 2021-04-21 GoDocker

　　加群方式：添加群管理员微信：ghostcloud2016，备注加群。我们的群管理员会把您加入到Docker爱好者群中。

 分 享 嘉 宾 

丁勇

丁勇，现任Ghostcloud CTO。国内微服务领域专家，对高性能、高可用集群系统有丰富的经验。曾任国内某知名研究所（涉密）云计算部门技术总监。

丁：大家好，我是精灵云科技的CTO丁勇，下面由我为大家简要介绍Docker1.11内部的一个重要“革变”，之所有命名为革变，是因为1.11版本起，Docker内部有了革命性的变化，虽然此次动作较大，但是没有改变既有命令或者API接口，用户能平滑过渡使用。那么，Docker 1.11相对于以前，到底有哪一些具体的变化呢？我们下面一一来看看。

丁：Docker1.11的此次革变，它开创了几个第一：首先，它是第一个支持OCI标准的发行版本，至于什么是OCI标准？我将在接下来的章节里面专门讲解它，这里我先略过；其次呢，它也是第一个构建于runC和containerd之上的发行版，runC和containerd的具体细节，我们在后面也将会讲到，这里也暂时略过；再次它是Docker有史以来，第一次大规模的重构引擎。重构引擎，这个动作非常大，我们知道Docker engine是Docker最核心的组件，在这里，大家可能会有疑问，如此大动作会不会造成新版的Docker极不稳定呢？针对这样的情况，我们精灵云也有类似的疑惑，所以，我们精灵云在目前仍然采用的是Docker 1.10.3版本，然后我们也安排内部人员带着这样的疑问在验证Docker 1.11，我们的宗旨是保证用户能用到可用的Docker，而不是一味追逐最新的Docker，我们每次升级Docker engine，我们都将会进行全面细致的验证和研究工作。好了，我们继续回到正题，那么针对前面讲到的Docker 1.11里的OCI标准，到底是什么呢？为什么会有这样的标准来规范Docker呢？带着这样的问题，我们看看下面的内容。

丁：我们先来谈谈Docker的野心和历史吧！可能大家更多听到的是Docker，而忽略容器技术的概念，一提到容器技术，大家可能第一时间也是想的是Docker，问题是：docker就等于容器技术吗？答案自然是否定的！容器技术它表示一个可管理的执行环境，与主机系统共享内核，与系统中的其他容器进程相互隔离。Linux下面有很多容器技术，较早的有Linux-Vserver、OpenVZ、Jails（FreeBSD）和Zones（Solaris）。随着2006年cgroups和2007年namespace技术的兴起，然后在2008的时候，LXC就诞生了，但由于LXC在容器的创建与使用方式较为复杂，且是内核态技术，维护和使用不便利。我们知道，在Docker的早期版本，是采用LXC作为基石，因为Docker自己的一套易用的命令体系，使得容器技术才得以真正的被发扬光大，Docker是走在容器的排头兵，但其一路走来，也是野心勃勃，它一直想要建立自己的生态系统，从而在docker 0.9版本开始，它也开始采用libcontianer，有了它，Docker不再需要依赖于Linux的部件如LXC等就可以做资源隔离，然后独树一帜，成就容器帝国梦想，Docker在0.9~1.8版本以前尚支持LXC，到了1.8版本时，彻底弃用了LXC。为了提高它更大的影响力，所以，在2015年6月开始，它也促成了OCI这个联盟的成立，旨在将容器工业化标准。当然，随着Docker的火爆兴起，很多龙头企业也积极响应和看好容器技术，一场云计算领域的工业革命拉开了帷幕。既然叫云计算领域的工业革命，Docker所处的容器也仅仅是其中一环了，要能使环环相扣紧密，容器的标准化也确实是迫在眉睫。

丁：前面我们提到容器的标准化迫在眉睫，那么OCI到底想做些什么事？第一点：它们想把容器的所有操作标准化，比如启停等，还包括一系列的工具，如此一来，我们以后在使用任何一家容器技术的时候，可以省去很多学习成本；第二点，是说不管容器里的具体运行的是什么进程，只要使用容器的标准操作，其执行效果均相同；第三点很好理解，就是不管你是什么异构环境还是平台，都支持容器的各项操作；第四点是标准化将要达到的要求，就是要求使容器技术的实现软件达到工业级的交付水平，即高可用，高稳定等。

丁：那么OCI是不是现有容器的唯一标准呢？我这里总结了2个目前比较流行的标准：OCF和OCP，OCP是OCI的前身，可能有些朋友会有疑问，为什么有了OCI还会有OCF？我个人的理解，OCI主要是规范容器的操作，而OCF主要是规范容器文件系统格式，这些标准具体内容我就不一一阐述了，有兴趣的朋友可以下去研究研究。

丁：好了，阐述完容器技术的相关内容后，我们回到Docker的变革的话题上。我们首先来看一看Docker1.11为了支持OCI标准和旧版本的Docker在架构上到底有哪些变化，可以归纳为2点？第一点：进程数成倍增加；以前版本的Docker只有一个Docker deamon的进程和一系列的容器的进程，然而，到了Docker 1.11后，除了原有的进程外，增加了1个containerd的进程，和同容器数量相同的runC进程；第二点：Docker 1.11彻底弃用以前的Docker engine通过调用libcontainer的库或LXC等库来操作容器的办法，转为通过进程间通信，调用containerd和runC的方式来操作容器。这样架构的优势在哪里？下面，我们着重来分析一下新架构中引入的containerd和runC相关的内容，顺便为你解答上面的疑问。

丁：那么，containerd是什么？其作用又有哪些呢？我们一起来看一下。从前面的Docker1.11的架构来看，控制容器的是runC，而控制runC的就是containerd。containerd其实是提供命令行和API的，1.11里的Docker deamon调用containerd的API，从而我们能够通过Docker管理机器中的容器。runC除了根据OCI规范运行容器，还包含有很多高级的特性，如容器的在线热迁移、快照与恢复等等，有兴趣的朋友可以仔细研究一下这些高级特性，然后可以在以后的实际项目中使用这些高级特性来增加项目的健壮性等。

丁：好了，既然我们知道了containerd是什么，那么docker为什么会选用containerd呢？有几个方面的原因，一是性能方面，containerd采用并发的方式管理容器，平均每秒可以启动126~140个容器，而老版本，从我们的测试数据结果来看，还不如其零头；二是从易用性方面说，可以通过命令行客户端或API来操作使用containerd,非常方便；三是从成熟度方面来分析，containerd的成熟度和现有的docker engine相当，所以可以将以前的docker engine里的容器的管理放心地托管给containerd；最后从兼容性方面来说，containerd可以直接运行docker的镜像，所以兼容藕合非常好！

丁：我们了解了containerd后，我们可能对runC的疑惑会更大了。我们可能会问，runC到底是什么？它是怎么管理和操作容器的？等等，下面我们一起来看一下。其实，runC实际上是从libcontainer演化而来的，我们知道libcontainer是docker 0.9开始取代LXC的来操作容器的核心组件，经过长期以来的不断迭代，目前已非常成熟，但是，以前版本的ibcontainer它是以调用库的方式集成到docker engine中的，现在，我们给libcontainer配上一个轻型的访问客户端，使用者通过客户端来访问libcontainer的功能，这就是runC，它是一个最简容器的管理实现。runC它是一个独立的进程，然后通过fork的方式创建容器的真正进程，runC实时监控着容器进程的各项指标。除此之外，runC还提供一些高级功能来管理容器进程，如热迁移功能，它是冻结容器进程的当前状态（包括内存中的状态），然后在其他地方再恢复出该容器进程。

丁：好了，我们一起看完上面的containerd、runC以及Docker 1.11的新架构后，到底会有哪些好处？我在这里总结了6条。一是docker的新架构更像是微服务的架构方式，将docker分解成了多个轻量级的可重用的服务模块；二是采用了微服务式的解藕的架构方式，被分解的若干模块互不依赖，意味着docker向高可维护性转变，最终将提高软件质量；三是各个独立的runC可以提高容器的并发处理能力，性能上比老版本有很大的提高；第四点，docker 1.11第一个支持OCI标准，这样对用户来说会更加稳定可用；第五点，因为containerd和runC较为稳定，升级较少，此种架构下，单纯地升级docker engine，不会中断容器的运行中的容器，更加提高了容器的可用性；最后一点，虽然说docker 1.11的内部变化非常大，但是既有的命令和API接口和老版本是统一的，使用者可以平滑过渡使用。

丁：讲到这里，可能很多朋友多多少少会有一些疑问了，比如有了contianerd，为什么还保留docker deamon，因为感觉containerd与以前docker engine的执能相同？我个人认为有几方面原因：一是为了兼容现有命令和API接口，旧版本的docker deamon除了承载docker engine外，很大一部分是提供docker命令和API的处理接口，这部分的功能被docker 1.11保留，从而达到用户可以平滑过度到docker 1.11；二是新版docker采用了微服务的架构思想，将各个大功能分解为轻量级可重用的模块，深度解藕，便于维护。经常架构的和编程的朋友也可能会问另外一个问题：从架构上看，docker deamon、containerd和runC之间采用了进程间通信，是否会影响性能？从官方测试结果和我们内部的测试结果来看，单个容器的性能和以前相当，但是并发创建容器等操作时，性能的确优于以前的版本；

丁：好了，讲完docker 1.11架构上的变化后，我们再来一起看看，docker 1.11里还有哪些新功能为我们的工作带来方便呢？我总结了几点：一是，docker1.11支持类DNS轮询的负载均衡，这个怎么理解呢？大家肯定知道DNS负载均衡技术，那么，在docker1.11里，把容器的名字当成域名一样理解，一个域名（容器link时的别名）后可以挂载多个容器，在进行容器link操作时，docker会自动均衡域名下的容器的负载；二是，docker开始支持VLAN，它可以现有网络架构更好地融合，这个就不累述了；三是开始对IPv6的支持，以前只支持IPv4；第四点是安全增强方面，docker1.11正式使用Yukikeu对镜像进行签名，防止镜像被篡改，这一点很容易理解；最后一点，我们知道以前我们可以attach到容器进程中，然后可以查阅或执行其他命令，现在我们也可以通过attach命令，attach到容器的网络和数据卷中，这样我们可以直接查看或配置容器的网络，也可以直接对数据卷进行操作，非常方便；好了，今天我们的分享就到此结束了，大家如果还有什么疑问，欢迎大家在此群或是通过我们精灵云官方的联系方式进行询问，我会尽力为大家答疑，谢谢大家！

想获得这次分享的完整版PPT？

即可获得线上分享的完整版PPT