歡迎光臨
每天分享高質量文章

Red Hat 的去 Docker 化容器實踐 | Linux 中國

使用一系列更小、可協同工作的元件替代 Docker。他的戰鬥口號是“拒絕臃腫的守護行程”,理由是與公認的 Unix 哲學相違背。
— Anarcat


致謝
編譯自 | https://anarc.at/blog/2017-12-20-docker-without-docker/ 
 作者 | Anarcat
 譯者 | Andy Song (pinewall) ? ? 共計翻譯:6 篇 貢獻時間:39 天

最近幾年,開源專案 Docker (已更名為Moby[1]) 在容器普及化方面建樹頗多。然而,它的功能特性不斷集中到一個單一、龐大的系統,該系統由具有 root 許可權執行的守護行程 dockerd管控,這引發了人們的焦慮。對這些焦慮的闡述,具有代表性的是 Red Hat 公司的容器團隊負責人 Dan Walsh 在 KubeCon + CloudNativecon[2] 會議中的演講[3]。Walsh 講述了他的容器團隊目前的工作方向,即使用一系列更小、可協同工作的元件替代 Docker。他的戰鬥口號是“拒絕臃腫的守護行程”,理由是與公認的 Unix 哲學相違背。

Docker 模組化實踐

就像我們在早期文獻[4]中看到的那樣,容器的基礎操作不複雜:你首先拉取一個容器映象,利用該映象建立一個容器,最後啟動這個容器。除此之外,你要懂得如何構建映象並推送至映象倉庫。大多數人在上述這些步驟中使用 Docker,但其實 Docker 並不是唯一的選擇,目前的可替換選擇是 rkt。rkt 引發了一系列標準的建立,包括執行時標準 CRI,映象標準 OCI 及網路標準 CNI 等。遵守這些標準的後端,如 CRI-O[5] 和 Docker,可以與 Kubernetes[6] 為代表的管理軟體協同工作。

這些標準促使 Red Hat 公司開發了一系列實現了部分標準的“核心應用”供 Kubernetes 使用,例如 CRI-O 執行時。但 Kubernetes 提供的功能不足以滿足 Red Hat 公司的 OpenShift[7] 專案所需。開發者可能需要構建容器並推送至映象倉庫,實現這些操作需要額外的一整套方案。

事實上,目前市面上已有多種構建容器的工具。來自 Sysdig 公司的 Michael Ducy 在分會場[8]中回顧了 Docker 本身之外的 8 種映象構建工具,而這也很可能不是全部。Ducy 將理想的構建工具定義如下:可以用可重現的方式建立最小化映象。最小化映象並不包含作業系統,只包含應用本身及其依賴。Ducy 認為 Distroless[9]Smith[10] 及 Source-to-Image[11]都是很好的工具,可用於構建最小化映象。Ducy 將最小化映象稱為“微容器”。

可重現映象reproducible container是指構建多次結果保持不變的映象。為達到這個標的,Ducy 表示應該使用“宣告式”而不是“命令式”的方式。考慮到 Ducy 來自 Chef 配置管理工具領域,你應該能理解他的意思。Ducy 給出了符合標準的幾個不錯的實現,包括 Ansible 容器[12]、 Habitat[13]、 nixos-容器[14]和 Simth[10] 等,但你需要瞭解這些專案對應的程式語言。Ducy 額外指出 Habitat 構建的容器自帶管理功能,如果你已經使用了 systemd、 Docker 或 Kubernetes 等外部管理工具,Habitat 的管理功能可能是冗餘的。除此之外,我們還要提到從 Docker 和 Buildah[15] 專案誕生的新專案 BuildKit[16], 它是 Red Hat 公司 Atomic 工程[17]的一個元件。

使用 Buildah 構建容器

Buildah logo

Buildah 名稱顯然來自於 Walsh 風趣的 波士頓口音[18]; 該工具的品牌宣傳中充滿了波士頓風格,例如 logo 使用了波士頓梗犬(如圖所示)。該專案的實現思路與 Ducy 不同:為了構建容器,與其被迫使用宣告式配置管理的方案,不如構建一些簡單工具,結合你最喜歡的配置管理工具使用。這樣你可以如願的使用命令列,例如使用 cp 命令代替 Docker 的自定義指令 COPY 。除此之外,你可以使用如下工具為容器提供內容:1) 配置管理工具,例如Ansible 或 Puppet;2) 作業系統相關或程式語言相關的安裝工具,例如 APT 和 pip; 3) 其它系統。下麵展示了基於通用 shell 命令的容器構建場景,其中只需要使用 make 命令即可為容器安裝可執行檔案。

  1. # 拉取基礎映象, 類似 Dockerfile 中的 FROM 命令

  2. buildah from redhat

  3. # 掛載基礎映象, 在其基礎上工作

  4. crt=$(buildah mount)

  5. ap foo $crt

  6. make install DESTDIR=$crt

  7. # 下一步,生成快照

  8. buildah commit

有趣的是,基於這個思路,你可以復用主機環境中的構建工具,無需在映象中安裝這些依賴,故可以構建非常微小的映象。通常情況下,構建容器映象時需要在容器中安裝標的應用的構建依賴。例如,從原始碼構建需要容器中有編譯器工具鏈,這是因為構建並不在主機環境進行。大量的容器也包含了 ps 和 bash 這樣的 Unix 命令,對微容器而言其實是多餘的。開發者經常忘記或無法從構建好的容器中移除一些依賴,增加了不必要的開銷和攻擊面。

Buildah 的模組化方案能夠以非 root 方式進行部分構建;但mount 命令仍然需要 CAP_SYS_ADMIN,有一個 工單[19] 試圖解決該問題。但 Buildah 與 Docker 都有[20]同樣的限制[21],即無法在容器內構建容器。對於 Docker,你需要使用“特權”樣式執行容器,一些特殊的環境很難滿足這個條件,例如 GitLab 持續整合[22];即使滿足該條件,配置也特別繁瑣[23]

手動提交的步驟可以對建立容器快照的時間節點進行細粒度控制。Dockerfile 每一行都會建立一個新的快照;相比而言,Buildah 的提交檢查點都是事先選擇好的,這可以減少不必要的快照並節省磁碟空間。這也有利於隔離私鑰或密碼等敏感資訊,避免其出現在公共映象中。

Docker 構建的映象是非標準的、僅供其自身使用;相比而言,Buildah 提供多種輸出格式[24],其中包括符合 OCI 標準的映象。為向後相容,Buildah 提供了一個“使用 Dockerfile 構建”的命令,即 buildah bud[25], 它可以解析標準的 Dockerfile。Buildah 提供 enter 命令直接檢視映象內部資訊,run 命令啟動一個容器。實現這些功能僅使用了 runc 在內的標準工具,無需在後臺執行一個“臃腫的守護行程”。

Ducy 對 Buildah 表示質疑,認為採用非宣告性不利於可重現性。如果允許使用 shell 命令,可能產生很多預想不到的情況;例如,一個 shell 指令碼下載了任意的可執行程式,但後續無法追溯檔案的來源。shell 命令的執行受環境變數影響,執行結果可能大相徑庭。與基於 shell 的工具相比,Puppet 或 Chef 這樣的配置管理系統在理論上更加可靠,因為它們的設計初衷就是收斂於最終配置;事實上,可以透過配置管理系統呼叫 shell 命令。但 Walsh 對此提出反駁,認為已有的配置管理工具可以在 Buildah 的基礎上工作,使用者可以選擇是否使用配置管理;這樣更加符合“機制與策略分離”的經典 Unix 哲學。

目前 Buildah 處於測試階段,Red Hat 公司正努力將其整合到 OpenShift。我寫這篇文章時已經測試過 Buildah,它缺少一些檔案,但基本可以穩定執行。儘管在錯誤處理方面仍有待提高,但它確實是一款值得你關註的容器工具。

替換其它 Docker 命令列

Walsh 在其演講中還簡單介紹了 Red hat 公司 正在開發的另一個暫時叫做 libpod[23] 的專案。專案名稱來源於 Kubernetes 中的 “pod”, 在 Kubernetes 中 “pod” 用於分組主機內的容器,分享名字空間等。

Libpod 提供 kpod 命令,用於直接檢查和操作容器儲存。Walsh 分析了該命令發揮作用的場景,例如 dockerd 停止響應或 Kubernetes 叢集崩潰。基本上,kpod 獨立地再次實現了 docker 命令列工具。kpod ps 傳回執行中的容器串列,kpod images 傳回映象串列。事實上,命令轉換速查手冊[26] 中給出了每一條 Docker 命令對應的 kpod 命令。

這種模組化實現的一個好處是,當你使用 kpod run 執行容器時,容器直接作為當前 shell 而不是 dockerd 的子行程啟動。理論上,可以直接使用 systemd 啟動容器,這樣可以消除 dockerd 引入的冗餘。這讓由套接字啟用的容器[27]成為可能,但暫時基於 Docker 實現該特性並不容易[28]即使藉助 Kubernetes[29] 也是如此。但我在測試過程中發現,使用 kpod 啟動的容器有一些基礎功能性缺失,具體而言是網路功能(!),相關實現在活躍開發[30]過程中。

我們最後提到的命令是 push。雖然上述命令已經足以滿足本地使用容器的需求,但沒有提到遠端倉庫,藉助遠端倉庫開發者可以活躍地進行應用打包協作。倉庫也是持續部署框架的核心元件。skopeo[31] 專案用於填補這個空白,它是另一個 Atomic 成員專案,按其 README 檔案描述,“包含容器映象及映象庫的多種操作”。該專案的設計初衷是,在不用類似 docker pull 那樣實際去下載可能體積龐大的映象的前提下,檢查容器映象的內容。Docker 拒絕加入[32] 檢查功能,建議透過一個額外的工具實現該功能,這促成了 Skopeo 專案。除了 pullpush,Skopeo 現在還可以完成很多其它操作,例如在,不產生本地副本的情況下將映象在不同的倉庫中複製和轉換。由於部分功能比較基礎,可供其它專案使用,目前很大一部分 Skopeo 程式碼位於一個叫做 containers/image[33] 的基礎庫。Pivotal[34]、 Google 的 container-diff[35] 、kpod push 及 buildah push 都使用了該庫。

kpod 與 Kubernetes 並沒有緊密的聯絡,故未來可能會更換名稱(事實上,在本文刊發過程中,已經更名為 podman[36]),畢竟 Red Hat 法務部門還沒有明確其名稱。該團隊希望實現更多 pod 級別的命令,這樣可以對多個容器進行操作,有點類似於 docker compose[37]實現的功能。但在這方面,Kompose[38] 是更好的工具,可以透過 複合 YAML 檔案[39] 在 Kubernetes 叢集中執行容器。按計劃,我們不會實現類似於 [swarm] 的 Docker 命令,這部分功能最好由 Kubernetes 本身完成。

目前看來,已經持續數年的 Docker 模組化努力終將碩果纍纍。但目前 kpod 處於快速迭代過程中,不太適合用於生產環境,不過那些工具的與眾不同的設計理念讓人很感興趣,而且其中大部分的工具已經可以用於開發環境。目前只能透過編譯原始碼的方式安裝 libpod,但最終會提供各個發行版的二進位制包。

本文最初發表[40]於 Linux Weekly News[41]


via: https://anarc.at/blog/2017-12-20-docker-without-docker/

作者:Anarcat[43] 譯者:pinewall 校對:wxy

本文由 LCTT 原創編譯,Linux中國 榮譽推出

贊(0)

分享創造快樂

© 2024 知識星球   網站地圖