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

OCI,runC,containerd 是什么?(部分)_第1张图片

OCI,runC,containerd....这是怎么了?

Open Container Initiative是什么?

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

什么是runC?

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

什么是containerd?

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

它们之间的关联?

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

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

OCI,runC,containerd 是什么?(部分)_第2张图片

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

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

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

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

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

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