OpenVZ VS Docker,不火只是时机的错吗?

Posted Container技术日报

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了OpenVZ VS Docker,不火只是时机的错吗?相关的知识,希望对你有一定的参考价值。

本文转载自 @登州知府 的微博,感谢授权。


OpenVZ和Docker都是轻量级的虚拟化技术,OpenVZ早在2005年就已经诞生,并且采用自行修改的Linux内核,安全性高于LXC和Docker,也已经成功地应用在生产环境中。我对OpenVZ工程师充满尊敬,他们贡献的范围不仅包括OpenVZ,还包括主流Linux内核:PID namespace和net namespace,以及一些cgroups controller。更不必提他们直接对LXC和Docker的贡献。但为什么OpenVZ技术高超如斯,却一直不温不火?而作为后继者的Docker,仅仅1年的时间就已经火到一塌糊涂?


我的看法是这样的:


OpenVZ和Docker的不同境遇,不是技术的原因,也不是宣传的原因,归根结底是由于二者的适用情景不同。


OpenVZ容器是一个轻量虚拟机,一个完整的操作系统环境,它的主要用途是充当虚拟私有服务器。而Docker的哲学是“每个容器运行一个应用进程”。不自行定制的话,Docker容器内不会带init等服务,它的主要用途是应用的运维,包括打包、转移、部署和运行等环节。LXC的本质是一个支持主流内核而非定制内核的OpenVZ,它与OpenVZ有很多共同的开发者。LXC容器也更接近于轻量虚拟机。


OpenVZ解决的是云基础设施提供者管理虚拟机的问题,主要应用在多租户的公有云环境;而Docker解决的是应用运维的问题,至少在现阶段,主要应用在本单位的私有计算设施上。为什么Docker安全性还没有足够保证,已经有这么多单位采用?因为以前这些应用直接部署在本单位购买的物理服务器或者虚拟机上,现在则是用Docker打包在容器内,这样既提高了运维的效率,安全性也不会比之前的工作方式低。


显然,需要应用运维的用户远远多于云基础设施提供者,所以,OpenVZ和Docker就有了不同的发展境遇。


从公司和生态的角度来说:


OpenVZ背后的公司是Parallels,主打的商业产品是Parallels Cloud Server(PCS)。根据官方网站,已经有10,000多家云服务提供商采用了Parallels的解决方案。在公有云平台这种多租户的环境中,安全是重中之重。因此,PCS采用的是修改过的RHEL6内核(`2.6.32`),对RHEL7内核的修改估计2015年会完成。OpenVZ和PCS共享相同的内核,但是用户态工具大不相同。举个例子,OpenVZ只提供命令行工具`vzctl`,而PCS则提供了完整的API。如果像我之前那样,需要在程序中集成OpenVZ,就只能封装命令行的`vzctl`。且不说研究`vzctl`的各种参数、解析标准输出这些琐碎工作,更要命的是有些`vzctl`操作是独占的,此时不允许多个`vzctl`进程并发执行。没有API,导致一个严重的后果:形不成一个以OpenVZ为中心的生态系统。也许这是Parallels有意为之。如果OpenVZ提供完善的API,总会有人去开发相应的实用工具和服务,最终与PCS形成事实上的竞争关系。


由于着眼点是轻量虚拟机,OpenVZ提供的模板(即镜像)都是操作系统,主要包括CentOS/Debian/Fedora/Ubuntu等几种,这就没必要专门设一个类似于Docker Hub那样的镜像中心。OpenVZ的镜像文件会映射到ploop设备上。有人问:把容器的文件直接写在常规文件系统,然后`chroot`不就完了呢?使用[ploop的好处](https://openvz.org/Ploop/Why)包括:不同的容器可以有不同的文件系统设置,且互不相影响性能;支持快速建立快照;有文件系统写入操作的跟踪器,有利于实现文件系统数据的实时迁移。OpenVZ还开启实时迁移工具项目[CRIU](http://criu.org/Main_Page),它充分地利用了ploop的特性和OpenVZ内核提供的kernel memory controller,后者意味着我们可以把一个虚拟机的内存状态也迁移到别处。


你看,OpenVZ开发者完全是从虚拟机的视角研发技术和产品。不知道是否受到Docker发展态势的影响,在2014年底的[OpenVZ past and future](http://openvz.livejournal.com/49158.html)一文中,Parallels决定把OpenVZ和PCS合并为一个统一的开源代码库,OpenVZ用户也能够像PCS用户那样使用更稳定、更多的功能特性。第一步是在2015年开放基于RHEL7修改的内核,重点是增加kernel memory controller支持,随后是ploop。是的,轻量虚拟机是OpenVZ永恒的视角,它一直狂奔在轻量虚拟机的道路上。


值得注意的是在2014年底,Parallels也宣布了自家PCS对Docker的支持(http://sp.parallels.com/news/pr/release/article/parallels-announces-support-for-docker-applications-on-parallels-containers/)。


反观Docker,它本来是dotCloud公司(当然,现在改名叫Docker公司了)的一个内部项目。dotCloud提供的服务是云计算应用引擎(Platfor as a Service,PaaS),云应用的运维才是dotCloud目标用户(即开发者和运维人员)的痛点。Docker镜像描述了应用程序的依赖,Docker用容器技术实现不同应用的隔离(这避免了不同应用的依赖之间相互影响)和转移。用户的应用千差万别,不可能像操作系统镜像那样只有有限几种,这就需要一个Docker Hub供大家分享各种应用程序镜像。Docker还应用Copy-on-Write技术和分层文件系统,有效地解决了Docker镜像和容器的大小问题。Docker完全开源,一开始就提供API,于是围绕Docker的工具和服务层出不穷,一个生态系统出现了。


OpenVZ和Docker的发展水平不同,是因为它们具有不同的vision,所以它们才会采取不同的镜像方案。也就是说,采用不同的镜像方案是“果”,而不是“因”。


从长远看,Docker有更好的发展前景。无论用户的基础设施是物理服务器、KVM/XEN虚拟机还是OpenVZ容器,最终目标还是要部署实现商业价值的应用。Docker提供的是每一个软件与互联网企业都需要的工具和服务,而OpenVZ容器只是诸多选择之一。


最后,说句题外话,一个常见的问题是坚持每个Docker容器只运行一个应用进程,还是当作一个轻量虚拟机?如果我的分析成立,应该坚持前者。如果要把容器当作一个轻量虚拟机,LXC/LXD更适合。


还有几个值得思考的问题。如果我们是Docker的开发者,如何实现Docker的商业价值?目前Docker存在什么问题,需要采取哪些改进措施?


欢迎回复您的想法与我们讨论。

以上是关于OpenVZ VS Docker,不火只是时机的错吗?的主要内容,如果未能解决你的问题,请参考以下文章

就问你 Spark 火不火?

docker

Docker的“正反”面

docker 基本操作Ⅱ(关于镜像操作)

vs启动报4.X的错

docker组成 以及启动服务遇到的错