博客水木

作为一种部署应用程序的全新方式，容器技术在短时间内获得了广泛关注，但是这种技术同样存在某些限制，并且和虚拟机存在本质上的不同。

虚拟化技术已经改变了现代计算方式，它能够提升系统资源使用效率、消除应用程序和底层硬件之间的依赖关系，同时加强负载的可以移植性和安全性，但是hypervisor和虚拟机只是部署虚拟负载的方式之一。作为一种能够替代传统虚拟化技术的解决方案，容器虚拟化技术凭借其高效性和可靠性得到了快速发展，它能够提供新的特性，并且帮助数据中心专家解决新的顾虑。

容器和虚拟机之间的主要区别在于虚拟化层的位置和操作系统资源的使用方式。

虚拟机依赖于hypervisor，其通常被安装在“裸金属”系统硬件之上，这导致hypervisor在某些方面被认为是一种操作系统。一旦 hypervisor安装完成， 就可以从系统可用计算资源当中分配虚拟机实例了，每台虚拟机都能够获得唯一的操作系统和负载(应用程序)。

通常，第一台虚拟机都将会被用来运行系统管理程序，比如Microsoft System Center。而之后的虚拟机可能包含其他企业负载，比如数据库、ERP、CRM、邮件服务器、媒体服务器、web服务器或者其他业务应用。虚拟机之间是完全隔离的——没有任何一台虚拟机知道(或者依赖)相同系统当中的另外一台虚拟机的存在——恶意软件、应用程序崩溃和其他问题只能影响一台虚拟机。虚拟机从一个虚拟系统被移动到另外一个当中，而不用考虑系统硬件和操作系统等因素。

而容器环境的工作方式则有所不同。对于容器环境来说，需要首先安装主机操作系统，之后将容器层(比如LXC或libcontainer)安装在主机操作系统(通常是Linux变种)之上。在安装完容器层之后，就可以从系统可用计算资源当中分配容器实例了，并且企业应用可以被部署在容器当中。但是，每个容器化应用都会共享相同的操作系统(单个主机操作系统)。

相比于虚拟机，容器拥有更高的资源使用效率，因为它并不需要为每个应用分配单独的操作系统——实例规模更小、创建和迁移速度也更快。这意味相比于虚拟机，单个操作系统能够承载更多的容器。云提供商十分热衷于容器技术，因为在相同的硬件设备当中，可以部署数量更多的容器实例。然而，单个操作系统有可能引起影响所有相关实例的单点事故。比如，恶意软件或者主机操作系统崩溃可能禁用或者影响所有容器。此外，容器易于迁移，但是只能被迁移到具有兼容操作系统内核的其他服务器当中，这样会无形中减少迁移选择。

从实际应用的角度来说，容器和虚拟机可以在同一个数据中心当中共存，因此这两种技术被认为是互补的——为现代应用程序架构师和数据中心管理员添加了可用工具集，通过不同的方式为应用负载提供支持。

没错，容器比虚拟机更能允许在有限的物理空间里安装更多的应用。以Docker为代表的容器技术，在云计算或数据中心领域击败了虚拟机。虚拟机会占用大量的系统资源。每台虚拟机不只是运行一个完整的操作系统副本，而是操作系统所需要运行的所有硬件虚拟副本，这会轻而易举地增加CPU和内存负担。相反，容器需要的只是一套支持程序和数据库的操作系统，以及足够的系统资源来运行特定的程序。这实际上意味着，利用容器技术，你能在每台服务器上运行多于虚拟机两到三倍的应用程序。除此之外，你可以利用容器创建一个便携并且可持续的、用于开发/测试和部署的运行环境，这相比于虚拟机又是一处利好。

如果这些就是我在比较容器和虚拟机时能想到的一切，我会立刻为虚拟机写一份讣告，宣告它的死讯。然而，还有很多比在服务器中放多少应用程序更重要的事情。

容器技术的问题：安全

经常被当下兴高采烈的容器技术支持者们所忽视的最大问题，便是安全。Daniel Walsh是一位任职于红帽的安全工程师，主要研究Docker和容器技术，他指出：容器技术并不像看上去那么可靠。以应用Libcontainers作为技术支持的Docker为例，在Linux系统的工作模式下，Libcontainers可以访问五个命名空间：流程，网络，安装，主机名和共享内存。这固然很好、很强大，然而仍然有很多重要的Linux核心子系统不能被容器所兼容，包括所有的设备、SELinux、Cgroup以及/sys下的所有文件系统。这意味着，如果某位用户或者应用程序获取了容器内部的超级用户权限，底层操作系统理论上可以被破解。这是一件非常糟糕的事情。

现在，出现了很多保护Docker和其它容器技术的措施。举例来说，你可以将一个/sys文件系统设置为“只读”，或者强制某个容器进程对特定的文件系统执行“只写”，抑或设置网络命名空间以使其只能与特定的企业内联网交流信息。但是，这些办法都不能从根本上解决问题，如此维护容器安全需要耗费你大量的时间和精力。

另一项安全问题是，很多人都在发布基于容器的应用，其中的一些比另一些要更可恶。我们假设你和你的团队有懒惰的倾向，你们不加辨别地安装到手的第一个容器，然后不知不觉就为服务器带入了木马。你必须让你的人明白，他们不能简单地像从手机里的应用商店下载游戏一样，从网络上下载应用程序。他们这种毫无责任意识的行为，很可能为你的服务器带来严重的安全隐患。

对于容器的其它担忧

好，如果我们能解决容器的安全问题，那么容器技术就可以统治世界了，是这样吗？很抱歉，并非如此。事实上，你还需要考虑容器其它方面的问题。

RackN公司CEO，OpenStack基金会的董事成员Rob Hirschfeld认为，容器的包装问题仍然棘手。创建一个加密箱能够部分地帮助解决下游问题（你知道你有什么），而不是上游的问题（你不知道你依靠什么）。“将部署划分成更多离散且独立的功能分区的确是聪明的抉择，但是这意味着你们要管理的部分也变得更多了。”

对此，我必须添加一句：这不仅是安全问题，也是一个质量是否能够保证的问题。固然，X容器可以运行NGINX网页服务，但是最终版本是你想要的吗？它包含TCP负载均衡更新的功能吗？在容器中部署应用固然是很容易的事，但是如果你安装了错误的容器，你最终在做的还是浪费时间。

Hirschfeld还指出，容器的扩展问题可以成为一个真正的难题。切记，容器的全部意义在于运行单个应用。你在容器里添加的应用功能越多，你从第一步开始使用虚拟机的可能性就越大。

在容器和虚拟机间做出抉择

那么，你究竟该如何在容器和虚拟机间做出抉择呢？Scott S. Lowe,一位虚拟机设计工程师，建议你考察你的“工作范围”。换言之，如果你需要运行单个应用程序的多个副本，比如MySQL, 你需要的就是容器。如果你需要灵活地运行多个复杂应用，那么你需要的就是虚拟机。

除此之外, 容器往往会把你局限在一个特定的操作系统版本里。这也许是好事，如果你在容器中恰当地运行了应用程序，你就不必担心它的依赖性——但是它同时也限制住了你。 如果你使用的是虚拟机的话, 不管你应用的是什么管理程序——KVM, Hyper-V, vSphere, Xen,你都能非常得心应手地运行任何操作系统。

你需要在最少的服务器上运行最大量的特定程序吗？如果那就是你，那么你需要使用容器——记住，你需要密切关注在你的系统中运行着的容器,直至容器安全问题能够最终得到保证。而如果你需要在服务器里运行许多个应用程序，或者使用多种多样的操作系统，那么你最好使用虚拟机。如果安全问题是贵公司的第一要义，那么你现在仍然最好还是使用虚拟机。

在实际情况中,我希望我们中的大部分都能在我们的云计算和数据中心里同时运行容器和虚拟机。容器技术在经济上的优势让任何人都无法忽视，然而虚拟机仍然拥有值得称道的优点。随着容器技术的成熟, 我真正希望发生的事情是虚拟机和容器技术可以融合到一起,为云计算领域带来实质意义上的改变。我们目前还没有做到，但是我们终有一天会做到。