关于其各种容器(container)选项，微软公司并没有提供很好的文档介绍。故而在本文中，我将为您介绍当您所在企业组织开始对其进行部署时需要考虑哪些东西。

今年一月份，我为Computerworld网站撰写了一篇关于Windows Server 2016技术预览测评的文章。我在这篇文章中提到了Windows Server最新的对于Hyper-V容器的支持已被添加到其对于Docker样式容器的支持。

然而，两个容器选项的存在却导致了很多的问题。一款Docker容器与新的Hyper-V容器之间的区别到底是什么?在哪些情况下，您企业想要使用其中的一款容器解决方案而非另一款?是否有单独的方法来部署这些容器解决方案呢?

关于这两种容器选项，微软公司并没有提供非常详尽的文档介绍。而对于Windows Server平台而言，容器本身又是很新的。鉴于上述这两方面的因素，我想要专门就Windows Server 2016在当前发布的预览版中究竟提供了什么具体的容器解决方案，或承诺将在该软件的RTM(Release to Manufacturing)版本发布日期(很有可能是在2016年下半年)之前所提供的，做一个整体性的介绍。

然而，就目前而言，您企业组织最好的办法便是仔细阅读有关不同容器选项的相关资料，并尽可能的推迟部署。我们仍然还处在Windows Server容器进程的早期，故而仍然有很多细节问题有待解决。

概述

当前，在Windows Server 2016中有两种类型的容器：Windows Server容器和Hyper-V容器。两者都仅适用于Windows Server;例如，两者都不可以混合和匹配Linux或Unix。

对于像我这样懒惰的管理者来说，不妨就让我们开门见山的从重要的问题开始吧：两种类型的容器中是否存在一种容器要比另一种容器更难以部署呢?答案是否定的。

容器类型执行不同，并在系统管理程序中，拥有不同级别的隔离和信任程度。但在其核心，这是一个由所有者的物理机所做出的部署时间决策——主机所有者决定哪种类型的容器将被使用，其就像在一个向导程序检查正确的单选按钮一样简单。您只需在创建时从两种容器中选择一种。该决策将影响到Windows Server 2016这一操作系统本身(虚拟机管理程序，这一切的底层的东西，运行在其之上的硅芯片和物理硬件设备)——在每种容器中隔离和执行工作负载。

那么，既然您现在已经知道了：部署任何一种容器选项给您企业所带来的工作量都是相同的，您又要怎样聪明地在两者之间作出决定呢?本质上，其要归结为信任：如果您信任运行在容器中的代码，那么您会选择一款Windows Server容器(即：传统的Docker式)。而如果您不信任代码，或者无法验证代码，又或者这些代码不是来自您自己企业组织内部的开发人员，那么，一款Hyper-V容器则是您所应该选择的。下面，就让我们来详细的看看每种容器选项吧。

Windows Server容器

Windows Server容器实际上只是Docker开源容器项目的一部分，所以如果您企业组织考虑部署一款Docker式的容器，您会考虑一款Windows Server容器。这些容器本质上是一种新型的虚拟机，在某些方面比传统的虚拟机的隔离性要小——因为在很多情况下，在主机上运行的所有容器都是共享的。在这些共享的项目中，包括了操作系统文件、目录和运行服务。这样做是为了提高效率，因为如果您在主机上运行三种不同的容器，所有相同版本的Windows Server将作为客户，您在任何给定的时间都只需要一个C:Windows 目录副本。

这种共享仍然从可能运行在主机上的任何给定的应用程序分离容器——但其也降低了管理费用，使容器更轻量级。使得您企业组织能够因为这种共享而让每台运行容器的服务器获得更多的空间，而不像传统的虚拟机，其更加孤立且不共享任何东西——因而往往有更多的重复。当您企业组织的主机和客户机都运行了相同的操作系统，以便能够充分利用这一共享时，您通常也会使用Windows Server容器;这样，您就不能在Windows Server 2016主机上运行一款Ubuntu Server容器。(对于这种类型的工作负载，您将使用传统的虚拟机。容器将不适合这种情况。您会使用虚拟机，其自2008年以来就已经支持Windows了。)

不管怎样，现在由Windows Server容器支持的两种容器图像操作系统是Server Core(不带图形用户界面的Windows)和Windows Nano Server，从根本上重构了适合于面向小微服务角色的微服务器。(更多的是关于微服务。)

那么，Docker将如何适应所有这一切呢? Docker提供了一个“管理层”，如果您愿意，API和引擎将管理容器——其已经迅速成为行业标准，而究其原因则很可能是因为Docker本身是开源的，并得到了广泛的应用。而互联网上的任何人都可以使用的Docker Hub则是一款真正市场风格的存储库，所有的应用程序都运行在Docker式的容器中。

Docker还提供了一款框架，开发人员们可以用来更接近其代码的实际操作，并建立他们的代码运行所需要的整个环境容器。开发人员们基本上是建立容器的图像，然后再很容易的运到操作，而且基本上其是作为客户机运行在主机上。更新和代码修复可以以相同的方式被快速和容易地处理。

这些容器图像甚至可以在整个应用程序的很小一部分上工作，这组成了解决方案，并使得其更容易在一个面向微服务的环境中工作。从一个全局的角度来看，借助容器的工作使得开发人员们能够编写出良好的代码，进而更好的在他们的环境中工作运行。开发人员可以不用再编写那种在他们自己的开发机器上工作运行良好，但部署到生产软件上就完全没有作用的代码了——因为二者现在是一样的了，而代码必须在两个地方都能工作运行。这也降低了操作运行人员和IT人员之间的摩擦——在原始服务器环境状态的IT和开发人员期望获得某些配置，但往往缺乏能力或理由改变生产环境，以适应他们的期望。

这些Docker式的Windows Server容器意味着一定程度的信任——要么是您已经从Docker Hub下载了一款受信任的应用程序，要么是您企业组织内部的开发人员或合同开发人员为您提供了运行您所信任的代码的容器。对于那些在容器中拥有可信代码的应用程序，Windows Server容器是被推荐且适当的。操作系统文件的共享和投影不应成为受信任代码的问题。

但是，当不受完全信任的代码或应用程序需要更多一点的安全，更多一点的隔离时，会发生什么呢?

Hyper-V容器

当您企业组织开始考察Hyper-V容器时，您会发现，其通过灵活性、图像和易于重新部署Docker式Windows Server容器的格式，以及Docker API和我在上文中所讨论的管理工具，将隔离的模型和传统虚拟机的抽象进行了结合。

微软Azure的首席技术官Mark Russinovich去年在一篇博客中写道：Hyper-V容器“将应用程序与担保相关的传统虚拟化隔离，但却是借助方便的、图像格式和Windows Server 容器管理模型，包括Docker引擎的支持。”这里的区别就在于隔离级别水平：Hyper-V容器不直接与主机共享操作系统文件、进程和服务。相反， Windows Server将每个小容器图像包裹在一台功耗非常低的虚拟机中，从而实现一款Docker式的Windows Server容器所不具备的抽象和信任边界。

然而，该虚拟机对于所有意图和目的的管理员是透明的。容器图像本身运行Windows Server能够理解：事实上，容器图像和不定期运行在不受限制的硅芯片上，从而能够充分利用对于来自这种意识操作系统的优化。但是，即使这些容器图像更加隔离孤立，他们的部署与Windows Server容器也没有任何不同。您仍然可以使用Docker API。您仍然使用Docker客户端。您只需选中一个不同的盒子，而容器图像本身都以相同的方式建立和交付，不论您想用哪些隔离模式来运行它们。

这种方法的缺点是：会带来更多的管理费用开销。由于额外的隔离，更多的代码和进程被复制。事实上，即使封装了一款Hyper-V容器的轻量级的虚拟机很小，但其的确增加了运行一个容器图像的成本。所以当您可以把一款功能强大的主机塞满Docker样式的Windows Server容器时，Hyper-V容器将被限制在较少数量的容器，其它所有的硬件都一样。

再次强调，这些容器图像将只支持Windows Server。即使有隔离，但容器图像和主机操作系统之间仍然有共同的共享性。所以如果您企业组织的容器图像运行了Linux，另一种风格的Unix，BSD或任何其他可替代的操作系统，对您企业而言，这些新的Windows Server 2016的功能都将无关紧要。

最重要的一点是：第三方代码、市场代码、或任何不被您企业组织的任何一个部分完全信任的代码都应该在Hyper-V容器中运行。这些同时也是多租户公有云和其他类似环境用户的最佳选择。除了容量能力，您企业什么也不会失去，但您却因为更加孤立而获得了安全优势。

Docker容器

现在为了证明其一直是任何技术最困难的部分，请允许我介绍Docker容器。在上文中，我提到了Windows Server容器是Docker开源项目的一部分。Docker容器有别于Windows Server 容器。 Windows Server 容器可以使用所有Docker的基础技术，但现有的用于管理Docker容器的Docker工具集(至少在当前这个版本中)与Windows Server容器并不兼容，也不与Windows Server容器管理工具兼容。

Docker容器都是其自身特定的事情，而Windows Server容器就像Docker 容器一样又能力共享和隔离——而这也就是我为什么将其称之为Docker样式的Windows Server容器的原因所在了——他们不是Docker容器本身。这在未来可能会改变，特别是在一个服务包或下一个版本的Windows Server中。但现在，即使这三种容器的类型可能都是相似的，但仍然有着不同的概念。Windows Server当前只支持两种容器。

当今的技术状况

眼下，在Windows Server 2016中支持的容器涉及到非常多的正在进行中工作。有很多部分都移到了容器中：消除对主机和操作系统文件，以及特定的版本和补丁级别的依赖;实现恰当的隔离，并确保没有任何代码能够破坏安全和信任边界;使得开发人员能够获得合适的工具和自动化水平，进而使得开发人员们能够在他们首选的集成开发环境(IDE)中与容器工作，并能够将他们的应用程序直接导入到容器;确保容器可以在公共云中无缝的上下移动;等等。

在所有这些情况中，仍然存在致命的工作错误和bug。如果容器对于您企业服务产品的路线发展蓝图是至关重要的话，那么您可能希望现在就开始测试Windows Server容器和Hyper-V容器的功能，特别是检查PowerShell命令对于容器是否可用，以及是否可以在Windows Server 2016主机上管理它们。

但是，如果容器是一个不错的选择，但对于您所在的企业组织又不是一个必须的选择的话，那么我的建议是推迟尝试任何事情，同时使用技术预览版4进行最基本的探索研究。目前仍然存在太多的不确定因素——包括前面提到的致命的错误和bug——以便能够真正获得一个统一的掌握。

对于Windows平台而言，容器的支持将是相当令人兴奋的。而关于其他方面，还有更多值得介绍的内容。

====================================分割线================================

本文转自d1net（转载）