CoreOS发起的AppC一定是好事?听红帽怎么说

云计算
对于CoreOS Fest大会上,红帽、VMware等公司都宣布支持AppC,很多人还都觉得CoreOS的春天来了,更有甚者说,竞争是好事,避免一家独大。不过红帽的riekrh同学可不这么认为。他认为AppC的成员里都没有目前发展最好的Docker,这很明显就是商业之间的竞争。从行业的发展角度来看,AppC的出现很可能会让行业里出现多种容器打包格式,这很有可能会阻碍容器技术的发展。

对于CoreOS Fest大会上,红帽、VMware等公司都宣布支持AppC,很多人还都觉得CoreOS的春天来了,更有甚者说,竞争是好事,避免一家独大。不过红帽的riekrh同学可不这么认为。他认为AppC的成员里都没有目前发展***的Docker,这很明显就是商业之间的竞争。从行业的发展角度来看,AppC的出现很可能会让行业里出现多种容器打包格式,这很有可能会阻碍容器技术的发展。

[[133583]]

本周洛杉矶举行的CoreOS Fest大会上,主题演讲之后的***个讨论会里,CoreOS不出意外地倾情推出应用容器规范(Application Container Spec,AppC)及其***版实现,rkt,并展望了该规范未来被广泛采用的光明前景。

Red Hat在做技术决策时,都会本着选出上游社区所支持的***技术方案的原则,持续评估所有可能的技术选择。这也是为什么Red Hat决定投入AppC并且积极为该规范做出贡献的原因。

Red Hat参与了很多上游社区。但是这样的参与并不代表将全力支持,或者只是觉得AppC或rkt可能能用于企业级IT,也或者永远也无法用于企业级。基于此,下面是今天我参加完讨论会后的一些心得:

rkt有很多招人喜欢的优点,比如围绕systemd的干净的执行模型,开放的开发和监管模型,或者规范本身。

我们一起来看看规范吧。

AppC(应用容器规范)绝对是朝着正确的方向迈出了一大步,它有效的解决了Docker v1在技术和部署模型上的缺陷。应用容器规范花了很多篇幅讲述容器规范可以做些什么,我觉得企业容器领域很需要这样的规范。同时我也觉得CoreOS有着构建规范及其周边社区的***动力。

除了。。。

时至今日,AppC还是只涵盖了基于容器、应用中心模型的很小一部分内容。容器将会重新定义操作系统,也许很多人都低估了这一点。这是个告别传统的单实例,宏内核,UNIX用户空间,进入到使用容器和增量打包技术实现的多实例,多版本环境新纪元的转折点。我们现在讨论的事情是要去改变软件行业已经使用了20年甚至40年的核心范式。

还有很多正在演化的领域,比如安全(security)、syscall、信号(signals)等等。AppC规范需要涵盖比现在更多的领域,它需要更加深入地定义兼容性,对底层系统的依赖性,操作系统,联合存储库命名空间和服务发现等领域。

另外一个很重要的方面可能被规范名字的关键字“应用”弱化了,目前,AppC只包含了单个容器和单个pod,这也是Docker为什么要做集群,因为只有很少的应用能在单个容器/单个pod里就可以运行。今天的讨论会里也提到了这个问题。同样,AppC在应用的可移植方面考虑也欠妥。Nulecule(发音类似:newly-cool)规范的初稿里尝试解决这个问题,将可移植性的概念拓展到整个应用,或者未来可以聚合的组件所提供的服务,并且允许描述多容器应用及其所有依赖组件。

因此组委会需要在AppC中解决这些问题,目前我们只是刚刚开始漫漫旅程,Red Hat会通过社区对此持续跟进。

要注意,AppC目前还不成熟,但与之相比更让人忧虑之处是rkt在推出Docker模型兼容接口的同时,还推出了自己的容器打包格式。我一直认为Docker提出了非常棒的想法将增量打包,镜像分层和容器组合在一起。这个工具改变了业界软件交付的方式。而由于项目之间竞争而产生的多种不同的打包格式可能会给这个领域带来风险,并放缓技术发展的节奏。这将意味着生态系统的碎片化,给实际提供容器内容的公司带来痛苦,这些公司包括Red Hat,我们的ISV合作伙伴以及想要尝试引入容器化的用户们。

在更为底层的组件级别,我们不得不使用dpkg,rpm和一些其他的东西,长期忍受这样的碎片化。回过头看看apt/dpkg和yum/rpm的 PK, 不难发现两种组件之间的竞争并不会给用户带来巨大的好处,相反会有副作用。因为这意味着用户需要用多种格式提供相同的内容,要么enable整个工具链,在系统架构里同时管理这两种高度冗余的格式,要么更为糟糕地强制用户在这两种生态系统中选择其中一种。容器层高级别的聚合只是轻微地改善了这个问题,但是又增加了高层的复杂性,和与现代分布式系统的深度集成。

AppC不支持Docker,主导讨论并且控制格式的公司会很快主宰容器打包标准。甚至没给Docker公司发表自己观点的机会。这并不是过分指责Docker或者CoreOS,每个公司都有做自己想做的事情的权利。实际上,我们现在有两个直接竞争的公司来推动容器标准化,他们使用竞争的工具链,竞争的规范和互不兼容的打包格式。这看上去就像Groundhog Day的火车相撞的慢镜头。我们,在广义的Linux和开源社区里,过去十五年已经发生过很多次类似的事情了,尤其在打包格式领域。

虽然需要更多的时间和空间来验证,但是两个创业公司各自推出不兼容的规范,试图差异化同时又直接竞争,这不是什么好事情。如果CoreOS和 Docker能够通力合作推出标准化的通用规范,镜像格式和分布式协议,那么会更有益于社区和所有需要使用这些技术的人们。目前,Red Hat会继续参与并推进这两种方式,期望以后能够合并统一。

原文链接:http://dockone.io/article/360
 

责任编辑:Ophira 来源: dockone
相关推荐

2020-12-16 18:00:06

数字货币数据安全数字化转型

2021-03-03 14:19:09

机器人人工智能职业

2021-06-15 23:04:17

Localhost域名网络

2018-06-24 09:12:33

redismemcache源码

2021-01-31 18:58:31

redismemcache源码

2018-01-05 10:48:54

混合云尚阳科技IDC

2018-10-30 09:56:31

IBM红帽收购

2015-05-06 13:52:52

微软外媒

2022-12-06 09:00:11

MySQL自增主键查询

2018-12-19 09:15:36

SDN软件定义网络广域网

2021-11-04 10:10:49

人工智能AI

2015-11-12 09:58:45

多租户SaaS软件架构设计

2023-10-08 10:14:12

2015-07-30 15:15:43

360

2019-10-31 15:45:25

Java薪酬语言

2019-01-09 08:42:18

2022-05-05 09:14:41

AlpineDocker镜像开发

2024-04-12 16:16:19

2020-10-09 14:49:41

大数据社会治理人工智能

2020-06-16 14:03:48

边缘计算网络人工智能
点赞
收藏

51CTO技术栈公众号