Docker 29 已針對全新安裝更改其預設映像檔儲存庫

背景

Docker 官方宣布從 Engine 29.0 版本開始，針對全新安裝的環境將預設儲存後端從傳統的 graph drivers（如 overlay2）切換為 containerd 映像檔儲存庫。這項轉變意味著 Docker 將採用業界標準的 snapshotters 技術來管理映像檔層級，雖然對於大多數使用者的工作流程是透明的，但在底層架構與磁碟空間管理上帶來了顯著的變化。

社群觀點

這項技術變革在 Hacker News 社群引發了激烈的討論，其中最受關注的焦點在於磁碟空間的消耗。由於 containerd 會同時保留映像檔的壓縮與解壓縮格式，這導致相同映像檔在硬碟上占用的空間顯著增加。部分開發者對此表示強烈不滿，認為 Docker 已經是開發環境中的空間殺手，如今為了加速推送與拉取速度而犧牲儲存空間，是一種「以空間換取時間」的權衡，但在許多筆記型電腦儲存空間受限的情況下，這種設計顯得不夠體貼。特別是針對機器學習領域的開發者，CUDA 或 PyTorch 等動輒數 GB 的大型映像檔，若每一層變動都導致重複的壓縮層儲存，將會讓開發週期變得極其痛苦。

然而，也有另一派觀點從效能角度為此辯護。有留言指出，在現代 NVMe 儲存設備上，CPU 處理壓縮與解壓縮的速度往往快於磁碟介面的傳輸頻寬，因此保留壓縮檔不僅是為了網路傳輸，也可能在特定硬體配置下提升整體效能。不過，這種效能紅利在不同硬體上表現不一，例如在較舊的筆記型電腦上，磁碟速度可能仍快於壓縮處理，這使得該設計的優劣取決於具體的使用場景。

除了空間問題，技術架構的變動也讓部分進階使用者感到困擾。由於資料路徑從 /var/lib/docker 轉移到了 /var/lib/containerd，這打破了許多原本依賴掛載特定路徑來達成資料持久化的自動化腳本或容器管理系統（如 IncusOS）。此外，目前該儲存後端尚不支援使用者命名空間重映射（userns-remap），這被視為一項退步，甚至有開發者直言這是一次「搞砸了」的更新，並開始考慮轉向 Podman 等替代方案。儘管如此，社群中仍有理性聲音指出，Docker 轉向 containerd 標準化是長遠的正確方向，目前的陣痛期雖然存在，但符合容器生態系的標準化趨勢。

延伸閱讀

在討論過程中，有網友分享了針對磁碟清理的實用指令，建議使用者定期執行 docker system prune -a --volumes 以釋放被占用的空間。針對 containerd 儲存空間重複占用的問題，留言中也提到 GitHub 上已有相關的 Issue（containerd/containerd#13307）正在討論如何優化此機制。對於需要在特定系統（如 Incus）上同步兩個目錄的使用者，則有開發者分享了透過 ZFS 子路徑掛載來同時管理兩個儲存路徑的實作經驗。