Docker誕生于2013年，并普及了容器的概念，以至于大多數(shù)人仍然將容器的概念等同于“Docker容器”。

作為第一個吃螃蟹的人，Docker設(shè)置了新加入者必須遵守的標(biāo)準(zhǔn)。例如，Docker有一個大型系統(tǒng)鏡像庫。所有的替代方案都必須使用相同的鏡像格式，同時試圖改變Docker所基于的整個堆棧的一個或多個部分。

[[410087]]

在此期間，出現(xiàn)了新的容器標(biāo)準(zhǔn)，容器生態(tài)系統(tǒng)朝著不同方向發(fā)展?，F(xiàn)在除了Docker之外，還有很多方法可以使用容器。

在本文中，我們將介紹以下內(nèi)容：

• 將Chroot、cgroups和命名空間作為容器的技術(shù)基礎(chǔ)
• 定義Docker所基于的軟件堆棧
• 說明Docker和Kubernetes需要堅持和遵守的標(biāo)準(zhǔn)
• 介紹替代解決方案，這些解決方案嘗試使用具有更好更安全的組件來替換原始Docker容器。

容器的軟件堆棧

像Chroot 調(diào)用、 cgroups 和命名空間等 Linux 特性幫助容器在與所有其他進(jìn)程隔離的情況下運(yùn)行，從而保證運(yùn)行時的安全性。

Chroot

所有類似Docker的技術(shù)都起源于類似Unix操作系統(tǒng)(OS)的根目錄。在根目錄上方是根文件系統(tǒng)和其他目錄。

從長遠(yuǎn)來看，這是很危險的，因?yàn)楦夸浿腥魏尾恍枰膭h除都會影響整個操作系統(tǒng)。這就是為什么存在一個系統(tǒng)調(diào)用chroot()。它創(chuàng)建了額外的根目錄，例如一個用于運(yùn)行遺留軟件，另一個用于包含數(shù)據(jù)庫等等。

對于所有這些環(huán)境，chroot似乎是一個真正的根目錄，而是實(shí)際上，它只是將路徑名添加到任何以/開頭的名字上。真正的根目錄仍然存在，并且任何進(jìn)程都可以引用指定根目錄以外的任何位置。

Linux cgroups

自2008年2.6.24版本以來，Control groups (cgroups)一直是Linux內(nèi)核的一項功能。Cgroup將同時限制、隔離和測量多個進(jìn)程的系統(tǒng)資源(內(nèi)存、CPU、網(wǎng)絡(luò)和I/O)使用情況。

假設(shè)我們想阻止用戶從服務(wù)器發(fā)送大量電子郵件。我們創(chuàng)建了一個內(nèi)存限制為1GB、CPU占用率為50%的cgroup，并將應(yīng)用程序的 processid添加到該組中。當(dāng)達(dá)到這些限制時，系統(tǒng)將限制電子郵件發(fā)送過程。它甚至可能終止進(jìn)程，這取決于托管策略。

Namespaces

Linux命名空間是另一個有用的抽象層。命名空間允許我們擁有許多進(jìn)程層次，每個層次都有自己的嵌套“子樹(subtree)”。命名空間可以使用全局資源，并將其呈現(xiàn)給其成員，就像它是自己的資源一樣。

具體來看，Linux系統(tǒng)開始時的進(jìn)程標(biāo)識符(PID)為1，并且所有其他進(jìn)程將包含在其樹中。PID命名空間允許我們跨越一棵新樹，它擁有自己的PID 1進(jìn)程。現(xiàn)在有兩個值為1的PID，每個命名空間可以產(chǎn)生自己的命名空間，并且相同的過程可以附加了幾個PID。

子命名空間中的一個進(jìn)程將不知道父級的進(jìn)程存在，而父命名空間將可以訪問整個子命名空間。

有七種類型的名稱空間：cgroup、IPC、網(wǎng)絡(luò)、mount、PID、用戶和UTS。

Network Namespace

一些資源是稀缺的。按照慣例，有些端口具有預(yù)定義的角色，不應(yīng)用于其他任何用途：端口80僅服務(wù)于HTTP調(diào)用，端口443僅服務(wù)于HTTPS調(diào)用等等。在共享主機(jī)環(huán)境中，兩個或多個站點(diǎn)可以監(jiān)聽來自端口80的HTTP請求。第一個獲得該端口的站點(diǎn)不允許任何其他應(yīng)用程序訪問該端口上的數(shù)據(jù)。第一個應(yīng)用程序在互聯(lián)網(wǎng)上是可見的，而其他所有應(yīng)用程序?qū)⒉豢梢姟?/p>

解決方案是使用網(wǎng)絡(luò)命名空間，通過網(wǎng)絡(luò)命名空間，內(nèi)部進(jìn)程將看到不同的網(wǎng)絡(luò)接口。

在一個網(wǎng)絡(luò)命名空間中，同一端口可以是開放的，而在另一個網(wǎng)絡(luò)命名空間中，可以關(guān)閉該端口。為此，我們必須采用額外的“虛擬”網(wǎng)絡(luò)接口，這些接口同時屬于多個命名空間。中間還必須有一個路由器進(jìn)程，將到達(dá)物理設(shè)備的請求連接到相應(yīng)的名稱空間和其中的進(jìn)程。

復(fù)雜嗎?這就是為什么Docker和類似工具如此受歡迎。現(xiàn)在讓我們來介紹一下Docker，以及它的替代方案。

Docker: 人人可用的容器

在容器統(tǒng)治云計算世界之前，虛擬機(jī)非常流行。如果你有一臺Windows機(jī)器，但想為iOS開發(fā)移動應(yīng)用程序，你可以購買一臺新的Mac，或者將其虛擬機(jī)安裝到Windows硬件上。虛擬機(jī)也可能是笨重的，它們經(jīng)常吞噬不需要的資源，而且啟動速度通常很慢(長達(dá)一分鐘)。

容器是標(biāo)準(zhǔn)軟件單元，具有運(yùn)行程序所需的一切：操作系統(tǒng)、數(shù)據(jù)庫、鏡像、圖標(biāo)，軟件庫、代碼和所需的其他組件。容器的運(yùn)行也與所有其他容器，甚至與操作系統(tǒng)本身隔離。與虛擬機(jī)相比，容器是輕量級的，所以它們可以快速啟動，并且容易被替換。

要運(yùn)行隔離和保護(hù)，容器需要基于Chroot、cgroups和命名空間。

容器的鏡像是在實(shí)際機(jī)器上形成應(yīng)用程序的模板，能夠根據(jù)單個鏡像創(chuàng)建盡可能多的容器，一個名為Dockerfile的文本文件包含了組裝鏡像所需的所有信息。

Docker帶來的真正革命是創(chuàng)建了Docker鏡像倉庫和開發(fā)了Docker引擎，這些鏡像以相同的方式在各地運(yùn)行，作為第一個被廣泛采用的容器鏡像，形成了一個不成文的世界標(biāo)準(zhǔn)，所有后來的入局者都必須關(guān)注它。

CRI and OCI

OCI 全稱為Open Container Initiative，它發(fā)布鏡像和容器的規(guī)范。它于2015年由Docker發(fā)起，并被微軟、Facebook、英特爾、VMWare、甲骨文和許多其他行業(yè)巨頭接受。

OCI還提供了規(guī)范的一個實(shí)現(xiàn)，被稱為runc ，它可以直接使用容器，創(chuàng)建并運(yùn)行它們等。

容器運(yùn)行時接口(Container Runtime Interface，簡稱CRI)是一個Kubernetes API，它定義了Kubernetes如何與容器運(yùn)行時交互。它也是標(biāo)準(zhǔn)化的，所以我們可以選擇采用哪個CRI實(shí)現(xiàn)。

用于CRI和OCI的容器的軟件堆棧

Linux是運(yùn)行容器的軟件堆棧中最基本的部分：

請注意，Containerd和CRI-O都堅持CRI和OCI規(guī)范。對于Kubernetes而言，這意味著它可以使用Containerd或CRI-O，而用戶不會注意到其中的區(qū)別。它還可以使用我們現(xiàn)在要提到的任何其他替代方案——這正是創(chuàng)建和采用了OCI和CRI等軟件標(biāo)準(zhǔn)的目標(biāo)。

Docker軟件堆棧

Docker的軟件堆棧包括：

• docker-cli，面向開發(fā)者的Docker命令行界面
• containerd，最初由Docker編寫，后來作為一個獨(dú)立的項目啟動; 它實(shí)現(xiàn)了CRI規(guī)范
• runc，它實(shí)現(xiàn)了OCI規(guī)范
• 容器(使用chroot、cgroups、命名空間等)

Kubernetes的軟件堆棧幾乎是相同的;Kubernetes使用CRI-O，而不是Containerd，這是由Red Hat / IBM和其他人創(chuàng)建的CRI實(shí)現(xiàn)。

containerd

containerd作為一個守護(hù)程序在Linux和Windows上運(yùn)行。它加載鏡像，將其作為容器執(zhí)行，監(jiān)督底層存儲，并負(fù)責(zé)整個容器的運(yùn)行時間和生命周期。

Containerd誕生于2014年，一開始作為Docker的一部分，2017年成為云原生計算基金會(CNCF)中的一個項目，并于2019年年初畢業(yè)。如果你想了解一些Containerd的使用技巧，歡迎查看下方的文章：

配置 containerd 鏡像倉庫完全攻略

runc

runc是OCI規(guī)范的參考實(shí)現(xiàn)。它創(chuàng)建并運(yùn)行容器以及其中的進(jìn)程。它使用較低級別的Linux特性，比如cgroup和命名空間。

runc的替代方案包括Kata-Runtime、GVisor和CRI-O。

Kata-Runtime使用硬件虛擬化作為單獨(dú)的輕量級VM實(shí)現(xiàn)OCI規(guī)范。它的運(yùn)行時與OCI、CRI-O和Containerd兼容，因此它可以與Docker和Kubernetes無縫工作。

Google的gVisor創(chuàng)建包含自己內(nèi)核的容器。它通過名為runsc的項目實(shí)現(xiàn)OCI，該項目與Docker和Kubernetes集成。有自己內(nèi)核的容器比沒有內(nèi)核的容器更安全，但它不是萬能的，而且這種方法在資源使用上要付出代價。

CRI-O是一個純粹為Kubernetes設(shè)計的容器堆棧，是CRI標(biāo)準(zhǔn)的第一個實(shí)現(xiàn)。它從任何容器鏡像倉庫中 提取鏡像，可以作為使用Docker的輕量級替代方案。

今天它支持runc和Kata Containers作為容器運(yùn)行時，但也可以插入任何其他OC兼容的運(yùn)行時(至少在理論上)。

它是一個CNCF孵化項目。

Podman

Podman是一個沒有守護(hù)進(jìn)程的Docker替代品。它的命令有意與Docker盡可能兼容，以至于您可以在CLI界面中創(chuàng)建一個別名并開始使用單詞“Docker”而不是“podman”。

Podman的目標(biāo)是取代Docker，因此堅持使用相同的命令集是有意義的。Podman試圖改進(jìn)Docker中的兩個問題。

首先，Docker總是使用內(nèi)部守護(hù)進(jìn)程執(zhí)行。守護(hù)進(jìn)程是在后臺運(yùn)行的單進(jìn)程。如果它失敗了，整個系統(tǒng)就會失敗。

第二，Docker作為后臺進(jìn)程運(yùn)行，具有root權(quán)限，所以當(dāng)你給一個新的用戶訪問權(quán)時，你實(shí)際上是給了整個服務(wù)器的訪問權(quán)。

Podman是一個遠(yuǎn)程Linux客戶端，可直接從操作系統(tǒng)運(yùn)行容器。你也可以以rootless模式運(yùn)行它們。它從DockerHub下載鏡像，并以與Docker完全相同的方式運(yùn)行它們，具有完全相同的命令。

Podman以root以外的用戶身份運(yùn)行命令和鏡像，所以它比Docker更安全。另一方面，有許多為Docker開發(fā)的工具在Podman上是不可用的，如Portainer和Watchtower。擺脫Docker意味著放棄你之前建立的工作流程。

Podman的目錄結(jié)構(gòu)與buildah、skopeo和CRI-I類似。它的Pod也非常類似于KubernetesPod。

Linux容器：LXC和LXD

LXC(LinuX Containers)于2008年推出，是Linux上第一個上游內(nèi)核的容器。Docker的第一個版本使用了LXC，但在后來的發(fā)展中，由于已經(jīng)實(shí)現(xiàn)了runc，所以LXC被移除了。

LXC的目標(biāo)是使用一個Linux內(nèi)核在一個控制主機(jī)上運(yùn)行多個隔離的Linux虛擬環(huán)境。為此，它使用了cgroups功能，而不需要啟動任何虛擬機(jī);它還使用命名空間，將應(yīng)用程序與底層系統(tǒng)完全隔離。

LXC旨在創(chuàng)建系統(tǒng)容器，幾乎就像你在虛擬機(jī)中一樣——但硬件開銷很小，因?yàn)檫@些硬件是被虛擬化的。

LXC不模擬硬件和軟件包，只包含需要的應(yīng)用程序，所以它幾乎以裸機(jī)速度執(zhí)行。相反，虛擬機(jī)包含整個操作系統(tǒng)，然后模擬硬件，如硬盤、虛擬處理器和網(wǎng)絡(luò)接口。

所以，LXC是小而快的，而虛擬機(jī)是大而慢的。另一方面，虛擬環(huán)境不能被打包成現(xiàn)成的、可快速部署的機(jī)器，而且很難通過GUI管理控制臺進(jìn)行管理。LXC要求技術(shù)人員有很高的技術(shù)水平，并且優(yōu)化后的機(jī)器可能與其他環(huán)境不兼容。

LXC VS Docker

LXC就像Linux上的一個增壓chroot，它產(chǎn)生的“小”服務(wù)器啟動更快，需要更少的RAM。然而，Docker提供了更多特性：

• 跨機(jī)器的可移植部署：使用一個版本的Docker創(chuàng)建的對象可以傳輸并安裝到任何其他支持Docker的Linux主機(jī)上。
• 版本控制：Docker可以用一種類似git的方式跟蹤版本——您可以創(chuàng)建容器的新版本，將它們回滾等等。
• 重復(fù)使用組件：使用Docker，您可以將已經(jīng)創(chuàng)建的包堆疊到新包中。如果您想要一個LAMP環(huán)境，可以安裝一次它的組件，然后將它們作為預(yù)先制作的LAMP鏡像重新使用。
• Docker鏡像存檔：可以從專用站點(diǎn)下載數(shù)十萬個Docker鏡像，并且很容易將新鏡像上傳到這樣的鏡像倉庫中。

LXC面向系統(tǒng)管理員，而Docker更面向開發(fā)人員。這就是Docker更受歡迎的原因所在。

LXD

LXD有一個特權(quán)守護(hù)進(jìn)程，它通過本地UNIX socket和網(wǎng)絡(luò)(如果啟用)公開REST API。您可以通過命令行工具訪問它，但它總是使用REST API調(diào)用進(jìn)行通信。無論客戶端是在本地機(jī)器上還是在遠(yuǎn)程服務(wù)器上，它的功能都是一樣的。

LXD可以從一臺本地機(jī)器擴(kuò)展到幾千臺遠(yuǎn)程機(jī)器。與Docker類似，它是基于鏡像的，所有更流行的Linux發(fā)行版都可以使用鏡像。Ubuntu的公司Canonical正在資助LXD的開發(fā)，因此它將始終運(yùn)行在Ubuntu以及其他類似Linux操作系統(tǒng)的最新版本上。LXD可以與OpenNebula和OpenStack標(biāo)準(zhǔn)無縫集成。

從技術(shù)上講，LXD是站在LXC的肩膀上(兩者都使用相同的liblxc庫和Go語言創(chuàng)建容器)，但LXD的目標(biāo)是改善用戶體驗(yàn)。

Docker會永遠(yuǎn)存在嗎?

Docker擁有1100萬開發(fā)者、700萬個應(yīng)用程序和每月130億次的鏡像下載。如果僅僅說Docker仍然是領(lǐng)導(dǎo)，那就太輕描淡寫了。然而，在這篇文章中，我們已經(jīng)看到，現(xiàn)在已經(jīng)有許多產(chǎn)品可以取代Docker軟件棧的一個或多個部分，并且通常情況下沒有兼容性問題。而且與Docker提供的服務(wù)相比，其他軟件的主要目標(biāo)是安全性。