腦洞大開的探索者總是想同時獲得容器的便捷與虛擬機的安全，本文將解析幾款成熟的容器與虛擬機結合產物。
前言
容器技術起源于虛擬化技術的發展，欣欣向榮的著實是容器技術潮流中一朵十分耀眼的浪花。在誕生之初，它常常被放在虛擬機技術的對立面，甚至還有過將替代虛擬機的夸大宣傳，在許多集群以及虛擬化方案設計的討論中，也總會將兩者拿來比較一番利弊。
現如今已經比較普及，這些曾經的傳言不攻而破。容器以及并沒有替代虛擬機，而是與之和諧共存，兩者各自具有不同的特征和相應適合的應用場景。但腦洞大開的探索者們總想同時獲得容器的便捷性和虛擬機的安全性，為此在兩者的邊界上進行了許多創造性的嘗試。在這篇文章里，我們將順著這個話題，聊聊當下比較成熟的幾款虛擬機和容器的結合產物。
容器式的虛擬機，虛擬機式的容器
關于容器與虛擬機的差異，具有普遍共識的特征，歸納起來大致有以下幾點：
如果從這些十分清晰的定義來看，近一年來開源界出現的一些虛擬化“邊界破壞者”們已經完全無視了這些規則。它們要么是運行在虛擬機中的操作系統，卻有著容器一樣的使用體驗，要么是基于容器技術的運行時隔離，卻應該當成虛擬機使用。因此，盡管這些技術的實現細節上差異巨大，但它們都有一個共同特征：攜帶著容器和虛擬機各一部分的基因，具備兩者優勢的結合。
這些璀璨的群星我們無法逐一細辨，只能通過窺一斑而知全豹的技術敏感力和洞察力，從這些虛擬化技術的新星中，挑選比較明亮的幾顆，與大家共同鑒賞。
小而美的Linux系統：
是 Labs公司設計的一款專為運行而定制的Linux發行版。它的定制到了什么程度呢？在最初發布后的近一年時間里，就是整個系統PID為1的根進程，其實說白了就是將一個后臺進程托管在Linux內核上。與其說它是Linux發行版，倒不如說是一個運行在硬件設備上的進程，而內核的存在僅僅是為了使用它的驅動，讓有個運行的地方。
系統的設計結構如圖1所示，這是一個雙進程的運行結構，所有的系統服務，包括管理操作系統設備的udev服務，管理系統網絡的、服務，管理日志的服務，以及與用戶交換使用的Shell進程，都以容器的形式運行于下層的 中。而與這些服務一起的還有另一個服務進程，稱之為User ，用以非root用戶方式運行用戶自定義的應用級服務。
圖1 系統結構
由于進程有時會發生意外崩潰，而根進程一旦奔潰將導致所有程序狀態不可逆終止的嚴重后果，在2016年2月發布的v0.4.3版本中，加入了一個只有幾行代碼的極簡init進程替代了的根進程位置，然而這并沒有改變在系統中的地位。操作系統本身十分輕巧，最新版本的系統ISO鏡像文件只有區區32.5M。這里面的主要內容其實只有三個部分：Linux內核、一個壓縮過的二進制文件，以及一個內置所有系統服務文件的鏡像。
從常規的定義來說，這是一個自帶內核的操作系統，因此需要按照虛擬機的方式運行和管理。事實上也正是如此虛擬機能裝php么，可以直接運行在KVM、Xen、和等主流的虛擬機和硬件虛擬化平臺之上。然而的使用，除了需要借助一些工具（例如cloud-init和ros），完全就像是在使用：整個操作系統的Shell是基于的鏡像制作的，用戶要是用不爽了可以拿或者的Shell鏡像換掉。若需要添加編譯內核模塊所需的內核頭文件，也只需下載指定的鏡像然后啟動相應服務即可。
在 Labs建立的生態圈中，還有一個重要成員是容器的調度管理平臺。這個今年3月末剛剛完成1.0版本發布的項目，能夠運行在包括在內的各種主流Linux系統之上，實現虛擬機和容器的同步可視化管理，因此也彌補了在使用和管理方式上與主流系統的差異性帶來的學習成本，從而將其輕量、高效的優勢充分放大，將的效力發揮到極致。
運行在硬件上的：Hyper
如果說還只是個運行了的Linux操作系統的話，Hyper則是真正地將容器的運行直接搬到了硬件虛擬層上。
hyper pull
hyper run -d -t --name
hyper exec ls
看到這組命令的時候你想到了什么？這是在啟動一個容器嗎？
事實上剛剛這組命令啟動了一個KVM/Xen虛擬機（具體是哪一種在Hyper安裝時就確定了），然后在這個虛擬機里執行了一次ls命令。那么第一條命令中的那個hyper pull是在做什么呢？腦洞大開的時候到了，這條命令下載了倉庫里的官方鏡像，而之后啟動虛擬機使用的正是這個鏡像！
正如上例子所演示的那樣，Hyper是一個能夠把鏡像當成虛擬機鏡像，將其直接運行在KVM或Xen的虛擬化硬件資源上的強大工具。它使用了一個高度精簡的Linux內核，系統的啟動時間僅為大約20ms，達到了與容器同一級別的啟動速度。如表1所展示的那樣，它結合了容器與虛擬機的主要優點。
表1 虛擬機、容器與Hyper的比較
Hyper的使用體驗實在太像，它不僅支持從官方的或者自建的私有倉庫獲取鏡像，還支持將本地的虛擬機鏡像推送回的鏡像倉庫中，甚至能夠支持推送到那些需要登錄驗證的倉庫。如果將Hyper制作成平臺化的工具，用戶將很難感知其后端運行的究竟是容器還是虛擬機，從而在提升隔離安全性的同時獲得容器一樣的便捷體驗。
目前Hyper的發展分成了兩個版本，即開源版本和平臺版本。前者允許用戶在自己的Linux主機上安裝和配置Hyper服務，后者則是將主機托管在Hyper的平臺上，用戶需按使用的時間和節點的規模付費，價格大約只有同等配置的傳統虛擬機的一半。開源的版本單獨建立了官方網站，而最初的官方站點現在則作為平臺版Hyper的根據地。
在Hyper的生態圈中，包含了很多來自以及社區的元素。例如能夠將Hyper運行在上的Nova驅動插件，將Hyper與進行整合的項目，以及將的網絡模塊用于以便于構建Hyper集群的項目等。利用這些現成的平臺，站在巨人的肩膀上，Hyper已經打造出了一片屬于自己的天地。
用戶態的操作系統隔離：LXD
LXD是一種提供虛擬化主機的方式，這一類工具其實并不算新鮮，早在Linux-和的時代它們就十分風光。那么這個一年多前才誕生的晚輩有何值得圈點之處呢？
實際上，之所以將LXD列為容器和虛擬機的結合產物，是因為它的實現主要基于LXC，而最早的實現也是基于LXC的。這意味著它雖是用于虛擬主機的解決方案，但骨子里的實現機制卻與容器本質上如出一轍。值得注意的是，LXD并不兼容的容器鏡像，也沒有采用AUFS那種層級式的不可變基礎設施模式，僅僅是支持對虛擬主機的運行狀態快照和還原，但它有自己的另一個殺手锏：服務熱遷移。
服務熱遷移指的是將服務在不中斷當前運行狀態的情況下，從一個物理節點移動到另一個物理節點，圖2中躍起的金魚十分形象地展示了這種服務遷移的方式。這一功能依賴于公司創造的CRIU技術，CRIU全稱是/ In ，這是一種能夠將特定服務的所有運行時信息保存成磁盤文件數據，然后在另一個地方進行原樣還原的技術。同時正如它的名字所表述的那樣，這項技術僅僅通過用戶態的代碼實現，無需對Linux內核做任何修改。
圖2 服務熱遷移
相比于修改內核以實現軟件虛擬化的做法，LXD所用的兩個核心技術都是在用戶態實現的。類似這樣即裝即用的省心設計，使得它的實施門檻比起早期的虛擬主機方案要低得多，因此普及起來更加容易。至于LXD與的關系其實十分微妙，兩者本也算是同門師兄弟，卻由于各自志向不同，踏上不同的道路。通常是用來運行特定服務的，屬于PaaS層的服務，在一個容器中啟動許多后臺進程并不是值得被稱贊的實踐。而LXD側重虛擬主機層面上的應用，屬于IaaS層的服務，用戶可以在上面安裝很多Linux應用，并運行很多的進程，甚至可以在其中像普通Linux那樣安裝并使用它創建服務的容器。
不過需要指出的是，直到目前，LXD還僅能夠運用在系統上，它是主導的開源技術棧中的一部分，這個技術棧還包括PaaS層的容器實現LXC、專用的文件系統LXCFS，以及實現嵌套的后臺服務，在網站上有更詳細的介紹。正在積極地讓LXD能夠在其他Linux發行版中運行起來，這項技術的未來發展依然值得期待。
總結
天下大勢分久必合，合久必分，容器與虛擬機這對曾經的歡喜冤家如今已碰撞出了不少創意的火花。不論是的“容器式的操作系統”虛擬機能裝php么，還是Hyper的“容器式虛擬機”，又或者LXD那樣的“虛擬機式容器”，技術的融合總是能創造出許多新的機遇和驚喜。
當大家還在談論容器化服務的時候，技術的先知者們早就已經開始了新的探索。隨著容器生態圈的繼續擴大，容器技術正在與越來越多的行業搭界，不論是過去八竿子打不著的大數據、物聯網領域，還是已經鬧得沸沸騰騰的微服務、虛擬化，一個更加廣闊的后容器技術時代正在到來，讓我們拭目以待。
作者簡介：
林帆，公司技術咨詢師。熱衷于對和容器技術應用的推廣，在容器規?；\維方面有較豐富實踐經驗。著有《實踐之路》一書。
責編：