從 Minimus 遷移到 Docker Hardened Images
Docker Blog · 2026-08-25
背景
Docker 於 2026 年 8 月 25 日發布遷移公告,說明硬化映像同業 Minimus 宣布停止營運,其 registry 將在 60 天緩衝期後、於 2026 年 10 月 22 日正式關閉。關閉後已拉取的映像仍可繼續運作,但不會再有新版本或 CVE 修補。對仍在生產環境使用 Minimus 映像的團隊,Docker 提出以 Docker Hardened Images(簡稱 DHI)接手作為主要遷移路徑。
核心改動
DHI 是 Docker 官方以原始碼建置並持續維護的硬化基底映像集合,目前收錄超過 4,000 個映像,提供與 Alpine、Debian 相容的變體。每個映像都隨附完整 SBOM、SLSA Build Level 3 出處證明與加密簽章,且不隱藏任何已知 CVE。Docker 表示相較一般公開映像,DHI 最多可減少 95% 的 CVE 數量、縮小 90% 的攻擊面。免費版以 Apache 2.0 授權開放、無使用者數上限並允許生產環境使用;付費層則加上 SLA 修補承諾、FIPS/STIG 變體、客製映像,以及 EOL 後最長五年的延伸支援。
影響範圍
對多數服務而言,遷移只需把 Dockerfile 裡的 FROM 行改指向 Docker Hub 上對應的 DHI 映像,不需大幅調整建置流程。Docker 提供的配套資源包括:
- DHI 目錄比對,用於在 Docker Hub 上找出對應映像
- 逐步遷移指南,列出每個步驟的細節
- 檢查清單,用於追蹤每個映像的替換與驗證進度
- 完整端到端遷移範例
- AI 助理
Gordon,可先跑出第一輪遷移草稿
對於仍在使用 Minimus 的客戶,Docker 另提供免費遷移協助(minimus@docker.com),涵蓋既有映像清單盤點與合規需求討論,不需先經過銷售流程。
懶惰工程師的自我觀測性指南
CNCF Blog · 2026-08-25
原本的問題
CNCF 部落格於 2026 年 8 月 25 日刊出這篇文章,指出多數開發者把埋點(instrumentation)當成額外負擔:程式碼變得雜亂、技術債增加,而觀測資料感覺是給 SRE 看的,對寫程式的人本身沒有直接好處。文章也點出各語言 SDK 成熟度不一、部分語言缺乏零程式碼埋點支援、工具選項過多、手動埋點語法繁瑣等實際痛點。
採用的方法
文章主張採用「以觀測性驅動開發」(observability-driven development):在寫新功能的同時就加入埋點,而不是事後回補。具體作法分四步:
- 先用
OpenTelemetry零程式碼埋點,涵蓋 Java、.NET、Python、JavaScript、PHP、Go,或用 eBPF 做語言無關的自動埋點 - 針對零程式碼埋點涵蓋不到的邏輯,再手動加入
code-based instrumentation - 在功能邏輯還新鮮時完成埋點,而非事後補
- 借助 AI 助理加速埋點程式碼撰寫,並用不同模型互相檢查結果
在 Kubernetes 環境下,零程式碼埋點可透過 OpenTelemetry Operator,將 .NET、Java、Node.js、Python 或 Go 的 agent 自動注入應用程式,不需修改原始碼即可產生 trace 與 metrics。
實際效果
文章示範以 OpenTelemetry Collector 接收 OTLP 資料,搭配 debug exporter 與 spanmetrics connector,直接從既有 trace 算出延遲相關指標,不需額外寫埋點程式碼就能得到效能數據。文中也整理了開發者可在本機直接檢視自己埋點資料的工具:只顯示 trace 的 OTel Desktop Viewer、涵蓋 trace/log/metric 與服務拓樸圖的 otel-tui,以及附儀表板的 OTel Front,都不需要先架設完整的觀測後端。
別想一次學完整套 Kubernetes
CNCF Blog · 2026-08-25
原本的問題
CNCF 部落格於 2026 年 8 月 25 日刊出Portainer 的 Joep Piscaer撰寫的文章,他自稱「戒斷中的 VMware 架構師」。他指出官方文件、認證考試、播客與部落格清單式教材,常讓初學者陷入零散知識點,卻始終拼不出 Kubernetes 的整體架構圖。他認為問題不在資訊不夠多,而是缺乏一套可以先建立起來的心智骨架。
採用的方法
Piscaer 主張先掌握五個核心概念,再往 GitOps、可觀測性、service mesh、policy engine 等專門主題延伸:
- 期望狀態與調和(desired state & reconciliation):Kubernetes 持續比對實際狀態與宣告狀態,自動修正差異,不需人工介入
- 控制平面與 worker node 架構:從 vSphere 式「珍惜每台機器」的思維,轉向把節點視為可拋棄資源
- 四層網路模型:依序理解 container-to-pod、pod-to-service、service-to-ingress、ingress-to-external 的連線路徑
- requests 與 limits 是存活契約:分辨 scheduler 排程用的參考值,與強制上限造成節流或被殺的差異
CNI/CSI插件架構:理解 Kubernetes 刻意不內建網路與儲存實作,而是定義標準介面
實際效果
依 Piscaer 的說法,把這五項基礎建立起來後,才足以應付真實世界的工作負載;GitOps、可觀測性、service mesh 與 policy engine 這類進階主題,應該等到遇到具體問題時再學,不必一開始就全盤攻略。CNI/CSI 的介面標準是同一套邏輯的延伸:Kubernetes 只定義「該建立什麼網路命名空間」「用什麼方式掛載儲存」這類規格,實際能力交給 Calico、Cilium、Flannel 或各雲端 CSI driver 各自實作,使叢集可依基礎設施更換方案,且不受限於 Kubernetes 核心版本更新週期。