作者：安樹博 青雲科技 PaaS 中間件開發工程師 從事 PaaS 中間件服務（Redis/Memcached 等）開發工作，熱衷對 NoSQL 資料庫領域內技術的學習與研究 官方鏡像版本無法滿足功能需求 鏡像記憶體在的漏洞無法規避 傳統構建方式鏡像體積越來越大 你在使用鏡像時是否遇到過以上問題呢？ ...
作者：安樹博 青雲科技 PaaS 中間件開發工程師
從事 PaaS 中間件服務（Redis/Memcached 等）開發工作，熱衷對 NoSQL 資料庫領域內技術的學習與研究
- 官方鏡像版本無法滿足功能需求
- 鏡像記憶體在的漏洞無法規避
- 傳統構建方式鏡像體積越來越大
你在使用鏡像時是否遇到過以上問題呢？
隨著雲原生技術的普及，業務負載上容器就越來越普遍。很多企業已經碰到，或正在解決以上這些容器鏡像的問題。隨著雲原生業務覆蓋範圍越來越大、越來越貼近業務核心，對於鏡像安全和可維護等要求也越來越高。
那麼構建鏡像的方式如何選型就需要根據應用的具體情況來做判斷。本文將對目前常見的幾種鏡像構建方式進行分析，幫您判斷。
主流鏡像構建方式
傳統鏡像
不特指某一鏡像，本文中代指 Debian/Centos/Ubuntu 等系統下構建的鏡像，對於 C/C++ 編寫的複雜程式，這是最常用的一種構建方式。
Alpine[1]
Alpine 操作系統是一個面向安全的輕型 Linux 發行版。通過 Alpine 構建的鏡像容量非常小，通常 5 MB 左右，包管理機制友好。具有下載速度快，安全性提高等優點。
Distroless[2]
源自於 Google 的鏡像，比 Alpine 更精簡。除了基礎文件其它都不包含，甚至沒有 Shell。大多數 Operator 都是基於此系列基礎鏡像編譯。
選型對比
以 Redis 基礎鏡像構建為例，將三種構建方式在漏洞修複、Shell 支持、C 庫、鏡像體積等方面進行對比。
| Alpine | Distroless | 傳統鏡像 | 備註 | |
|---|---|---|---|---|
| 漏洞修複 | 快 | 極快 | 一般 | Debian 11 更新到最新 cve 漏洞還有 80 多個，Alpine 和 Distroless 最新版全部修複。 |
| Shell | sh | 無 | bash | Distroless 沒有 Shell 也就沒辦法進入鏡像去管理和後期維護。 |
| C 庫 | musl | 可選 | glibc | Alpine 的 C 庫是 musl，雖然理論上和 glibc 差異不大, 但 C/C++ 程式在此編譯可能會有不同，要進行充分測試。 |
| 鏡像體積 | 約 5MB | 約 2MB | 30MB - 500MB | |
| 包管理器 | apk | 無 | apt/yum | Alpine 的 apk 包管理器包含軟體較少, 只有 1000 多個，且都是精簡版，但覆蓋了常用軟體。 Distroless 沒有管理器，需要自己找依賴文件拷貝到鏡像里。 傳統鏡像 apt/yum 軟體豐富，但比較臃腫。 |
選型決策樹
根據上面總結的三種方式的異同，再根據用戶需求抽象成選型決策樹，可根據判斷做出相應的構建方式。
選型總結
- 如果需要進入鏡像管理維護（Shell 工具），不推薦 Distroless 構建；
- 如果需要考慮跨平臺並減少非必要依賴庫，推薦 Alpine 或 Distroless 構建；
- 如果原應用是基於 C/C++ 編寫且很複雜，建議使用傳統鏡像；
- 如果基於 Go 編寫，傳統鏡像可以排除。
下一期，我們將演示如何使用 Alpine 構建一個 Redis 鏡像，盡情期待！
參考引用
- Alpine www.alpinelinux.org
- Distroless https://github.com/GoogleContainerTools/distroless
