Amazon在容器管理服务方面已经完全打败Microsoft,Azure目前尚不能支持Windows容器管理服务,而AWS的EC2 Container Service已经能够支持Windows容器——尽管这项测试服务仍然存在一些警告。 Amazon提供了一个CloudFormation模板,用于创建基于Windows的EC2容器集群,用户只需点击几下即可开始使用。Jeff Bar的博客文章声称该项服务已准备好“在我们正式投产之前最后完善该项功能的同时容器化和测试Windows应用程序”。
Windows Server 2016在2016年9月发布以来一直支持Docker。在运行容器之前要先激活一项Windows功能,下载Docker runtime,使用基于Microsoft的Windows Server Core的映像或Nano Server映像。 AWS构建了一个自定义的Windows Server机器映像,该映像已配置Docker,并使用CloudFormation模板在EC2中创建虚拟机。 Amazon建议在不同的集群中运行Linux工作负载和容器化的Windows工作负载,但在集群中可以使用Docker Hub或EC2 Container Registry产生的映像。
Windows主机的用户体验与现有的基于Linux的平台相同:容器主机作为EC2虚拟机运行,并使用AWS任务定义来启动容器。Windows任务定义并不包括所有任务功能,其中某些功能被列为具有未知行为。在网络堆栈中缺失许多功能,且不支持容器和自定义DNS设置之间的链接。
由于这些缺失的功能,以及Windows不支持覆盖网络的事实,很大程度上限制了目前AWS中的Windows容器的可用性。如果缺乏覆盖网络,在不同主机上运行的容器之间将无法进行通信,因此Web应用程序容器无法把消息发布到消息队列容器或将数据保存到数据库容器,除非它们都托管在同一个EC2上。这个局限性将在Windows更新中进行解决,但发布时间尚未公开。在这个问题解决之前,这项服务只能适用于无状态架构,即其应用程序组件在容器中运行,而使用平台的其他部分:如 Simple Queue Service进行通信和Relational Database Service进行存储。
实现覆盖网络之后,用户就能够在同一个Docker Swarm里在不同的操作系统上运行主机,因此ECS保持集群分离的建议可能会改变。在同一个集群中运行Linux和Windows Docker引擎便于用户采用混合解决方案,即使用任何堆栈中的最佳技术,并让平台在它们之间进行连接。采用分布式解决方案则可以在Linux上使用Nginx容器,代理在Windows容器上运行的完整ASP.NET应用程序,但对所有组件使用相同的ECS基础架构和管理接口。
Azure容器服务和Google容器引擎目前尚不支持Windows管理容器服务,尽管在它们的云服务中有IaaS选项。 Microsoft提供ARM模板来运行Windows Server 2016 VM。该VM预配置了Docker以及下载到VM上的Windows Server Docker映像。 Google Compute Engine支持在VM上运行的Windows容器,但没有自定义机器映像,因此用户需要自行在Windows上配置Docker。
其他公司也开始对Windows Docker进行容器管理服务的研究。 Kubernetes 1.5版本的一个主要功能是支持Windows,DC / OS也声称即将支持Windows。随着Docker和Microsoft之间的商业合作,很可能还将推出一个Windows版本的Docker Datacenter。届时用户将有一整套全面的,用于管理内部容器或云服务中的容器的产品可供选择。