Containers: Docker, Windows and Trends

【编者的话】本文翻译自Azure官方博客，由Azure CTO MARK RUSSINOVICH撰写，从最基本的容器介绍起，并逐步介绍到Docker，并讲述了容器在Windows上的受支持情况，以及当下的一些趋势。阅读本文有助于了解微软对容器的看法，以及微软关于容器的未来的看法。文章稍长，如有错误，请慷慨指出。

近来，当人们在讨论云计算时，他们一定会提到容器。一些组织试图去了解什么是容器？容器对于他们在云上的应用程序意味着什么？在面对特殊容器开发和IT操作方案时，如何更好地使用容器？这些组织分布在商业领域的各个部分，从银行和大型金融服务公司到电子商务网站。

从最基础的什么是容器？容器如何工作？今天的容器在什么情形下被广泛使用？到“容器化”趋势的显现。通过分享我的观点，我想帮助你理解如何更好地拥抱这个重要的云计算发展，这样，你就可以无缝地构建、测试，部署，以及管理你的云应用程序。

容器概述

在抽象术语上，所有的计算都是基于一些运行的 function ，这些 function 运行在物理资源上，物理资源如处理器，内存，硬盘，网络等，而这些计算是为了完成一个任务，无论是简单的数学计算，如1+1，还是多台机器间的应用程序，如交易所。随着时间的流逝，物理资源越来越强大，但应用程序经常不会利用物理机所提供的部分资源。于是，为了模仿底层物理硬件，并允许多个应用程序同时运行（每一个应用程序会利用物理机上的部分物理资源），"虚拟"资源出现了。

我们常常将这些模拟技术称为虚拟化。但许多人一听到虚拟化，就会想到虚拟机，而虚拟机只是虚拟化的一个实现而已。虚拟内存，一个由所有通用操作系统所实现的机制，会给应用程序留下一些假象，这些假象会让应用程序以为电脑内存是为它们服务的，并且应用程序甚至可以获得一种体验————应用程序可以使用的内存超过电脑所拥有的内存。

容器是另一种虚拟化，也称为OS虚拟化。在Linux上，今天的容器可以为应用程序，创造感知————一个完全隔离，并独立的OS。为了运行容器，本地硬盘会看起来像一个崭新的OS文件拷贝，内存看起来像只保存了文件和刚开机系统的数据，而且只有系统在运行。为了完成这些，创建容器的主机会做一些聪明的事。

第一个技术是命名空间的隔离。命名空间包括一个应用程序会交互的所有资源，包括文件，网络端口，以及运行程序列表。命名空间隔离允许主机为每个容器分配一个虚拟命名空间，这个虚拟命名空间只包含它所应该看到的资源。通过严格的监视，容器无法获得命名空间(容器所拥有的命名空间)外的文件，因为容器看不到这些文件。应用程序无法列出，或与容器外的应用程序交互，因此，当有数十或成百上千的应用程序正在运行时，应用程序会愚蠢地以为它是系统上唯一正在运行的程序。

为了效率，许多操作系统文件，目录和运行的服务被容器之间共享，并投影到每个容器的命名空间。只有当一个应用程序改变它的容器时，例如调整一个已经存在的文件或创建一个新文件时，容器才会从底层主机OS中获取不同的副本————通过使用Docker的“copy-on-write"最优化，只有容器的部分会改变。在单个主机上，部署多个容器变得高效，这其中的原因之一就是这种共享机制。

其次，主机会控制有多少主机资源会被容器所使用。管理资源，如CPU，RAM，和网络带宽，使得一个容器可以获得它所期望的资源，并且不影响其他正在运行中的容器的性能。例如，容器是可以被限制的，限制它无法使用超过10%的cpu，这意味着无论容器内的应用程序怎么尝试，容器是无法突破另外的90%，另外的90%可以分配给其他容器或自己使用。Linux通过使用一种称为“cgroups”的技术，实现这样的管理。如果是为了适应不断变化的应用程序代码，主机上的容器需要互相协作的，且允许标准的OS动态资源分配，那么资源管理是不要求的。

源于命名空间隔离和资源管理所带来的可靠执行，再结合来自OS虚拟化的瞬间启动，对于应用程序来说，这两者的结合使得容器更加理想。在开发过程中，开发人员可以快速迭代，由于其环境和资源使用情况，对于整个系统来说是一致的，一个容器包装的应用程序（该应用程序可以在开发者的系统上工作）可以在不同的生产系统中以同样的方式工作。即时启动和很小的内存占用同样有利于云方案，因为应用程序可以快速扩展，并且相比于将多个应用程序实例分别安装在一台VM上，安装在同一机器上的多个应用程序实例可以最大化地利用资源。

比较一个使用虚拟机和一个使用容器的相似案例，这个比较强调通过交流获得效率。下面所展示的案例中，主机上存在3个VMs，为了使VMs上的应用程序完全隔离，它们都各自拥有OS文件，lib和应用程序代码的拷贝，再加上一个存在于内存的完整OS实例。即使主机或已存的VMs已经有正在运行的同一版本实例，开始一个新的VM仍需要引导另一个OS实例，并将应用程序库载入内存中。每个应用程序的VM都要为其私有拷贝，付出包括OS引导，内存占用等代价，这些限制了运行在主机上的应用程序实例(VMs)的数量。

下图所展示的是使用容器的相似案例。这里，容器简单地共享了主机操作系统，包括内核和lib，因此他们不需要引导OS，载入lib，或者为这些文件付出私有内存的代价。为了让应用程序在容器运行，容器需要一些必要的内存和硬盘空间，这也是它们唯一的增量。当应用程序感觉像是一个专用的OS时，应用程序的部署就像是把它安装到专用主机上。容器包装的应用程序能在几秒中内启动，并且同一台机器可以安装的应用程序实例的数量比VM中可以安装的还多。

Docker的出现

命名空间隔离的概念和相关OSs的资源管理已经被关注很久了，回到BSD jails，Solaris Zones，甚至基本的UNIX chroot(change root)机制。然而，通过创建一个通用的toolset，包装模型和部署机制，Docker极大地简化了容器化和分发应用程序（该应用程序可以运行在任意Linux主机上）。通过对任意主机提供相同的管理命令，这种常见技术不仅简化了管理，而且为无缝DevOps，创造了独一无二的机会。

从开发者的桌面到测试机器，到一套生产环境，Docker镜像可以被创建，并在几秒内相同地部署到任意环境。这个故事利用DockerHub，创造了一个巨大且不断增长的应用程序包装生态系统。公共的容器包装应用程序Registry（由Docker维护）目前在公共社区仓库发行了超过180 000个应用程序.此外，为了保证包装格式相同，Docker最近和作为创始成员之一的微软组织了Open Container Initiative(OCI),旨在确保容器包装仍然是一个开放，并且由基金会所主导的格式。

Wndows Server与容器

为了让大家感受到容器的威力，去年10月份，我们宣布了在Windows服务器实现容器技术的计划。为了让使用Linux Docker容器的开发者在Windows Server上有着相同的体验，我们宣布了与Docker的合作伙伴关系，以扩展Docker API和toolset来支持Windows Server。对于我们来说，这是一个造福我们所有客户的机会，无论他们是使用Linux，还是使用Windows。正如我最近在 Dokercon 演示的，我们很高兴让开发者和系统管理员在部署他们的容器包装应用时，无论是在Linux，还是在Windows Server，都可以获得一个统一，开放的体验。我们正在开发这个公共 Docker Github仓库 。

在Windows Server 2016，我们将发布两种容器，两种容器都可以使用Docker APIs和Docker客户端：（Windows Server容器和Hyper-V容器）部署。Linux容器需要来自主机的Linux内核的Linux APIs，而Windows容器需要来自主机的Windows内核的Windows APIs。因此，你不能在Windows Server主机上运行linux容器，或者在Linux主机上运行Windows Server容器。然而，同样的Docker管理器可以管理所有这些容器。你不能在Linux上运行一个打包的Windows容器，一个Windows容器包可以和Windows Server容器，Hyper-V一起工作，因为它们都为Windows Kernel优化。

在一些情况下，你可能需要在同一台主机上从不同的可信边界运行应用程序。一个案例就是：如果你正在实现一个多租户的PaaS或者SaaS产品，你需要允许客户在你的产品上提供他们自己的代码，以扩展服务的功能。你不会想要一个客户的代码连接到你的服务，或者能够接触到其他客户的数据，你需要一个比VM灵活的容器，并且可以充分利用Docker生态圈。我们在Azure上有几个这样的例子，如Azure Automation和Machine Learning。我们把它们运行的环境称为 hostile multi-tenancy （敌意的多租户），因为我们假设存在这样的客户，他们有意地寻求颠覆这种隔离。在这样的环境下，Windows Server容器的隔离可能无法提供足够的保障，这就是我们开发Hyper-V容器的原因。

Hyper-V容器与容器化略有不同。为了创建更多的隔离，Hyper-V容器每一个都有自己的Windows Kernel拷贝，并且直接分配内存给它们，这是强隔离的一个关键需求。我们为CPU，内存，和IO隔离(如，网络与存储)使用Hyper-V，并提供与VMs相同的隔离级别。和VMs一样，主机只暴露一小部分受限的接口给容器，以用于通信和共享主机资源。这种有限的共享意味着，相比于Windows Server容器，Hyper-V在启动时间上有点低效，但这种隔离需要允许不信任的和 hostile multi-tenant 的应用程序运行在同一主机上。

Hyper-V容器与VMs不一样吗？除了对OS的优化(来源于Hyper-V已经全面意识到自己位于容器而不是物理机上），Hyper-V容器的部署是借助于Docker的魔力，并且可以使用的包与运行在Windows Server容器上的完全相同。因此，隔离级别的交易与效率/灵活是一个由主机所有者在部署时的所做决定，而不是在开发时的决定。

编排

随着客户开始采用容器，他们遇到了一个挑战。当他们部署数十，或成百上千的容器（这些容器构成一个应用程序）时，追踪和管理部署需要在管理和编排方面有所提高。容器编排已经成为一个令人兴奋的，并且具有多个选择与解决方案的创新领域。容器编排工具被分配到服务器池中(VMs或者裸机服务器)，通常称为集群，并且按时间将容器部署到这些服务器中。一些编排工具不仅走得更远，而且为连接位于不同服务器上的容器配置网络，另外一些则是包含了负载平衡，容器名称解析，滚动更新等，还有的则是可扩展的，并且允许使用应用程序框架扩展额外功能。

关于编排解决方案的进一步探讨，可能需要一个完整的关于其自身的文章。下面是几项技术的概述，所有这些在Azure上都支持。

1. Docker Compose 允许你定义多容器应用。 Docker Swarm 管理多主机间的Docker容器，并通过单个Docker主机上的一些API，组织这些Docker容器。 Swarm和Compose可以放在一起，通过Docker，提供一个完整的编排技术built。

2. Mesos 是一个早于Docker的编排和管理解决方案，最近Mesos在其内置应用框架Marathon增加了对Docker的支持。这是一个开放，并且由社区(由 Mesosphere 公司所创建)所主导的解决方案。我们最近演示了 Mesos与DCOS 在Azure的整合。

3.Kubernetes是一个由谷歌创建的开源解决方案，它为多台主机间的管理提供了将容器分组到 Pods 的功能。 这也是在Azure上受到支持的。

4.Deis是一个开源PaaS平台，是用来部署和管理与Docker整合的应用程序。 我们有一种在Azure上部署Deis集群的简单方式 。

我们很高兴大部分受欢迎的编排解决方案在Azure受到支持，在过去的一段时间里，我们看到社区的兴趣和使用率在逐步上升，我们期望能更加融入到这些社区当中。

微服务

更能立即赚钱的容器，其用途更关注于，通过减化开发者部署在云或on-premises中的服务的测试生产流程，简化DevOps。但现在有另一个正在成长的方案，在方案中，容器更加引人入胜。微服务是一种应用程序开发方法，在该方法中，应用程序的每部分都会被当作一个全面而又独立的组件去进行部署，如果该部分可以被独立扩展和更新，我们则称之为一个微服务。例如，接收公网请求的应用程序子系统可以从子系统中分离出来，分离的方法是：将请求放到后端子系统的队列中，这样就可以读取或将其丢弃到数据库中。当应用程序是使用微服务创建的，则每一个子系统就是一个微服务。在一个single box上的dev/test环境中，每个微服务可能有自己的实例。但随着客户需求水平的上升和下降，每一个微服务都可以根据他们的资源请求扩展到集群服务器间的不同实例数量。如果有不同的队伍在生产它们，则每支队伍可以单独更新它们。

微服务不是一个新的编程方法，虽然它无法被容器明确约束，但当其应用于一个以微服务为基础的复杂应用程序时，Docker容器的好处被放大了。灵活性意味着一个微服务可以进行快速扩展，以满足增加后的工作量。命名空间和容器的资源隔离能防止微服务实例干扰别人，并且Docker打包格式的使用与API，为微服务开发者和应用程序运维人员，打开了Docker生态圈。使用一个优秀的微服务架构，客户可以在减小可用性损失并维持高度灵活性的同时，解决管理，部署，编排，为基于容器的服务需求打补丁等难题。

今天，有很多种使用微服务构建应用模型的解决方案，以及很多我们在Azure的合作伙伴。Docker Compose和Mesophere Marathon只是两个例子。前不久，我们 宣布 并随之释放了一个服务“Fabric”的开发者预览版，这是我们自己的微服务应用平台。它是一个丰富的微服务生命周期管理功能的集合

，包括滚动更新与回滚，分区，摆放限制等。特别是，除了无状态微服务之外，它还支持全状态微服务，这种差异化的事实是微服务管理的数据是与微服务存在于同一服务器上的。事实上，Fabric服务是唯一一个通过将状态管理和同步复制框架直接构建到集群管理而提供全状态微服务的PaaS平台。我们开发这个应用程序框架是为了让内部服务能够进行全状态同步复制的超大规模扩展，像Cortana，Azure SQL Database，Skype for Business这样的服务就是建造在这个微服务之上。我们将在今年的晚些时候释放Fabric服务的公共预览版，但在这期间，你可以在 这里 查看更多关于Fabric服务的信息。

我希望上述帮助可以让你更好地了解微软关于容器的看法、 常见的容器用例，以及一些容器周围新兴行业的趋势。一如既往的，我们期待你的反馈，特别是，如果这里有你想了解更多的领域。

关键字：
 Developer      IT Pro/ Devops        Management     Containers     Deis
 Docker Compose     Docker Swarm     Dockers     hyper-v      Mesos             
 Microservices     Namespaces     Service Fabric     Windows Server 2016

原文： Containers: Docker, Windows and Trends （翻译：洪国安）