最近Docker对整个平台发布了新的版本，Docker引擎升级至  ，Swarm升级至1.2版本，Compose和Machine也分别升级至1.7和0.7版本。这次升级也开始支持Mac和Windows 10 Bete版的操作系统。上述还只是这个升级的“冰山一角”，不过对于用户来说还算适度更新吧。底层的引擎经过大规模的重构保证了首个兼容（  ）OCI的运行时。更具体的说，现在用户可以直接在  和  上构建引擎了。

OCI，runC，containerd....这是怎么了？

Open Container Initiative是什么？

OCI在2015年6月宣布成立，旨在围绕容器格式和运行时制定一个开放的工业化标准。OCI的目标是为了避免容器的生态分裂为“小生态王国”，确保一个引擎上构建的容器可以运行在其他引擎之上。这是实现容器可移植性至关重要的部分。只要Docker是唯一的运行时，它就是事实上的行业标准。但是随着可用（和采纳）和其他引擎，有必要从技术的角度上定义“什么是容器”，以便不同实现上可以达成最终的一致。

什么是runC？

runC是一个轻量级的工具，它是用来运行容器的，只用来做这一件事，并且这一件事要做好。如果你了解过Docker引擎早期的历史，你应该知道当时启动和管理一个容器需要使用LXC工具集，然后在使用 libcontainer 。 libcontainer 就是使用类似 cgroup 和 namespace 一样的Linux内核设备接口编写的一小段代码，它是容器的基本构建模块。为了是过程更加简单，runC基本上是一个小命令行工具且它可以不用通过Docker引擎，直接就可以使用容器。这是一个独立的二进制文件，使用OCI容器就可以运行它。更多信息，请阅读  的  。

什么是containerd?

containerd 是一个简单的守护进程，它可以使用runC管理容器，使用gRPC暴露容器的其他功能。相比较Docker引擎，使用 gRPC ，containerd暴露出针对容器的  ，然而Docker引擎只是使用 full-blown HTTP API接口对Images，Volumes，network，builds等暴露出这些方法。获得更过的细节解释，请参考  的  。

它们之间的关联？

正如上面提到的，Docker引擎可以在runC和containerd上构建。1.11之前，引擎只用于Volums,networks,containerd等。

现在它所有的工作分为四个部分：引擎，containerd，runC，containerd-shim，后者位于runC与containerd之间的部分。

Docker引擎仍然管理者images，然后移交给containerd运行，containerd再使用runC运行容器。

containerd只处理containers管理容器的开始，停止，暂停和销毁。由于容器运行时是孤立的引擎，引擎

最终能够启动和升级而无需重新启动容器。还有一些其他的好处是：

当linux的代码被删除和其他容器运行时的这些改变时能够保持一种统一的Docker UI命令（表面上看一切都是一样的）

由于现在有四个组件，以前只是一个单独的“docker”二进制文件，现在查分各自功能为四个文件： docker , docker-containerd ,

docker-containerd-shim ,和 docker-runc 。如果你在主机上，就可以通过 ps as grep docker 获取正在运行的进程。

本文转自银狐博客51CTO博客，原文链接http://blog.51cto.com/foxhound/1834235如需转载请自行联系原作者

战狐