[ECUG专题回顾]《Docker vs. Rocket:技术方案差异性剖析》-马全一(docker.cn创始人)

12月初在DockerCon EU 2014之前一周CoreOS抛出了一个 Container Runtime产品Rocket,虽然大家都在关注 Docker和Rocket的竞争,但我觉得后面还有比Container大战更恐怖的是Container OS大战。



我今天会介绍一下到底什么是Docker,前面的孙宏亮同学也介绍了什么是Docker。但是每个人对 Docker 都有不同的认识,我来解释一下这一年里Docker 官方对自己的定义变化。Docker 现在做的是一个平台,动了 Docker 生态环境中其它公司的奶酪。所以这 个 Rocket 引擎不是最关键的,最关键是 CoreOS 抛出了一个 Specification,现在社区里 面都在讨论这个 Specification。我重点会讲这个的 Spec 和 Docker 的实现有什么不同, 最后我会讲明年即将到来的 Container OS 的大战。到底是 Rocket 还是 Docker 能笑到最后,我觉得肯定是 Docker。



这是我自己的介绍,这就跳过了。



我是从去年 ECUG 深圳的会开始讲 Docker 的和筹建 Docker 中文社区的,到今年我讲了有 10 来场。上半年做了很多 Docker 开源技术传播的工作、组织翻译了很多文章和 DockerCon视频的字幕。在 10 月份专门做了一个 Docker 的镜像仓库存储服务 docker.cn 。这个跟前面孙宏亮同学讲的是不一样的。他做的是官方 Docker Hub 的 Registry Mirror ,你可以理解为是 Docker 镜像仓库在中国搞了一个 Mrror,它会每天跟官方同步。我们 开发的 docker.cn 是完全跟它隔离开了,在我们这里的镜像是不能同步到官方的,而且我 们没有用 Docker 的开源版本。我们按照 Docker Registry API V1 协议写的,由于 Docker Hub 是不开源的,我们是自己分析协议做的。现在 Docker Registry API 的协议 在 V1 和 V2 版本之间过度,所以我后面会讲到 App Spec 和 V1 版本有哪些不同,和 V2 版本有哪些不同。docker.cn 现在是专注于为国内的开发者提供镜像仓库存储服务,镜像 文件也是放在七牛上的,用的也是七牛的 CDN 服务。我们还有一家 CDN 赞助商,目前 Public 和 Private 都是免费的,不管存多少个镜像仓库。



现在讲到底什么是 Docker? 我去年在 ECUG 讲的时候它还是 LXC Framework,是 D otCloud 在运维 PaaS 平台的过程中,觉得 LXC 的 C Library 不太好搞,用 Python 写了一 个运维工具,后来开源的时候叫 Docker,用 Golang 重写了。现在的 Docker Hub 和 Docker Registry 都是 Python 写的,他们正在用 Golang 重写。所以我们比较幸运,等 Docker Registray V2 写完了我们就 Build 到 docker.cn,我们就是唯一一个程序能够兼用 V1、V2 两个协议的程序。 Docker 镜像仓库存储这个事情还是比较麻烦的。每个版本在 升级有很多不兼容的地方,Docker 自己有时候也不兼容。比如你用 CentOS 6.5 的版本装 是 Docker 0.9,装完之后就发现哪个存储服务都用不了,必须升级到最新版本才能用。 现在是 V1 到 V2 的版本过渡。



到今年 3 月份的时候 Docker 出了一个 Libcontainer,它叫做 Container Engine,是容器 的引擎。那容器的引擎就是说要兼容很多解决方案,它兼容 LXC、Libvirt 好像不兼容。 后来到 10 月份的时候出了一个比较震惊的新闻,就是 Docker 跟微软兼容,大家都不知 道怎么个兼容。我后来问了问,可能的情况就是说 Docker 的这套接口在 Windows 兼容 ,我估计应该在明年 Q3、Q4 会出来。这个是 Docker 到 3 月份的变化。



到 6 月份的时候 Docker 说自己是一个 Platform,一个为开发和运维服务的平台。因为 6 月份所有的媒体都在讲 Docker,所以很多人都是先知道 Docker 后知道有叫 Container 的技术。所以 Docker 这个事情做的非常”好“,大家一说 Docker 就是说 Container 的容 器,Docker 如果这样下去就变成 Container 技术的事实标准,就是 Container 的代名词。原来 Docker 的存储 Index改为 Docker Hub。到 10 月份的时候我们在北京 Container 大会时,他们抛出来一个新的概念叫 ContainerOps,Container 从开发一直到 CI、CD ,从生产到运维全部都是面对 Container 。



最近 DockerCon EU会出了三个新的东西,Docker Mashine 是相当于搞了一个 Docker 的 镜像,搞好了直接 Convert 成一个亚马逊的镜像直接就可以跑起来,比如你配置好了一 个 Docker 的 VirtualBox 虚拟机就可以到 Amazon EC2 和 Google GCE 运行起来。 Docker Swarm 是搞了一个大的资源池,就是在 Amazon EC2 几个VM、在 Google GCE 开了几个VM把它们 Connection在一起,申请一个 Docker 镜像的时候直接选帮用户选一个 VM 处理。Docker Compose 实际上是单机编排工具,这个其实我们也做过一个 Golang 语言的版本。Docker Compose 是用 Fig 重写的。平台是 Docker最新的定义,它 想做了一个平台,它还要想做更多,类似 etcd 服务发现和集群的管理肯定要做。 所以 CoreOS 会觉得它的市场空间就更小了,其实它的市场空间本来就不大,它觉得要自己搞 一个 Container Runtime,CoreOS 发布了一个标准化的规范希望大家来去讨论,其实 Docker 也是有可能进来要一起来完善 Specification 。所以最后这个事情我觉不止是说这两个产品的竞争, 可能还是在争夺到底谁来定这个 Specification,看谁在社区里的影响力大吧。



App Container Specification 的 Goal 实际是针对于 Docker 目前实现有问题的地方。首 先是下载,Docker 下载比较慢,下载流程比较复杂,前面孙宏亮同学也讲过就是 Pull 和 Push 都是比较慢的。



首先讲的是不同的地方,App Container 首先讨论使用哪种开源模型,大家其实是想通过 比较平等的方案最后来去确定这个标准。Docker有一个 DGAB 的组织,我们翻译成 Docker 管理咨询委员会,凡是成立管理咨询委员会最近都没什么太好的情况。Docker 管 理咨询委员会代表社区和 Docker 官方沟通,所以你只能有建议权,至于决定不决定还是 在 Docker Inc. ,,所以大家都觉得这事不太开放。他们第一讨论的是我们怎么建立开放 的机制,这个事变得所有的社区参与者都是平等来决定而不是在一家公司手里。



我们讲 Image 的定义,Docker 最新的版本现在支持 OverlayFS,但是内核必须在 3.18 以 上。Docker 的核心是每一个 Image 都是一个目录, 这个目录你在 run 的时候是靠 AUFS 或其它机制来实现叠加的效果,只有最上面的那一层是可写的。我是最看重这一点,我觉 得它的商业价值都体现在这一点上。这个 App Container Spec 目前里面认为 Image 就是 一个目录,在 rootfs 目录下会有一个 Manifest 文件。Docker 其实是说很多层目录叠加 ,上面的把下面的覆盖掉最后生成的 Container 。Docker 是叫镜像仓库,所以会有一个 管理版本的概念,这个设计是参考了很多 git 的实现。 Docker 跟 Spec 相同的地方就是 说,当前都是用 tar 进行压缩的。Docker Push 的时候是把每一个 Image 做成一个 tar 的 包传上去, Docker Pull 把每一层 tar的包下载下来再解压。App Container Spec 就是说



不要搞那么多层,就一个 tar 文件。Docker 就搞了很多层,很多层就要记录,比如说层 级关系。然后还有签名,App Container Spec 里面说用 gpg 签名,或者签名加上加密, Docker 是把这个目录压缩为一个包的时候,在流的过程中做了 SHA256 的校验产生校验 ID。App Container Spec的 Image 的 ID 是 SHA256 算出来的,Docker 设计的时候这个 ID 是 Random 的 ID ,比如说你和我都写了相同的目录,咱俩的 Image ID 不是同的。我 们每天会从 Docker 官方会同步镜像仓库到 docker.cn ,其实每天都是编译同一个的东西 ,但是 Image ID 不同所以造成存储的浪费。Docker 在 V2 的协议里面也是说要改流计算 ,这两个在趋势上是一样的。App Container Spec 现在说要用 SHA512 计算,因为说在 64 位的 CPU 下, SHA512 算的速度会比 SHA256 快,这个还在讨论中。



第三个不一样的地方,Rocker可以用外部的程序去压缩。以前的代码里面是没有任何一 个第三方库的,所有的东西都重写,所以他是没有 gzip 的功能,也没有做压缩和加密。 在国内做 Docker 镜像仓库存储,大家都希望比较加密。我们希望做一个加密的存储,当 时是在压缩的过程中对流进行加密,加密完了以后向 Docker 官方传的时候就不认识了。 Spec 的建议是用外部的命令去压缩,这是一个不同的地方,我估计 Docker 官方可能也 会采用这种方案,所以这个是 Spec 和 Docker 的实现不同。但是最后实现我估计都会用 pgp 的方式。



第二部分 Image 的定义,其实关键一点这是Docker V2 版本 和 V1不太一样,V1版本是 为每一个 Image 都有对应的 JSON 文件,整个是分散的。比如说你要看数据的话你要把 10 个 Image 的 JSON 数据放在一起,V2也是采用重新组成一个文件的方式,其实两个在 设计上我看了没有什么不同,不同的地方就是 History 这个位置,Docker有每一层,所以 把每一层Image都放在这个位置了。App Container Spec 定义的时候就全在一个里面,就 这么一点不同。但虽然说名字不一样,但是要做的事情是一样的,这个是 Image 的不 同。



Runtime 也有不同的定义,所以我们看 Runtime 有一个文件,你会在 Docker 的文件目 录下会找到一个对应的文件,这两个部分定义其实没有什么不同,只是 Docker 目前是东 西比较多,而Spec定义的时候还没有做到这一点,所以 Docker 这个会比较全一点,基本上内容没什么区别,因为你不管 Docker 也好什么也好,所有做解决方案的全部是用 Cgroup 和 Namespace,没有任何的其他解决方案,所以他们没有什么不同,不同可能 就是名字不一样。



我觉得在 Runtime 期间 Spec 也好和Docker也好没什么不一样的,不一样的地方叫 Image Discovery,它会带一个签名文件和 aci 文件,它希望随便放在哪儿下载都可 以。。Spec这个版本又加了一个叫 Meta Discovery,它怎么做呢?我要想下载一个 ReduceWorker 他去问有没有,返回的值是这个东西,它其实只不过是在这里面做了一些 定义,说返回值是什么、签名是什么,它返回这个定义。实际上最后在讨论的时候大家还 是觉得 Docker 目前的设计要比好一点,Docker 所有的访问是从哪里来呢?你如果要是 看过 Docker API 的实现,所有的信息是 HTTP Header 和 HTTP Body 里面的数据,返回 来的数据也是 HTTP Header 加 HTTP Body 。目前我觉得 Spec 没有 Docker 设计的好, 设计还在讨论的过程中,这个 Spec 就没有最终定下来。核心的一点,我觉得 Spec 搞这 个事情实际上是希望去中心化的,这是他们最核心的想法,最后实现的时候还没有定论, 我觉得要等至少这个规范版本比较稳定一点,现在是 0.11 。



还有一个 Metadata Server,不一样的地方就是说这个 Metadata Server 相当于 Discovery 里面的这个部分,这个是什么意思呢?这个是说当你一个 Container 跑在服务 器上,你想知道里面跑的状态的时候你需要去调这个接口,这实际上是相当于跑的那台机 器的状况。我提了一个 Issue,我觉得应该在这个地方再加一个 Log,我能拿到 Container的日志,这个也是大家在用 Docker 的时候遇到的问题。



Name Type,就是像前面这个地址的定义,我没太看明白这个定义的意义是什么,我理 解是说它是个 URI 的标准。



这是最后一页了,CoreOS搞了一个 Rocket 和 Spec 跟 Docker 争夺标准,其实我觉得它 更危险。 CoreOS 没有我们传统认为的包管理机制,都是以 Docker 的机制跑上去,现在 就是跑什么东西都是以 Containe r的方式跑在上面的。第一个出来跟它竞争的是 Ubuntu Core, Ubuntu 采用这种方式把整个系统打到最薄只有一个内核和 Docker 的容器。LXD是以一个 Container 方式去运行一个完整的操作系统,,那个东西出来大家都没关注他, 大家觉得 Ubuntu 这帮人太不甘寂寞了非要搞这个东西。现在看起来和 Redhat Atomic 就是三国鼎立,我其实比较看好 Ubuntu。做这样一个系统的成本,我觉得被拉的非常 低。我觉得 Container 管理工具都很容易跟 CoreOS竞争,如果我用 Docker 的时候管非 常大的 Container 集群我可能不关心是CoreOS 还是 Atomic ,CoreOS 的市场会被越来越小。所以我觉得明年最火热的争夺应该是这个事情 Container OS War,其实倒不是 Container。就这么多,谢谢大家。



PPT:http://qiniuppt.qiniudn.com/maquanyi.pdf


视频(何全&马全一): http://qiniu-opensource.qiniudn.com/ecug-2014-hequan.mp4