Docker vs.Rocket vs.Odin:容器技术终极比拼

容器已经在网络领域掀起了一股潮流，其所带来的轻量化、更为灵活的效果足以作为传统虚拟机系统的替代方案。容器与虚拟机之间的最大差别在于，单一容器可以共享多个常用文件，而虚拟机则存在着离散性与原子性——即使存储与网络资源处于虚拟化及共享状态。具体来讲，虚拟机更像是互不关联的孤岛，而容器之间则更像是群岛关系。

我们预计，终有一天大部分操作系统实例会由虚拟机转向容器环境。事实上，操作系统供应商们已经开始争先恐后地压缩自家产品的体积，从而使其新版本更容易适应容器环境下的具体要求。

那么，容器是否已经准备好在我们的网络体系当中占据核心地位?容器的优势与短板又分别是什么?带着这些问题，我们测试了三款容器方案——Docker、Rocket/rkt以及openVZ/Odin(原名为Parallels)。

Docker在容器技术领域属于当之无愧的龙头，但其中也存在着不少需要克服的潜在问题。Rocket/rkt解决了其中一部分问题，但却尚未准备好全面进入大家的生产环境。

OpenVZ/Odin能够同时提供容器方案外加一套兼容多种主流虚拟机管理平台的“虚拟环境”，但仍然存在着一些局限。

这三套方案都具备相当出色的实用性，但与传统虚拟机管理程序及虚拟机系统相比，其实际水平仍然有所欠缺。不过在精心部署与认真打理之下，三者也确实拥有着可圈可点的潜在发展空间。

在对三款产品进行测试时，我们选择了企业级系统基础设施作为背景，而非DevOps及持续开发环境。不过容器背后蕴藏的巨大能量意味着其很难脱离系统基础设施存在，而其控制层也尚不适合或者说无法充分适应持续开发实践当中的快速部署、规模调整以及设计思路。

此次测试的每一款产品都处于快速转型的过程当中，其中年纪稍长的OpenVZ/Virtuozzo扮演的角色则略有区别——其更像是一款面向服务供应商的控制层产品。

容器所要解决的实际问题

容器技术的演变主要受到编排流程需求的推动，客户需要较虚拟机部署更具轻量化优势的方案，但同时又能够继续享受到集群化、快速安装及移除等机制所带来的便利。此外，这一切还需要配合可靠性与安全性保障，这是每一套新型平台需要面对的关键性考核标准，同时也是云计算概念发展所带来的重要副产品之一。

在openVZ/Virtuozzo方案当中，容器执行流程与快速推出能力更多面向负责将基础设施与设备进行匹配并交付给客户的服务供应商。具体实例包括网站/电子邮件打包托管、网站营销、语言高度本地化的设备型产品以及相关服务。在这种情况下，根据操作系统的多种预设置实例提供操控与计费方案将成为拉拢客户的关键所在。

作为Parallels品牌(openVZ赞助方兼Virtuozzo出品方)调整后的产物，Odin长久以来一直肩负着上述任务。它具备更出色的可预测性、更理想的内置功能搭配，而且灵活性水平也足够作为Docker的托管方案使用。

Docker提供的是一套轻量化操作系统环境，并通过应用操控指令的方式严格保证控制措施的推行。其具体操控内容既可立足于基础性层面，也可以涉及复杂度更高、针对性更强的控制工作。

Rocket/rkt与Docker非常相似，但却某些方面却显得更加原始(而且尚未准备好正式进入生产环境)。不过目前Rocket似乎已经针对这些问题作出了改进，并开始给Docker造成日益严重的竞争威胁。在实际测试中，我们发现rkt能够很好地满足我们的一部分工程技术需要，而Docker在这些方面却显得有些停滞不前。

Odin及其开发成果openVZ将自身标榜成为一套虚拟环境，在这一混合模型当中、经过修改的内核被用于同时承担起传统虚拟机管理程序与容器托管环境这两大任务。举例来说，大家完全可以将Docker或者Rocket运行在openVZ之上。

我们发现，这三款产品使用的实现方式几乎完全相同。事实上，这三个项目之间确实存在着交叉支持的现象，当然此外还有很多其他贡献者参与了进来——就连主要贡献者的名单都相当惊人。三者似乎都通过多种方式为彼此作出赞助，而它们也代表着同样的一股新兴势力——即以轻量化为主要特色的实例管理解决方案，旨在摒弃传统虚拟机管理程序的“沉重”劣势。

因此，容器托管方案到底能否彻底取代曾经称霸一时的虚拟机管理程序呢?就我们目前得出的答案来看，暂时还不行——它们的着眼点与既定目标完全不同。不过同时需要指出的是，以CoreOS、Ubuntu Server小型实例甚至红帽即将推出的Atomic发行版等为代表的轻量化操作系统都已经在设计当中考虑到了作为框架引入容器托管方案的可能性。而相信我们也将在Windows 10当中见到容器技术的普及——虽然Mac OS目前还没有在容器方面作出任何尝试。

下面让我们对这三大主流方案作出一一解析。

OpenVZ/Odin Virtuozzo 6.0

OpenVZ是一款Linux发行版，主要负责对虚拟机以及/或者容器访客实例进行托管。OpenVZ资源以现代3.X+版本Linux内核为基础，同时利用OpenVZ内核实现下载。虽然我们可以将大量不同类型的OpenVZ组件服务安装在Linux 3.X+当中，但只有OpenVZ内核的功能能够得到全面支持。

OpenVZ访客实例可以表现为虚拟机或者容器系统。当大家向其中添加操控机制、计费以及管理面板时，则需要用到另一款商用产品——Odin Virtuozzo。顺带一提，Odin是Parallels这家瑞士企业进行品牌调整之后的产物。

我们早在2008年就曾经对Virtuozzo的Windows版本进行过评测。当时Virtuozzo只适用于32位服务器环境，由此带来的内存容量局限严重影响了它的实用性。虽然这款Windows产品目前仍然存在，但Virtuozzo如今已经能够使用共享内核，从而在Linux平台之上顺畅打理容器系统。

我们下载到openVZ并将其安装到了一台联想ThinkServer RD640设备之上。由于这套方案所使用的Linux内核已经相当古老，所以我们需要尽可能考量其兼容性水平，确保其能够与硬件设备顺利协作。根据说明，我们拥有大量服务器功能可供选择——虽然尚未在测试中得到证实——而且任何能够与Red Hat 6相兼容的服务器硬件，都将能支持openVZ或者Odin。

虽然我们已经证实了openVZ与Odin能够顺利使用RAID，但大家仍然只能从HBA以及JBOD磁盘组合当中直接进行选择。此外，我们通过测试发现其支持“硬”IPv6虚拟机/容器地址，但总体而言IPv6支持能力仍然有所局限。

Virtuozzo是一套虚拟环境，而且在我们的测试当中，托管虚拟机为典型的Windows Server。Linux及FreeBSD最好是以容器的方式处理。Virtuozzo通过一款Web应用实现控制，而且在正常UI之外还提供必要的命令行组件。如果大家愿意，几乎可以完全通过命令行界面完成全部控制操作。

容器可以由Docker、Rocket或者LinuXContainers/LXC生成。此外，大家也可以使用下载自Odin的OpenVZ/VIrtuozzo容器库。

OpenVZ的使用方式与Docker以及rkt非常相似。虚拟环境的安装非常简便，其硬件性能表现也与VMware 5.5下的同等配置保持一致。我们并没有使用泛用式基准测试检查其性能表现，此次选择的只有作为火狐35性能指标的SciMark浏览器测试——这是考虑到其拥有类似的工作负载以及使用背景。

从这个角度来看，OpenVZ在很大程度上类似于虚拟机管理程序，只不过在整体处理强度方面低于VMware——或者说其更接近Windows Hyper-V。值得一提的是，OpenVZ并不具备VMware ESXi 5.X提供的专用功能集——或者成本水平。

测试OpenVZ与Virtuozzo

我们首先尝试了OpenVZ/OVZ。安装完成后提供两套库，其一面向各类红帽式发行版，另一套则面向Debian各发行版。下面所使用的分支版本已经过预sysctrl，因此可作为后sysctrl参考。各个分支版本在功能性方面基本一致，因为安装基础中的二进制文件非常相近。

相关说明文件适用于熟悉Linux的使用者，不过在新手看来内容似乎还不够完备。

OpenVZ倾向于配合裸机，但也能够以虚拟机方式运行。在使用裸机时，其性能水平能够得到显著提升。我们强烈建议大家不要使用OpenVZ或者VIrtuozzo作为虚拟机方案，这将导致性能水平急剧下滑——特别是在资源分配过度时，主机整体都会出现卡顿。

OpenVZ容器，或者称其为“虚拟环境”，的基础定位为一项cgroup-demoted服务。如果我们利用OpenVZ内核来替代标准Linux内核，则可以使用一套名为ploop的文件系统，并借此降低需要使用的Linux节点数量。

在选定文件系统类型之后，我们随后需要安装主容器控制器vzctl，接下来是负责控制容器资源量/配额的vzquota。其中vzctl应用能够被用于部署来自openvz.org网站的各类容器镜像。这些容器在初始体积非常小巧，我们能够以压缩包的形式将其解压到缓存目录当中并加以部署。

在这里我们要提醒大家，Linux 3.x新版本内核中所使用的内核并非全部能够支持内存与CPU控制(除了OpenVZ的内核)。我们在运行过程中并没有发现问题，但可以想象肯定会出现某种内核无法由OpenVZ全部实现编译的情况，这会导致主机内的虚拟机或者容器系统单纯依赖于OpenVZ内核。从表面上看，在必要的情况下任意内核都能够通过重新编译启用全部功能，但我们并没有在测试中加以检验。

各容器镜像在发送中还配合一条GPG密钥，用于对该镜像进行验证。这一点非常重要。根据具体需求，大家可以构建自己的镜像，当然目前也已经有大量OpenVZ源Linux镜像供我们选择。已经下载完成的镜像可以通过镜像缓存直接进行部署，不过在我们的测试环境下，其速度并不像Docker配合CentOS那么出色。部署过程的时间差异几乎可以忽略不计，多次部署之间的时差大约为数秒，这可能是因为ploop需要花点时间创建自己的文件系统。

Odin Virtuozzo 6 SP1

Odin的Virtuozzo属于OpenVZ的商业检测版本，其在我们的测试当中拥有非常接近于Red Hat 6的实际表现。Virtuozzo的安装过程耗时相当长，但最终还是识别出了我们使用的iSCSI存储机制——虽然我们发现，iSCSI会拖慢Virtuozzo的速度表现。NFS也受到支持，而且在测试当中其速度仅比iSCSI稍微快上一点。

Virtuozzo提供一套网络页面，用于对IP配置(IPv4)进行操控，其中包括虚拟网卡及VLAN。其具体方式类似于Xen/XenServer与VMware对网络机制的处理思路，同时支持多租户配置方案。

我们可以通过两种方式创建Odin虚拟环境，其一为采用本地虚拟机管理程序——这意味着任何拥有良好处理器/平台支持效果的操作系统——另一种则专门针对Linux容器负载所设计。

这些有效载荷可以由ploop文件系统负责承载，但pfcached/ParallelsFileCacheDaemon也可以在自己的ploop文件系统缓存当中对文件执行常见的重复数据删除操作。其中pfcached利用一套算法选择如何及何时执行重复数据删除操作，但我们估计这不太可能带来显著的初始性能提升——因为该算法需要经过相当长的适应时间才能带来明确成效。

OpenVZ/Virtuozzo容器由于由vzctl或者prctl负责控制的实例。大家可以通过各种常见方式与之进行对接，包括ssh、RDP或者控制台。反过来，容器会自主执行相关任务，包括处理工作、处理并存储数据，或者生成一套网络页面等。

容器或者虚拟机可以通过虚拟以太网进行隔离，而且不支持内部容器或者虚拟机通信连接; 要实现这些功能，大家需要自己想办法完成，包括使用Puppet、Chef或者其它方案。虚拟USB、磁盘驱动器以及DVD一应俱全，不过只支持原始视频。我们可能需要构建起多台硬件服务器并加以对接，才能实现高可用性目标，不过此次测试并没有就此进行尝试。

我们安装了四套测试Windows及Linux ISO库(使用是我们自己的ISO源)来充当访客虚拟机，全部获得成功。我们并没有尝试高级图形处理、虚拟USB端口以及音频端口。我们还测试了几套来自同一套Linux发行版的Odin镜像，并发现不同发行版之间的安装过程并无差别(我们使用的实例为Ubuntu 14.04与Odin提供的Ubuntu 14.04)。

在OpenVZ当中，用户可以随时下载镜像，并将其部署在主机之上。使用预格式化模板、由用户制作或者OpenVZ/Parallels/Odin提供的镜像都能够充分享受内存优化带来的效果，不过周期性出现的负载峰值可能导致虚拟机或者容器出现运行缓慢状况——当然，此类情况在其它预设有性能上限的虚拟机管理程序当中也很常见。

CPU MHz(即时钟频率)、性能峰值以及CPU数量皆可随意分配。OpenVZ不提供CPU亲和力选项，这可能是因为我们很难在Linux内核那孱弱的CPU任务亲和水平之上实现此类效果。

在使用ploop的情况下，我们能够轻松实现文件系统快照保存，而这也是VIrtuozzo实现虚拟机或者容器实时迁移的前提所在。事实上，虚拟机或者容器文件系统被打包成为一个巨大的对象，而非一系列由各类sysctl操作控制的分散文件、文件夹以及索引节点。不过我们并没有测试其实时迁移效果。

使用感受

我们可以在Virtuozzo当中塞进数量惊人的容器及虚拟机系统。访问操作起效正常，而且该操作系统能够识别出主机上的全部24个CPU计算核心，并允许我们将其分配给虚拟机或者容器。由于我们的存储资源只有数TB、内存则为128 GB，因此我们不清楚运行当中到底是哪种资源先达到瓶颈——处理器还是存储机制。我们可以对磁盘及内存进行过度分配，并在测试当中发现部分虚拟机因此出现了异常。

我们在测试当中收到了一条来自虚拟机或者容器的异常状态通知消息。虽然有些失落，但这类问题其实并不罕见。我们无法在虚拟机已经停机的情况下通过设置最低CPU阈值来触发警报，因为其只适用于追踪CPU的使用量峰值。IPMI消息收发或者负责向检测机制发送主机状态的类似API集能够起到很好的提示作用，而且我们应该能够在必要时将nagios或者其它监控工具嵌入到虚拟机/窗口负载当中。然而，我们发现磁盘作为资源类型之一也面临着同样的问题——我们会在磁盘被写满之后收到消息，但其连续24个小时未进入活动状态却不会提供任何通知(这可能意味着主机已经发生故障)。尽管Virtuozzo在定位上不同于VMware XenServer或者Hyper-V，但我们仍然有必要提供这类功能以满足多租户内部云或者将其作为云平台的小型/中型服务供应商的实际需求。

OpenVZ的容器也可以采取Docker形式并在Docker环境下运行，这就使其能够与Docker生态系统顺利对接。由于Parallels拥有自己的多种容器形式，我们发现Docker容器格式的存在有些多余，但我们仍然在CentOS系统之下测试了主机平台与Docker的协作效果。在原始SciMark基准测试当中，执行时间大概要比原生容器运行时间长18%，但与运行同类虚拟机比较时耗只长15%。所以，大家可以选择使用Docker，但我们并不推荐这么做，因为这相当于硬性弄出了一套影响性能的套娃结构。

Docker 1.6

Docker能够运行在数量繁多的Linux发行版、Mac OS版本以及实验性微软平台之上。我们在测试中尝试中四个Linux主机版本外加一台Mac OS主机。这种强大的兼容能力其实有好处也有坏处。毕竟Docker之所以具备这么高的人气，主要是由于其便捷性以及通过同一套控制机制对各类相似及差异化容器加以编排的能力。

大部分现有Linux内核以及MacOS都能够运行Docker容器。我们可以将Docker安装在主机平台之上，而后再在Docker控制“之内”启动一套操作系统实例。Docker在托管操作系统实例时拥有诸多便捷特性，换句话说，我们可以轻松将Docker编排之下的虚拟机资源进行拆分。

Docker的价值之一在于，我们可以从Docker库中规模庞大的实例类型中作出选择。大家可以从Docker.com网站处获取库及容器选项，其中不少都拥有抢眼的知名应用开发商“官方”标记。其中一部分由Docker网站托管，也有一部分可以通过GitHub获得。总体而言，陈列在我们面前的是数量繁多的开发平台以及经过打包的应用方案(包括WordPress衍生版本以及Hadoop集群组件等等)。

Ubuntu 14.04服务器可以算是一类典型的Docker实例了，其使用的主机资源相对比较有限。容器当中运行的可以是Linux/Apache/MySQL/PHP/Perl(LAMP)等实例，而且此类可选实例数量繁多且类型多样。我们现在能够从Canonical或者红帽公司那里得到大量经过体积缩减的镜像，其中一部分镜像甚至通过刻意精简来防止未使用进程从容器中抢夺CPU计算周期。

只需要使用docker run命令，我们就能轻松让一切运转起来。这条命令会将容器/虚拟机实例化，并使用目录用于数据存储——与会对安全水平造成影响的Linux chroot命令不同，这更接近于OpenVZ/Virtuozzo。

Docker容器镜像使用union文件系统，或者简称unionfs，其会为容器制作出文件夹基础体系。与OpenVZ/VIrtuozzo类似，Docker会通过unionfs为每套利用Docker运行的容器提供分层结构。这就使得类似的镜像之间能够通过一次更新就共享到同样的基础文件，而且会在需要保存镜像快照或者更新镜像时节约存储空间。举例来说，我们可以一次性更新openssh并将效果推广到20套容器当中，因为它们依赖于同一套已完成更新的镜像。

使用unionfs能够显著提高Docker的执行效率，但这同时也可能由于源镜像损坏而令大量容器陷入瘫痪——业界对此一直提出尖锐的批评。我们也可以利用RESTful put/get在user-initiator命令当中对Docker的容器镜像加以控制。不过这条命令与root user一样，非常强大但也非常危险。通过这种方式，我们能够实现对访问、密码、SSH密钥安全库以及其它强烈推荐使用的标准安全机制的控制。这种控制方式有限松散但却速度很快，而且充满乐趣。

ISO镜像也能够以自动化方式构建，这样企业用户就能够更为高效地维护自己的镜像结构并在符合安全要求的前提下实现镜像控制。

我们可以通过ssh通信或者其它API访问Docker内部，包括使用Puppet等通信结构。存储经过降级，而且可以通过user security加以进一步控制(例如chroot、chmod或者其它规定的文件限制/元数据控制机制)。在某些情况下，大家也可以使用ploop或者其它文件系统来享受到我们之前在OpenVZ/Virtuozzo章节中提到的便利效果。

利用Docker生成容器环境

Docker并不像OpenVZ/VIrtuozzo那样专注于帮助常规容器节约存储空间，例如对常规存储文件进行重复数据删除。在理论上讲，OpenVZ/Virtuozzo能够以更为紧凑的方式对容器进行打包。也就是说，在同样的硬件平台之上，我们可以利用OpenVZ/Virtuozzo承载大量Docker容器实例，而且实现方式也很简单。

而且Docker也不像Virtuozzo那样提供控制层检测机制。Docker要求我们使用控制脚本及密钥完成管理工作，相比之下Virtuozzo的方式显然更为便捷。目前市面上存在大量能够完成此类任务的第三方应用产品，但我们并没有在测试中加以尝试。

管理大量容器主机并不是什么难事，不过这对于管理员的评估技能提出了一些要求。Docker Swarm是一款API，允许大家将一组Docker容器视为单一对象加以操作，这意味着整套容器集群都能够实现单点控制。这不仅将实例的快速向外扩展变为可能，同时也为实例预留了更为可观的运行空间。

测试流程里最让我们乐在其中的部分，就是尝试利用自己的命令保证容器步调一致。这部分功能还不够完善，而且我们需要提醒大家，即使能够轻松玩转Docker Swarm、您也有可能在调度工作中使一部分容器进入休眠状态。

将大量容器汇总成单一托管对象会给管理员带来巨大的职责压力。值得一提的是，我们可以利用Apach Mesos之类的应用对集群化容器这样的大规模数据集进行严格控制。从企业安全的角度出发，大家必须非常谨慎地处理这方面工作，否则资源暴露的直接后果就是发生资源劫持。

Rocket/rkt 0.5.4

Rocket的出现与发展几乎一直伴随着CoreOS的前进脚步。CoreOS是一款经过严格修整的操作系统，专注于减少攻击面并为Docker提供高效的运行基础。CoreOS在GitHub的项目描述中将自己形容为一套App容器运行时(系统)，这是一套体积小巧但稳定性极高的应用平台。

Rocket lacks some key components and requires more construction savvy than either Docker or Virtuozzo. We were pleased to see that it focuses on security with source image provenance and payload control.

立足于Linux内核，CoreOS的发展速度稍微落后于Docker，这是因为它更多作为一款集群操作系统存在、而非控制层。CoreOS是rkt项目的赞助商之一，但该项目目前还没有作好进入生产环境的准备。从原则角度讲，我们一般不会在审查当中对这类产品提出太高的要求，因为技术业界普遍认为beta测试版本并不适用于实际生产。

由于这三款容器解决方案都采用几乎同样的成熟Linux组件，我们会更多地关注rkt的设计思路而非其实践表现。平心而论，rkt同样非常复杂，但考虑到其在各个层级采用的严格安全措施，我们认为它的潜在安全风险更低一些。

Rocket在容器实例构建管理机制当中纳入了严格的监控手段，这意味着镜像在由rkt加以启动之前，必须以特定方式进行构建。这一点与OpenVZ以及Docker的管理方式有所不同，因为二者所使用的容器控制器都能够直接使用现成的ISO镜像——包括来自当前正在运行的系统、容器控制器库/注册库或者隔壁好友的镜像。但这些在Rocket当中都无法实现。

在测试当中，我们发现rkt在容器运行时控制方面的基础效果与Docker及OpenVZ非常接近：使用守护程序控制容器数量，并在整个生命周期之内对容器实例加以管理。由于执行标准更为严格，因为rkt的安全性水平要比Docker更高。

从历史角度看，业界对于Docker安全性/可靠性的质疑催生了Rocket/rkt的出现乃至发展。事实上，rkt所遵循的原则体现了其不同于其它容器技术方案的核心价值观。由此产生的App Container(简称appc)正是一项专门的规范，用于解决Docker安全性薄弱的问题。而系统内在可靠性也必须被纳入优先级考量，无论实际接受管理的容器数量是多是少——尽管rkt允许重载，这一前提也丝毫没有动摇。

考虑到以上原则，appc规范专注于确保所下载的镜像拥有可靠的签名出处以及正确的组装方法完整性。下面我们引述几条来自GitHub的appc规范要求：

这项规范的核心目标包括：

设计出下载及启动速度更快的App Container

确保镜像拥有加密验证以及理想的可缓存能力

通过设计确保实现手段的可组合性与独立性

使用常见技术进行加密、归档、压缩以及传输

利用DNS命名空间对镜像进行命名与发现

Rocket将自身作为上述规范的典型实现机制，而其它多家厂商也对这一定位表示认同，具体包括红帽、谷歌、VMware以及Apcera等。而且尽管CoreOS+rkt这一组合与appc规范要求基本属于同一含义，但rkt在实现方案角度的地位同VMware(Lightwave/Photon)以及Apcera(Continuum)等同——虽然截至测试之时，后两者尚未正式推出。

Rkt遵循appc方法生成tar(即Tape Archive)格式的镜像文件而非ISO，因此其GPG密钥会同ISO本身一同进行散列处理，从而保证容器底层镜像经过严格验证。通过这种方式，源文件的完整性与安全性更具保障(几乎不可能出现文件替换、补丁等级错误、恶意软件、软件包损坏以及其它可能影响ISO使用的情况)。而且每套镜像都拥有一个独一无二的ImageID。

我们可以创建一个文件夹，并将其作为rkt的rootfs或者顶层文件系统。我们并未对镜像进行压缩，如果大家需要采取这种处理方式，请记得预先在未压缩的镜像当中插入JSON格式的镜像manifest。大家也可以根据需求选择其它的压缩步骤，包括在镜像在解压/解密时拥有密钥作为保护(我们推荐使用AES-256)。我们还在等待能够直接完成上述操作而无需使用命令行界面的控制层机制——不过直接使用命令行也不是很复杂。

一旦完成了加密过程并将JSON manifest插入到镜像当中，我们即可将其投入执行。镜像在启动后会作为pod存在，其本质上也就是容器，但“pod”这个语用来形容镜像似乎更为形象。

所谓pod当中包含有一整套拥有自己ID的可执行文件，并会作为单一对象使用UUID(遵循IETF RFC 4122)对所执行pod的功能进行操作。该UUID拥有自己的命名空间，由rkt创建并进行持续管理; 通过这种方式，也就实现了实例控制。随后rkt会通过初始化操作为该UUID创建一个rootfs，其中包含与JSON manifest相关文件夹的一份白名单。每一次容器对象开始启动，它都会创建一个一次性的新文件系统，从而确保不存在痕迹残留。

我们发现，manifest在其中起到了关键性作用。如果manifest存在问题，那么整套方案都无法正常起效。不过在创建完成之后，它会重新审查该源的真实性。在最新版本当中，其适用范围更是将Docker镜像涵盖于其中。总体而言，我们觉得这样严格的制度还是物有所值的，而检测监控机制的效果将成为决定其未来发展的核心所在。

测试Rkt

我们使用OpenVZ/Virtuozzo章节中提到过的同一套联想平台建立起一台CentOS 6测试主机，为了方便起见这次我们使用了最低主机环境而非CoreOS。我们制作了两套镜像，其一是来自TrunKeyLinux的WordPress镜像——我们特意选择了WordPress 4.2.2版本，另一套则是通用型Ubuntu 14.04服务器镜像——其经过一次更新，专门用于建立最小化服务。接下来，我们找到了几套适用于这两套平台的库镜像。

我们可以通过基于命令行的rkt命令对资源(例如pod所需要的内存分配机制)、带宽等进行分配。由于rkt不具备检测机制，因此目前我们必须使用脚本——为此我们还专门复习了一下JSON语法。

此次接受测试的版本允许我们通过简单的http用户名/密码下载来自Docker(或者类Docker)注册库中的镜像。这也意味着整套库都可以供我们使用，并通过安全覆写方式修改优先级链，从而摆脱审计/合规的相关要求——当然，除非日志严格监控我们的行为并执行错误修正。

我们编写出的这些脚本随后被快速复制到我们的联想主机服务器之上。我们开始运行这些用于生成实例的脚本，利用嵌入其中的伪指令启动系统，并在创建实例的同时为这台联想设备设定了用于应对暂时性卡顿的解决方案——接下来要做的就是专注观察其反应了。

但我们忘记设定CPU资源分配策略了，因此在启动全部实例的同时，巨大的启动资源需求量直击主机计算核心。没有任何一台服务器能够在这样的冲击之下幸存。但幸运的是，我们通过重启修正了脚本当中的错误。

在实践过程中，我们从Docker那边获得了两套镜像，并经过一系列调整使其能够在rkt运行时中执行。我们还以脚本方式设定了多套容器的启动流程，并得以执行了一次向外扩展执行实验——但这同样耗费了我们大量精力。而且值得强调的是，第三方工具确实能够为rkt提供帮助。

批评意见

这三款应用都以root方式运行，因为它们需要直接从内核获取处理速度。三套方案的说明文档中只是稍微提到了AppArmor与SELinux，但三者都能够利用这些沙箱机制将容器隔离起来，从而避免其破坏或者大量占用系统资源。

用于承载容器系统的集群/主机硬件平台无法避免某套受到感染的容器利用其安全权限接入其它存在于同一平台上的容器，同样的情况也会发生在立足于同一安装基础的不同容器之间。因此，容器的安全保障只作用于其内部工作流程当中。

从集群/主机的层面出发，由守护程序负责控制容器进程，而其它负责控制这些守护程序的进程必须得到严格保护——这种作法在大部分企业当中已经成为安全工作的核心要点。接下来则要提到密钥控制，在这方面Virtuozzo的表现非常不错，但仍然不够全面。我们需要的是一套能够妥善管理SSH密钥，同时对各容器运行进程所需要的通信层加以控制的整体架构。Virtuozzo无疑带来了良好的开端。当然，对这三套方案来讲，还需要配合其它内部软件定义网络机制才能真正步入成熟。

不过在目前的主流虚拟机管理程序当中，还没有密度与效率兼备的先例出现，特别是同时对存储文件及执行文件进行重复数据删除处理。从这个角度看，容器属于裸机实例与虚拟化技术相结合的混合产物。基于虚拟机管理程序的虚拟机系统彼此相互隔离，通常属于离散实例，但容器则无需受到此类限制。虚拟机管理程序能够从底层角度出发，保护实例免受资源劫持的困扰。而虚拟机对于沙箱技术的应用在理论上远高于容器——当然，安全失误同样有可能轻易摧毁这两类实例苦心构建而成的防御体系。

总结

容器技术确实非常便捷，而且允许操作系统实例与可执行文件以简单的方式进行交换，并实现资源共享(在操作系统层级)。容器在根源上讲，包括补丁/修复级别，并非完全不透明，但除非采用严格的方法来进行审计及日志记录，否则其很容易为恶意人士所利用。

不过我们必须承认，容器技术让实例的快速向外扩展/向上扩展成为可能，而这也将成为其冲击市场的主要卖点。在我们看来，OpenVZ是目前容器领域最为成熟的解决方案，而且其采用的完全虚拟化或者容器化混合模式也足以在目标市场上——即互联网服务供应商及托管服务供应商——受到追捧。

Docker则是一套值得认真考量的方案，其发展背后拥有极为强大的推动力量。从GitHub参与者数量的角度看，Docker开发工作中拥有着大量活跃技术支持者群体。但我们同时注意到，大量参与者的涌入让Docker注册库中的源镜像出现了一些问题，这甚至体现在了我们所选择的测试样本当中。这种状况让我们非常紧张，因为容器本身非常难于探测，其组合与独立组件很难直接查看、权威来源也很难得到审计——即使对大型企业来说也是如此。

这反过来让我们更加专注于appc规范的发展以及rkt项目的前进走势。毫无疑问，rkt的严格监管与appc合规机制的出现值得我们为之鼓掌，不过rkt本身并没有作好从实验阶段走向实践部署的万全准备。

容器技术是什么?其与虚拟机有何区别?

容器化应用能够摆脱虚拟机管理程序的束缚。容器当中的实例执行方式与传统虚拟机管理程序的执行方式有所差别，其中每一套容器都能够共享通用文件，而非各自拥有独立的离散操作系统/应用组合。

从概念上讲，容器中的实例构成元素包括操作系统、应用程序代码、通信连接以及临时及永久性数据存储。

与半虚拟化虚拟机实例类似，容器利用接口通过容器管理器的管理设置将通信及存储需求(必要时)同外部环境相连。

容器环境被介入式安全墙同主机的计算核心及root进程隔离开来，且通常与其它容器共同运作在同一台主机之上。

容器可以包含独立的指定主机操作系统，同时也能够以可互换机制构建，这就让采用Ubuntu、Red Hat Atomic、CoreOS以及SUSE乃至其它操作系统建立容器混合体变成可能。除非有意连接，否则容器主机对于容器内的运行状况一无所知。

反过来，这就使得设备与进程分别存在于彼此隔离的世界，并能够以对象的方式在主机之间往来迁移。此类主机通常采用Linux操作系统，但Docker也能运行在苹果、BSD等环境当中。微软公司最近演示了利用微软.Net将Docker镜像由Windows服务器平台迁移至Linux主机的过程——前提是各主机所使用的CPU为同一类别(是的，我们还不能将在ARM上开发出的容器运行在英特尔/AMD平台当中)。主机平台的这种互换能力正是系统设计师们所追求的目标，他们希望把容器像乐高积木那样随意调遣。

我们的主要批评意见是：目前容器系统能够接受未知来源或者不具备权威创建者信息的容器镜像。作为大量共享源应用的平台方案，一款应用遭受渗透或者突破有可能让容器之上的所有实例出现问题。

这是因为除非由注册库发布的某套容器镜像能够从零开始依次组装，或者拥有权威可信的来源，否则我们必须首先将其视为可疑对象。而对基于容器的通用文件进行更新管理也需要配合更为严格的控制手段。

而在另一方面，我们的一次操作即可恢复、升级或者重新配置一组容器的功能甚至特性——这种能力同样有利有弊。