淺談 Linux 容器和鏡像簽名

從根本上說，幾乎所有的主要軟體，即使是開源軟體，都是在基於鏡像的容器技術出現之前設計的。這意味著把軟體放到容器中相當於是一次平台移植。這也意味著一些程序可以很容易就遷移，而另一些就更困難。

我大約在三年半前開展基於鏡像的容器相關工作。到目前為止，我已經容器化了大量應用。我了解到什麼是現實情況，什麼是迷信。今天，我想簡要介紹一下 Linux 容器是如何設計的，以及談談鏡像簽名。

Linux 容器是如何設計的

對於基於鏡像的 Linux 容器，讓大多數人感到困惑的是，它把操作系統分割成兩個部分：內核空間與用戶空間。在傳統操作系統中，內核運行在硬體上，你無法直接與其交互。用戶空間才是你真正能交互的，這包括所有你可以通過文件瀏覽器或者運行ls命令能看到的文件、類庫、程序。當你使用ifconfig命令調整 IP 地址時，你實際上正在藉助用戶空間的程序來使內核根據 TCP 協議棧改變。這點經常讓沒有研究過 Linux/Unix 基礎的人大吃一驚。

過去，用戶空間中的類庫支持了與內核交互的程序（比如 ifconfig、sysctl、tuned-adm）以及如網路伺服器和資料庫之類的面向用戶的程序。這些所有的東西都堆積在一個單一的文件系統結構中。用戶可以在 /sbin 或者 /lib 文件夾中找到所有操作系統本身支持的程序和類庫，或者可以在 /usr/sbin 或 /usr/lib 文件夾中找到所有面向用戶的程序或類庫（參閱文件系統層次結構標準）。這個模型的問題在於操作系統程序和業務支持程序沒有絕對的隔離。/usr/bin 中的程序可能依賴 /lib 中的類庫。如果一個應用所有者需要改變一些東西，就很有可能破壞操作系統。相反地，如果負責安全更新的團隊需要改變一個類庫，就（常常）有可能破壞面向業務的應用。這真是一團糟。

藉助基於鏡像的容器，比如 Docker、LXD、RKT，應用程序所有者可以打包和調整所有放在 /sbin、/lib、/usr/bin 和 /usr/lib 中的依賴部分，而不用擔心破壞底層操作系統。本質上講，容器技術再次乾淨地將操作系統隔離為兩部分：內核空間與用戶空間。現在開發人員和運維人員可以分別獨立地更新各自的東西。

然而還是有些令人困擾的地方。通常，每個應用所有者（或開發者）並不想負責更新這些應用依賴：像 openssl、glibc，或很底層的基礎組件，比如，XML 解析器、JVM，再或者處理與性能相關的設置。過去，這些問題都委託給運維團隊來處理。由於我們在容器中打包了很多依賴，對於很多組織來講，對容器內的所有東西負責仍是個嚴峻的問題。

遷移現有應用到 Linux 容器

把應用放到容器中算得上是平台移植，我準備突出介紹究竟是什麼讓移植某些應用到容器當中這麼困難。

（通過容器，）開發者現在對 /sbin 、/lib、 /usr/bin、 /usr/lib 中的內容有完全的控制權。但是，他們面臨的挑戰是，他們仍需要將數據和配置放到 /etc 或者 /var/lib 文件夾中。對於基於鏡像的容器來說，這是一個糟糕的想法。我們真正需要的是代碼、配置以及數據的隔離。我們希望開發者把代碼放在容器當中，而數據和配置通過不同的環境（比如，開發、測試或生產環境）來獲得。

這意味著我們（或者說平台）在實例化容器時，需要掛載 /etc 或 /var/lib 中的一些文件或文件夾。這會允許我們到處移動容器並仍能從環境中獲得數據和配置。聽起來很酷吧？這裡有個問題，我們需要能夠乾淨地隔離配置和數據。很多現代開源軟體比如 Apache、MySQL、MongoDB、Nginx 默認就這麼做了。但很多自產的、歷史遺留的、或專有程序並未默認這麼設計。對於很多組織來講，這是主要的痛點。對於開發者來講的最佳實踐是，開始架構新的應用，移植遺留代碼，以完成配置和數據的完全隔離。

鏡像簽名簡介

信任機制是容器的重要議題。容器鏡像簽名允許用戶添加數字指紋到鏡像中。這個指紋隨後可被加密演算法測試驗證。這使得容器鏡像的用戶可以驗證其來源並信任。

容器社區經常使用「容器鏡像」這個片語，但這個命名方法會讓人相當困惑。Docker、LXD 和 RKT 推行獲取遠程文件來當作容器運行這樣的概念。這些技術各自通過不同的方式處理容器鏡像。LXD 用單獨的一層來獲取單獨一個容器，而 Docker 和 RKT 使用基於開放容器鏡像（OCI）格式，可由多層組成。糟糕的是，會出現不同團隊和組織對容器鏡像中的不同層負責的情況。容器鏡像概念下隱含的是容器鏡像格式的概念。擁有標準的鏡像格式比如 OCI 會讓容器生態系統圍繞著鏡像掃描、簽名，和在不同雲服務提供商間轉移而繁榮發展。

現在談到簽名了。

容器存在一個問題，我們把一堆代碼、二進位文件和類庫放入其中。一旦我們打包了代碼，我們就要把它和必要的文件伺服器（註冊伺服器）共享。代碼只要被共享，它基本上就是不具名的，缺少某種密文簽名。更糟糕的是，容器鏡像經常由不同人或團隊控制的各個鏡像層組成。每個團隊都需要能夠檢查上一個團隊的工作，增加他們自己的工作內容，並在上面添加他們自己的批准印記。然後他們需要繼續把工作交給下個團隊。

（由很多鏡像組成的）容器鏡像的最終用戶需要檢查監管鏈。他們需要驗證每個往其中添加文件的團隊的可信度。對於最終用戶而言，對容器鏡像中的每一層都有信心是極其重要的。

作者 Scott McCarty 於 8 月 24 日在 ContainerCon 會議上作了題為 Containers for Grownups: Migrating Traditional & Existing Applications 的報告，更多內容請參閱報告幻燈片。

via: https://opensource.com/bus/16/8/introduction-linux-containers-and-image-signing

作者：Scott McCarty 譯者：Tanete 校對：wxy

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

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive