導讀

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

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

Linux 容器是如何設計的

對于基于鏡像的 Linux 容器，讓大多數(shù)人感到困惑的是，它把操作系統(tǒng)分割成兩個部分：內(nèi)核空間與用戶空間。在傳統(tǒng)操作系統(tǒng)中，內(nèi)核運行在硬件上，你無法直接與其交互。用戶空間才是你真正能交互的，這包括所有你可以通過文件瀏覽器或者運行l(wèi)s命令能看到的文件、類庫、程序。當你使用ifconfig命令調(diào)整 IP 地址時，你實際上正在借助用戶空間的程序來使內(nèi)核根據(jù) TCP 協(xié)議棧改變。這點經(jīng)常讓沒有研究過 Linux/Unix 基礎的人大吃一驚。 過去，用戶空間中的類庫支持了與內(nèi)核交互的程序(比如 ifconfig、sysctl、tuned-adm)以及如網(wǎng)絡服務器和數(shù)據(jù)庫之類的面向用戶的程序。這些所有的東西都堆積在一個單一的文件系統(tǒng)結構中。用戶可以在 /sbin 或者 /lib 文件夾中找到所有操作系統(tǒng)本身支持的程序和類庫，或者可以在 /usr/sbin 或 /usr/lib 文件夾中找到所有面向用戶的程序或類庫(參閱文件系統(tǒng)層次結構標準)。這個模型的問題在于操作系統(tǒng)程序和業(yè)務支持程序沒有絕對的隔離。/usr/bin 中的程序可能依賴 /lib 中的類庫。如果一個應用所有者需要改變一些東西，就很有可能破壞操作系統(tǒng)。相反地，如果負責安全更新的團隊需要改變一個類庫，就(常常)有可能破壞面向業(yè)務的應用。這真是一團糟。 借助基于鏡像的容器，比如 Docker、LXD、RKT，應用程序所有者可以打包和調(diào)整所有放在 /sbin、/lib、/usr/bin 和 /usr/lib 中的依賴部分，而不用擔心破壞底層操作系統(tǒng)。本質(zhì)上講，容器技術再次干凈地將操作系統(tǒng)隔離為兩部分：內(nèi)核空間與用戶空間?，F(xiàn)在開發(fā)人員和運維人員可以分別獨立地更新各自的東西。

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

遷移現(xiàn)有應用到 Linux 容器

把應用放到容器中算得上是平臺移植，我準備突出介紹究竟是什么讓移植某些應用到容器當中這么困難。 (通過容器，)開發(fā)者現(xiàn)在對 /sbin 、/lib、 /usr/bin、 /usr/lib 中的內(nèi)容有完全的控制權。但是，他們面臨的挑戰(zhàn)是，他們?nèi)孕枰獙?shù)據(jù)和配置放到 /etc 或者 /var/lib 文件夾中。對于基于鏡像的容器來說，這是一個糟糕的想法。我們真正需要的是代碼、配置以及數(shù)據(jù)的隔離。我們希望開發(fā)者把代碼放在容器當中，而數(shù)據(jù)和配置通過不同的環(huán)境(比如，開發(fā)、測試或生產(chǎn)環(huán)境)來獲得。 這意味著我們(或者說平臺)在實例化容器時，需要掛載 /etc 或 /var/lib 中的一些文件或文件夾。這會允許我們到處移動容器并仍能從環(huán)境中獲得數(shù)據(jù)和配置。聽起來很酷吧?這里有個問題，我們需要能夠干凈地隔離配置和數(shù)據(jù)。很多現(xiàn)代開源軟件比如 Apache、MySQL、MongoDB、Nginx 默認就這么做了。但很多自產(chǎn)的、歷史遺留的、或專有程序并未默認這么設計。對于很多組織來講，這是主要的痛點。對于開發(fā)者來講的最佳實踐是，開始架構新的應用，移植遺留代碼，以完成配置和數(shù)據(jù)的完全隔離。

鏡像簽名簡介

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

容器社區(qū)經(jīng)常使用“容器鏡像”這個詞組，但這個命名方法會讓人相當困惑。Docker、LXD 和 RKT 推行獲取遠程文件來當作容器運行這樣的概念。這些技術各自通過不同的方式處理容器鏡像。LXD 用單獨的一層來獲取單獨一個容器，而 Docker 和 RKT 使用基于開放容器鏡像(OCI)格式，可由多層組成。糟糕的是，會出現(xiàn)不同團隊和組織對容器鏡像中的不同層負責的情況。容器鏡像概念下隱含的是容器鏡像格式的概念。擁有標準的鏡像格式比如 OCI 會讓容器生態(tài)系統(tǒng)圍繞著鏡像掃描、簽名，和在不同云服務提供商間轉移而繁榮發(fā)展。 現(xiàn)在談到簽名了。 容器存在一個問題，我們把一堆代碼、二進制文件和類庫放入其中。一旦我們打包了代碼，我們就要把它和必要的文件服務器(注冊服務器)共享。代碼只要被共享，它基本上就是不具名的，缺少某種密文簽名。更糟糕的是，容器鏡像經(jīng)常由不同人或團隊控制的各個鏡像層組成。每個團隊都需要能夠檢查上一個團隊的工作，增加他們自己的工作內(nèi)容，并在上面添加他們自己的批準印記。然后他們需要繼續(xù)把工作交給下個團隊。 (由很多鏡像組成的)容器鏡像的最終用戶需要檢查監(jiān)管鏈。他們需要驗證每個往其中添加文件的團隊的可信度。對于最終用戶而言，對容器鏡像中的每一層都有信心是極其重要的。

總結

以上是生活随笔為你收集整理的linux代码签名,浅谈Linux容器和镜像签名(示例代码)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。