在之前的文章中，我们从容器OS、容器引擎，基础架构的容器网络、存储、安全，容器运行必不可少的镜像仓库、编排，及运维关注的监控、日志，多维度关注并解读了容器生态圈中的各个玩家。总体而言，较为活跃的有Google主导的kubernetes生态，和Docker公司主导的docker生态。选择哪个技术流派从某种意义上，也决定了选择哪种生态，这也是当前使用容器的公司面临的一大难题。
本文将从容器引擎为切入点，说明这两大流派的历史、初衷和技术对比。
容器引擎玩家知多少
看到这个标题，你的表情可能是这样滴[惊愕]：纳尼？容器引擎不就是docker么？这时，
CoreOS
可能在后面默默地流泪，因为CoreOS的
rkt
也是玩家中的一员。虽然目前Docker的容器使用者相对更多，但rkt的发展也不可忽视。
Rocket与Docker
引发的站队
这里让我们先来八一个卦，故事要从2013年开始说起。是的，
Docker
公司在2013年发布了后来红遍大江南北的docker产品，一场新的技术带来一次新的革命，也带来新的市场机遇，CoreOS也是其中的一员，在容器生态圈中贴有标签：专为容器设计的操作系统CoreOS。作为互补，CoreOS+Docker曾经也是容器部署的明星套餐。值得一提的是，CoreOS为Docker的推广和源码社区都做出了巨大的贡献。
然而好景不长，CoreOS认为Docker野心变大，与之前对Docker的期望是“一个简单的基础单元”不同，Docker也在通过开发或收购逐步完善容器云平台的各种组件，准备打造自己的生态圈，而这与CoreOS的布局有直接竞争关系。
2014年底，CoreOS的CEO Alex Polvi正式发布了CoreOS的开源容器引擎Rocket（简称rkt），作为一份正式的“分手”声明。当然，Docker的CEO Ben Golub也在官网作出了及时回应，总体意思表明没有违背初心，但这些都是应用户和贡献者的要求而扩展的，希望大家能一起继续并肩作战。
当然，我们都知道了后来的事实，作为容器生态圈的一员，Google坚定的站在了CoreOS一边，并将kubernetes支持rkt作为一个重要里程碑，Docker发布的docker 1.12版本开始集成了集群swarm的功能。作为相亲相爱的一家人，Google于2015年4月领投CoreOS 1200万美元，而CoreOS也发布了Tectonic，成为首个支持企业版本kubernetes的公司。
从此，容器江湖分为两大阵营，Google派系和Docker派系。
而CoreOS除了Rocket和CoreOS外，也提供类似dockerhub的Quay的公共镜像服务，也逐步推出容器网络方案flannel、镜像安全扫描Clair、容器分布式存储系统Torus（2017年2月在对应github项目上表示停止开发）等优质的开源产品，包括早期的etcd，各个产品都和kubernetes有了很好的融合。
CNI&CNCF
在两大派系的强烈要求（对撕）下，2015年6月，Docker不得已带头成立了OCI组织，旨在“制定并维护容器镜像格式和容器运行时的正式规范（“OCI Specifications”），以达到让一个兼容性的容器可以在所有主要的具有兼容性的操作系统和平台之间进行移植，没有人为的技术屏障的目标 （artificial technical barriers）”。在2016年8月所罗门和Kubernetes 的Kelsey Hightower的Twitter大战中，所罗门透露出对容器标准化消极的态度。
有意思的是，同年（2015年）7月，Google联合Linux基金会成立了最近国内容器厂商陆续加入的CNCF组织，并将kubernetes作为首个编入CNCF管理体系的开源项目。旨在“构建
云原生
计算并促进其广泛使用，一种围绕着微服务、容器和应用动态调度的以基础设施架构为中心的方式”。陆续加入CNCF的项目有CoreDNS，Fluentd（
日志
），gRPC, Linkerd（服务管理），openTracing，
Prometheus
（
监控
）。
Docker与Rocket的半毛钱关系
为了表示本文真的是篇技术型文章，也来说说Docker和Rocket的一些对比。
Docker和Rocket目前都遵循OCI标准，但两者对容器引擎的设计初衷有较大差异：
总的来说，CoreOS认为引擎作为一个独立的组件，而Docker目前已发展成为一个平台，这也是CoreOS推出Rocket的官方原因之一。从功能角度来对比，Docker提供了日志、镜像和管理，甚至在1.12版本集成了swarm集群功能。而Rocket（rkt）的边界为在Linux系统上运行应用容器的功能组件。
表1 常用功能对比
容器安全也是CoreOS一直诟病docker的地方，docker自1.10后的版本在安全性上也在不断增强。以下从容器的安全方面，包含镜像、系统、容器运行时三部分横向对比。需要说明的是，镜像安全中镜像扫描也尤为重要，Docker Cloud和DockerHub提供在线漏洞扫描，CoreOS也提供了Clair开源项目对接CVE库进行镜像的漏洞扫描。
表2 安全对比
Linux系统安全策略
Namespace隔离性， Cgroups配额资源限制， Capability权限划分，SELinux/AppArmor访问控制权限。
Namespace隔离性， Cgroups配额资源限制，Capability权限划分，SELinux/AppArmor，TPM（Trusted Platform Module）
运行时 安全
由其他方案和厂家提供
支持KVM虚拟机中运行pod时，基于OS内核级和hypervisor级的隔离，非容器宿主机的cgroups和namespace隔离。
除了两者在功能和安全上的对比，为了用户方便评估，在兼容性上也稍作比较。可以看到，发布较晚的rkt在对Docker兼容性方面采用包容的态度，且rkt和kubernetes保持一致，基本运行单元为pod。
表3 兼容运行单元对比
本文从历史的角度说明rkt的由来，及引伸的技术流派问题。同时，也对Docker和rkt从设计（功能、安全和兼容性）的初衷进行简单对比。如果单从Docker和rkt社区相比，Docker目前热度更高，但后续如何发展，与其说是简单的Docker和rkt对比，倒不如说是两大技术流派的选择。
对于容器引擎的选择，虽然rkt在安全和兼容性设计上更胜一筹，但当前用户使用Docker较多，笔者分析主要也是以下原因：
安装便利性。对于企业常用的OS，在CentOS中进行yum和Ubuntu中进行apt-get，即可方便安装；同比，目前CoreOS官网信息表明，rkt针对CentOS版本还不能使用在生产环境中，对ubuntu也没有发布对应的安装包。另外，对于国内的网络环境，笔者科学上网后几经波折才下载到rkt的release版本。
社区活跃度。从两者在github中的数据，可以看到Docker社区无论在贡献者数量和提交次数上都比rkt社区要多，一定程度上也说明了两者用户的使用数量。这点和两者首个版本发布的时间有很大关系。
鉴于以上，建议容器平台使用者和学习者目前可以优先考虑Docker作为容器引擎，或是直接使用容器相关厂家提供的从容器引擎到容器云平台的整体解决方案。对于需要基于容器进行二次开发形成产品的容器厂家，尤其是基于kubernetes提供服务的厂家，建议同时对rkt保持关注。
