关于微软容器战略，你需要知道的十件事

摘要：自从微软和宣布合作以来，微软一直在容器上面的战略可谓稳扎稳打。最近，微软加入，并作为创始成员承诺支持常见容器的格式和运行。这种定位导致大家对于微软容器战略的认识模糊。微软的容器策略并不是可移植性说的直白一点。

自从微软和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作为一个平台有三个组件：

Docker Engine

Docker Tools

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容器的云平台。

本文由张鹏程编译整理

原文链接： http://blog.tenxcloud.com/?p=462