容器技術起源於虛擬化技術的發展，欣欣向榮的 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