[[170908]]

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

我大約在三年半前開展基于鏡像的容器相關工作。到目前為止，我已經容器化了大量應用。我了解到什么是現實情況，什么是迷信。今天，我想簡要介紹一下 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 會讓容器生態系統圍繞著鏡像掃描、簽名，和在不同云服務提供商間轉移而繁榮發展。

現在談到簽名了。

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

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