容器技術起源於虛擬化技術的發展，欣欣向榮的 docker 著實是容器技術潮流中的一朵十分耀眼的浪花。在 docker 誕生之初，它常常被放在虛擬機器技術的對立面，甚至還有過 docker 將替代虛擬機器的誇大宣傳，在許多集群以及虛擬化方案設計的討論中，也總會將兩者拿來比較一番利弊。
現如今 docker 已經比較普及，這些曾經的傳言不攻而破。容器以及 docker 並沒有替代虛擬機器，而是與之十分和諧的共存，兩者各自具有不同的特徵和相應適合的應用場景。但腦洞大開的探索者們總想同時獲得容器的便捷性和虛擬機器的安全性，為此在兩者的邊界上進行了許多創造性的嘗試。在這篇文章裡，我們將順著這個話題，聊聊當下比較成熟的幾款虛擬機器和容器的結合產物。
關於容器與虛擬機器的差異，具有普遍共識的特徵歸納起來大致有以下幾點：
如果從這些十分清晰的定義來看，近一年來開源界出現的一些虛擬化『邊界破壞者』們已經完全無視了這些規則。它們要麼是執行在虛擬機器中的作業系統，卻有著容器一樣的使用體驗，要麼是基於容器技術的執行時隔離，卻應該當成虛擬機器使用。因此，儘管這些技術的實現細節上差異巨大，它們都有乙個共同特徵：攜帶著容器和虛擬機器各一部分的基因，具備兩者優勢的結合。
這些璀璨的群星我們無法逐一細辨，只能通過窺一斑而見全豹的技術敏感力和洞察力，從這些虛擬化技術的新星中，挑選比較明亮的幾顆，與大家共同鑑賞。
專案 star 數量：2200+
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 映象。
在 rancher labs 建立的生態圈中，還有乙個重要成員是 docker 容器的排程管理平台 rancher。這個今年 3 月末剛剛完成 1.0 版本發布的專案，能夠執行在包括 rancheros 在內的各種主流 linux 系統之上，實現虛擬機器和容器的同步視覺化管理，因此也彌補了 rancheros 在使用和管理方式上與主流系統的差異性帶來的學習成本，從而將其輕量、高效的優勢充分放大，將 docker 的效力發揮到極致。
專案 star 數量：800+
如果說 rancheros 還只是個執行了 docker 的 linux 作業系統的話，hyper 則是真正的將容器的執行直接搬到了硬體虛擬層上。
看到這組命令的時候你想到了什麼？這是在啟動乙個 docker 容器嗎？hyper pull ubuntuhyper run -d -t –name machine ubuntu
hyper exec machine ls
正如上例子所演示的那樣，hyper 是乙個能夠把 docker 映象當成虛擬機器映象，將其直接執行在 kvm 或 xen 的虛擬化硬體資源上的強大工具。它使用了乙個高度精簡的 linux 核心，系統的啟動時間僅為大約 20ms，達到了與容器同一級別的啟動速度。如表一所展示的那樣，它結合了容器與虛擬機器的主要優點。
表一 虛擬機器、容器與 hyper 的比較
hyper 的使用體驗實在太像 docker，它不僅支援從官方的 dockerhub 或者自建的私有 docker 倉庫獲取映象，還支援將本地的虛擬機器映象推送回 docker 的映象倉庫中，甚至能夠支援推送到那些需要登入驗證的倉庫。如果將 hyper 製作成平台化的工具，使用者將很難感知其後端執行的究竟是容器還是虛擬機器，從而在提公升隔離安全性的同時獲得容器一樣的便捷體驗。
目前 hyper 的發展分成了兩個版本，開源版本和平台版本。前者允許使用者在自己的 linux 主機上安裝和配置 hyper 服務，後者則是將主機託管在 hyper 的平台上，使用者需按使用的時間和節點的規模付費，**大約只有同等配置的傳統虛擬機器的一半。開源的版本單獨建立了官方** 而最初的官方站點 現在已經作為平台版 hyper 的根據地。
在 hyper 的生態圈中，包含了很多來自 openstack 以及 kubernetes 社群的元素。例如能夠將 hyper 執行在 openstack 上的 nova 驅動外掛程式 hypernova，將 hyper 與 kubernetes 進行整合的專案 hypernetes，以及將 openstack 的網路模組 neutron 用於 kubernetes 以便於構建 hyper 集群的 kubestack 專案等。利用這些現成的平台，站在巨人的肩膀上，hyper 已經打造出了一片屬於自己的天地。
專案 star 數量：900+
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，在** 上有更詳細的介紹。canonical 正在積極的讓 lxd 能夠在其他的 linux 發行版中執行起來，這項技術的未來發展依然值得期待。
天下大勢分久必合，合久必分，容器與虛擬機器這對曾經的歡喜冤家如今已經碰撞出了不少創意的火花。不論是 rancheros 的『容器式的作業系統』，還是 hyper 的『容器式虛擬機器』，又或者 lxc 那樣的『虛擬機器式容器』，技術的融合總是能創造出許多新的機遇和驚喜。
當大家還在談論容器化服務的時候，技術的先知者們早就已經開始了新的探索。隨著容器生態圈的繼續擴大，容器技術正在與越來越多的行業搭界，不論是過去八竿子打不著的大資料、物聯網領域，還是已經鬧得沸沸騰騰的微服務、虛擬化，乙個更加廣闊的後容器技術時代正在到來，讓我們拭目以待。
容器與虛擬機器
是否容器化是個問題，或者說容器vs虛擬機器是永恆的爭論 資源需求 安全架構優缺點 容器的優缺點 在mirantis，我們經常考慮如何將整個傳統的開發域上雲，我們首先考慮的不是如何去移動乙個開發域，而是考慮該開發域該不該上雲。在本文中，我們將討論在特定情況下上雲需要考慮的一些問題。目前將應用遷移到雲上...
容器和虛擬機器
說明 容器和虛擬機器都依賴於宿主機才能執行。宿主機可以是筆記本，是資料中心的物理伺服器，也可以是公有雲的某個例項。假設宿主機是一台需要執行 4 個業務應用的物理伺服器。在虛擬機器模型中，首先要開啟物理機並啟動 hypervisor 引導程式。一旦 hypervisor 啟動，就會占有機器上的全部物理...
虛擬機器和容器比較
容器相比虛擬機器更輕量 一 虛擬機器 二 容器 一 本質上的區別 vm vmware 在宿主機器 宿主機器作業系統的基礎上建立虛擬層 虛擬化的作業系統 虛擬化的倉庫，然後再安裝應用 container docker容器 在宿主機器 宿主機器作業系統上建立docker引擎，在引擎的基礎上再安裝應用。那...