雲計算的下一個時代
為什麼部署如此困難？
所有這些工具存在的原因是在將軟件部署到生產環境時出現的問題。 以下是一些需要解決的常見問題：
· 環境一致性。 編寫將在單個平臺上運行的代碼要容易得多。 因此，您需要最小化跨部署的平臺差異。
· 可擴展性。 您應該能夠快速擴展基礎架構，以滿足需求高峰並最大程度地降低成本。
· 安全。 這幾乎是不言自明的。 您希望您的軟件容易受到各個級別的黑客的攻擊。
· 監控。 您想有效地監視基礎結構上的負載並提取各種數據以優化您的操作。
· 對開發人員友好。 軟件開發人員希望儘可能少地工作來向客戶發佈其最新版本。 通過讓開發人員感到滿意，以後您將避免許多問題。
此列表並不詳盡，但是這些是一些常見問題，直到最近才解決。
使用虛擬機進行部署
在容器問世之前，虛擬化堆棧是大規模應用程序部署的必備工具。 要了解差異，您首先必須瞭解什麼是操作系統以及什麼是內核。
操作系統是管理硬件並控制正在運行的軟件的系統軟件。 最重要的是，它使（並帶走了）硬件對進程的訪問權。
內核是操作系統的主要組件。 其餘的OS在那裡可以加載內核。 它始終駐留在內存中，並且可以完全控制硬件和軟件。
現在，虛擬化是一種在共享硬件上運行多個操作系統的方法。 一個稱為主機的操作系統運行一個管理程序，該管理程序可以使來賓操作系統安全地訪問硬件。 有時沒有主機操作系統。 Type-1虛擬機管理程序直接在硬件上運行並加載虛擬機。
典型的部署堆棧由在多個服務器上運行的多個虛擬機組成。 您可以在上面看到此類堆棧的簡化圖。 有時，它是每個應用程序VM，每個客戶端VM或每個概念VM（一個用於數據庫，一個用於緩存，等等）。 您會注意到浪費了多少資源：每個VM都必須運行自己的操作系統實例（大多數情況下是Linux），從而導致職責重複。 您還可以想象管理這樣的基礎架構有多麼困難：您可以有效地獲得100多個服務器（例如SaaS平臺），它們都是獨立的虛擬機。
基於VM的方法的部署過程可以採用以下兩種方法之一。 構建系統可以生成帶有內置軟件的VM的完整映像，並且一旦更新到達，VM就會重新啟動。 或者，構建系統僅生成軟件包，並使用一組腳本將其上載到服務器。 這兩種方法的缺點是設置複雜，最終導致VM之間的不一致。 當您需要更新操作系統版本時，一場真正的噩夢就開始了。 您將必須執行兩次：首先是主機OS，然後是來賓OS。
但是，這種方法有其優點。 這樣，您可以完全控制系統各個方面的環境，並可以對其進行配置以完全滿足您的需求。 由於您可以直接連接到VM並將其用作常規工作站，因此它也簡化了調試。
使用容器部署
隨著諸如Docker之類的容器運行時以及諸如Kubernetes之類的容器編排系統的出現，軟件基礎設施的新紀元開始嶄露頭角。 您可能對容器很熟悉，有些甚至使用了它們，所以現在我將解釋它們的工作原理。
容器嘗試實現與虛擬機相同的概念，但消除了機器之間的重複工作。 您還記得上一節中的內核概念嗎？ 嗯，Docker不再為應用程序加載整個操作系統，而是讓容器使用主機OS的內核，同時允許它們側載應用程序特定的庫和程序。 由於Linux內核非常普遍，並且在發行版之間並沒有真正改變，因此可以實現完全的平臺獨立性。 通過調整容器及其映像，您可以微調您的應用將使用的特定庫和配置，從而獲得性能提升，而無需運行整個操作系統。 典型的容器堆棧如下所示：
運行整個操作系統所需的liveLess開銷意味著您可以在同一硬件上運行更多容器（更多應用）。 值得注意的是，由於其強大的命名空間支持，Docker僅可用於Linux內核。 命名空間將可用資源標準化，並且可以控制哪個進程可以訪問哪些資源。 因此，每個容器都能準確獲取所需的CPU時間，內存，存儲空間和網絡連接量。 當您在macOS / Windows上運行Docker時，它會在後臺啟動Linux VM，這就是為什麼在這些平臺上它運行速度如此之慢的原因。
當然，基於容器的方法有其缺點。 該軟件必須適合在容器（容器化）中使用，並且這可能會很棘手，尤其是對於舊的代碼庫。 另外，由於Docker使用Linux內核，因此您不能使用它來運行專為Windows Server設計的舊軟件（在引入.NET Core之前）。 容器具有更多用於資源分配和互操作功能的配置，因此很容易搞砸建立適當的基礎架構的過程。 最後，由於Docker容器共享同一內核，因此您不能使用自定義內核（例如，用於基於事務的軟件的Realtime Linux內核）。
容器的優點之一是能夠在開發計算機上輕鬆運行它們的能力。 開發人員非常喜歡這個，所以讓我們繼續。 部署過程本身也容易得多，您只需將預先構建的容器上載到容器存儲庫中，然後您的生產服務器就會提取更新的版本。
使用Unikernel進行部署
儘管容器正迅速成為行業標準，但Unikernels仍有很多工作要做。 Unikernel試圖進一步推動容器的概念，從而完全不需要OS。 Unikernel通過使用庫操作系統來實現此目的。 庫操作系統提供與常規操作系統類似的功能（但僅限於單用戶，單個地址空間），但以您的應用程序使用的庫形式提供。 因此，無需在內存中維護駐留內核，而是通過預構建的二進制庫來管理所有內容。 但是，Unikernel不處理資源分配，因此它們仍然需要管理程序：
您可以將虛擬機管理程序視為常規操作系統，而將unikernels視為在其上運行的進程，以解決問題。 區別在於，所有特定於應用程序的系統調用都應儘可能靠近應用程序推送，而管理程序僅處理直接的硬件互操作。
您可以想象，unikernel的開銷甚至比容器少，並且應該具有更高的性能。 而且，通過消除使用多用戶，多地址空間內核，可以大大提高安全性。 Unikernels是一項真正令人驚奇的技術，但它們還遠未投入生產。 首先需要解決的一些問題是：
· 調試。 由於unikernel沒有任何操作系統在運行，因此您無法直接連接到其Shell並進行調查。 我相信將會有一個更簡單的方法，但是還沒有。
· 簡化構建。 生成單核圖像非常複雜，並且需要對此主題有深入的瞭解。 在簡化和標準化流程之前，採用將非常緩慢。
· 框架支持。 當前的大多數應用程序框架都必須修改並生成有關Unikernels中使用情況的文檔。
一些著名的Unikernel項目包括ClickOS，runtime.js和Clive。
結束語
感謝您的閱讀，希望我對Unikernels主題感興趣。 請繼續關注有關這項革命性技術的更多帖子！
資源資源
· 維基百科上的Unikernels
· Unikernel項目列表
普通英語的筆記
您知道我們有四本出版物嗎？ 通過關注他們，表達他們的愛：普通英語JavaScript，普通英語AI，普通英語UX，普通英語Python –謝謝並繼續學習！
另外，我們始終對幫助推廣優質內容感興趣。 如果您有要提交給我們任何出版物的文章，請使用您的中等用戶名和您感興趣的內容發送電子郵件至[email protected]，我們將盡快回復您！
(本文翻譯自Michael Krasnov的文章《Unikernel Vs Container Vs Operating System: Side-By-Side Comparison》，參考：https://medium.com/javascript-in-plain-english/unikernel-vs-container-vs-operating-system-side-by-side-comparison-3b8d6d93665d)
