【讨论】Docker会取代虚拟机吗?

Docker无疑是当下最具影响力的开源项目。Docker何以如此的成功? 它是否取代虚拟机，这样的转变是不是会在将来某一天出现的一个巨大的临界点时突然爆发? 如果是的话，那会是什么时候?

为了解答这些问题，让我们先来简单的回顾一下过去的发展历程吧！这样也许能够促使我们更好的了解当下的状况和展望未来。

在虚拟机技术普及之前，系统管理员们习惯于上线物理服务器来为他们的用户提供服务。这个过程很繁琐，无法实现完全的自动化，并且需要花费几个小时甚至几天。如果出问题了，他们只能跑到机房去更换物理元件。

伴随着虚拟机的出现，DevOps人员可以在他们所有的物理服务器上任意的安装Hypervisor，然后他们便可以在用户提出申请时直接分配新的虚拟机。上线一台虚拟机不再需要几个小时，而仅仅只需要几分钟就够了，而且可以自动化完成。底层硬件的差异越来越少，而更多的是变得商务化。如果某个用户需要更多额外的资源，创建一个新的虚拟机就行了。如果一个物理主机出现了故障，管理员只需要将该宿主机承载的虚拟机迁移或恢复到另外的宿主机即可。更细致 的部署模式变得可行和易于操作。

用户不再需要把他们所有的程序都运行在同一台主机上，通过使用虚拟机，他们可以将底层硬件的功用发挥到淋漓尽致。人们可以在一个虚拟机上跑数据库， 在另外一个上面运行中间件，然后在第三个上面跑web，而完全不用担心硬件资源利用率的问题。在同一家企业里，一群人负责购买服务器物理硬件，而另外一群人负责软件栈的架设，他们的职能划分相对独立并且互不干涉。连接两个团队的桥梁便是虚拟机。解决方案架构师们可以方便廉价的将每个应用部署到不同的虚拟机 上，而极大的减少了他们的运维成本。正因为如此，软件工程师们也同样喜爱它。这也正是Hypervisor技术所带来的最大的创新。

几年过去了，人们已经习惯于通过虚拟机来承载他们的业务。初创公司甚至于不再倾向于购买服务器硬件资源了，他们只需要购买亚马逊的AWS服务即可。如今，每个应用一台虚拟机已经成为了部署软件栈的标准方式。

自上世纪90年代以来，应用程序的部署方式其实并没有什么太大的变动。从那时候开始，如果我们需要部署一个应用，那便需要安装一个linux发行版本，而构建的主要意义在于驱动硬件设备，然后我们需要安装应用所需要的deb或者rpm包，最后才安装和配置我们真正想要运行的那个应用。

直到2013年，Docker提出了一个简单而有效的工具来创建、分发和部署应用程序，它们以一种很赞的方式运行在相对独立的Linux容器里。另 外，针对众多的应用而言，它提出了一个registry的概念，这有点像苹果的app store，这里为了清晰起见，我将其称之为“云应用”。部署 Nginx Web服务器就变成了类似"docker pull nginx"这样简单。这比安装一个最新版的Ubuntu LTS可简单快捷多了。

Docker云应用都是预配置的并且不再需要安装一些Linux发行版附带的无用的软件包。事实上，Nginx Docker云应用是由Nginx社区直接提供和分发的，而并非是Canonical或红帽。

Docker最突出的创新之处在于引入了一整套包括registry在内的云应用标准规范。它不再是使用虚拟机的方式来运行云应用，取而代之的是利用Linux容器。 容器技术实际上在多年前就已经出现，但是一直以来只是在有限的几个圈子里传播，并没有被大众广泛接受。尽管他们提供了非常好的性能体验，但是较之虚拟机而言，他们提供的功能实在有限，并且隔离性方面很弱。作为一个后起之秀，Docker使得Linux容器突然变得流行，然而Docker之所以成功不能完全归功于容器。这只是一个偶然罢了。

这么说来，容器技术本身到底存在些什么问题呢? 首先，他们对热迁移技术的支持还很稚嫩，而且他们不能运行在非原生的工作栈上（例如，在Linux上运行Windows或者是在Windows在运行Linux）。更进一步来说，容器技术最主要的挑战在于安全性：相对于虚拟机而言，它存在更多的潜在风险。实际上，在容器圈子里，无论是 Docker，CoreOS还是其他任何人，都不太建议多租户的容器部署。在虚拟机的时代，你不必关心谁将会去使用它，又或者是它会被如何利用。而就容器 技术来说，在同一台宿主机上，不太建议运行归属于多个不同用户的容器。亚马逊和谷歌都提供了容器托管服务，但是基于隔离性和安全性方面的考虑，他们都是将 每个容器运行在对应的一个单独的虚拟机之上。这种方式可能看起来不是那么的高效，但是的确非常简单实用。

人们也开始逐渐意识到这一点（译者注：Docker和虚拟机结合的这一个点）。在今年年初高调发起的一些项目正是尝试将虚拟机的一些优点融入到Docker当中，其中最具代表性的当属Intel和Hyper推出的Clear Linux项目。