转载

从容器规范看Docker和Rocket

【编者按】 在“ 选择Docker还是Rocket做容器?为何不选择两个? ”一文中,曾提到CoreOS的创始人Polvi和Docker的创始人Sonomon都认为,Rocket和Docker没有竞争性。Docker平台是一个产品,Rocket是一个组件。企业可以选择Docker替代Cloud Foundry,也可以使用Rocket构建Cloud Foundry。CoreOS在发布Rocket时就指出,Rocket的出现是因为有些人需要一个更“纯净”的容器。换句话说,Rocket算是“App Container Specification”的标准实现。本文作者从“App Container Specification”入手,分析了 Rocket和Docker在技术实现上的不同。 以下为原文:

Docker Rocket,殊途同归

首先,对于那些把 Docker 与 Rocket 放在一起比较的人,我想劝你们首先适当地调查一下。如果有这样两个软件:一个已经有1年多的历史,作为一个开源项目由全世界上千的开发者共同参与,并且已经或即将在实际的生产环境中被部署、测试;而另一个软件则是“新鲜出炉”的。如果这个较成熟的软件不是特别烂的话,那么很有可能它就是赢家。

所以,将 Docker0.1.1与最近 预发行的Rocket 拿来比较会更公平一些。此外, CoreOS的CTO Brandon Philips 也多次强调 ,Docker的一些功能将不计划加入到Rocket中——不只是现在,也许永远不会。为什么?因为Rocket项目的重点,至少目前的情况——不是重新实现Docker。Rocket是 “App Container Specification” 的实现,因此,想比较两者,最好比较“App Container Specification”和最初的Docker清单或者Docker实现的其它规范。

以下的比较都将基于以上共识:

Systemd

通常情况关于 Rocket的讨论最多的话题是 systemd-spawn 或者是 systemd 。 CoreOS已将systemd作为他们Linux发行版的init系统。他们可以接着使用Init 脚本或者upstar,但是他们选择使用了将来会成为所有主流Linux版本标准的init系统。实话说我并没有关于systemd独到的见解,只是读过Lennart等人的一些文章。对于CoreOS来说,将systemd作为新的Linux发行版的init系统的是不明智的。另外,CoreOS已经获得了我的信任,我对此深信不疑。你可能会抛出 btrfs 与我争论,但是, 那个会很快消失 ,我希望它会被修复,或者被其他可靠的方案替换。毕竟稳定性比功能更重要。

好吧,让我们回到问题上来。其中 systemd做的或者说能够做的事情多是进程管理。你可能会认为,systemd解决这个问题的方式,多少有些重叠了服务、进程管理的概念,并且将一些原本能在PID1之外很简单的任务复杂化了,但因为CoreOS是systemd的忠实用户,如果使用其它工具来实现反而显得奇怪。

此外, 据Brandon介绍 , Rocket的最初实现使用systemd-nspawn的原因是他们想用systemd,Systemd-naspawn 已经实现,而且正在做他们想做的东西,所以它有助于项目的开始。坦率地说,在0.1.1版本,我并不关心他们使用的技术,没准以后都会变的,因为Rocket的设计是可插拔的。如果你不喜欢systemd-nspawn,可以用你自己的 stage1 实现, Rocket已经提供了详细的命令行参数。

另外需要指出的是,那些认为想使用 Rocket,就必须运行systemd的人就完全错了。Rocket根本不需要systemd。它也能与其它init系统,如SysV或upstart配合工作。我在upstart上测试了Rocket,没有遇到任何问题。Rocket仅仅是“重用”了systemd和systemd-nspawn,处理 stage1 和 stage2 。

App Container

有些人可能还没有准确地理解“App Container Specification”。他们一直在说 systemd,并说Docker是如何好,不需要在容器中用systemd运行进程。Docker通过后台进程管理单进程的容器。Docker后台进程未被写成一个进程管理工具,当你的容器停止时,这种设计的弊端就会显现出来。你最终要通过主机或者容器中的进程管理工具来应付它。如果你还没有经历过这样的事,要么你可能是幸运的,又或者没有在环境中运行大量的容器。

我们需要进程管理,或进程管理提供的某些功能。如果读过 “App Container Specification” , 你会理解这点的 。我将其中一部分摘录如下:

容器执行一个或多个应用程序,共享PID namespacenetwork namespacemount namespaceIPC namespace 和UTS  namespace 。执行之前,每个应用程序将开始转为(比如chroot)自己特有的读写根文件系统。容器的定义是,包含一系列应该在一起启动的应用,以及应用与整个容器的隔离器。

上面明确提到了几个进程共享Linux的命名空间。换言之,Kubernetes的Pod与以上对容器的定义很像,我不知道这是否与CoreOS正在积极参与Kubernetes的开发有什么关系。但Kubernetes Pod是一组容器,而不是容器中的一组进程。这让你能从多个Docker镜像组成一个Pod中获益。这是App Container Specification定义了 依赖关系 的地方,所以你的容器可以依赖于其他容器,因此通过 Stage0 创造的最终容器runtime可能是 这样的 。

现在,你已经在容器中运行多个进程,其中一些可能是后台进程,并且 可能需要被监督,你需要一个进程管理器。至今我用过最好的管理器是 runit ,但话说回来,当你已经积累了大量关于systemd的经验时,你为什么会想要写runit脚本或使用其他管理器?如果我是CoreOS,也会做出一样的决定——systemd。

Docker 和命名空间

现在,让我们回到 Docker。Docker一直倡导一个容器运行一个进程。总的来说,我同意这一点,因为Linux容器主要是为了实现主机的进程隔离,而每个容器运行一个进程,会给你带来更多的灵活性和复合型,独立的更新、回滚等,操作更加简单。然而,当你创建一个新的Docker容器或事实上LXC容器,容器被重新分配一套由 libcontainer 提供的全新的Linux命名空间。实话说,我觉得这有点浪费。于Docker还挺有意义,因为你要在一个容器中运行一个单独的进程,并且如果你想提供更通用的进程环境,来覆盖大多数的用例,你可能需要libcontainer高效提供的大量可用命名空间。

只为一个进程创建一组命名空间,增加了内核大量的额外管理工作。如果你的主机上运行了很多的容器,可能会出现内核某些方面的瓶颈。你可能会说开销很小,但是为什么非要过度占用内核呢?

因此,为了节省开销,可以共享进程之间的命名空间。但是有个问题,如果你开始共享命名空间,并且创建它的容器已经终止,它会删除共享命名空间的所有的进程。 Kubernetesde在设计Pod时,就考虑到这个问题了。 Kubernetes Pod中第一个被创建的容器,会被从internal/24 VLAN中分配一个IP地址,该IP地址也被Pod内共享一个network namespaces的容器共享。

你可以看到这里微妙之处。每当“网络”创建的容器停止时,他会撤销 Pod中所有的其它容器,因为没有可以共享的命名空间了,所以需要从头创建新的Pod,重新分配IP。更糟糕的是,你的连接也没了。所以,当你的容器停止后,不能自动重启它们。我相信通过观察Docker销毁容器的过程,可以找到解决办法,但是,那有些绕。所以,如果你想要在Docker容器中运行多个进程,你会需要一个进程管理工具。

监管日志

最后,讲一下日志。日志由管理进程负责。通常这个进程管理器通过捕获进程的stdout/stderr ,并将其记录到一个日志。“App Container Specification”上有关 日志 的说明如下:

应用程序应登录到 stdout和stderr。容器执行程序负责捕捉和不断输出。

对于 CoreOS来说,systemd似乎是一个显而易见的选择。 Runit在这方面做得很好 ,但这又回到我已经在前面提到的,专业上来讲,这是不必要的额外工作。

Docker的做法是, 把近六个月的日志记录到日志插件 prosposal文档中。虽然还未实现,但考虑到这是由 Michael Crosby 提出的,我对它有信心。

用户体验和使用经验

大家对Rocket的另一个不满在于用户体验。但请记住,Rocket最新发布的版本是0.1.1。你知道第一辆车的样子吗?它看起来是这样的。这当然不是最好的用户体验,然而这是朝着法拉利和保时捷的第一步。

从容器规范看Docker和Rocket

但同样也是最重要的是,Rocket是App Container Specification的实现,不会强加给你任何东西。同样,Dockerfiles、Docker daemon以及其它你想要的实现,都只能靠你自己了。甚至是Stage1!你想让Docker作为管理器?破解它,并把它作为参数传递给 rkt run ,成为一个Stage1进程。我都能想象在未来,CoreOS很可能会实现一些很棒的工具,甚至提升Ops 和Devs的用户体验。但那些工具可能会作为单独的项目,而不是Rocket的核心部分。在这一点上我认为最重要的是项目的稳定。

结束语

我要十分明确地说,我喜欢 Docker,并且一直在关注Docker。这篇博文并不是在讨论Docker或Rocket好与坏。大多数人都是没有读过“App Container Specification”,才会总是要比较这两者的好坏。

最后,强烈建议你去了解一下Docker和Rocket。如果你喜欢用C编码,你也应该试试LXC或其它类似的技术。还有很多事情可以做,很多机会,让你成为目前这个行业巨变的一部分!

原文链接: Docker vs Rocket Gimme a Break

【相关活动】 Docker上海Meetup活动将在2015年01月18日于UCloud摩尔会议室举行,演讲内容鞥富:联科集团的联席合伙人吴秉宗博士的《应用程序容器“Docker”与基础设施容器“Joyent”SmartMachines 的融合》、点融网运维技术主管万林涛 《Docker在Devops流程中的使用(以点融p2p互联网金融应用为例)》、Cisco高级工程师杨章显《Kubernetes系统架构介绍(Kuberenetes各核心部件的实现原理及其协同工作)》,以及UCloud高级技术专家罗成对《Docker与数据库的应用结合》。报名地址: http://huiyi.csdn.net/activity/product/goods_list?project_id=1646

如需要了解更多Docker相关的资讯或是技术文档可访问Docker技术社区;如有更多的疑问请在Dcoker技术论坛提出,我们会邀请专家回答。CSDN Docker技术交流QQ群:303806405。

正文到此结束
Loading...