容器能够罢免虚拟机，成为下一代计算架构吗？我已经听到很多行业人士说容器从为人所知到真正得到应用几乎比之前的任何技术都要快，这是由开发人员驱动的，正如IT需要效率与规模，DevOps以及业务都在寻求敏捷。

容器是VMworld 2015大会最为热门的话题之一。VMware很清楚地看到了近期容器与虚拟机混搭将会快速进入企业数据中心。IT组织仍旧需要捍卫安全性以及数据管理需求，即使是容器化的应用也不例外。VMware已经在虚拟机端交付了容器，而且相关设计已经取得成功，对虚拟化及云管理解决方案进行了扩展以支持（而且我认为最终会同化）企业集装箱化项目。

VMware全新的vSphere集成容器（VIC）使得管理及确保运行在虚拟机（称之为虚拟容器主机）中容器的安全性几乎和管理及确保传统虚拟机的安全性没什么两样。VIC作为第一流的IT管理对象出现在VMware管理工具中，继承了vSphere 提供的众多虚拟机管理功能，包括强大的安全性。这使得所有VMware顾客都能够很平滑地采用容器技术。

然而，我们认为应用容器真正的转折点将是容器超越简单的无状态计算引擎并直接处理持久性数据之时。到那时，容器必然受限于范围及规模。

容器中有什么？

简言之，容器在其进程内封装并隔离了应用代码，使得代码认为自己独享一台机器，将所有的系统服务调用转交给容器主机。由于容器实际上是进程，因此很多（可能数以千计）容器能够很轻松地共享单台物理或虚拟服务器。

应用认为他们拥有一个完整运行的操作系统（就像是在虚拟机内运行），但这些应用实际是在共享主机操作系统。应用之间的隔离性要低于在虚拟机内运行时的隔离性，但效率更高（因为每个容器并没有运行自己的操作系统）。

容器还有一些其他的优势。容器在用户空间内运行，因此破坏、阻碍或者造成内核级崩溃的可能性很小。容器能够被快速复制，通常是被缓存，而且很容易调整。容器几乎能够在任何地方构建（比如开发人员的MacBook）并在任何地方运行（比如亚马逊Web服务）。这意味着容器在最初设计时就是无状态的，不包括需要保护或保留的数据。

最初设计容器是为了构建微服务。微服务架构非常适合设计为在云中运行的应用。这些新应用是无状态的，因为它们并不保存内部数据而且能够根据运营需求动态调整。

然而，集装箱应用存储仍旧是一个棘手问题。运行在容器内的应用能够访问本地操作系统存储，但如果容器被迁移（或者克隆、复制等等）到另一台容器主机，那么将不会带走当前主机上的数据。因此，无状态容器并不适合需要可靠及持久数据服务的应用。在微会话级将数据保留在云存储比如亚马逊S3中的微服务运行的很好，但大多数应用的需求并非仅限于此。

存储问题解决之道

这意味着容器在未来的数据中心中只是一个小角色，仅限于开发人员使用或者全新的云托管微服务应用？我们认为容器的优势极具吸引力，使得企业数据中心无法忽略，而且正如你可能已经猜测的那样，容器数据管理产品正在脱颖而出。

例如，ClusterHQ公司的Flocker使得容器能够挂载唯一的Flocker数据集并能够跟随容器一起移动。Flocker对数据集进行分区并将共享的块存储挂载到所有的容器主机。采用该解决方案，容器成为“无状态的”而且能够很容易地承载几乎所有应用，即使是数据库比如MongoDB与MySQL。

Flocker 1.3支持OpenStack Cinder块存储而且来自EMC、NetApp、Hedvig以及Nexenta等厂商的自定义驱动程序很快就会出现。在VMworld大会上，VMware宣布支持Flocker，这样容器就能够使用vSphere挂载的任何存储。这还包括vSAN以及支持虚拟卷的第三方存储。上述场景非常有趣，因为他们增加了明确的存储服务，比如针对每个容器所使用存储的QoS。

在其有限的无状态构成中，容器以及虚拟机各司其职。既然容器直接支持虚拟存储，那么hypervisor厂商就需要提供高附加值功能。既然未来的数据中心可能是虚拟机/容器环境的混合体，在虚拟机中会存在大量的容器（并支持混合、以DevOps为中心的云运营），那么hypervisor厂商提供具备整体管理方案的机会非常大。

容器正在帮助我们构建一个越发流畅、敏捷但最终很复杂的环境。这意味着我们需要更好的安全工具，更动态的网络以及适应性更强的存储。一定要让我们知道IT组织如何适应并采用容器产品，以及广泛采用容器技术存在哪些挑战。

本文节选自《IT新架构》十一月刊：淘汰邮件？