Docker 讓容器成為預設，也把脆弱部署變成常態

2013 年後容器成為主流，但 Docker 也把脆弱的部署習慣變成預設。

Docker 在 2013 年把 Linux namespaces 與 cgroups 包裝成工程團隊能直接採用的產品，改變了軟體交付的速度與門檻。它的成功是真實的：從 dotCloud 的內部專案，迅速變成開發、CI、發佈流程中的標準元件。但這份成功也帶來副作用，許多團隊開始把「能打包」誤認為「已經有平台」。

第一個論點

Docker 最大的貢獻是把容器從系統管理者的工具，變成一般工程師也能操作的工作流。寫 Dockerfile、build image、run container、push registry，這條路徑足夠清楚，才讓 Red Hat、Microsoft、IBM、AWS 等供應商快速跟進。沒有這種可用性，容器不會這麼快進入主流。

但可用性不等於運維成熟。容器映像只是環境假設的快照，不是正確性的保證。實務上，runtime 參數、kernel 行為、儲存驅動與網路政策，仍然決定服務是否穩定。Docker 把複雜性藏進更漂亮的介面，並沒有消除它。

第二個論點

Docker 最強的價值之一是可重現性。macOS 開發機、Linux CI、正式環境只要跑同一個 image，就能少掉大量「我機器上可以」的問題。對跨環境交付的團隊來說，這是實打實的效率增益，也是 Docker 能成為默認工具的原因。

但同一套打包模型，也鼓勵把所有依賴塞進 image，然後把這叫做可攜性。結果常見的是 image 變大、runtime 重複、每次改動都要重建整條管線。問題不在容器格式，而在 Docker 讓「先包起來」變得太容易，團隊因此延後了架構紀律，最後累積成 pinning drift、層級膨脹與不透明的部署行為。

第三個論點

Docker 更深的影響不是技術，而是文化。它讓產品團隊習慣先想 container，再想 service，最後才想 system。這種順序在有成熟平台工程的組織裡很有效；在沒有平台能力的組織裡，卻會把每個元件都切成獨立 image，讓本地環境變成一個縮小版叢集。

這不是抽象批評。2018 年的一項分析顯示，單一主機上跑 8 個容器已經是常見情境，而有四分之一的組織分析樣本每台主機跑 18 個以上。密度上升不是免費的，它直接拉高可觀測性、Secrets 管理、image 掃描與網路政策的成本。Docker 讓分散式部署變得理所當然，但多數組織的治理能力並沒有同步成熟。

反方可能怎麼說

支持者會說，Docker 的歷史功績非常明確：它把原本只屬於專家的能力民主化，降低了可重現軟體交付的門檻，也推動 CI/CD 成為主流。更重要的是，它替整個產業建立了共同語言，讓 images、registries、immutable artifacts 這些概念能被普遍理解。

他們也會說，錯的不是 Docker，而是使用 Docker 的人。把單體系統做壞的人，換成微服務也一樣會做壞；容器只是部署原語，不是架構決策本身。

這個反駁只說對一半。工具會塑造預設，而 Docker 的預設確實把團隊推向「先打包、後設計」。我承認它對產業是正面推力，但我不同意它的普及只是純粹的好事。它讓太多團隊在還沒說清楚 failure modes 之前，就先學會把任何東西 containerize。

你能做什麼

如果你是工程師、PM 或創辦人，把 Docker 當成 build 與 distribution layer，不要把它當成架構替代品。image 要小、runtime contract 要清楚、Secrets 不要寫進 layer，並把 orchestration、observability、policy 當成和打包同等重要的設計項目。真正該問的不是「能不能 Dockerize」，而是「這個容器遮住了哪些失敗模式，誰要負責」。