容器是否已经为它们在网络中的黄金时间准备就绪?其中的利弊是什么呢?为了搞清楚这个问题，我们测试了三个容器Docker、Rocket/rkt 和openVZ/Odin(以前的Parallels)。
容器像风暴一样席卷了整个网络世界，它们为传统的虚拟机提供了轻量化且更为灵活的替代方案。容器与虚拟机之间最大的不同之处在于容器可以共享公共文件，虚拟机进程为不连续的颗粒，即便存储和网络都被虚拟化和共享后情况仍然如此。虚拟机更像是孤岛，容器可以是孤岛也可以是社区。
我们预测，终究有一天位于虚拟层之上的大部分操作系统实例将是容器。实际上，操作系统厂商目前正在全力为他们的产品开发轻量化且对容器友好的版本。因此，容器是否已经为它们在网络中的黄金时间准备就绪?其中的利弊是什么呢?为了搞清楚这个问题，我们测试了三个容器Docker、Rocket/rkt 和openVZ/Odin(以前的Parallels)。
在发展势头方面，Docker处于领先地位，但是它们也存在一些需要克服的潜在问题。Rocket/rkt虽然解决了Docker面临的一些问题，但是它们并没有做好投入生产的准备。OpenVZ/Odin既可以提供容器方式，也可以提供容易让人们联想起热门虚拟层平台的“虚拟环境”，但是存在着许多限制。与传统的虚拟层和虚拟机综合体相比，这三种容器都存在潜在优势和潜在劣势。通过谨慎使用和全面考虑，这三种容器都拥有巨大的潜力。
我们在企业系统基础设施环境中而非在开发运营和持续发展环境中对这三种产品展开了测试。容器背后的力量意味着，相对于快速发展的需求/优势、扩展性和持续发展实践背后的理念，它们更难脱离系统基础设施和其控制层。
此外，我们所测试的每一种产品都处于快速转型时期，较老的OpenVZ/Virtuozzo扮演了一个稍许不同的角色，对于服务提供商来说，其更多的是一款控制层产品。
容器要解决的问题
对流程编排的需求是容器演进的推动力。与部署虚拟机相比，流程编排更为轻量化，并且系统中的部分组件连接集群，并且可被快速安装和卸载。所有的这些工作需要都可靠性和安全性，这也是对每种平台最重要的评价。它们是云计算[注]理念发展过程中的一个副产品。
在openVZ/Virtuozzo方案中，容器流程和快速部署更多的在于服务提供商，因为他们向用户提供了以工具驱动的基础设施。实例中包括了预置的网络/电子邮件主机、网站经营、类似语言定位工具的解决方案和相关服务。在这种情况下，操作系统的仪表和多实例计费对于潜在用户来说非常关键。
Odin前身为Parallels的分支，后者是openVZ的支持者并推出了Virtuozzo。目前，Odin已经做这项工作很长时间了。它们更具预测性和灵活性足以做为Docker的主机。
Docker提供了一个轻量化的操作系统环境，该环境受到了所用仪表的控制权的管理与规范。这种仪表是最基本的，并且可以用于复杂的管理控制层。
Rocket/rkt与Docker相似，但是在某些方面更加原始(并且没有做好投入生产的准备)。由于Rocket的发展貌似是对Docker不安全和扩张的回应，我们发现rkt可以满足我们的部分需求。此前我们曾经希望在Docker开发中实现这些需求。
Odin和openVZ使用了一个经修改的内核，其可用于传统的虚拟层和容器托管环境。例如，我们可以在openVZ上运行Docker或Rocket。
我们发现这三种产品使用的是都是一种非常相似的方式。实际上这三种产品都有着长长的捐助者名单，它们都是交叉渗透的。它们是新兴的解决方案的代表，能够轻量化实例管理，消除传统虚拟层的“笨拙”。
那么，容器托管方式能够替代传统的Type 1虚拟层吗?我们现在的答案是：不完全是这样。我们注意到轻量化的操作系统实例，如CoreOS、Ubuntu Server和Red Hat即将推出的Atomic发行版都旨在作为容器托管试的内部架构。尽管MacOS容器还没有出现，但是对于Windows 10容器的出现我们并不感到惊讶。
OpenVZ/Odin Virtuozzo 6.0
OpenVZ为一个Linux发行版，其可容纳托管的虚拟机和/或容器的访客实例。OpenVZ资源在于现代化的3.X+ Linux内核，OpenVZ内核用于下载。尽管部分OpenVZ服务可安装在Linux 3.X+上，但只有OpenVZ内核可保证支持所有的功能。
OpenVZ访客实例可以是虚拟机或是容器。当我们增加了仪表、计费和管理层，我们就得到了一个商业化的Odin Virtuozzo产品。Odin是瑞士Parallels公司对其产品的品牌重塑。
我们曾在2008年对Virtuozzo进行了评估。当时32位服务器的内存限制降低了Virtuozzo的可用性。目前Windows产品情况依然如此，但是Virtuozzo目前可以使用共享内核在Linux领域内变身为容器。我们下载了openVZ，并将其安装在了联想ThinkServer RD640上。由于这一方案使用的Linux内核相对较早，我们需要确保硬件的兼容性。虽然我们有着大量的服务器功能，但是我们被告之与Red Hat 6相关的服务器硬件兼容性可与openVZ 或 Odin协同工作。
目前我们已经证实openVZ和Odin可与RAID协同工作，以及虽然IPv6虚拟机/容器地址被支持并被测试，但是IPv6并不完全被支持。Virtuozzo是一个虚拟环境，在我们的测试中，托管的虚拟机通常是Windows Servers。Linux和FreeBSD作为容器最为适合。Virtuozzo通过web应用被控制，并且必须要有命令行组件，不过这个命令行组件并不在UI中。如果我们愿意，那么它们几乎完全被CLI控制。
Docker、Rocket或LinuXContainers/LXC都可以用于创建容器。此外，通过Odin下载，还可创建一个供openVZ/Virtuozzo容器使用的仓库。在OpenVZ的部署与Docker和Rkt相似。虚拟化环境安装起来很容易，可获得与配置相似的VMware 5.5中的硬件相同的性能。我们没有使用过多的测量标准，只使用了SciMark浏览器进行了大概的性能测试，其下载性能与后台使用场景都与Firefox 35相似。
在这种方式中，OpenVZ非常像一个虚拟层，但是整个处理流程与VMware相比更为轻量化，它们可能更像Windows Hyper-V。不过，它们并没有VMware ESXi 5.X的大量功能。
测试OpenVZ和Virtuozzo
我们首先测试的是OpenVZ/OVZ。安装存在着两个分支，一个是针对的是类似RedHat的版本，另一个针对的是Debian版本。每一个都是pre-sysctrl的分支和post-sysctrl的推断。由于安装基础二进制文件都非常相似，所有分支的功能实际上都相同。其说明文档适合熟悉Linux的安装者，但是并不完全适合新手。
尽管OpenVZ可以作为虚拟机运行，但是它们希望的是裸机。在使用裸机时，性能还是比较快的。我们强烈建议不要使用OpenVZ或Virtuozzo作为虚拟机，因为这样会降低性能。
Docker 1.6
Docker作为一个根进程在许多Linux发行版、MacOS版本和微软平台上运行。我们测试了4个版本的Linux主机和一个MacOS主机。这即是好事也是坏事。由于简单并且能够编排相似和不同的容器，因此Docker受到了广泛欢迎。目前大多数的Linux内核都能够运行Docker容器。Docker可以很方便的托管操作系统实例。
Docker的部分价值在于有可从Docker仓库中选择许多实例变种。在Docker.com中注册的仓库和容器中充满了知名应用开发厂商的“官方”镜像，部分镜像被托管在Docker的网站上，部分被链接至应用开发商的网站上，还有一部分与GitHub连接到了一起。此外，有许多开发平台和预置应用工具可供使用。
典型的Docker实例可能是Ubuntu 14.04服务器实例，其在可用主机资源方面相对较少。或许容器正在运行一个Linux/Apache/MySQL/PHP/Perl (LAMP)实例，通用实例非常多并且各种类型都有。让事情运行起来就像使用docker运行命令那样简单。这一命令实例化了容器/虚拟机实例，其将使用存储子目录，这不同于Linux chroot在安全方面的工作，而是与OpenVZ/Virtuozzo相同。
Docker容器镜像使用了联合文件系统/ unionfs，其可成为容器专用的文件夹基础设施。与OpenVZ/Virtuozzo一样，Docker可通过unionfs让层致力于每个由Docker启动的容器进程。这允许相似的镜像共享基础文件，只需要一次升级，保留镜像快照或镜像升级所需的空间即可。例如在升级openssh时，因为它们依赖于升级后的镜像，因此可迅速为20个容器进行升级。
Docker作为容器平台
在删除所存储的重复性共同文件方面，Docker并不像OpenVZ/Virtuozzo那样倾向于保留共同的容器空间。理论上，OpenVZ/Virtuozzo可将容器紧密地打包在一起。这表明，在使用与OpenVZ/Virtuozzo测试时一样的硬件平台，我们可更为轻松地放置大量的Docker容器实例。
与Virtuozzo相比，Docker没有控制层仪表。Docker需要更为精心地处理控制脚本和密钥，相比之下Virtuozzo更为便利。目前许多第三方厂商开始通过应用解决方案来解决这一问题。不过，我们此次并没有测试这些应用解决方案。
管理庞大的容器主机并不困难，但这需要娴熟的技能。Docker Swarm是一个API，允许一组Docker容器作为一个对象，通过一个单点控制就可以管理一组容器。同时这也使得实例可以快速扩展。
创建可作为对象管理的一组容器平台需要极强的责任心。这表明，要有像Apache Mesos这样能够将庞大数据[注]集控制作为集群化容器的应用。从机构安全配置方面看，这必须要极其小心，因为暴露的资源都是有可能被劫持的资源。
Rocket/rkt 0.5.4
Rocket是一个占用空间小且高度稳定的应用平台，它的引入是为了与CoreOS进行协调。Rocket缺乏一些密钥组件(+微信关注网络世界)，与Docker或Virtuozzo相比，它们需要一些精通架构的专业人员。我们非常高兴地看到它们通过源镜像出处和负载控制将重点聚焦在了安全性上。
在Linux内核的基础上，CoreOS的演进速度比Docker要慢，它们是一个针对集群的操作系统，而不是针对控制层的操作系统。CoreOS是rkt的多家赞助商之一，不过它们并没有为投入生产做好准备。通常我们并不会对没有很大需求的产品进行对比。因为测试版本往往都无法满足现实生产的需求。
这三个容器都使用了相同成熟度的Linux组件，我们考虑rkt更多的是出于它们的理念，而非实践情况。Rkt并不简单，不过我们认为它的风险较小，因为它们有着更为严格的安全标准。
测试Rkt
我们利用openVZ和Virtuozzo使用的联想平台借助CentOS 6创建了一个测试平台，启动了一个迷你托管环境。我们制作了两个镜像，一个是由TurnKeyLinux制作的WordPress镜像，该镜像是为WordPress 4.2.2准备的，另一个是通用的Ubuntu 14.04服务器镜像。它们可以被升级或是创建迷你服务。
资源，如pod所需的内存分配、带宽等都可通过基于CLI的rkt命令Here，仪表正在消失，脚本语言成为了必须。我们还重新学习了JSON语法。
我们测试的版本也允许下载，其主要通过简单的http用户名/密码和来自Docker(或类似Docker)Registry的镜像。除非针对下载行为对日志进行严格监视，对错误进行强制修正，否则安全上的忽略将会突破权限链，并可能破坏所需要的审核和合规性。
我们忘记设置CPU共享，一旦启动了所有的实例，就会对主机内核产生巨大的启动需求。在这种情况下没有任何服务器会坚持下来。幸运的是，重新启动允许我们修正我们的错误(我们脚本中的错误)。
实际上，我们从Docker那里获得了两个以上的镜像，在经过大量欺骗后，它们都能够正确执行。我们还编写脚本让许多容器一起启动，在这种情况下，它们都能够试验性地执行扩展文件，不过这需要做大量的工作。第三方工具也可为rkt提供帮助。
评论
这三个应用都可以作为根运行。他们需要从内核提升速度。AppArmor和SELinux对于这三个应用来说比较温和，但是三个应用都可以使用这些沙盒将容器与DoSing系统资源隔离起来。
一个容器平台/主机硬件平台不会阻止一个拥有安全权限的被感染容器与同平台中的其它容器协同工作。由于容器天生是在内部运行的，因此它们是安全的。
在这个平台/ 托管层，控制后台程序的进程必须要受到特别保持，在一些机构中这已经成为了核心安全活动。尽管Virtuozzo做的相对较好，但是密钥控制并不全面。可正确管理SSH密钥，控制各个容器的通信平台的架构需要进一步完善。目前Virtuozzo已经开始了这项工作。其它的软件定义网络[注]内部构件需要与这三个产品进行协调。而这三个产品也需要进一步成熟。
从效率到密度方面都存在着许多发展潜力，但是它们在Type 1虚拟层中并没有真正实现并行，尤其是应当在这里对已存储文件和已执行文件进行删重。在某种程度上，容器是一种带有虚拟化技能的混合裸机实例。基于虚拟层的虚拟机是孤立的，通常都是独立的实例，有些实例未必是真正的容器。虚拟层保护实例免遭资源劫持或是防范恶意软件的能力非常弱。虽然安全上的失误会很轻松地突破每种实例的安全防护策略，但是由沙盒组成的防火墙理论上更适合虚拟机而非容器。
总结
容器非常方便，并且允许操作系统实例+可执行文件在一种简化的资源共享(在操作系统级)环境中进行交换。容器的开发商、他们修补和解决问题的水平都并非完全不透明，但是除非制定严格的规则进行审核和登记，这些厂商才会努力向着我们期望的目标前进。
我们承认实例可快速横向扩展和纵向扩展的能力具有魅力。OpenVZ是我们的评估中最为成熟的容器，它们的全虚拟化或容器化的混合模式使得它们对于目标市场、互联网服务提供商和托管服务提供商都具有重要意义。
Docker则是一个非常重要的架构，它们在发展中得到了大力支持。如果GitHub参与者数量是一个指标，那么Docker发展中的活跃程度则是压倒性的。我们也注意到目前Docker Registry源镜像存在一些问题，包括我们找出来作为案例的那些问题。让我们感到不安的是容器难以被探查，并且它们的组成和单个组件也都难以被进行简单地评估和审核。
我们希望在rkt中看到的与appc规范有关的东西能够继续发展。尽管除了测试和试点部署外，rkt并没有做好大规模部署的准备，但是rkt的规范和appc合规性均得到了认可。
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
