Docker公司正著手將其容器方案同一類完全不同的應用程序打包方式加以合并——也就是unikernel。

為了實現這項目標，Docker方面收購了來自英國劍橋的初創企業Unikernel Systems公司，后者長久以來一直致力于這方面研發工作。容器王者的計劃是利用Docker工作流創建出最小化、按需配置的操作系統，其中包含運行單一特定應用程序所必需的全部功能，且能夠運行在任何平臺之上——從微型物聯網裝置到數據中心服務器。

“通過將Docker中為人熟知的工具與可移植優勢同下一代unikernel技術的卓越效率及針對性結合起來，”Docker公司在新聞稿中指出，“企業客戶將能夠擁有一套極為靈活的平臺，從而在不受制于任何特定基礎設施的前提下實現頒式應用程序的構建、發布與運行。”

簡約而不簡單

事實上，unikernel技術的設計思路并不復雜：選取一款應用程序，審視其必需的操作系統調用，而后對該應用進行編譯并將其需要的操作系統組成部分打包成單一的統一內核當中。

雖然unikernel的構建難度較大，但其二進制鏡像在尺寸方面要遠遠小于應用程序與完整操作系統的打包產物。另外，由于unikernel當中的活動組件更少，因此其攻擊面也會相應減小——發生故障的機率亦大大降低。

正如在Docker正式出場之前，容器技術概念已經存在相當長一段時間但卻始終未能得到廣泛認同，unikernel機制也面臨著同樣的問題。Xen項目(部分項目成員目前正效力于Unikernel Systems公司)在不久之前創造出了Xen Mirage unikernel系統，這是一套由OCaml語言編寫而成的定制化應用程序與操作系統堆棧。而作為另一個unikernel相關項目，IncludeOS則將該操作系統中的各項服務作為庫添加到一款C++應用程序當中。

Unikernel能夠對應用程序代碼以及其運行所必需的操作系統組件進行編譯，從而保證該應用擁有恰好必要的運行條件。如此一來，我們就能夠獲得體積極為小巧的單一、快速啟動二進制系統鏡像，其攻擊面亦相當有限。

更簡單的構建途徑

那么Docker公司打算如何使用這一技術概念?簡而言之：其利用現有Docker工具集以簡化在各類Docker支持平臺之上將應用程序打包為unikernel的流程。

Docker公司市場營銷副總裁David Messina指出，這套方案將為unikernel世界帶來“民主化”。根據他的觀點，利用Docker的常規工具與工作流進行unikernel構建將“使得unikernel為成千上萬已經接納Docker技術的企業及組織機構所接受。”

根據Unikernel Systems公司CTO Anil Madhavapeddy的說法，這套工作流相當于首先在某套容器中選取應用程序外加配套的配置文件，而后在無需開發人員介入的前提下實現unikernel構建。整個構建過程與應用程序自身所使用的編程語言密切相關，這意味著利用C語言編寫的應用程序將擁有完全不同于Java或者OCaml應用的關聯性組合。目前對該工作流進行最大程度統一化調整的任務已經基本完成，這意味著我們可以通過同樣的流程實現x86與ARM編譯。

下一步發展方向

Madhavapeddy還對比了Docker計劃采取的構建方式與當前現有unikernel系統的“昂貴、手動”構建模式(例如NetApp的OnTap以及思科的IOS)。

“我們已經確保其針對性傾向能夠實際起效，”他指出，同時強調稱開發人員也可以通過他們目前常用的各高級API構建低級組件。“Unikernel當中包含大量行之有效的構建組件，不過過去它們一直很難被拼裝起來。”

在“為容器匹配量身定做的操作系統”之外，Docker公司給出的下階段發展方向是利用CoreOS等方案進一步傳播這項概念。不過unikernel方案不太可能徹底取代容器技術，正如容器也并不能完全取代虛擬機系統一樣。

毫無疑問，如果unikernel真的能夠通過略高于容器化應用的構建難度加以實現，那么其將帶來極為可觀的發展前景。其擁有諸多顯著優勢，包括允許我們在服務器之上以更高密度運行應用。另外，這也意味著Docker公司將能夠以前所未有的方式實現微服務應用模式——例如立足于資源極為有限的客戶端環境(也就是物聯網裝置)。

原文標題：Docker kicks off the unikernel revolution

【51CTO.com獨家譯稿，合作站點轉載請注明來源】