8月中旬，微软发布了Windows Server 2016预览版，正式加入了Container的特性，发布之前，Microsoft Azure CTO Mark Russinovich特意发表博文，对整个容器生态分享了自己的观点，其中详细分析了Windows Server对Container的两种支持形式及应用场景，以及微软在容器编排和微服务方面展开的工作。
译文链接：http://www.alauda.cn/2015/09/14/containers-docker-windows-and-trends/
以下为原文：
最近，只要提到云计算，就少不了容器的身影。从银行和大型金融服务公司，到电子商务网站等各个商业机构，都想了解容器是什么，它们对云应用意味着什么，以及如何最好的将它们应用于自身特定的开发与IT场景。
从容器是什么以及它们如何工作这类基本问题，到当今它们最广泛的应用场景，再到最新兴起的“容器化”潮流，我想分享我的观点，帮助您理解如何将这一重要的云计算技术无缝应用到云应用的构建、测试、部署与管理过程中。
◤容器概览◢
抽象来说，所有计算都是在“物理”资源集上运行一些“功能”，这些资源包括处理器、内存、磁盘、网络等。完成一个任务，不论是1+1这样简单的数学计算，还是跨机器的复杂应用，比如Exchange。随着时间的推移，物理资源越来越强大，但是物理资源的“边角余料”时常不能被应用程序充分利用。因此，在物理硬件之上创建了“虚拟”资源，多应用并发运行成为现实——充分利用硬件的每一小部分物理资源。
我们通常把这类仿真技术称作虚拟化。提到虚拟化，很多人都会立刻想到虚拟机，而这只是虚拟化的一种实现。虚拟内存——一种操作系统级别的实现机制，使应用程序误以为计算机的内存全部都给它们使用了，甚至它们能够访问比计算机的物理内存还要大的多的内存空间。
容器是另一种虚拟化，也是对操作系统的虚拟化。今天Linux上的容器，为应用程序创建了完全隔离且独立的操作系统。对于运行中的容器，本地磁盘就像操作系统文件的原始副本，内存只保持着一个刚启动的操作系统的文件和数据，惟一运行中的只有操作系统。要做到这些，创建容器的宿主机做了一些机智的事情。
第一项技术是namespace isolation。Namespace包含一个应用程序能够交互的所有资源，包括文件、网络端口号和进程表。Namespace isolation使主机能够给每个容器一个虚拟的namespace，容器在这个虚拟的namespace内，只能看到它应该看到的资源。因此，容器不能访问没有包含在它的虚拟namespace内授权的文件。不属于容器的应用，既不能查看也不能与容器内的应用交互。这个“被欺骗”的应用程序相信它是在整个系统上运行的惟一一个应用，而系统上同时运行着数十或数百个这样的应用。
为了提升效率，许多操作系统文件、目录和运行的服务在容器间共享，并映射到每个容器的namespace。仅当应用在它的容器内改变这些资源时，比如修改一个已存在的文件或创建新文件，容器会从宿主操作系统得到一份副本——利用Docker的“copy-on-write”优化，仅仅复制发生变化的部分。这一共享特性，是在一台主机上高效部署多个容器的技术之一。
另外，主机控制着容器可以使用多少资源，管控着cpu、内存和网络带宽等资源，确保容器得到它期望的资源，同时不会影响主机上其它容器的性能。比如可以限制一个容器不能使用超过10%的CPU。这意味着即使它内部的应用做此尝试，它也不能访问其余的90%，而这一部分主机可以分配给其它容器或留给自己使用。Linux通过“cgroups”实现了这样的管理技术。资源管理在下列情况不是必须的：容器以合作方式运行在同一主机上，允许操作系统动态分配资源，以适应应用代码变化的需求。
结合操作系统虚拟化带来的即时启动，namespace isolation带来的可靠执行，以及资源管理，使容器成为应用开发和测试的理想环境。在开发阶段，开发者可以快速迭代。因为它的环境和资源在系统间保持一致，一个运行在开发者系统上的容器化应用将以相同的方式运行在另一个生产系统上。即时启动和低空间消耗也为云环境带来便利，因为应用可以快速横向扩展，更多应用实例可以安装到一台机器上，与虚拟机相比，能够最大限度利用系统资源。
对比虚拟机，由于共享带来的效率提升，在容器的应用场景中体现得更明显。在下述例子中，宿主机上安装了三个虚拟机。为了在虚拟机中为应用提供完全隔离环境，每个应用拥有完全的操作系统文件副本、库、应用代码，内存中有一个完整的操作系统实例。启动一个新的虚拟机需要启动一个新的操作系统实例，即使宿主机或现有的虚拟机已经运行着相同的版本，并且还要向内存加载应用程序库。每个应用都有启动操作系统的花费，并且在内存中有完整操作系统的空间消耗，这些问题也限制了在宿主机上运行的虚拟机数量。
下图展示了在相同场景中使用容器的情况。容器共享了宿主机操作系统，包括内核和库，因此它们不需要启动一个操作系统，加载库文件，也就没有它们带来的内存开销。它们占用的空间仅仅为容器中的应用需要占用的内存与磁盘。然而应用环境就像是一个专用操作系统，应用部署在上面，就像部署在一个专用的主机上一样。容器化的应用启动仅需数秒，而且相对于虚拟机部署，宿主机能够容纳更多的应用实例。
◤Docker的魅力◢
操作系统的namespace isolation与资源管理技术由来已久，可以追溯到BSD Jails，Solaris Zones，甚至是UNIX的chroot（change root）机制。然而，通过创建一个通用工具集，打包模型和部署机制，Docker大大简化了应用的容器化与分发，使它们可以运行在任意Linux主机上。这种普适技术不只通过通用管理命令简化了任意主机的管理工作，还为无缝的DevOps创造了条件。
从开发者桌面到测试机再到生产集群，一个要部署在多个环境的Docker镜像能够在数秒内创建出来。目前已经形成了一个巨大且不断成长的将应用Docker容器化的生态系统，DockerHub是一个Docker维护的公有容器化应用中心，已经发布了超过180,000个应用。另外，为了保持包格式统一，Docker最近发起了OCI组织（Open Container Initiative），旨在确保容器包格式保持开放，并且由基金会来主导这个格式。微软也是这个组织的发起成员之一。
◤Windows Server与容器◢
为了让容器能惠及所有的开发者，去年十月我们宣布在Windows Server上实现容器技术。未来让开发在Windows Server上拥有与Linux Docker容器相同的体验，我们还宣布将与Docker一起扩展Docker API和工具集，以便支持Windows Server Container。所有客户都会从中获益，Linux和Windows都一样。正如最近我在 DockerCon展示的，我们希望开发者和系统管理员创造一个统一和开发的体验，在Windows Server和Linux环境中都能部署他们的容器化应用。这项工作在Docker GitHub 上可以看到具体进展。
我们将在Windows Server 2016，发布两种容器，都可以使用Docker API和Docker客户端部署，它们是：Windows Server Container和Hyper-V Container。Linux容器需要Linux主机内核提供的API，而Windows ServerContainer需要Windows主机内核提供的API，因此你不能在Windows Server主机上运行Linux容器或者在Linux主机上运行Windows Server Container。然而，相同的Docker客户端可以管理所有这些容器。虽然不能在Linux上运行Windows容器，一个Windows容器包可以运行在Windows Server Container或Hyper-VContainer上，因为它们都使用Windows内核。
那么在Windows Server Container和Hyper-V Container之间应该作何选择呢？共享内核使快速启动和高效封装成为现实，Windows Server Container之间共享宿主操作系统。大量的共享数据和API意味着，在namespaceisolation和资源管理方面，不论设计还是实现的缺陷，应用可能逃逸出它自己的容器，或拒绝向宿主机和其它容器提供服务。本地提权漏洞就是一个应用程序可以加以利用的地方。
因此，Windows Server Container非常适合的场景就是，操作系统信任那些驻留其上的应用，并且应用间互相信任。换句话说，宿主操作系统与应用有着相同的信任边界。对于许多多容器应用来说，应用构成了一个大型应用的共享服务，而且这些大型应用又来自同一个组织。
然而，在某些情况下你可能想在同一主机上，运行不同受信边界的应用。比如你正在实现一个多租户的PaaS或SaaS，并允许客户扩展你的服务。你不希望客户的代码与你的服务互相影响，也不希望它们访问其他客户的数据，但是你需要比虚拟机更灵活的容器以及Docker生态系统带来的便利。在Azure上，有许多这类服务，比如Azure Automation和Machine Learning服务。我们把它们的运行环境叫做”敌对的多租户“（hostile multi-tenancy），我们不得不假设客户有意破坏隔离性。在这类环境中，Windows Server Container的隔离性可能无法提供足够的保证，促使我们开发了Hyper-V容器。
Hyper-V Container的实现方式也略有不同。为了构建更高的隔离性，每个Hyper-V Container既有他们自己的Windows内核副本，也有直接分配给他们的内存，这是强隔离性的关键需求。我们使用Hyper-V实现CPU、内存和IO的隔离性（比如网络和存储），而且达到了与虚拟机相同的隔离级别。就像虚拟机一样，主机只给容器暴露一个小的、受限的接口，用于通讯和共享主机资源。这种受限的共享意味着Hyper-V Container启动时有一点效率损失，而且比Windows Server Container略重，但是它的隔离级别允许不受信的应用，和”敌对的多租户“应用运行在一个主机上。
那Hyper-V Container不就是虚拟机吗？Hyper-V Container除了针对操作系统的优化，使它能完全意识到自己在一个容器内，而不是在一个物理机上，还会利用Docker的神奇部署能力。并且在Windows Server Container上的包也可以在Hyper-V上运行。因此，在隔离级别与效率/灵活性之间权衡，只是一个部署时间的决策，而不是开发时间的决策——由主机的所有者决定。
◤容器编排◢
当客户采用了容器，他们就会遭遇一个挑战。当他们部署几十几百甚至几千个容器的时候，跟踪、管理这些容器，就需要更高水平的管理和编排技术。容器编排已成为一个令人兴奋的创新领域，这个领域已经有多种选择和解决方案。容器编排器被分配给服务器池（虚拟机或裸机），通常称做“集群”，并在这些服务器上调度部署。有些变牌器负责在不同服务器的容器之间配置网络，有些负责负载均衡、容器命名、滚动更新等等。有些功能是可扩展的，使应用框架也具备这些附加能力。
要把容器编排的解决方案讲清楚可能还需要一整篇文章，下面是一些相关技术的快速概述。它们都在Azure上得到了支持：
Docker Compose 能够定义简单的多容器应用。Docker Swarm 通过相同的API，管理并组织跨主机的Docker容器。 Swarm 和Compose是由Docker提供的容器编排解决方案；
Mesos 是一个早于Docker的容器编排与管理方案，不过它已于最近在Marathon内加入了对Docker的支持。它是个开放、通讯驱动的方案，由Mesosphere 构建。我们最近也宣布了对Mesos的集成以及Azure上的DCOS；
Kubernetes 是一个Google构建的开源解决方案，容器的跨多主机管理，通过“Pod”分组形式实现。Azure也已经支持；
Deis 是个开源的PaaS平台，可以用来部署、管理集成了Docker的应用。我们提供了一个简单方法在Azure上部署Deis集群。
Auzre已经支持当今最流行的容器编排方案，对此我们十分兴奋，并期望能在社区中参与更多工作。因为随着时间的推移，我们看到了用户的兴趣与使用量也在变高。
◤微服务◢
容器化最直接的好处在于简化DevOps，简化了开发者从内部测试、部署服务到生产环境的工作。不过容器还有另一个引人注目的应用场景。微服务作为一种应用开发方式，应用的每一部分，都可以作为一个完整的组件部署，并且可单独的扩展与升级。比如说，一个应用的子系统从互联网接收请求，另一个单独的子系统把请求推入一个队列，再由一个后台子系统从读取队列将数据存入数据库。
当应用采用了微服务架构，每个子系统就是一个微服务。在开发/测试环境，每个微服务可能是一个实例，但是在生产环境，每个微服务可以在集群内按照各自的资源需求，独立的横向扩展为不同数量的实例，根据用户请求实现服务升降级。如果每个微服务由不同团队创建，它们也可以由各团队进行独立升级。
微服务不是开发的新方法，也并非是与容器绑定的，但是实现一个复杂的微服务架构应用时，Docker容器放大了它的便利性。Docker的灵活性意味着，微服务可以随负载增长而快速的横向扩展，namespace与资源隔离阻止了微服务实例之间互相干扰。Docker包格式和API为微服务开发者和运维，提供了强大的Docker生态系统。基于一个好的微服务架构，用户可以解决管理、部署、业务流程和打补丁问题，同时维持高灵活性，降低可用性风险。
现在有许多构建微服务架构的解决方案，并且在Azure上我们与它们都有合作关系。Docker Compose 与 Mesosphere Marathon就是两个这样的例子。在built大会之前，我们发布了自己的微服务应用平台，Service Fabric的开发者预览版。
网友评论