再谈容器与虚拟机的那点事
容器技术起源于虚拟化技术的发展，欣欣向荣的 Docker 着实是容器技术潮流中的一朵十分耀眼的浪花。在 Docker 诞生之初，它常常被放在虚拟机技术的对立面，甚至还有过 Docker 将替代虚拟机的夸大宣传，在许多集群以及虚拟化方案设计的讨论中，也总会将两者拿来比较一番利弊。
现如今 Docker 已经比较普及，这些曾经的传言不攻而破。容器以及 Docker 并没有替代虚拟机，而是与之十分和谐的共存，两者各自具有不同的特征和相应适合的应用场景。但脑洞大开的探索者们总想同时获得容器的便捷性和虚拟机的安全性，为此在两者的边界上进行了许多创造性的尝试。在这篇文章里，我们将顺着这个话题，聊聊当下比较成熟的几款虚拟机和容器的结合产物。
容器式的虚拟机，虚拟机式的容器
关于容器与虚拟机的差异，具有普遍共识的特征归纳起来大致有以下几点：
- 容器实例与主机共享操作系统内核，通过内核提供的运行时隔离能力为服务提供独立的用户域、文件系统、网络以及进程运行空间。虚拟机的每个实例自带操作系统，因而是一种硬件级的虚拟化隔离。
- 容器通常是专用于运行特定服务的，它的镜像通常只包含运行该服务所需的上下文内容，许多广泛使用的镜像都只有几十 MB，甚至几 MB 大小。虚拟机则需要提供包括内核在内的通用进程运行环境，它的镜像偏向于大而完整的全功能集合，即使一个最小的精简镜像的体积也有几百 MB。
- 容器的使用方式倾向于开箱即用，镜像提供的是一个『不可变的基础设施环境』。虚拟机则倾向于让用户根据所用的系统，自定义初始化操作，使用 Ansible、Puppet 这样的配置工具来进行基础设施的管理。
- 容器在启动速度和运行性能上更有优势，虚拟机在安全性上更有优势。
如果从这些十分清晰的定义来看，近一年来开源界出现的一些虚拟化『边界破坏者』们已经完全无视了这些规则。它们要么是运行在虚拟机中的操作系统，却有着容器一样的使用体验，要么是基于容器技术的运行时隔离，却应该当成虚拟机使用。因此，尽管这些技术的实现细节上差异巨大，它们都有一个共同特征：携带着容器和虚拟机各一部分的基因，具备两者优势的结合。
这些璀璨的群星我们无法逐一细辨，只能通过窥一斑而见全豹的技术敏感力和洞察力，从这些虚拟化技术的新星中，挑选比较明亮的几颗，与大家共同鉴赏。
小而美的 Linux 系统：RancherOS
GitHub 项目地址：https://github.com/rancher/os/
项目 Star 数量：2200+
项目启动时间：2015 年 2 月
RancherOS 是 Rancher Labs 公司设计的一款专为运行 Docker 而定制设计的 Linux 发行版。它的定制到了什么程度呢，在最初发布后的近一年时间里，Docker 就是整个 RancherOS 系统 PID 为 1 的根进程，其实说白了就是将一个 Docker 后台进程托管在 Linux 内核上。与其说它是 Linux 发行版，倒不如说是一个运行在硬件设备上的 Docker 进程，而内核的存在仅仅是为了使用它的驱动，让 Docker 有个运行的地方。
图一 RancherOS 系统结构
RancherOS 系统的设计结构如图一所示，这是一个双 Docker 进程的运行结构，所有的系统服务，包括管理操作系统设备的 udev 服务，管理系统网络的 netconf、dhcpcd 服务，管理日志的 rsyslogd 服务，以及与用户交换使用的 Shell 进程，都以容器的形式运行与下层的 System Docker 中，而与这些服务一起的还有另一个 Docker 服务进程，称为 User Docker，用来以非 root 用户方式运行用户自定义的应用级服务。
由于 Docker 进程有时候会发生意外崩溃，而根进程一旦奔溃将导致所有程序状态不可逆终止的严重后果，在 2016 年 2 月发布的 v0.4.3 版本中，加入了一个只有几行代码的极简 init 进程替代了 Docker 的根进程位置，然而这并没有改变 Docker 在 RancherOS 系统中的地位。RancherOS 操作系统本身十分轻巧，最新版本的系统 ISO 镜像文件只有区区 32.5M。这里面的主要内容其实只有三个部分：Linux 内核、一个压缩过的 Docker 二进制文件、以及一个内置所有系统服务文件的 Docker 镜像。
从常规的定义来说，这是一个自带内核的操作系统，因此 RancherOS 是需要按照虚拟机的方式运行和管理的。事实上也正是如此，RancherOS 可以直接运行在 kvm、xen、vmware 和 virtualbox 等主流的虚拟机和硬件虚拟化平台之上。然而 RancherOS 的使用，除了需要借助一些工具（例如 cloud-init 和 ros），完全就像是在使用 Docker：整个操作系统的 Shell 是基于 Docker 的 BusyBox 镜像制作的，用户要是用不爽了可以拿 Ubuntu 或者 Debian 的 Shell 镜像换掉。若需要添加编译内核模块所需的内核头文件，也只需下载指定的 Docker 镜像然后启动相应服务即可。
在 Rancher Labs 建立的生态圈中，还有一个重要成员是 Docker 容器的调度管理平台 Rancher。这个今年 3 月末刚刚完成 1.0 版本发布的项目，能够运行在包括 RancherOS 在内的各种主流 Linux 系统之上，实现虚拟机和容器的同步可视化管理，因此也弥补了 RancherOS 在使用和管理方式上与主流系统的差异性带来的学习成本，从而将其轻量、高效的优势充分放大，将 Docker 的效力发挥到极致。
运行在硬件上的 Docker：Hyper
GitHub 项目地址：https://github.com/hyperhq/hyperd
项目 Star 数量：800+
项目启动时间：2015年5月
如果说 RancherOS 还只是个运行了 Docker 的 Linux 操作系统的话，Hyper 则是真正的将容器的运行直接搬到了硬件虚拟层上。
hyper pull ubuntu hyper run -d -t –name machine ubuntu hyper exec machine ls
看到这组命令的时候你想到了什么？这是在启动一个 Docker 容器吗？
事实上刚刚这组命令启动了一个 kvm/xen 虚拟机（具体是哪一种在 Hyper 安装时就确定了），然后在这个虚拟机里执行了一次『ls』命令。那么第一条命令中的那个『hyper pull』是在做什么呢？脑洞大开的时候到了，这条命令下载了 DockerHub 仓库里的官方 ubuntu 镜像，而之后启动虚拟机使用的正是这个 Docker 镜像！
正如上例子所演示的那样，Hyper 是一个能够把 Docker 镜像当成虚拟机镜像，将其直接运行在 kvm 或 xen 的虚拟化硬件资源上的强大工具。它使用了一个高度精简的 Linux 内核，系统的启动时间仅为大约 20ms，达到了与容器同一级别的启动速度。如表一所展示的那样，它结合了容器与虚拟机的主要优点。
表一 虚拟机、容器与 Hyper 的比较
Hyper 的使用体验实在太像 Docker，它不仅支持从官方的 DockerHub 或者自建的私有 Docker 仓库获取镜像，还支持将本地的虚拟机镜像推送回 Docker 的镜像仓库中，甚至能够支持推送到那些需要登录验证的仓库。如果将 Hyper 制作成平台化的工具，用户将很难感知其后端运行的究竟是容器还是虚拟机，从而在提升隔离安全性的同时获得容器一样的便捷体验。
目前 Hyper 的发展分成了两个版本，开源版本和平台版本。前者允许用户在自己的 Linux 主机上安装和配置 Hyper 服务，后者则是将主机托管在 Hyper 的平台上，用户需按使用的时间和节点的规模付费，价格大约只有同等配置的传统虚拟机的一半。开源的版本单独建立了官方网站 http://hypercontainer.io，而最初的官方站点 https://hyper.sh 现在已经作为平台版 Hyper 的根据地。
在 Hyper 的生态圈中，包含了很多来自 OpenStack 以及 Kubernetes 社区的元素。例如能够将 Hyper 运行在 OpenStack 上的 Nova 驱动插件 Hypernova，将 Hyper 与 Kubernetes 进行整合的项目 Hypernetes，以及将 OpenStack 的网络模块 Neutron 用于 Kubernetes 以便于构建 Hyper 集群的 Kubestack 项目等。利用这些现成的平台，站在巨人的肩膀上，Hyper 已经打造出了一片属于自己的天地。
用户态的操作系统隔离：LXD
GitHub 项目地址：https://github.com/lxc/lxd
项目 Star 数量：900+
项目启动时间：2014年11月
LXD 是一种提供虚拟化主机的方式，这一类工具其实并不算新鲜，早在 Linux-VServer 和O penVZ 的时代它们就曾经十分风光。那么这个一年多前才诞生的晚辈有何值得圈点之处呢？
实际上，之所以将 LXD 列为容器和虚拟机的结合产物，是因为它的实现主要基于 LXC，而 Docker 最早的实现也是基于 LXC 的。这意味着它虽是用于虚拟主机的解决方案，骨子里的实现机制却与容器本质上如出一辙。值得指出的是，LXD 并不兼容 Docker 的容器镜像，也没有采用 AUFS 那种层级式的不可变基础设施模式，仅仅是支持对虚拟主机的运行状态快照和还原，但它有自己的另一个杀手锏：服务热迁移。
服务热迁移指的是将服务在不中断当前运行状态的情况下，从一个物理节点移动到另一个物理节点，图二中跃起的金鱼十分形象的展示了这种服务迁移的方式。这一功能依赖于 Canonical 公司创造的 CRIU 技术，CRIU 全称是 Checkpoint/Restart In Userspace，这是一种能够将特定服务的所有运行时信息保存成磁盘文件数据，然后在另一个地方进行原样还原的，同时正如它的名字所表述的那样，这项技术仅仅通过用户态的代码实现，无需对 Linux 内核做任何修改。
图二 服务热迁移
相比于 OpenVZ 修改内核以实现软件虚拟化的做法，LXD 所用的两个核心技术都是在用户态实现的，类似 Docker 这样即装即用的省心设计，使得它的实施门槛比起早期的虚拟主机方案要低得多，因此普及起来更加容易。至于 LXD 与 Docker 的关系其实十分微妙，两者本也算是同门师兄弟，却由于各自志向不同，踏上不同的道路。Docker 通常是用来运行特定服务的，属于 PaaS 层的服务，在一个 Docker 容器中启动许多后台进程并不是值得被称赞的实践。而 LXD 侧重虚拟主机层面上的应用，属于 IaaS 层的服务，用户可以在上面安装很多 Linux 应用，并运行很多的进程，甚至在其中像普通 Linux 那样安装 Docker 并使用它创建服务的容器。
不过需要指出的是，直到目前，LXD 还仅仅能够运用在 Ubuntu 系统上，它是 Canonical 主导的 LinuxContainers 开源技术栈中的一部分，这个技术栈还包括 PaaS 层的容器实现 LXC、专用的文件系统 LXCFS、以及实现 CGroup 嵌套的后台服务 CGManager，在网站 https://linuxcontainers.org 上有更详细的介绍。Canonical 正在积极的让 LXD 能够在其他的 Linux 发行版中运行起来，这项技术的未来发展依然值得期待。
总结
天下大势分久必合，合久必分，容器与虚拟机这对曾经的欢喜冤家如今已经碰撞出了不少创意的火花。不论是 RancherOS 的『容器式的操作系统』，还是 Hyper 的『容器式虚拟机』，又或者 LXC 那样的『虚拟机式容器』，技术的融合总是能创造出许多新的机遇和惊喜。
当大家还在谈论容器化服务的时候，技术的先知者们早就已经开始了新的探索。随着容器生态圈的继续扩大，容器技术正在与越来越多的行业搭界，不论是过去八竿子打不着的大数据、物联网领域，还是已经闹得沸沸腾腾的微服务、虚拟化，一个更加广阔的后容器技术时代正在到来，让我们拭目以待。
本文转自CSDN，原文链接：http://geek.csdn.net/news/detail/75199
