Docker 29 在 2026 年 3 月推出，release notes 讀起來像一份無趣的維護版本：最低 API 版本抬到 1.44、containerd image store 變成新裝預設、nftables 進入實驗支援。這三個看似技術層面的調整合起來把整個自架社群折成兩半——一半跟著版本走，另一半的工具永遠停在 Docker 28 那個時代。這篇整理 Docker 29 到底改了什麼、為什麼 Watchtower 跟 Dockge 這種每天在跑的東西會直接罷工、升級 VPS 上的 Docker 主機前該先做哪幾件事。
一次抬升 API 版本，換來一整排工具集體沉默
Docker 29 把 daemon 能對話的最低 client API 版本從 1.24 拉到 1.44。翻譯成人話：任何內部還在用 Docker 25 之前 SDK 的工具，連拉容器清單這件事都做不到。錯誤訊息是 client version 1.43 is too old. Minimum supported API version is 1.44——不是網路問題、不是權限問題，就是被 daemon 直接掛掉。
Docker 官方給出的理由是「歷史包袱太重、要往前走」，但這一刀切下去把整個生態系分成三堆。第一堆是活著的工具，Portainer 在 2.33.5 LTS 跟 2.36.0 STS 都補上支援、Traefik 3.6.1 加了 API 版本協商、CapRover 1.14.1 跟 LazyDocker 0.24.2 各自釋出修正版本。這批只要跟著升就沒事。
第二堆是重傷但還有救的。Watchtower 是最痛的一個——這個負責自動更新容器 image 的守護程式已經兩年多沒有正式 release，社群 fork 了好幾個版本但都沒有一個明確接手。想繼續用 Watchtower 的人只能鎖 Docker 28、或者改用 Diun、Ouroboros 這類替代品。第三堆已經沒救：Dockge 這個輕量 Compose 面板從 v29 出來到現在都還沒修好、CasaOS 的 App Store 拉不到清單、Swarmpit 專案被 archive、Yacht 從 2023 年開始就沒人維護。
這件事的殘忍之處在於，被斷奶的工具不會馬上倒——它們會在升級當下靜靜地變成殭屍，UI 打得開、頁面看得到，只是所有跟容器有關的動作都失敗。監控面板停留在最後一次成功的資料、更新排程默默略過、部署腳本回 500 錯誤但沒人看 log。運氣好的話幾天內會發現，運氣不好就是某天早上打開發現一堆容器兩個禮拜沒更新過安全性 patch。
containerd image store 悄悄變成預設
這是另一個容易被忽略的改動。Docker 29 對「新裝」的機器把 image 儲存後端從舊的 graph driver（overlay2、aufs、btrfs 那些）換成 containerd 的 snapshotter。既有系統升級後不會被強制搬遷，會保留原本的 driver 繼續跑，但只要重新裝一次 Docker、或者拿一份 Ansible playbook 重新 provision VPS，就會直接進入 containerd 模式。
實務差異在幾個地方。containerd store 支援 lazy pulling、遠端 content store、以及未來要接的 P2P image 分發，這些都是舊 graph driver 做不到的事。壞處是 image inspect 的欄位結構、docker save/docker load 產生的 tarball 佈局、以及某些解析 /var/lib/docker 的備份工具在兩種後端下行為不完全一樣。
想拒絕這次遷移可以在 /etc/docker/daemon.json 塞：
1 | { |
但這只是把時鐘按停。graph driver 在下一次大版本會被移除，長期最好還是驗證自己的備份與監控腳本在 containerd store 下能不能運作。
nftables 進場，iptables 開始倒數
Docker 過去幾年被酸最多的一件事：不管系統 firewall 是 UFW 還是 firewalld，只要容器 publish 一個 port，Docker 就用自己那套 iptables chain 把規則塞到最前面，等於整套 host firewall 被繞過去。有一篇 2018 年的 GitHub issue 到 2026 年都還在收留言。
Docker 29 開始提供 nftables 作為 firewall backend，方式是在 daemon 啟動時加 --firewall-backend=nftables 或者在 daemon.json 寫：
1 | { |
這個選項目前還標為實驗，但官方明說未來會成為預設、iptables 支援會 deprecate。功能上跟原本的 iptables backend 等價，一樣建 DOCKER、DOCKER-USER、DOCKER-FORWARD 這些邏輯上對應的 chain，只是搬到 nftables 的 table 底下。
真正值得注意的是幾個副作用。啟用 nftables backend 之後 Docker 不會主動幫 host 開 net.ipv4.ip_forward，需要手動在 /etc/sysctl.d/ 底下建一支設定檔加上 net.ipv4.ip_forward=1 並且執行 sysctl --system 套用（sysctl -p 預設只會讀 /etc/sysctl.conf，不會載入 /etc/sysctl.d/ 底下的檔案）；不然容器對外的 masquerade 會斷。另外 DOCKER-ISOLATION-STAGE-1 跟 DOCKER-ISOLATION-STAGE-2 兩條 chain 在 v29 被移除，意思是不同 bridge network 上的容器如果 publish port，理論上可以互相打到，過去被這兩條 chain 隔離的 traffic 現在會通。多網段部署要重新盤點一下有沒有依賴這個隱含的隔離。
從 iptables 轉到 nftables 是遲早的事，Debian 13 已經把 nftables 當預設 firewall backend、systemd-networkd 走的也是 nftables 路徑，Docker 這步只是跟上。臺灣機房環境裡如果還在跑 Ubuntu 20.04 或 Debian 11 這種老底子的 host，建議先把 host OS 升級到 Debian 13 或 Ubuntu 24.04，再去啟用 Docker 的 nftables backend，兩件事分開做比較好排除問題。
升級 VPS 上的 Docker，該檢查的清單
升級 Docker 29 前，值得花十分鐘做這幾件事。第一件：確認目前版本跟 image store。
1 | docker version --format '{{.Server.Version}}' |
如果 Server 是 v23 或更舊，不要一步跳到 v29——先升到 v25 讓 API 平滑過渡，再跨到 v29。跨太多版對 daemon 元資料反而容易出事。
第二件：清點自己在用的容器管理工具。這一份表格值得存起來對照。
| 工具 | 狀態 | 說明 |
|---|---|---|
| Portainer ≥ 2.33.5 | 支援 | 升級後即可 |
| Traefik ≥ 3.6.1 | 支援 | 需重啟 |
| CapRover ≥ 1.14.1 | 支援 | |
| Watchtower | 停更 | 建議改用 Diun 或 Ouroboros |
| Dockge | 未修 | 目前沒有替代路徑，只能鎖 Docker 28 |
| CasaOS | 未修 | App Store 功能失效 |
| Swarmpit | 已 archive | 專案不再維護 |
Compose v1 (docker-compose) |
不相容 | 改用 docker compose plugin |
Compose v1 那個獨立 binary 是最容易忽略的點——很多老舊部署腳本裡還有 docker-compose up -d，升級後會直接爆炸。改成 docker compose up -d（中間空格）走 plugin 版本就沒事。
第三件：firewall 規則。如果過去有寫過 iptables 規則去配合 Docker，例如手動加 DOCKER-USER 鏈裡的規則、或者用硬編碼 subnet（172.17.0.0/16），這些規則在 nftables backend 下不會自動搬過去。建議改用 interface 為基準的規則（-i docker0）以及依靠 Docker 建立的 chain 名稱，不要自己去猜 subnet。
第四件：備份。Docker daemon 升級之後如果出現 image 拉不下來、container 起不來的情況，最快的復原路徑是回捲——大部分 VPS 供應商都提供整機 snapshot，升級前先建一個，比事後救資料快很多。用 restic 或 bup 對 /var/lib/docker 額外做一次備份也是保險做法，但 daemon 在跑的時候檔案系統快照未必一致，snapshot 前先 systemctl stop docker 會比較乾淨。
官方套件庫別直接 apt upgrade
Ubuntu 24.04 從 2026 年開始把 Docker 29.1.3 推進一般更新循環，Debian 13 backports 也開始跟上。這件事的意思是：一個平常沒事跑的 apt update && apt upgrade 可能在完全沒警告的情況下把 Docker 升到 v29，接著整臺 VPS 上的容器編排工具開始一片綠變紅。
臺灣機房裡跑生產服務的 VPS，建議把 Docker package 從自動升級名單裡拉出來，改用手動控制。Debian/Ubuntu 系可以用：
1 | sudo apt-mark hold docker-ce docker-ce-cli containerd.io |
要升級的時候再 unhold，並且指定版本安裝：
1 | sudo apt-get install docker-ce=5:29.0.0-1~ubuntu.24.04~noble \ |
RHEL/AlmaLinux/Rocky 系用 yum versionlock 或 dnf versionlock 也可以做到一樣的事。這種做法讓升級成為一個明確的決定，而不是某個星期二晚上被 unattended-upgrades 悄悄推上去。
這次升級對自架社群的長期影響
Docker 29 這一波之後，社群裡有個明顯的分水嶺：主動維護的專案跟過去兩三年沒動的專案，命運從此完全不同。這也逼著自架玩家去重新盤點自己那套 stack——那些選型時看起來輕巧方便的工具，其實可能建立在「維護者一年會回信一兩次」的脆弱基礎上。
長期來看，Docker 這個 project 正在往幾個方向收斂：跟 Kubernetes 生態系用同一個 containerd runtime、firewall 走 nftables 跟系統 firewall 對齊、API 拉高門檻讓上游 SDK 不需要無限相容過去十年的呼叫。這些改動的方向是對的，代價是要求下游工具跟得上。跟不上的、或者維護者已經不在的，就會在這種節奏下逐漸淘汰。
結語
Docker 29 的升級不會摧毀伺服器，但會在一個下午之內把伺服器上一整批容器管理工具變成殭屍。真正的重點不在 API 版本或 nftables 這些技術細節，而在於：手上這套自架 stack 裡有多少工具，仍然有活人在維護。Watchtower 那個例子只是提醒——很多每天在跑的東西，其實已經很久沒人接電話了。
臺灣機房的 VPS 環境如果要跑穩定的 Docker 生產服務，除了選對主機，還需要能承載這種持續遷移節奏的網路品質跟工程支援。NCSE Network 在是方電訊機房提供 NVMe SSD、Intel Gold CPU 的 VPS，網路走臺灣直連 IP Transit，適合放對 Docker 升級路徑、容器安全、以及 CI/CD 節奏有要求的服務——想了解方案細節可以到 ncse.tw 看看目前的規格與價格。
