2015 年容器大火，围绕着容器技术的发展也涌现了许多新项目。同时，许多“老”项目也开始支持容器作为运行环境。下面介绍这些项目：

规范标准类

容器使用了 Linux 内核的特性， Docker 的成功也主要在于其充分挖掘了此类特性。但 Docker 流行之后，社区开始思考怎么定义一套完整的容器规范标准，使容器的规范不再局限于 Docker 。同时， Docker 仅仅定义了一个容器，多容器的互联也需要规范标准。下面提到的项目是目前主流的标准，有的并非为容器而生，但也在为容器规范化做出努力。

OCF

OCF(Open Container Format)是由 OCI(Open Container Initiative)发布的一套容器规范和运行时环境，其初步版本基于 Docker 镜像和运行时，但是最终目的是定义一套不受任何软硬件平台、不受任何公司和项目束缚的容器标准。 OCI 由各大厂商组成，包括谷歌、红帽、华为等。 OCF 对标准容器规范指定了 5 条规则：

1 标准化操作：例如，创建容器、删除容器、打包容器等操作都必须标准化；

2 内容无关性：不管容器内部内容是什么，上述操作不能有任何行为上的变化；

3 平台无关性：在任何 OCI 支持的平台上，上述操作都必须能够无差别执行；

4 为自动化而设计：标准容器是为自动化而生，其规范必须满足自动化条件；

5 企业级交付：标准容器需要适用于企业级流水线交付任务。

下面简要介绍 OCF 标准。目前， OCI 定义一个容器包含如下内容：

config.json

runtime.json

rootfs/

config.json表示与容器相关的配置，例如启动容器之后执行的命令，容器的环境变量等

runtime.json表示与 host 相关的配置，例如对 cgroup 、 namespace 的支持

rootfs表示容器可见的根目录，即容器中的“/”目录。 OCF 对其内容不作约束，常见的子目录有 lib, bin 等等。

任何基于 OCF 规范实现的命令行工具，都可以解析上述内容并管理容器，例如 runC( https://github.com/opencontainers/runc), TODO 。

目前为止， OCI 主要精力集中在容器运行环境，之后， OCI 还将对容器打包、验证、分发等模块进行标准化。总而言之， OCI 是继 Docker 大火之后，社区对容器标准的一种尝试，现在已经得到非常多大公司的认可。

appC

appC 是 CoreOS 提出的容器运行标准，早于 OCF 标准。 CoreOS 目前是 OCI 成员之一，在大力推进 OCI 的发展， appC 和 OCI 最终可能会合并为一个标准。不同于 OCI ， appC 更加成熟，其内容除了容器运行时环境，还包括：

打包规范： appC 定义了如何将一个应用打包（ tar 文件），如何保持环境变量、挂载点等内容。相比之下， OCF 仅定义了目录结构。

镜像验证： appC 定义了如何验证镜像内容未被修改过，如何保证镜像安全传输；

镜像传输： appC 定义了镜像传输的机制，包括 https, bittorrent 等，这一点与 Docker 的 centralized hub 有明显的区别。

目前基于 appC 规范已经有不少实现，如 Jetpack, Kurma, rkt 等。其中 rkt 是 CoreOS 对 appC 的标准实现。

Nulecule

Docker 对应用的打包方式仅仅局限于单个容器层面，我们可以使用 Dockerfile 描述一个容器配置，然后打包、分发镜像，之后该容器便可以在任何 Linux 机器上运行。但是， Docker 缺少一个多容器运行的标准：既如何描述一个由多容器组成的应用。目前一些基于 Docker 的集群管理系统已经能够支持多容器的部署，比如 Docker Swarm ， Kubernetes ，但是这些系统并没有定义一个标准的、通用的、可移植的格式。此外，此类系统的特点是将多容器应用的部署当做系统的状态，即他们更多的是强调应用的调度、互联、监控，而非应用的部署。缺少复合应用的支持，使 Docker 的许多特点黯然失色，因为实际生产环境中的应用必然是由多应用构成的。例如：我们现在可以很方便地部署一个 redis 容器，但是部署 redis cluster 容器很困难，更不用说基于 redis cluster 的应用。

红帽公司在 2015 年提出了 Nulecule ，该项目定义了一个多容器应用部署的规范，包括应用的元数据、依赖、参数配置等等。应用发布者只需要依照 Nulecule 的规范提供应用的构成方式，然后将此构成方式打包成 Docker 镜像发布。 Nulecule 的打包方式可以参考： https://github.com/projectatomic/nulecule/tree/master/spec/examples/template 。 具体来讲， Nucecule 包括以下文件：

｜－ Dockerfile

｜－ artifacts

│ └── kubernetes

│ ｜－ pod.json

│ └── service.son

｜－ Nulecule

└── README.md

Dockerfile 将该目录所有文件打包成 Docker 镜像； Nulecule 文件是具体的应用描述，例如每个组件的容器镜像，还包括上面提到的依赖、参数配置等； artifacts 目录包括底层集群管理系统所使用的配置文件。

Nulecule 本身只是一个规范文档，红帽公司基于 Nulecule 实现了 Project Atomic ，包括命令行工具 atomic 。运行一个应用和运行一个容器的方式几乎相同，例如：使用下述命令即可启动一个应用：“ atomic run company/myapp:v0.1 ”。其中镜像 company/myapp:v0.1 为前文提到的打包后的 Docker 镜像。

TOSCA

TOSCA （ Topology and Orchestration Specification for Cloud Applications ），是 OASIS 维护的一套用于描述应用和基础设施的标准，包括服务组件类型、组件关系、操作方式（例如，部署，补丁，关机）等等。这些描述独立于创建服务的供应商、任何特定的云服务提供商或托管服务的技术。采用 TOSCA 标准的项目主要有 OpenStack Heat ， Cloudily 等。

TOSCA 并非为容器而生，有人将 TOSCA 和 Nulecule 做对比，认为 Nulecule 可以粗略地理解成容器版的 TOSCA 。尽管有相似之处，但 TOSCA 包含了大量规范细则，涉及面非常广。

Cloud Native

经过长期发展，云计算领域逐渐认识到应用架构模式已经成为云计算发展的瓶颈，因此，国外几乎所有互联网公司联合成立了 Cloud Native Computing Foundation ，来促进云计算的发展，旨在提高企业对上述模式的采纳程度。简单来讲， cloud native 指的是：

容器为载体：使用容器作为应用运行、交付的载体，可以提高开发效率、增大代码重用率、简化部署等；

动态管理：建立一套中心管理系统（私有云或公有云）来动态调度容器、机器资源，提高运维效率，机器使用率；

微服务架构：利用服务依赖解耦合来提高敏捷性，降低代码维护开销。

项目类

本节综述了目前开源社区和互联网公司围绕容器技术开发的相关项目。这里只列举出了较为完善和流行的项目。

Docker Machine

Docker Machine 是 Docker 公司为解决 Docker 安装、环境配置等问题而开发项目，现在已经支持 10 余种云平台和虚拟机软件，包括 AWS 、 OpenStack 、 VirtualBox 等。创建一个支持 Docker 的机器只需要使用命令：“ docker-machine create – d virtualbox default ” 。 Docker Machine 屏蔽了底层资源的复杂性，使得开发人员可以自动化创建、删除机器资源，尽可能地避免在平台差异性上消耗精力。

Swarm

Swarm 是 Docker 公司为解决容器集群化而开发的项目。 Swarm 将多台主机抽象成一台主机，用户可以像使用一台主机般使用 Docker 。例如，当使用命令“ docker run app ”时， Swarm 会根据集群状态将容器调度到一台远程的服务器运行，用户同样可以使用“ docker ps ”来查看当前容器状态。对于用户而言， Swarm 的调度是透明的。 Swarm 极大程度地兼容了 Docker 的 API ，同时有效地调度集群资源，向容器集群化迈出了一大步。 Swarm 还在不断开发中，需要解决容器互联、数据共享等迫切问题。

Compose

Compose 是 Docker 公司解决容器编排的项目，其前身是 Fig 项目。 Compose 解决的问题类似 Nulecule 规范，既如何部署多容器应用。不管是 Docker 本身也好， Machine 、 Swarm 等项目也好，都集中在了单容器应用， Compose 很大程度上是对前面项目的补充。用户向 Compose 提交一个 yaml 文件，包含所有容器的配置，例如各自的端口、容器互联信息等； Compose 根据该文件内容，启动容器。 Compose 的具体格式，可以参考： https://docs.docker.com/compose/yml

Mesos

Mesos 是一套资源管理与调度平台，目前可以支持上千台机器的管理任务。 Mesos 对资源的管理方式是独有的两层调度： Mesos 核心调度器负责管理所有机器资源，并为上层 Framework 提供计算资源。 Framework 是第二层调度器，它根据核心调度器提供的资源判断是否满足需求，如果满足需求，则运行 Framework 所管理的任务；否则重新像核心调度器申请资源。常见的 Framework 有 Marathon, Chronos ，分别负责长时间运行的服务和 Cron 任务，其他 Framework 还包括常用的大数据平台，例如 Spark 、 Hadoop 等。

Kubernetes

Kubernetes 来自于 Google 内部的大规模集群管理工具 Borg ，根据官方说法“ Kubernetes 代表了 Google 过去十余年设计、构建和管理大规模容器集群的经验”。简单地说， Kubernetes 是一个管理跨主机的容器化应用的系统，支持多容器部署、高可用性、应用弹性伸缩、跨主机网络、负载均衡、服务发现等应用级功能，同时支持集群自恢复机制、资源调度、资源隔离、监控等集群级功能。 Kubernetes 是目前唯一遵循“一切皆容器”的项目，既所有功能都是基于“应用容器化”实现，并稳定而快速地发展着。

Hyper

Hyper 是 HyperHQ 公司发布了的一个开源项目，初衷是结合 Docker 容器和虚拟机的优点，可以在 hypervisor 上运行 Docker 镜像的引擎。根据 Hyper 官方的说法，他们与 Docker 的核心区别在于 Hyper 没有使用 Container 技术，而是通过 VM 直接运行 Docker 镜像，是一个完全基于虚拟化的解决方案。

Containerd

Containerd 是 docker 公司开源项目，旨在为 runC 提供守护进程。 Containerd 沿袭了 docker C/S 的结构， server 守护进程的核心是一个 eventloop ，负责监听容器的创建，销毁，快照等事件； client 名为 ctr ，通过 gRPC 与 server 通信。 Containerd 还处在非常早期的阶段，功能还并不完善。 docker 公司发布该项目的主要是表明其对容器生态环境的支持，也同时汲取 runC 高级特性对 docker 进行互补。

Clear Container

Clear Container 是由 intel 推出的 Clear Linux （ Clear Linux 是 Intel 提供的面向云场景的 linux 发行版）中的一项技术， 通过将虚拟机和容器结合起来，旨在提供安全容器。官方宣称目标是让用户可以充分使用虚拟机的隔离，同时拥有容器的部署能力。

最小 OS

RancherOS

RancherOS 是 Rancher Labs 的一个开源项目，其宗旨是开发一个支持 docker 的最小化操作系统。在 RancherOS 中，所有应用都采用容器，包括系统程序 udev, rsyslog 等；同时， RancherOS 用 docker daemon 取代了传统的初始化系统如 sysvinit 、 systemd 。承载初始化任务的 docker daemon 称为系统 Docker ，该系统 docker 会创建一个特殊的系统服务容器，即用户 Docker ，来负责管理用户的 docker 容器，避免了用户对系统 docker 容器的直接操作。具体系统结构可以参加 github 项目主页： https://github.com/rancher/os

CoreOS

CoreOS 本身是 Linux 的一个发行版，但与其他发行版（如 Centos 、 Ubuntu ）有着很大的区别： CoreOS 是为容器集群而生。不同于许多基于 Linux 做容器管理、编排系统的项目， CoreOS 将这些功能并入了操作系统中。这样，每个装有 CoreOS 的主机就可以随时随地加入一个 CoreOS 集群而不需要额外配置。对开发人员而言，无论集群中有多少 CoreOS 主机，操作方法都是相同的。 CoreOS 主要开发了两个项目来达到这一目的： etcd 和 Fleet 。 etcd 是分布式的键值存储系统，主要负责 CoreOS 集群中节点间的服务发现和配置共享； etcd 提供多种功能来保证集群的高可用性。 Fleet 是分布式的 systemd 系统。对用户而言，与操作单机 systemd 无差别， fleet 会将用户的 systemd unit 动态分发到集群中。

Project Atomic

Project Atomic 是红帽公司开发的操作系统，专门为运行容器而作了优化。 Project Atomic 采用 docker 运行容器、 kubernetes 管理容器，使用 systemd 做系统服务， rpm-ostree 做系统包管理。其中 rpm-ostree 实现了 Atomic 升级，是红帽主推的功能之一。它的核心原理是升级操作系统是原子操作。 Atomic 会将需要升级的内容保存在专门的目录，分开存储，如此以来， Atomic 可以将操作系统的变更进行版本控制，当出现问题，可以快速回滚到上一个版本。

Ubuntu Core

Ubuntu 是一个专为云平台和智能设备打造的全新 ubuntu 操作系统。 Canonical 公司对 Ubuntu Core 的核心优势做出以下几点评论：安全： Snappy 应用受 Canonical 的 AppArmor 内核安全系统限制，该系统提供了严格的、基于 MAC 的隔离和人性化的安全配置文件。可靠性： Snappy 可以提供可靠的更新，在自动修复安全问题的同时，它还能够更快地更新云上的服务器。更好的开发体验：创建 snappy Ubuntu 应用比传统打包方式简单许多。扩展性： Ubuntu Core 支持许多模块化框架，它们可以由与 Canonical 合作的供应商提供。 ubuntu core 包含四层： Application, Framework, Ubuntu Core 和 Enablement 层。 Application 层将所有应用进行了隔离，因此用户可以下载安装任意的应用； fromework 曾用来扩张 ubuntu core ，例如 docker 即是 ubuntu core 中的一个 framework ，为 ubuntu core 提供运行容器的框架。 Ubuntu Core 层即 Canonical 提供的最小 OS ，用户可以通过 snappy 命令行安装多个 ubuntu core ，来对系统进行原子更新。 Enablement 层是硬件层，由设备提供商或者 Canonical 公司提供。 Canonical 公司有意将 snappy 安装模式引入到新的 ubuntu 桌面系统，使 snappy 包管理和 debian packages (deb)共存。至于是否 snappy 会代替 dpkg ，还有待时间的考量。

Microsoft Nano

Nano 是 Windows Server 带来一个全新的 Nano Server 选项。这是微软配合 Docker 所产生的一个底层的 OS. 据微软称， Nano Server 体积非常苗条、极为精简，极佳优势，剥离了 GUI ，专注于云基础设施、云应用程序以及容器。

VMware Photon

Vmare Photon 是 Vmware 为 vSphere 而优化的 Linux 发行版，专门为运行容器而生，支持多项容器技术如 docker, rkt 和 pivatal garden container 。 Vmware Photon 的设计也遵循了其他最小化 OS ，具有运行快，体积苗条，强化容器安全等优点。 Photon 的主要使用对象是采用了 Vmware 虚拟化技术的客户 - Photon 可以使他们轻松地在已有的基础设施中运行容器，并得到企业级的支持。

原文作者：

才云科技首席技术官 邓德源

曾为美国谷歌（ Google ）集群管理组核心成员（ Cluster Management Team ），主要参与开发集群管理系统：该系统为谷歌所有运维工程师提供统一的集群管理入口，是谷歌自动化运维的重要组成部分，其主要职责：管理运维工程师提交的生产环境变更请求，自动化风险分析，自动化生产环境准备工作，以及各种集群容错处理。此系统保证了系统升级、软硬件错误等均能及时被发现并处理，保证谷歌集群能 24/7 小时不间断工作。在谷歌期间作为核心成员参加了开发基于容器集群的谷歌开源项目（ Kubernetes ），一度成为全球前十的贡献者和贡献最高的华人。该项目将谷歌多年内部使用容器的经验以开源的形式呈现给所有开发者，被称为谷歌用来颠覆现有云计算市场和技术，在谷歌内部受到极高的重视和优先级，在开源和云计算社区也获得了极高地反响。 于 2013 年获美国顶级计算机学府 Carnegie Mellon University (CMU)大学电子与计算机工程学位，专修操作系统、分布式计算等方向。 2011 年毕业于电子科技大学机械与自动化专业。于 2010 年参与亚太机器人大赛，代表电子科大获全国第一名，后代表中国队在埃及获金牌。