为什么Docker != Containers,Docker OSS != Docker Inc.

jopen 4年前

去年VMware启动了一个称为 Bonneville 的项目,之后演进为 vSphere Integrated Containers

最近我调动到VMware Cloud Native Application Business Unit(VMware 云原生应用程序业务部门),Bonneville和VIC是我的日常工作内容。

如果你懒得阅读上面给出的博客链接,那么简单来说,vSphere Integrated Containers是一种技术,允许用户预配VM的同时保留Docker的体验(API/CLI,镜像格式,公开的registry,等等)。这么做的好处是,简单来说,有利于开发人员(他们“需要Docker”),并且有利于IT(因为大多数IT部门都具备围绕VM的标准化运营能力)。

这样的理念不容易理解,因为业界存在一个流行的基本误解:Docker = 容器。

这是必须改变的观念。

进入“unikernels”。

从这里开始,本篇博客的所有内容都仅仅是我的个人观点,和我的公司无关(仅仅提醒一下)。

几天前,Unikernel Systems发表声明,他们会加入Docker(Inc.)。 这里 有谈论这一事件的简短视频。

视频里有一些有意思的点。

其中,“能够使用相同的Docker工具,该工具在开发人员中应用广泛,将快速加速unikernels的使用”,这个说法很重要,大家需要在理解Docker !=容器的基础之上加以理解。

可以进一步将这句话改为(在Bonneville的上下文里):“能够使用相同的Docker工具,该工具在开发人员中应用广泛,将允许用户利用传统的IT已经标准化了的VM设施”。

或者放在下幅图里理解(图中架构有所简化):

为什么Docker != Containers,Docker OSS != Docker Inc.

无需干扰用户的前端体验,就可以为合适的工作选择正确的后台支撑(可以使用Unikernel,容器或者VM)。

这个想法非常强大。

上图还需要注意,VM并不代表是在VM之上运行OS,然后运行容器。也就是说,我们讨论的不是在纯物理机OS上初始化容器还是在VM里的OS上初始化。

上图展示的是由Docker初始化的VM(这正是 vSphere Integrated Container 技术所实现的。)

如果你想更进一步,我建议大家看一下 Ben Corrie去年在QCon上有关Bonneville的演讲 。非常值得花50分钟看一下这段视频。

现在回到Unikernels。

博客圈里已经有好几篇文章深入探讨 unikernel为什么不适合生产环境 (这些文章需要辩证地对待,取决于你问的是谁,你可能也听说过VM不适合生产环境;不确定这些对于容器的判断是否公正)。

还有几次相关主题的在线讨论,其中一次是Hacker News的 超长讨论

大量评论中真正吸引我注意力的是Solomon Hykes(Docker的创办者和CTO)所说的:

“计算机一次只运行一个unikernel。只不过有时候它们是虚拟机。记住虚拟化越来越趋向硬件辅助,这里的软件部分是成熟的。因此大多数情况下应该将这些担忧隔离开,假定VM只是一种特殊类型的计算机。

在hypervisor不够安全的其他用例下,可以转而使用物理机。

我得承认我并不是100%确定他在这里想表达的意思。有时候大家都使用的指代IT堆栈里的某个东西的术语会变化,从而造成混乱。如果你也觉得我们这里还处在初级阶段,方案还有些混乱...那么你的整体感觉是对的。

我从这段话里学到的是Docker意图提供解决方案。可以是纯物理机上的容器,VM上的容器,hypervisor上的Unikernel,等等。

我认为VIC(我喜欢用hypervisor上的“containerVM”来指代VIC)是Solomon暗示的另一种解决方案。

因此未来很可能的替代解决方案的更为详细的架构图类似:

为什么Docker != Containers,Docker OSS != Docker Inc.

Docker收购Unikernel Systems的事实应该唤醒大家这方面的意识,这对整个业界有深远的教育意义。

当然这也会给一些人带来困扰:

为什么Docker != Containers,Docker OSS != Docker Inc.

我认为这是好事,因为给了大家选择最适合自己使用场景的后台的权利。但是,不管Docker是否收购,unikernel都会继续存在。也就是说,用户可以选择unikernel并且一直使用它。

我身体里的阴暗小人建议我们应该透过Docker Inc.的视角来看待这一切,它是Docker OSS(Open Source Software)项目背后的商业公司。

Docker Inc.渴望位于“堆栈的顶层”。这样他们会是“大家看到并且与之交互的接口”,这会让其处在十分有利的地位。

他们尝试确定“控制点”。这本身不是什么坏主意,这是所有商业公司都希望达到的保持差异化的方式。

我从来没有看到哪一家商业公司的策略是停留在堆栈的最底层,等待由其上能够轻松使用的技术上帮助其实现商业价值。这个领域有很成熟的业界实践和模式。

现在假象一下如果Docker不去收购Unikernels Systems会怎么样。

如果unikernels在未来成功了,我们就会看到两种独立并且平行的堆栈(一个Docker/容器堆栈,和一个unikernel堆栈),很可能有不同的接口。

这时会出现一个第三方(比如,Kubernetes),屏蔽掉后台运行时及其接口,提供部署到这两种堆栈的单一入口点。那么,结果是,商业化Docker(Docker OSS项目和Docker Inc.商业实体)。

Joe说堆栈中位置越高价值越大,这是对的,但是我认为,在尝试并且使用它时,需要确定正确并且稳固的控制点。

到这里,希望Docker != 容器这个观点应该更加清楚了,还有个大家未来需要熟悉的另一个核心概念。

这个核心概念是: Docker OSS != Docker Inc.

这样的摩擦已经发生在一些公司和项目之间,比如,Kubernetes,Mesos和Docker(Inc.)。他们(还有其他很多)都在为成为这样的“入口点”而“激烈竞争”。

事实上,当所有人都在使用Docker(OSS)标准化时,Docker Inc.只是尝试围绕Docker构建业务模型的众多公司中的一个。

Docker Inc.有(明显)优势,但是大家得记住Docker OSS != Docker Inc.

总之,我想要澄清我并不是想妖魔化Docker Inc.

他们是一家伟大的公司,我非常喜欢它的理念,并且它正在做所有商业公司(包括我就职的公司)都会做的事情:产生利润。

原文链接: Why Docker != Containers and Docker OSS != Docker Inc. (翻译:崔婧雯 校对:)

===========================

译者介绍

崔婧雯,现就职于IBM,高级软件工程师,负责IBM WebSphere业务流程管理软件的系统测试工作。曾就职于VMware从事桌面虚拟化产品的质量保证工作。对虚拟化,中间件技术,业务流程管理有浓厚的兴趣。

</div>

来自: http://dockone.io/article/995