Distroless Image 牛刀小試

距離上次重度探討「極簡化容器」已經快六年多了¹。這議題，以前可能只是某些人技術上的興趣，現在則可能是必要。

原因是：Docker Inc 的一些措施，讓人不得不慎重考慮替代方案。

搬家的必要

這陣子容器世界起了不少變化，除了眾所周知的「Docker Desktop 要收費了」規定 ²，另一個較少被提及影響是 Docker Hub 的緊縮政策：

• Image CI 緊縮：Docker Hub 取消免費用戶的 automated builds 功能。 ³
• Image pull 緊縮：Docker Hub 開始對未付費者施以較嚴格的限流措施。 ⁴

於是，未付費的人，不僅在使用 Docker Hub 時會受到管制，還會波及產製 image 的 CI pipeline，不時會遇到這樣的 “toomanyrequests” 限流警告：

要避開這限制，治標方法是：

• 架設 image proxy。 ⁵
• 註冊 Docker Hub 帳號，將帳密寫進 CI pipeline 裡，以獲得稍微寬鬆一點點的 rate limit 門檻。

治本方法，則得從兩方面著手：

1. Image 要從 Docker Hub 搬遷到 ghcr.io 之類的地方。
2. 直接引用的 base image(s) 也必須從 Docker Hub 換成 gcr.io 或 ghcr.io 之類的地方。

其中 (1) 很簡單，只要會 CI pipeline 即可辦到，像 GitHub Action 就有許多現成的元件可用。

至於 (2) 則比較麻煩。當然啦，對於玩過「極簡化容器」技術的人來說，這也只是小事一樁。

Distroless image

以前玩 minimal image 的人，是以 alpine 系列為大宗，只要不介意背後用的是 musl libc，這可以產生非常 “minimal” 的 image。近來 Google 的 “distroless” images 則提供 glibc 偏好者的另一種選擇，儘管它不算是 “minimal”，但也稱得上是 “small-enough”。

曾經我也是追求 minimal docker image 的一族 ¹，現在我只求 small-enough 就好。畢竟對大多數應用場景來說，像以下這兩個 image，一個約 8 MB，一個約 29 MB，差異其實是可以忽略不計的：

可是，若以資安角度來看，8.347 MB 的 image 被挑出許多漏洞，這很顛覆「alpine 又小又安全」的既定印象：

反觀 28.76 MB 的 image 卻比較安全，這也很顛覆「glibc 系列不安全」的既定印象：

因此，我會建議，對大多數應用程式來說，選擇 Google 的 distroless 路線，可以省下許多與 alpine 相容性搏鬥的精力，又可以享受到許多好處：

• 有 Google 在維護。
• Base image 的所在地 gcr.io 沒有限流問題。
• 透過 multi-stage builds 機制，沿用既有工具鏈即可輕鬆製作。

對於 distroless 感興趣的，請參考 “What’s Inside Of a Distroless Container Image: Taking a Deeper Look” 這篇文章。