Docker Engine 近期有許多重要的版本更新，根據官方最新的釋出公告與社群反饋，Docker v29 系列，包含剛釋出的 Docker Engine 29.1.0，除了更新架構外，陸續有一些因為升級架構與系統變化產生的災情，各家容器實作也陸續調整配合 API 更新，但截至目前為止，Docker 官方後續的升級與更新，仍舊是有一定的風險，值得開發者社群留意。
Docker 29.1.0：BuildKit 與 Containerd 升級
根據最新的官方技術細節，29.1.0 版本在底層引擎上做了顯著的提升，該團隊正努力讓 Runtime 環境與最新的雲原生標準接軌。
BuildKit 升級至 v0.26.1，作為 Docker 構建映像檔的核心，這次升級預期將帶來更快的構建快取（Cache）處理與更佳的多平台構建穩定性。
Containerd 二進位檔更新至 v2.2.0，從靜態二進位檔層級直接更新了 Containerd，這對於容器的生命週期管理、映像檔儲存效率都有底層的最佳化。
以下是官方說明與相關連結 :
Packaging updates
- Update BuildKit to v0.26.1. moby/moby#51551
- Update containerd binary to v2.2.0 (static binaries). moby/moby#51271
Networking
- Do not overwrite user-modified
/etc/resolv.confacross container restarts. moby/moby#51507 - fix
--publish-all/-Pfor Windows containers. moby/moby#51586 - Fix an issue that prevented container restart or network reconnection when gateway configuration failed during container stop or network disconnect. moby/moby#51592
- Windows containers: don’t display an IPv6-mapped IPv4 address in port mappings. For example,
[::ffff:0.0.0.0]:8080->80/tcpinstead of0.0.0.0:8080->80/tcp. moby/moby#51587
CyberQ 一台已經更新到 Docker Engine 29.1.0 的實例
網路與 DNS 邏輯的關鍵變更
在這次 29.1.0 的更新日誌中，有一項關於網路行為的修正特別引人注目，這極有可能解釋了為何社群近期頻傳 DNS 解析異常：
/etc/resolv.conf 設定不再被覆蓋：官方公告指出：「Do not overwrite user-modified /etc/resolv.conf across container restarts.」
CyberQ 觀察，在過去，容器重啟時，Docker Daemon 往往會重置內部的 DNS 設定（/etc/resolv.conf）。這項改動原本的立意是好的，保留用戶在容器運行期間手動修改的 DNS 配置。然而，這種「持久化」行為若與宿主機的網路變更（如 VPN 切換、網路環境改變）發生衝突，極有可能就是導致容器重啟後 DNS 解析失效、連線無法恢復的主因。
建議重點觀察上述 PR #51507 的後續評論，看官方是否會因為災情嚴重而 revert（撤銷）此變更，或推出新的 Flag 來控制此行為。
此外，針對網路連線的穩定性，本次更新還包含了：
修復 Gateway 配置失敗後的重連問題：解決了當 Gateway 設定失敗導致容器停止或網路斷開後，無法順利重啟或重新連線的 Bug。
Windows 容器的修正
對於使用 Windows Server 或混合環境的企業用戶，本次也修復了幾個長期存在的顯示與連接埠映射問題：
修復 -P / –publish-all：解決了 Windows 容器無法正確自動發布所有連接埠的問題。
最佳化 IPv6 顯示格式：在連接埠映射顯示上，不再顯示令人困惑的 IPv6 映射 IPv4 地址（如 [::ffff:0.0.0.0]:8080），而是回歸更直觀的標準顯示。
社群災情：29.1.0 的 DNS 危機
雖然 v29 帶來了長遠的改進，但根據 Reddit 與 GitHub 上的最新社群回報，剛釋出的 Docker Engine 29.1.0 版本（特別是在 Debian 13/Trixie 等新發行版源中）似乎包含了一個嚴重的 DNS 解析錯誤，29.1.0 breaks the embedded DNS resolver #51614。
多位資深用戶回報，升級至 29.1.0-1 後，容器內部的 DNS 解析功能完全失效，導致服務全面中斷。目前的暫時解法是降級回 29.0.4 版本，或手動在容器內指定外部 DNS 伺服器，但這顯然不適合生產環境的自動化部署。密切關注該 Issue 是否會被標記為 Regression 並在 29.1.1 版本中被 Revert（撤銷）或引入新的 Flag（例如 –overwrite-resolv-conf）來控制此行為。
此外，v29.0.0 的 API 變更也讓許多「設定後不理（Set-and-forget）」的自託管服務被影響，有的用戶發現自動更新後，整個監控與反向代理服務癱瘓，必須手動介入修復或鎖定版本。
擁抱現代化，告別舊時代
除了上述細節，v29 系列的整體大方向仍維持不變，其中最關鍵的變動在於強制要求最低 API 版本為 1.44，Docker Daemon 將不再接受過舊的客戶端請求。
API 門檻提升：這是本次社群反彈最大的改變。許多長期未更新的工具（如舊版 Portainer、Traefik、Watchtower）因仍使用舊版 API，在 Docker 升級後直接「斷線」或無法管理容器。而 Portainer 日前推出的新版本 2.33.5 LTS (長期支援版)、2.36.0 STS (短期支援版)，已經修改程式，配合更新了 API 要求，能夠順利使用。
CyberQ 其中一組安裝 Portainer 的實例，已經是 Docker Engine 29.1.0，Portainer 則是 2.33.5 LTS 。
Containerd Image Store 預設化：針對新安裝的環境，Docker 預設啟用 containerd image store。這能提升映像檔管理的效能與一致性，但也改變了底層儲存邏輯。
nftables 實驗性支援：為了適應新的 Linux 發行版趨勢，Docker 終於開始支援 nftables 作為防火牆後端，這對於資安配置來說是一大福音，但目前仍處於實驗階段。
Cgroup v1 棄用：雖然支援將持續到 2029 年，但官方已明確建議盡速遷移至 Cgroup v2，這對於依賴舊版資源管理的 legacy 系統來說就必須得跟著修改。
資安與穩定的權衡，立意良善但風險未除
CyberQ 認為，從最新的 Changelog 來看，Docker 試圖解決「容器重啟後 DNS 設定遺失」的問題，引入了 /etc/resolv.conf 保留機制。然而，技術細節顯示這項改動可能與現有的網路自動化工具產生了意料之外的副作用，導致了目前社群回報的 DNS 災情。
GitHub Issue #51614 反映出基礎設施軟體的困難點，Docker 團隊試圖解決一個用戶設定被覆蓋的問題，卻意外製造了一個網路環境無法自動應對的問題。其實用容器久了，我們會知道，不可變動（Immutable）通常是指映像檔，而不是那些會隨著環境動態調整的網路配置。
對於企業用戶，CyberQ 的建議維持不變：
暫緩升級 29.1.0：鑑於 /etc/resolv.conf 處理邏輯的變更，建議等待下一個 Patch 版本（如 29.1.1）針對此邏輯進行更完善的邊界測試後再行升級。
檢查工具相容性：確認你的周邊工具支援 Docker API 1.44。
鎖定版本：生產環境請務必鎖定 Docker 版本，如 29.0.4 或更穩定的 28.x 系列，避免自動更新帶來不可預期的網路行為改變。
v29.1.0 的 resolv.conf 修正是一個正確方向但執行需要多方配合的改動。它解決了持久化問題，卻可能製造了新的問題。建議各位先觀望，待災情平息後再行部署。
11 月 28 日更新，官方已經解決這個 DNS 問題，釋出了 29.1.1。
