作者：安樹博 青云科技 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
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/502168.html
標籤：其他
上一篇：用HTTP服務的方式集成 learned cardinality estimate 方法進 Postgresql
下一篇：用HTTP服務的方式集成 learned cardinality estimate 方法進 Postgresql