部署到 Kubernetes 的第一步是將應用程式放入容器中。 在本系列中，我們將了解如何建立小型、安全的容器映像。
感謝 Docker，建立容器映像從未如此簡單。 指定基本映像、新增變更並建立容器。
雖然這種技術非常適合入門，但使用預設基礎映像可能會導致使用充滿漏洞的大型映像進行不安全的工作。
此外，Docker 中的大多數映像都使用Debian 或Ubuntu 作為基礎映像，雖然這提供了出色的兼容性和輕鬆的自訂（Docker 檔案只需要兩行程式碼），但基礎映像可以為容器添加數百兆位元組的額外負載。 例如，Go“hello-world”應用程式的簡單 node.js 檔案大約有 700 MB，而您的實際應用程式大小只有幾兆位元組。
因此，所有這些額外的工作量都是對數位空間的浪費，也是安全漏洞和錯誤的絕佳藏身之處。 那麼讓我們來看看兩種減少容器鏡像大小的方法。
第一個是使用小型基礎映像，第二個是使用建構器模式。 使用較小的基礎鏡像可能是減少容器大小的最簡單方法。 最有可能的是，您使用的語言或堆疊提供了比預設圖像小得多的原始應用程式圖像。 讓我們來看看我們的node.js 容器。
預設情況下，在 Docker 中，node:8 基礎映像大小為 670 MB，而 node:8-alpine 映像大小僅為 65 MB，即小了 10 倍。 透過使用較小的 Alpine 基礎鏡像，您將顯著減少容器的大小。 Alpine 是一個小型輕量級的 Linux 發行版，在 Docker 用戶中非常受歡迎，因為它兼容許多應用程序，同時保持容器較小。 與標準 Docker“node”映像不同，“node:alpine”刪除了大量服務檔案和程序，只留下那些足以運行應用程式的檔案和程式。
要遷移到較小的基礎映像，只需更新 Dockerfile 即可開始使用新的基礎映像：
現在，與舊的 onbuild 映像不同，您需要將程式碼複製到容器中並安裝任何依賴項。 在新的 Dockerfile 中，容器以 node:alpine 映像啟動，然後為程式碼建立目錄，使用 NPM 套件管理器安裝依賴項，最後執行 server.js。
此升級使容器的尺寸縮小了 10 倍。 如果您的程式語言或堆疊沒有基本映像縮減功能，請使用 Alpine Linux。 它還將提供完全管理容器內容的能力。 使用小型基礎鏡像是快速建立小型容器的好方法。 但使用建構器模式可以實現更大的減少。
在解釋型語言中，原始碼首先傳遞給解釋器，然後直接執行。 在編譯語言中，原始碼首先被轉換為編譯程式碼。 然而，編譯經常使用運行程式碼實際上不需要的工具。 這意味著您可以從最終容器中完全刪除這些工具。 您可以為此使用建構器模式。
程式碼在第一個容器中創建並編譯。 然後將編譯後的程式碼打包到最終容器中，而無需編譯該程式碼所需的編譯器和工具。 讓我們透過這個過程來運行一個 Go 應用程式。 首先，我們將從 onbuild 映像轉移到 Alpine Linux。
在新的 Dockerfile 中，容器以 golang:alpine 映像開頭。 然後，它為程式碼建立一個目錄，將其複製到原始程式碼中，建立該原始程式碼，然後運行應用程式。 這個容器比 onbuild 容器小得多，但它仍然包含我們實際上不需要的編譯器和其他 Go 工具。 因此，讓我們提取編譯後的程式並將其放入自己的容器中。
您可能會注意到這個 Docker 檔案中有些奇怪的地方：它包含兩個 FROM 行。 前 4 行部分看起來與先前的 Dockerfile 完全相同，只是它使用 AS 關鍵字來命名此階段。 下一部分有一個新的 FROM 行來啟動新鏡像，我們將使用 Raw alpine 作為基礎鏡像，而不是 golang:alpine 鏡像。
Raw Alpine Linux 沒有安裝任何 SSL 證書，這將導致大多數透過 HTTPS 的 API 呼叫失敗，所以讓我們安裝一些根 CA 憑證。
現在有趣的部分來了：要將編譯後的程式碼從第一個容器複製到第二個容器，您只需使用第二部分第 5 行的 COPY 命令。 它只會複製一個應用程式文件，不會影響 Go 實用工具。 新的多階段 Docker 檔案將包含一個大小僅為 12 MB 的容器映像，與原始容器映像的 700 MB 相比，這是一個很大的區別！
因此，使用小型基礎鏡像和建構器模式是無需大量工作即可創建更小容器的好方法。
根據應用程式堆疊的不同，可能還有其他方法可以減少映像和容器的大小，但是小型容器真的有可衡量的好處嗎？ 讓我們來看看小型容器非常有效的兩個領域——效能和安全性。
若要評估效能提升，請考慮建立容器、將其插入登錄機碼（推送）、然後從登錄機碼擷取（拉取）的流程的持續時間。 您可以看到較小的容器比較大的容器有明顯的優勢。
Docker 將快取這些層，因此後續建置將非常快速。 然而，許多用於建置和測試容器的 CI 系統不緩存層，因此可以節省大量時間。 正如您所看到的，根據機器的能力，建造大型容器的時間為 34 到 54 秒，而使用建構器模式減少的容器時間為 23 到 28 秒。 對於此類操作，生產率將提高 40-50%。 因此，請考慮您建立和測試程式碼的次數。
容器建置完成後，您需要將其鏡像（推送容器映像）推送到容器註冊表中，以便您可以在 Kubernetes 叢集中使用它。 我建議使用 Google 容器註冊表。
使用 Google 容器註冊表 (GCR)，您只需支付原始儲存和網路費用，並且無需額外的容器管理費。 它是私密、安全且速度非常快的。 GCR 使用許多技巧來加速拉動操作。 如您所看到的，使用go:onbuild 插入Docker 容器映像容器將需要15 到48 秒，具體取決於電腦效能，而使用較小的容器執行相同的操作將需要14 到16 秒，對於生產力較低的機器運轉速度優勢提升3倍。 對於較大的機器，時間大致相同，因為 GCR 對共享圖像資料庫使用全域緩存，這意味著您根本不需要加載它們。 在低功耗計算機中，CPU 是瓶頸，因此使用小型容器的優勢在這裡更大。
如果您使用 GCR，我強烈建議您使用 Google Container Builder (GCB) 作為建置系統的一部分。
正如您所看到的，它的使用可以讓您在減少Build+Push 操作的持續時間方面取得比生產機器更好的結果- 在這種情況下，構建容器並將其發送到主機的過程加速了近2 倍。 另外，您每天還可以獲得 120 分鐘的免費建置時間，這可以滿足大多數情況下您的容器建置需求。
接下來是最重要的效能指標－檢索或下載拉取容器的速度。 而如果你不太在乎推播操作所花費的時間，那麼拉取過程的長度會對整個系統效能產生嚴重影響。 假設您有一個由三個節點組成的集群，其中一個出現故障。 如果您使用的是 Google Kubernetes Engine 等管理系統，它會自動以新節點取代失效節點。 但是，這個新節點將完全是空的，您必須將所有容器拖曳到其中才能開始工作。 如果拉取操作花費的時間足夠長，您的叢集將始終以較低的效能運作。
有很多情況會發生這種情況：向叢集新增節點、升級節點，甚至切換到新容器進行部署。 因此，最大限度地減少拉拔時間成為關鍵因素。 不可否認的是，小容器的下載速度比大容器快得多。 如果您在 Kubernetes 叢集中執行多個容器，則可以節省大量時間。
看看這個比較：與使用 go:onbuild 執行相同的操作相比，對小型容器進行拉取操作所需的時間要少 4-9 倍，具體取決於機器的功率。 使用共用的小型容器基礎映像可以顯著加快新 Kubernetes 節點部署和上線的時間和速度。
我們來看看安全問題。 較小的容器被認為比較大的容器安全得多，因為它們的攻擊面較小。 是不是真的？ Google 容器註冊表最有用的功能之一是能夠自動掃描容器是否有漏洞。 幾個月前，我創建了 onbuild 和 multistage 容器，所以讓我們看看那裡是否有任何漏洞。
結果令人驚訝：在一個小容器中僅偵測到 3 個中等漏洞，而在一個大型容器中發現了 16 個嚴重漏洞和 376 個其他漏洞。 如果我們查看一個大容器的內容，我們可以看到大多數安全問題與我們的應用程式無關，而是與我們甚至不使用的程式有關。 因此，當人們談論大型攻擊面時，他們就是這個意思。
要點很明確：建立小型容器，因為它們為您的系統提供真正的效能和安全優勢。
一些廣告🙂
感謝您與我們在一起。 你喜歡我們的文章嗎？ 想看更多有趣的內容？ 通過下訂單或推薦給朋友來支持我們， , 我們為您發明的入門級服務器的獨特模擬： （適用於 RAID1 和 RAID10，最多 24 個內核和最多 40GB DDR4）。
Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 數據中心便宜 2 倍？ 只有這裡 在荷蘭！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 閱讀
來源： www.habr.com