一份如何選取 Linux 容器鏡像的 對比報告 闡述了鏡像選取中的一些最佳實踐。報告中涉及了架構、安全和性能等因素，此外，商業(yè)用戶還需要考慮廠商的支持情況。
　　Linux 容器提供了對內核空間和用戶空間組件的獨立管理，這是是通過使用 cgroups 和 命名空間 （Namespace）等資源及進程隔離機制實現的。雖然 Solaris 和 BSD 也提供了與 Linux 容器技術類似的 抽象機制 ，但此份對比報告只聚焦于 Linux 容器技術。運行容器的主機提供了運行容器所需的操作系統(tǒng)內核和一系列工具。另一方面，容器鏡像提供了運行分布在容器間的應用所需的軟件庫、解釋器和應用代碼。所有這些都依賴于底層系統(tǒng)庫。對于解釋性語言也同樣適用，因為解釋器本身也是使用底層語言編寫的。
　　第一個原則是容器鏡像的大小。各容器鏡像在磁盤上的大小不等，從 Fedora 這樣的 230MB 大小，到 Alpine Linux 這樣的 4MB 大小。但是在選取一個鏡像發(fā)布版時，鏡像的大小并非 唯一應該考慮的問題 。鏡像的主要分組包括 Debian/Ubuntu、RHEL、Centos、Fedora 和 Alpine。
　　第二個原則是容器中的安全漏洞問題。該問題已成為 很多報告 的主題。根據 一份最新的研究 ，Docker Hub 上的公開 Debian 容器鏡像所具有的漏洞最少，而 Ubuntu 鏡像的漏洞最多。該研究僅涉及了哪些公開的 Docker 鏡像。一些工具也提供了不同程度的防護和功能，例如 Clair 和 vuls 這樣的開源工具，以及 Twistlock 等這類商業(yè)工具。很多軟件廠商已實現對發(fā)布版及 Web 服務器和數據庫這樣的通用軟件中的未知漏洞的 自動測試 。一些開源 工作 也致力于減緩或最小化容器漏洞，兩者都會對主機和容器間的相互通信產生影響（參見該 幻燈片 的第 7-9 頁）。
　　第三個原則是鏡像中的軟件包情況。glibc 等核心庫和軟件包格式會對容器的安全和性能產生影響。一些成熟的軟件庫，例如 glibc 和 gcc，具有很大規(guī)模的用戶社區(qū)，并已經被穩(wěn)健地使用多年。這也是容器鏡像使用這些軟件庫的首要原因。但是 Alpine 等一些發(fā)布版堅持另辟蹊徑，這 已經導致 了一些 問題 。
　　除了上述三個原則，企業(yè)用戶還需要考慮鏡像的生命周期和產品支持因素。RHEL 和 Ubuntu 給出了一些商業(yè)支持選項，它們通過論壇對各種用戶提供社區(qū)支持。Ubuntu 和 RHEL 引領了生命周期范圍的管理，即一個發(fā)布版本得到支持的時間范圍，在此期間將提供軟件缺陷修復、補丁與特性的向后移植（Backporting）及支持。
　　報告給出的結論是，容器鏡像的選擇類似于選擇 Linux 發(fā)布版。為此，Google 的“ Distroless ”鏡像給出了一種非常有意思的拆分方式。Distroless 僅是一個提供各種應用及其運行時依賴的鏡像，并不包含哪些在任一 Linux 發(fā)布版中通常都會包含的程序，例如 Shell 和軟件包管理等。
?