Docker 於日前釋出了 29.3.0 版本，本次更新在 API 信任驗證、CLI 擴充性、AMD GPU 硬體加速支援，以及系統底層的穩定性上，都帶來了對開發者與維運團隊相當實用的改進。
CyberQ 實測後，也認為由於近期 AMD GPU 應用在 AI 工作流與相關應用上逐漸有被提高比重的趨勢，Docker 適時地更新有助於 AMD GPU 裝置的部署，同時，也為新型 AI 算力鋪路。
CDI 規範對 GPU 調度的 4 大深遠影響
打破廠商壁壘，實現硬體中立 (Vendor Agnostic)
過去，Docker 必須「認識」NVIDIA 或 AMD GPU 才能正確調度它們。而透過 CDI，硬體廠商只需在主機上生成一份標準的 JSON 描述檔（通常位於 /etc/cdi/ 目錄下）。
當 Docker 29.3.0 宣佈透過 CDI 支援 AMD GPU 時，意味著 Docker 核心程式碼不需要寫死任何針對 AMD 的特殊邏輯；它只需要看得懂 CDI 規範。這讓異質運算環境（例如同一叢集內混搭 NVIDIA GPU、AMD GPU 或其他 AI 專用晶片）的統一調度成為可能。
大幅簡化 Kubernetes 的基礎設施維護
在 K8s 叢集中，調度 GPU 依賴 Device Plugin。
過去： Plugin 需要處理複雜的掛載邏輯、環境變數注入，甚至要在執行時修改容器的 Spec。這不僅容易出錯，維護成本也極高。
現在： K8s Device Plugin 只需要向 Kubelet 回報一個簡單的設備名稱字串（例如：vendor.com/gpu=all）。Kubelet 將這個字串交給底層的 Runtime，Runtime 再去查閱對應的 CDI JSON 檔，自動完成所有底層的掛載與設定。
提升資安合規與系統隔離性
從資安防禦與合規的角度來看，CDI 是一大進展。以往為了讓容器能存取 GPU 驅動程式，開發團隊常常為了方便而給予容器過高的權限，或是大範圍地 Bind Mount 主機的系統目錄。
CDI 規範允許以聲明式（Declarative）的方法精確定義：
Device Nodes： 僅注入所需的 /dev/nvidia0，而非開放整個 /dev。
動態函式庫： 僅掛載模型推論或訓練絕對需要的 .so 檔案。
生命週期 Hooks： 僅在容器啟動的特定階段執行必要的初始化腳本。
這種最小權限原則 (Least Privilege) 的實作，大幅減少了容器逃逸的攻擊面，在進行資安合規審查時也能提供明確的存取控制軌跡。
為新型 AI 算力鋪路
隨著 AI 發展，專用加速晶片（如 TPU、NPU）如雨後春筍般出現。CDI 提供了一個通用的「隨插即用」介面。新硬體廠商只要釋出符合 CDI 規範的設定產生器，就能立刻無縫接入現有的容器生態系，不需要等待上游開源社群花數個月時間去審查與整合專屬程式碼。
總結來說，CDI 把硬體注入的髒活從「動態的容器執行時期」轉移到了「標準化的靜態設定檔」。它不僅解決了過去幾年的歷史共業，更為接下來 AI 算力多樣化的時代，鋪好了一條安全且易於管理的基礎設施高速公路。
以下則是我們覺得本次 Docker 29.3.0 值得一提的其他重點：
強化軟體供應鏈安全與 API 驗證
對於重視 DevSecOps 與合規性的團隊，這次在 API 層面的更新提供了更透明的映像檔來源追蹤：
映像檔身分驗證支援：GET /images/json 端點現在支援 identity 查詢參數。啟用後，回應內容將包含 manifest 摘要，並為每個 manifest 提供受信任的來源與身分資訊（Identity field）。這項改進將有助於自動化稽核與防範軟體供應鏈攻擊。
網路 MAC 位址修正：POST /networks/{id}/connect API 現在能正確套用 EndpointSettings 中的 MacAddress 欄位（此欄位雖在 API v1.44 就已加入，但先前被系統忽略），讓網路存取控制更加精確。
憑證儲存細節修正：在儲存 Registry 密碼時，現在會完整保留開頭與結尾的空白字元，避免因特殊密碼格式導致的驗證失敗問題。
AI 開發與底層硬體支援
隨著 AI 工具與模型的蓬勃發展，容器化環境對 GPU 的調度需求日益增加：
AMD GPU 的 CDI 注入機制：–gpus 選項現在針對 AMD GPU 全面採用基於 CDI (Container Device Interface) 的注入方式。這項標準化更新能讓 AI 模型訓練與推論的硬體直通設定更加穩定且易於管理。
CLI 工具與開發者體驗升級
為了讓日常開發與除錯更順暢，CLI 與掛載機制也進行了最佳化：
更彈性的 Bind Mounts：在 –mount 標籤中新增了 bind-create-src 選項，提供更細緻的掛載行為控制。
智慧化的 Plugin 錯誤提示：Plugin Hooks 的觸發機制升級，現在不僅在指令成功時觸發，在指令失敗時也會執行。開發者可以利用全新的 error-hooks 在錯誤發生時提供針對性的除錯建議與提示。
向下相容性提升：最低支援的 API 版本要求從 v1.44 降至 v1.40（等同於 Docker 19.03），大幅減少了在舊版環境中操作的阻力。
系統穩定性與網路修復
在 Daemon 運作與系統整合方面，修復了多個問題：
DNS 設定保護：修復了 Daemon 重新載入（reload）時可能導致 DNS 設定損毀的問題。
Systemd 整合最佳化：新增對 systemd 253 Type=notify-reload 協定的支援，並在 Daemon 重新載入設定時加入 sd_notify “RELOADING” 通知。此外，READY 與 STOPPING 訊號現在改為同步發送，確保系統狀態切換的可靠性。
並發操作 Bug 修復：解決了執行 docker system prune 時，若恰好有容器被移除會導致「rw layer snapshot not found」錯誤的問題。
套件升級：核心元件 BuildKit 升級至 v0.28.0，Go 執行環境升級至 1.25.7 版本。
CYberQ 認為，總結來說，Docker 29.3.0 在確保系統穩定運作的前提下，進一步補足了映像檔溯源的需求，並透過 CDI 標準化了 AMD GPU 的使用體驗。建議有使用到相關 API 或在容器中執行 AI 運算任務的團隊，可以安排時程進行升級測試。
完整更新細節與 Pull Requests 列表，可參考 GitHub 上的 docker/cli 與 moby/moby 29.3.0 milestone。
