自从微软和 Docker 宣布合作以来，微软 Redmond 一直在容器上面的战略可谓稳扎稳打。最近，微软加入 Open Container Initiative （ OCI ），并作为创始成员承诺支持常见容器的格式和运行。在最新的 Windows Server 2016 技术预览版中，微软终于将本地的 Windows Container 技术提供给开发人员和系统管理员。
由于媒体的关注和用户的积极反响，对于许多消费者来说，容器就等于是 Docker 的代名词。而且它只在 Linux 上运行。鉴于这些事实，在开发者社区里，对于微软支持容器技术也一直比较混乱。在不同的博客文章中，微软强调其投资容器。微软高管并不羞于告诉我们他们有多么爱 Docker 和其背后的团队。这种定位导致大家对于微软容器战略的认识模糊。我不止一次听到开发商询问他们是否可以在 Windows 上运行 Linux 容器，反之亦然。在 Docker 、 Windows Containers ，以及 Hyper-V Containers 领域同样非常混乱，下面我就试图详细阐明微软的容器战略。
说的直白一点。你不能从 Linux 中 push Docker Image 并且 pull 它到 Windows machine 来启动容器。这两个操作系统之间底层内核的差异使它很难让容器可移植。过去，微软试图将一个 POSIX 兼容 UNIX 子系统 Services for Unix 。但是，这不同。回到容器中，你无法使用微软容器模仿 Package once deploy everywhere ”。
Microsoft Windows Server 2016 能够运行两种不同类型的容器 Windows Containers 和 Hyper-V Containers.。为什么我们需要两种类型的容器？因为他们是专为单独的用例和场景。 Windows Server 2016 技术预览版 3 仅仅支持 Windows Containers 。最终版本将包括两种。
这种优势保留了容器的优势——速度、敏捷性和性能。这是一个已知的事实，容器比虚拟机启动快得多。这是因为它们共享底层操作系统的内核。微软为容器设计 Windows Server 2016 来支持共享内核模型。 Windows Containers 依赖操作系统共享服务。这个设计自然导致更轻、更快的容器。他们非常类似于 Linux 容器。 Windows Containers 提供低级隔离，这在一定程度上降低运行异构工作负载的安全性。
如果你认为因为隔离级别， Windows 容器不太安全，那么您应该考虑 Hyper-V Containers 。他们不共享操作系统相同的内核，因而带来强壮的隔离级别，类似于虚拟化。在幕后， Hyper-V Containers 使用 VM 在他们自己的 namespace 运行专用容器。这种架构导致更重的容器大小和更长的启动时间。所以，你还需要使用它们吗？如果你有敏感的工作负载需要更健壮的隔离和安全， Hyper-V Containers 是最好的。在多租户环境中像公共云，他们提供最好的安全性和遵从性。
如果微软有自己的本地容器实现， Docker 的作用是什么?
让我们仔细分析 Docker 的架构。
Docker 作为一个平台有三个组件：
1. Docker Engine
2. Docker Tools
3. Docker Registry
Docker Engine 在 expose API 过程中担当大任。 DockerCLI 是管理容器生命周期的工具链。 Docker Registry 是存储图像的中央位置。
微软和 Docker 密切合作从 Windows Containers 和 Hyper-V Containers 中提供相同的 API 。这就使得微软的容器和 Docker 的巨大生态系统彼此协作，命令行接口也移植到 Windows 。
命令行接口可以在 Windows10 和 Windows Server 2016 操作系统上获取。开发人员和管理员可以将客户端指向到一个运行的 Docker Engine 并且控制它。这意味着它可以从 Windows10 上管理运行在 Red Hat 服务器上的 Linux 容器。自微软决定让它的容器引擎兼容 Docker Engine ，相同的客户端被用来管理 Windows Containers 以及 Hyper-V Containers 。从技术上讲，只要 CLI 能和远程引擎对接，它也可以从 Ubuntu 或者 OS X 上管理微软容器。
除了使用 DockerCLI 和工具，用户可以使用自己喜欢的 PowerShell 环境来自动化容器管理。微软已经带来一套 Cmdlets 处理方 Windows 和 Hyper-V Containers 。这对本地工具和容器的集成有着重要作用。
Azure Service Fabric 是微软对于 Kubernetes 的对标。这是一个设计和部署微服务的平台。当多个同质容器管理和编排在一起，形成一个微服务应用程序。微软声称 Service Fabric 是 Azure 核心基础设施的基本技术。目前支持的服务包括 Skype 、 InTune 、 Azure Data Factory 、 Azure DocumentDB 。它在 Azure SQL Database 和 Bing Cortana 上被用来管理超过 140 万客户数据库。开发者能够将他们的代码作为容器打包，将由 Service Fabric 编排。这种技术现在就可以在 Windows 和 Azure 上获取但是将移植到 Linux 和其他云平台。
Service Fabric 服务可能还处在早期，但这并不能阻止微软用户在 Azure 上使用编排工具 Kubernetes 和 Mesosphere 。因为自从 Windows Containers, Hyper-V Containers 提供相同的 DockerAPI ，这些工具就可以与微软容器协同工作。它可以混合、匹配 Linux 容器和 Windows 容器构建一个复合的微服务应用。 Docker Swarm, Kubernetes, Mesosphere 以及 CoreOS Fleet 可能不区分容器。这对微软用户和 Docker 用户来说是双赢。
微软落后于亚马逊和谷歌的一个主要领域就是容器托管服务或容器作为服务（ CaaS ）。亚马逊在上一届 re:Invent 上宣布 EC2 Container Service (ECS )，最近已经提供这种服务。谷歌将它专业的 Kubernetes 与 Google Compute Engine 结合提供 Google Container Engine (GKE )。其他平台如 Tutum 和 Joyent 也提供 CaaS 等。微软也许是等待它的容器技术稳定之后才发布，当它准备好了， Azure 云平台将成为第一个管理 Linux 和 Windows 容器的云平台。
本文由张鹏程编译整理
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.