不止Docker：八款容器管理開源方案
Docker誕生于2013年，并普及了容器的概念，以至于大多數人仍然將容器的概念等同于“Docker容器”。
作為第一個吃螃蟹的人，Docker設置了新加入者必須遵守的標準。例如，Docker有一個大型系統鏡像庫。所有的替代方案都必須使用相同的鏡像格式，同時試圖改變Docker所基于的整個堆棧的一個或多個部分。
在此期間，出現了新的容器標準，容器生態系統朝著不同方向發展。現在除了Docker之外，還有很多方法可以使用容器。
在本文中，我們將介紹以下內容：
- 將Chroot、cgroups和命名空間作為容器的技術基礎
- 定義Docker所基于的軟件堆棧
- 說明Docker和Kubernetes需要堅持和遵守的標準
- 介紹替代解決方案，這些解決方案嘗試使用具有更好更安全的組件來替換原始Docker容器。
容器的軟件堆棧
像Chroot 調用、 cgroups 和命名空間等 Linux 特性幫助容器在與所有其他進程隔離的情況下運行，從而保證運行時的安全性。
Chroot
所有類似Docker的技術都起源于類似Unix操作系統(OS)的根目錄。在根目錄上方是根文件系統和其他目錄。
從長遠來看，這是很危險的，因為根目錄中任何不需要的刪除都會影響整個操作系統。這就是為什么存在一個系統調用chroot()。它創建了額外的根目錄，例如一個用于運行遺留軟件，另一個用于包含數據庫等等。
對于所有這些環境，chroot似乎是一個真正的根目錄，而是實際上，它只是將路徑名添加到任何以/開頭的名字上。真正的根目錄仍然存在，并且任何進程都可以引用指定根目錄以外的任何位置。
Linux cgroups
自2008年2.6.24版本以來，Control groups (cgroups)一直是Linux內核的一項功能。Cgroup將同時限制、隔離和測量多個進程的系統資源(內存、CPU、網絡和I/O)使用情況。
假設我們想阻止用戶從服務器發送大量電子郵件。我們創建了一個內存限制為1GB、CPU占用率為50%的cgroup，并將應用程序的 processid添加到該組中。當達到這些限制時，系統將限制電子郵件發送過程。它甚至可能終止進程，這取決于托管策略。
Namespaces
Linux命名空間是另一個有用的抽象層。命名空間允許我們擁有許多進程層次，每個層次都有自己的嵌套“子樹(subtree)”。命名空間可以使用全局資源，并將其呈現給其成員，就像它是自己的資源一樣。
具體來看，Linux系統開始時的進程標識符(PID)為1，并且所有其他進程將包含在其樹中。PID命名空間允許我們跨越一棵新樹，它擁有自己的PID 1進程。現在有兩個值為1的PID，每個命名空間可以產生自己的命名空間，并且相同的過程可以附加了幾個PID。
子命名空間中的一個進程將不知道父級的進程存在，而父命名空間將可以訪問整個子命名空間。
有七種類型的名稱空間：cgroup、IPC、網絡、mount、PID、用戶和UTS。
Network Namespace
一些資源是稀缺的。按照慣例，有些端口具有預定義的角色，不應用于其他任何用途：端口80僅服務于HTTP調用，端口443僅服務于HTTPS調用等等。在共享主機環境中，兩個或多個站點可以監聽來自端口80的HTTP請求。第一個獲得該端口的站點不允許任何其他應用程序訪問該端口上的數據。第一個應用程序在互聯網上是可見的，而其他所有應用程序將不可見。
解決方案是使用網絡命名空間，通過網絡命名空間，內部進程將看到不同的網絡接口。
在一個網絡命名空間中，同一端口可以是開放的，而在另一個網絡命名空間中，可以關閉該端口。為此，我們必須采用額外的“虛擬”網絡接口，這些接口同時屬于多個命名空間。中間還必須有一個路由器進程，將到達物理設備的請求連接到相應的名稱空間和其中的進程。
復雜嗎?這就是為什么Docker和類似工具如此受歡迎。現在讓我們來介紹一下Docker，以及它的替代方案。
Docker: 人人可用的容器
在容器統治云計算世界之前，虛擬機非常流行。如果你有一臺Windows機器，但想為iOS開發移動應用程序，你可以購買一臺新的Mac，或者將其虛擬機安裝到Windows硬件上。虛擬機也可能是笨重的，它們經常吞噬不需要的資源，而且啟動速度通常很慢(長達一分鐘)。
容器是標準軟件單元，具有運行程序所需的一切：操作系統、數據庫、鏡像、圖標，軟件庫、代碼和所需的其他組件。容器的運行也與所有其他容器，甚至與操作系統本身隔離。與虛擬機相比，容器是輕量級的，所以它們可以快速啟動，并且容易被替換。
要運行隔離和保護，容器需要基于Chroot、cgroups和命名空間。
容器的鏡像是在實際機器上形成應用程序的模板，能夠根據單個鏡像創建盡可能多的容器，一個名為Dockerfile的文本文件包含了組裝鏡像所需的所有信息。
Docker帶來的真正革命是創建了Docker鏡像倉庫和開發了Docker引擎，這些鏡像以相同的方式在各地運行，作為第一個被廣泛采用的容器鏡像，形成了一個不成文的世界標準，所有后來的入局者都必須關注它。
CRI and OCI
OCI 全稱為Open Container Initiative，它發布鏡像和容器的規范。它于2015年由Docker發起，并被微軟、Facebook、英特爾、VMWare、甲骨文和許多其他行業巨頭接受。
OCI還提供了規范的一個實現，被稱為runc ，它可以直接使用容器，創建并運行它們等。
容器運行時接口(Container Runtime Interface，簡稱CRI)是一個Kubernetes API，它定義了Kubernetes如何與容器運行時交互。它也是標準化的，所以我們可以選擇采用哪個CRI實現。
用于CRI和OCI的容器的軟件堆棧
Linux是運行容器的軟件堆棧中最基本的部分：
請注意，Containerd和CRI-O都堅持CRI和OCI規范。對于Kubernetes而言，這意味著它可以使用Containerd或CRI-O，而用戶不會注意到其中的區別。它還可以使用我們現在要提到的任何其他替代方案——這正是創建和采用了OCI和CRI等軟件標準的目標。
Docker軟件堆棧
Docker的軟件堆棧包括：
- docker-cli，面向開發者的Docker命令行界面
- containerd，最初由Docker編寫，后來作為一個獨立的項目啟動; 它實現了CRI規范
- runc，它實現了OCI規范
- 容器(使用chroot、cgroups、命名空間等)
Kubernetes的軟件堆棧幾乎是相同的;Kubernetes使用CRI-O，而不是Containerd，這是由Red Hat / IBM和其他人創建的CRI實現。
containerd
containerd作為一個守護程序在Linux和Windows上運行。它加載鏡像，將其作為容器執行，監督底層存儲，并負責整個容器的運行時間和生命周期。
Containerd誕生于2014年，一開始作為Docker的一部分，2017年成為云原生計算基金會(CNCF)中的一個項目，并于2019年年初畢業。如果你想了解一些Containerd的使用技巧，歡迎查看下方的文章：
配置 containerd 鏡像倉庫完全攻略
runc
runc是OCI規范的參考實現。它創建并運行容器以及其中的進程。它使用較低級別的Linux特性，比如cgroup和命名空間。
runc的替代方案包括Kata-Runtime、GVisor和CRI-O。
Kata-Runtime使用硬件虛擬化作為單獨的輕量級VM實現OCI規范。它的運行時與OCI、CRI-O和Containerd兼容，因此它可以與Docker和Kubernetes無縫工作。
Google的gVisor創建包含自己內核的容器。它通過名為runsc的項目實現OCI，該項目與Docker和Kubernetes集成。有自己內核的容器比沒有內核的容器更安全，但它不是萬能的，而且這種方法在資源使用上要付出代價。
CRI-O是一個純粹為Kubernetes設計的容器堆棧，是CRI標準的第一個實現。它從任何容器鏡像倉庫中 提取鏡像，可以作為使用Docker的輕量級替代方案。
今天它支持runc和Kata Containers作為容器運行時，但也可以插入任何其他OC兼容的運行時(至少在理論上)。
它是一個CNCF孵化項目。
Podman
Podman是一個沒有守護進程的Docker替代品。它的命令有意與Docker盡可能兼容，以至于您可以在CLI界面中創建一個別名并開始使用單詞“Docker”而不是“podman”。
Podman的目標是取代Docker，因此堅持使用相同的命令集是有意義的。Podman試圖改進Docker中的兩個問題。
首先，Docker總是使用內部守護進程執行。守護進程是在后臺運行的單進程。如果它失敗了，整個系統就會失敗。
第二，Docker作為后臺進程運行，具有root權限，所以當你給一個新的用戶訪問權時，你實際上是給了整個服務器的訪問權。
Podman是一個遠程Linux客戶端，可直接從操作系統運行容器。你也可以以rootless模式運行它們。它從DockerHub下載鏡像，并以與Docker完全相同的方式運行它們，具有完全相同的命令。
Podman以root以外的用戶身份運行命令和鏡像，所以它比Docker更安全。另一方面，有許多為Docker開發的工具在Podman上是不可用的，如Portainer和Watchtower。擺脫Docker意味著放棄你之前建立的工作流程。
Podman的目錄結構與buildah、skopeo和CRI-I類似。它的Pod也非常類似于KubernetesPod。
Linux容器：LXC和LXD
LXC(LinuX Containers)于2008年推出，是Linux上第一個上游內核的容器。Docker的第一個版本使用了LXC，但在后來的發展中，由于已經實現了runc，所以LXC被移除了。
LXC的目標是使用一個Linux內核在一個控制主機上運行多個隔離的Linux虛擬環境。為此，它使用了cgroups功能，而不需要啟動任何虛擬機;它還使用命名空間，將應用程序與底層系統完全隔離。
LXC旨在創建系統容器，幾乎就像你在虛擬機中一樣——但硬件開銷很小，因為這些硬件是被虛擬化的。
LXC不模擬硬件和軟件包，只包含需要的應用程序，所以它幾乎以裸機速度執行。相反，虛擬機包含整個操作系統，然后模擬硬件，如硬盤、虛擬處理器和網絡接口。
所以，LXC是小而快的，而虛擬機是大而慢的。另一方面，虛擬環境不能被打包成現成的、可快速部署的機器，而且很難通過GUI管理控制臺進行管理。LXC要求技術人員有很高的技術水平，并且優化后的機器可能與其他環境不兼容。
LXC VS Docker
LXC就像Linux上的一個增壓chroot，它產生的“小”服務器啟動更快，需要更少的RAM。然而，Docker提供了更多特性：
- 跨機器的可移植部署：使用一個版本的Docker創建的對象可以傳輸并安裝到任何其他支持Docker的Linux主機上。
- 版本控制：Docker可以用一種類似git的方式跟蹤版本——您可以創建容器的新版本，將它們回滾等等。
- 重復使用組件：使用Docker，您可以將已經創建的包堆疊到新包中。如果您想要一個LAMP環境，可以安裝一次它的組件，然后將它們作為預先制作的LAMP鏡像重新使用。
- Docker鏡像存檔：可以從專用站點下載數十萬個Docker鏡像，并且很容易將新鏡像上傳到這樣的鏡像倉庫中。
LXC面向系統管理員，而Docker更面向開發人員。這就是Docker更受歡迎的原因所在。
LXD
LXD有一個特權守護進程，它通過本地UNIX socket和網絡(如果啟用)公開REST API。您可以通過命令行工具訪問它，但它總是使用REST API調用進行通信。無論客戶端是在本地機器上還是在遠程服務器上，它的功能都是一樣的。
LXD可以從一臺本地機器擴展到幾千臺遠程機器。與Docker類似，它是基于鏡像的，所有更流行的Linux發行版都可以使用鏡像。Ubuntu的公司Canonical正在資助LXD的開發，因此它將始終運行在Ubuntu以及其他類似Linux操作系統的最新版本上。LXD可以與OpenNebula和OpenStack標準無縫集成。
從技術上講，LXD是站在LXC的肩膀上(兩者都使用相同的liblxc庫和Go語言創建容器)，但LXD的目標是改善用戶體驗。
Docker會永遠存在嗎?
Docker擁有1100萬開發者、700萬個應用程序和每月130億次的鏡像下載。如果僅僅說Docker仍然是領導，那就太輕描淡寫了。然而，在這篇文章中，我們已經看到，現在已經有許多產品可以取代Docker軟件棧的一個或多個部分，并且通常情況下沒有兼容性問題。而且與Docker提供的服務相比，其他軟件的主要目標是安全性。
