架構現代化的里程碑，但災情初現
Docker Engine 29.0.0 日前正式發佈，這不僅是一次標準的版本更新，也算是 Docker 架構現代化的改進。此版本帶來了期待已久的 nftables 實驗性支援、將 containerd 設為新安裝的預設鏡像儲存，並正式開始不支援 cgroup v1。
然而，這次重大更新的另一個影響是相容性成本增加，一些舊的容器在本次更新中的多項 Breaking Changes 將受到影響，從 Go 模組的棄用、API 版本的提升，到終止對舊款 ARM 裝置的支援都有。CyberQ 彙整了目前官方文件、測試和實際使用的現象，來看看這次的 Docker 升級。
導入更貼近 Linux 主流的技術
Docker 29.0.0 有不錯的重要變革，主要可以看它這次支援了重要的 Linux 核心子系統 nftables ，以及導入了對 containerd 的支援，
1、實驗性支援 nftables
長久以來，Docker 高度依賴 iptables 進行網路規則管理。隨著 nftables 成為 Linux 核心中現代防火牆的標準，社群對支援的呼聲也日益高漲。
在 29.0.0 版本中，開發者現在可以透過設定 Docker 守護程式 (daemon) 的 firewall-backend 選項為 nftables 來啟用實驗性支援。
官方文件與 Reddit 上的使用者回報均指出，這項功能仍標記為 Experimental。目前 Swarm 模式尚不支援 nftables，Overlay 網路規則仍依賴 iptables。
社群反應也在觀察中，有開發者認為 Docker 在這方面的腳步過慢，部分使用者早已轉向 Podman，也有維運者持保留態度，指出 Docker 的實驗性功能（如 IPv6）往往維持多年才進入穩定階段。
2、containerd 鏡像儲存成為預設（新安裝）
對於全新安裝的 Docker 環境，containerd 鏡像儲存現在成為預設選項。這代表 Docker 進一步與 OCI（Open Container Initiative）標準接軌，將核心的容器執行與鏡像管理交由 containerd 處理，以簡化架構並提升效能。
但要注意：
此變更不適用於已配置 userns-remap 的守護程式。
現有安裝升級時不會自動轉換為 containerd 儲存。
官方文件目前仍未明確標示此為 GA（正式支援）功能，故屬於社群觀察階段。
必須正視的 Breaking Changes
本次更新的破壞性變更清單很長，IT 管理員和開發者在升級前必須仔細檢視 Docker Engine 29.0.0官方更新說明，並和應用 AP 團隊確認，同時先進行快照備份後再來升級。
1、Go 模組開發者的影響
若使用 Go 語言與 Docker API 互動：
舊模組棄用： github.com/docker/docker 模組已棄用。
新模組路徑： 改為 github.com/moby/moby/client 和 github.com/moby/moby/api。
版本前綴： 從 v29 開始，發佈版本加入 docker- 前綴（例如 docker-v29.0.0）。
2、cgroup v1 正式棄用（支援至 2029 年 5 月）
官方明確指出 cgroup v1 已標記為 Deprecated，支援將持續到 至少 2029 年 5 月。
這並不意外，Kubernetes 與主要發行版早已全面擁抱 cgroup v2。Docker 此舉是為了跟上主流 Linux 生態。
不過，這已開始造成舊環境的衝擊。由於 Docker Desktop 預設使用 cgroup v2，部分仍依賴 v1 的工作負載可能無法正常運作。
3、終止對舊版 ARM 與 Raspbian 的支援
對物聯網（IoT）與邊緣運算領域舊機器影響不小：
Debian armhf (32-bit)： 軟體包改為面向 ARMv7 CPU，無法在 ARMv6（如 Raspberry Pi 1、Pi Zero）上執行。
Raspbian (32-bit)： 官方不再提供套件，建議改用 Debian arm64 或 armhf。
4、其他重要變更
API 版本要求部分，Docker daemon 現要求 client API 版本至少為 v1.44。
Docker Content Trust則是已從 CLI 移除，未來將以獨立外掛形式提供。
社群實測與災情回報
CyberQ 主要的 Portainer 管理平台所在的 QNAP NAS 主機還是 Docker 27.1.2，另一個品牌的 NAS 主機官方容器套件則仍是停留在相對舊的版本 Docker 24.0.2，畫面中這台 CyberQ AMD 測試機是 Linux 主機的 Docker ，則已經更新到 29.0.0。由於主要的 Portainer 執行在 Docker 27.1.2 上，並未受到影響，因此還能管理系統環境中的每個 Docker node。
雖然目前未出現大規模災情，但多個熱門工具鏈已經傳出問題。以下為開發者與社群近期我們覺得可留意的回報：
1、Portainer 無法連線本機 Docker Socket
「升級到 Docker 29.0.0 後，Portainer CE 2.33.3 無法連線管理本機環境」
— GitHub Issue #12925
CyberQ 另一組 docker 環境，主機所在使用的 Portainer 就沒辦法順利運作，顯示為 Down，無法存取本機容器。
現象：Portainer 在 Debian 12 + Docker 29.0.0 上無法透過 UNIX socket 存取本機容器。
推測原因：API 權限或 socket 層權限控制方式變更。
2、Traefik 代理停止運作
「Traefik 使用 Docker API 1.24，升級後 daemon 要求最低 1.44，導致 client version too old」
— Traefik 社群論壇
意涵：任何依賴舊版 API 的代理、監控工具若未升級將立即失效。
建議：檢查 client API version 是否 ≥ 1.44。
3、Watchtower 自動更新失效
Reddit 使用者指出：「Docker 29.0.0 讓 Watchtower 偵測到的 API 版本為 1.25，導致完全無法運作。」
— Reddit 回報
Github 也有使用者回報問題 Incorrect docker version detection。
CyberQ 實測在 Docker 29.0.0 的機器上，Watchtower 會顯示 API 版本為 1.25 太舊的錯誤。
暫時解法：暫停自動更新、鎖定 Docker 28.x 版本，待 Docker 29.0.x 或 Watchtower 更新修補。
建議：升級前確認自動更新服務（Watchtower、Diun 等）支援新 API。
4、Nextcloud AIO 控制容器無法存取
「升級 Docker 至 29.0.0 後，Nextcloud AIO master container 出現 ‘client version 1.41 is too old’ 錯誤」
— Nextcloud Issue #7096
意涵：即使是應用平台本身（非 CLI），若內部管理容器使用舊 API，也會被拒絕。
CyberQ 推薦升級建議與檢查清單
維運（Ops）團隊
暫緩生產升級： 建議先在測試／開發節點觀察 1–2 週。
檢查相依工具：
CI/CD、監控、自動更新（Watchtower）
代理／反向代理（Traefik、Caddy）
管理介面（Portainer、DockStation）
cgroup 遷移規劃：
檢查 cat /sys/fs/cgroup/ 是否為 v2。
若仍為 v1，建議提前測試切換策略。
Socket / 權限變動： 若 UI 工具透過 /var/run/docker.sock 連線，建議重新檢查權限與 SELinux 設定。
保持回滾機制： 保留 docker-ce=28.x 套件快取與快照，必要時可緊急降級。
開發者（Dev）
更新 Go 模組 Import 路徑： github.com/moby/moby/client
重新測試 SDK 介接： 確認支援 Docker API v1.44。
IoT/ARM 專案： 檢查裝置 CPU 架構，ARMv6 裝置無法升級。
實驗性功能測試： nftables 功能仍標示 experimental，建議在 dev 環境啟用測試。
審慎評估相關版本後續與容器工具、依賴項更新
Docker 29.0.0 是一次「技術債清理版」的重大釋出，從架構層面積極擁抱 cgroup v2、nftables 與 containerd，但也因此切斷了大量舊版相容層。
這次升級的重點不只是新功能，而是 Docker 正式劃出了一條清晰界線：
「從傳統到現代容器架構的分水嶺」。
短期內將有更多工具鏈被迫升級或修補，尤其是依賴舊 API 的監控、自動化、代理系統。建議先測試再升級，觀察至少兩週。提早更新 SDK 與 API 相容性。IoT 用戶確認硬體支援，避免升級後無法重啟容器。
整體而言，這次更新的長遠方向是正確的，但過渡期內 API 相容性問題會持續一小段時間。
Docker 29.0.0 代表官方徹底擁抱主流 Linux 技術堆疊的決心，如果你的維運環境涉及多平台容器、代理工具或自動化更新，請務必密切追蹤後續 v29.0.1、v29.0.2 修補版，以及各第三方工具的相容性更新狀態。
