最近，谈论到云端运算时绝对少不了 container 这个话题。从银行、主要金融服务机构到电子商务网站等等的所有相关产业，大家都想要了解什么是 container、对云端应用程序有何意义、如何才能在其特定开发与 IT 相关作业中发挥最大作用。

 

这篇文章介绍了，从 container 基本概念和运作方式，以及现在最广泛使用的方式，再到支持「containerization」的新兴趋势，期望能协助大家了解如何以最佳方式掌握这个重要云端发展，并进一步完美的建构、测试、部署及管理您的云端应用程序。

 

Container 概述

 

以抽象概念来说，运算的本身是指一些「功能」在处理器、内存、磁盘、网络等组合的「实体资源」上执行的这一个动作，不论是简单的1+1数学计算，或是如「Exchange」般横跨多部机器的复杂应用程序，都在运算的范围内。

 

随着科技的进步，实体资源越趋强大，然而应用程序通常仅仅是运用到实体机器所提供的一小部分资源。因此创造出「虚拟」资源用来仿真本体的实体硬件，并且使多个应用程序能够同时执行 – 分别使用同一部实体机器的小部分实体资源。

 

我们通常将这些模拟技术称为「虚拟化」。许多人一听到虚拟化就会立刻想到虚拟机 (VM)，不过那只是虚拟化之中的一种实现方式。虚拟内存，是一种所有一般用途操作系统 (OS) 采用的机制，可以让应用程序「以为」是其专属的计算机内存，甚至让应用程序能够存取的内存远高于计算机本身所配备的内存。

 

Container 是另一种类型的虚拟化，也可称为操作系统虚拟化。现在，Linux 上的 container 已经能够完全隔离，并且使操作系统与应用程序各自独立。对执行中的 container 而言，本机磁盘就如同是操作系统档案的原始副本，内存的作用仅在保留新进启动的操作系统，而唯一在执行的就是操作系统。为达此目的，用于建立 container 的「主机」机器需要具备新颖的执行机制。

 

第一项技术是命名空间隔离。命名空间包含应用程序可与之互动的所有资源，例如：档案、网络端口以及执行程序列表。命名空间隔离可供主机给予各 container 一个虚拟化命名空间，其中仅包含该 container 内可见的资源。

 

在此有限的能见度之下，无论 container 本身的权限为何，也无法存取不属于其虚拟化命名空间的档案，因为根本看不见，当然也无法列出或处理不属于此 container 的应用程序，如此一来，即使系统内有数十个或数百个其他应用程序正在执行，container 会使应用程序「认为」自己是系统中唯一执行的应用程序。

 

为了追求效率，许多的操作系统档案、目录及执行中服务会共享于各 container 之间，并投射到各 container 的命名空间。只有在应用程序对其 container 进行变更时，例如修改现有档案或建立新档案时，container 才会衍生出和本体主机操作系统不同的副本 – 但仅限于变更的部分，使用 Docker 的「写入时复制」优化功能。

 

第二，主机将控制可供 container 使用的主机资源量。亦即管理如 CPU、RAM、网络带宽等资源，以确保container可获得所需的资源且不致影响主机上其他正在执行的 container 的效能。

 

例如，可限制某一 container 不得使用超过 CPU 10% 的资源。也就是说，应用程序无论如何也不会越界使用到另外 90% 的资源，因为这些资源是由主机指派给其他 container 使用或是供主机本身使用。Linux 是采用名为「cgroups」的技术管理资源。若位于同一主机内的 container 相互合作，且容许标准操作系统动态资源指派可适应应用程序代码的变更需求，则不需要管理资源。

 

来自操作系统的迅速启动加上来自命名空间隔离与资源管理的可靠执行，使 container 成为应用程序开发及测试最佳的环境。开发流程期间，开发人员能够快速的反复执行。由于环境与资源运用在各系统内均一致，能在开发人员系统内执行的 container 应用程序，也能在不同系统中运作。

 

快速启动及占用资源小的优点极适合于云端应用，因为应用程序能够迅速的向外延展，而且能够融入一部机器内的应用程序数量会远高于各在一部虚拟机内的数量，使资源的运用达到最大化。

 

一般虚拟机与使用 container 的虚拟机两相比较，就可发现共享所能提供的高效率优点。在下图范例中，主机机器内拥有三部虚拟机。为使虚拟机内应用程序完全隔离，每一部虚拟机必须拥有自己的操作系统档案、链接库及应用程序代码的副本，还要包含操作系统的完整内存内储例项。建立新的虚拟机时需要启动另一个操作系统例项 – 即使主机或现有虚拟主机已执行相同版本的例项，同时还需将应用链接库加载内存内。每一部应用程序虚拟机都需要为自用的副本负担操作系统启动及内存内储的资源，因而限制了主机上能够执行的应用程序 (虚拟机) 数量。

http://s7/mw690/001O1jsngy6VrL3AWOOa6&690以及趋势" TITLE="Container：Docker、Windows 以及趋势" />

下图是使用 container 的范例。在这边，container 可以简单的共享主机操作系统，包括核心及链接库，因此不需要再另外启动一套操作系统、加载链接库或为这些档案负担内存的资源，占用的空间也仅限于 container 内执行的应用程序所需要的内存与磁盘空间。由于应用程序的环境如同专用的操作系统，使得应用程序的部署也如同于专用的主机上部署一般。Containerization 的应用程序能迅速启动，一部机器上能容纳的应用程序例项也远高于一般虚拟机。

http://s7/mw690/001O1jsngy6VrKZyV5I86&690以及趋势" TITLE="Container：Docker、Windows 以及趋势" />

 

Docker 的要求

 

关于操作系统的命名空间隔离及资源管理已是老生常谈，可以追溯至 BSD Jails、Solaris Zones 甚至是最基本的 UNIX chroot 机制。然而，透过建立共同工具组、封装模型及部署机制，Docker 大幅简化了 containerization 及应用程序的分配，使应用程序能在任何 Linux 主机的任何地方执行。这项随处分布的技术不仅透过任何主机均相同的管理指令简化了管理作业，更为完美的 DevOps 创造了独特的机会。

 

从开发人员的桌面到一部测试机器再到一组生产机器，建立的 Docker 映像亦可迅速完整部署至任何作业环境。此一作法已经为 Dockercontainer 内所封装应用程序建立起庞大、持续成长的生态系统，透过 DockerHub，由 Docker 维持的公共 containerization 应用程序登录，目前在公共社群数据库中已发布 180,000 项以上的应用程序。此外，为维持保障封装格式的通用性，Docker 最近组织了「开放式 container 联盟」(OCI)，目的在于确保 container 封装维持其开放性与基层导引型格式，Microsoft 就是其中之一的创立成员。

 

Windows Server 及 Containers

 

为将强大的 container 提供给所有开发人员，去年 10 月微软发布了将 container 技术纳入 Windows Server 的计划。同时，为了使用 Linux Dockercontainer 的开发人员能够在 Windows Server 上拥有相同体验，我们也宣布与 Docker 成为合作伙伴以延伸 Docker API 及工具组来支持 Windows Server Containers。对我们而言，这是一个服务所有 Linux 及 Windows 客户的绝佳机会。最近于 DockerCon 展示时，我们非常高兴能建立开发人员与系统管理人员的一致性、开放性体验，共同部署由 Windows Server 及 Linux 所组成的 container 化应用程序。我们正在开放性 Docker GitHub 数据库中发展这项作业。

 

在 Windows Server 2016 中，我们将释出两款均可使用 Docker API 及 Docker 客户端部署的 container：Windows Server Containers 及 Hyper-V Containers。由于 Linuxcontainer 需要来自主机核心的 Linux API，Windows Server Containers 需要主机 Windows 核心的 Windows API，因此无法于 Windows Server 主机上执行 Linuxcontainer，也无法于 Linux 主机上执行 Windows Server Container。

 

但是，相同的 Docker 客户端可以管理所有的这些 container，虽不能在 Linux 上执行套装的 Windowscontainer，Windowscontainer 套件却可于 Windows Server Containers 及 Hyper-V Containers 上运作，因为两款 container 都是使用 Windows 核心。

 

也有人提到 Windows Server Container 和 Hyper-V Container 使用时机的这个问题。由于核心的共享可提供快速启动及高效率封装，Windows Server Containers 可以和主机与其他 container 共享操作系统。共享资料及 API 代表着可能有数种途径，可以是利用设计或因为命名空间隔离或资源管理中出现的瑕疵，使应用程序跳出其 container 或拒绝服务至主机或其他 container。而操作系统供货商所发布用于加强本机权限弱点的修补程序，就是一个应用程序可以利用的瑕疵。

 

因此，当操作系统信任在其中执行的应用程序且所有应用程序彼此信任时，Windows Server Containers 是最佳选择。换句话说，主机操作系统及应用程序均在相同的信任范畴之中。对于许多多重 container 应用程序、组成大型应用程序共享服务的应用程序、部分来自相同组织的应用程序而言，确是如此。

 

然而在某些状况下，可能需要在同一部主机上执行来自不同信任范畴的应用程序。举例来说，如果您正在实施多组织用户共享的 PaaS 或 SaaS，以利客户们供应其本身的程序代码来扩充您的服务的功能性。您不会希望一位客户的程序代码干扰到您的服务或取得其他客户数据的存取权，但是您会需要一个比虚拟机更弹性且能拥有 Docker 生态系统优点的 container。

 

在 Azure 中我们有多个这样的例子，像是 Azure Automation 及 Machine Learning。我们称此执行环境为「恶意多重租用」，因为我们必须假设有客户是刻意的寻找着破坏隔离的方法。在这些类型的环境中，Windows Server Containers 可能无法提供足够的保障，因而促使了我们开发 Hyper-V Containers。

 

Hyper-V Containers 采用了作法稍有不同的 containerization。为建立更完善的隔离，每一个 Hyper-V Containers 均拥有自己的 Windows 核心副本，也拥有直接分配的内存 – 强力隔离的关键需求。我们在 CPU、内存、IO 隔离上使用 Hyper-V (如同网络及储存设备)，提供和虚拟机相同程度的隔离。如同用于虚拟机，主机仅释出小量、受限制的接口给 container，用于通讯及共享主资资源。高限制的共享表示 Hyper-V Containers 的启动时间效率及分布密度会稍低于 Windows Server Containers，但能提供允许非信任及「恶意多重租用」应用程序于同一部主机上执行时所需的隔离。

 

那么 Hyper-V Containers 不是和虚拟机一样吗？除了已知的操作系统优化之外，请注意 Hyper-V Containers 是 container 而不是实体机器，不仅可以透过 Docker 的强大功能部署，而且使用的套件和 Windows Server Containers 所使用的套件完全相同。因此，隔离程度与效率 / 弹性的取舍是部署时间决策而非开发时间决策 – 由主机拥有人所决定。

 

协调流程

 

在采纳 container 之后，客户们发现了一项难题。当他们部署数十、数百或数千应用程序的 container 时，追踪及管理部署需要先进的管理与协调流程。

 

Container 协调流程已成为多重选项及解决方案创新的新兴领域。Container 协调流程程序接受指派一群服务器 (虚拟机或裸机服务器)，通常称为「丛集」，并将 container 的「排程」部署在这些服务器上。

 

部分协调流程程序更进一步的用于设定不同服务器上 container 之间的网络作业，其他也用于负载平衡、container 名称解析、轮替更新等等。部分协调流程程序可扩充并启用应用程序架构带入这些额外的功能。

 

协调流程解决方案可能会需要更深入的讨论，在此仅快速浏览其中部分用于支持 Azure 的技术：

 

1. Docker Compose 用于定义简单的多 container 应用程序。Docker Swarm 则透过单一 Docker 主机所使用的同一 API 管理及组织横跨多部主机的 Dockercontainer。Swarm 及 Compose 的组合可提供由 Docker 所建构的完整协调流程技术。
2. Mesos 是一套可实际预先更新 Docker 的协调流程及管理解决方案，最近更新增支持 Docker 功能至其内建的应用程序架构 Marathon。这是一套由 Mesosphere 所建构的开放式、社群推动型解决方案。我们最近展示了 Mesos and DCOS on Azure 的整合作业。
3. Kubernetes 是一套由 Google 建构的开放原始码解决方案，提供 container 群组为用于管理多部主机的「Pods」。Azure 上也支持此技术。
4. Deis 是一个开放原始码 PaaS 平台，用于部署及管理 Docker 所整合的应用程序。我们已经有了在 Azure 上轻松部署 Deis 丛集的方式。

对于大多数受欢迎的协调流程解决方案能够支持 Azure，我们感到非常高兴，也期望在大家越加关注及使用率提升之际能多多结合这些社群。

 

Microservices

 

Container 更切身的用法已聚焦于简化 DevOps，使开发人员能更轻松的测试云端或内部部署的各项服务生产流程。但是另一股不断成长的趋势使得 container 越发引人注目。

 

Microservices 是一种应用程序开发的途径，其中应用程序每一部分均以完全自足组件的方式部署，称为能够个别扩充及更新的 Microservices。例如，由公共网络接收要求的应用程序子系统，可能不同于将要求置入队列以供后端子系统读取并放入数据库的子系统。当应用程序使用 Microservices 建构时，各子系统即是一项 Microservices。

 

在单一区块开发 / 测试环境中，Microservices 可能各自拥有一例项，但在生产执行时则能各自向外延展至一服务器群集内不同数量的例项，视客户要求程度起伏的资源需求而定。若是由不同的序列产生，则该序列也独立负责给予更新。

 

Microservices 既不是新的程序规划方法，也不是 container 专属，但在应用至 Microservices 应用程序时却能突显出 Dockercontainer 的优点。

 

弹性，代表 Microservices 能迅速向外延展以因应提高的负载，container 的命名空间及资源隔离则可防止一个 Microservices 例项干扰其他例项，并使用 Docker 封装格式及API为 Microservices 开发人员及应用程序操作人员解锁 Docker 生态系统。

 

在拥有良好 Microservices 架构之下，客户能解决 container 型服务的管理、部署、协调流程与修补作业需求，同时也降低可用性流失的风险并维持高度的弹性。

 

现在有许多使用 Microservices 建构应用程序模型的解决方案，我们也在 Azure 上建立不少合作对象。Docker Compose 和 Mesosphere Marathon 就是两个最好的例子。在开始建构的不久前，我们宣布并释出 Service Fabric 的开发人员预览，Service Fabric 是我们自有的 Microservices 应用程序平台。其中包含丰富的 Microservices 生命周期管理功能，更包括有复原功能的轮替更新、分割、附加限制等等。

 

值得注意的是，除了无状态的 Microservices 之外，也支持可设定状态的 Microservices，区分的方式是利用 Microservices 管理同是共处于同一服务器上的数据。事实上，Service Fabric 是唯一提供可设定状态 Microservices 的 PaaS 平台，采用的状态管理及复制架构已直接内建于其丛集管理之中。

 

我们开发此应用程序模型是为了使内部服务能够扩充至超大规模，并提供可设定状态复制及 Cortana、Azure SQL Database、Skype for Business 等服务建构于其上。我们计划于今年内释出 Service Fabric 的公开预览，在那之前，欢迎登入 Service Fabric 专属网站了解详情。

 

希望这篇文章能协助大家描绘出 Microsoft 的 container 愿景、最常见的 container 应用案例以及与 container 相关的新兴产业趋势。如同以往，我们非常欢迎您提供意见，尤其是提出您想了解更多的部分。

 

原文出处：

http://azure.microsoft.com/blog/2015/08/17/containers-docker-windows-and-trends/