很多人第一次認識 Docker，通常都是從幾個指令開始的。
沒錯，我也跟大家一樣，從一個簡單的容器開始認識 Docker。
docker pull nginx
docker run -p 8080:80 nginx
docker ps
docker build -t my-app .Code language: CSS (css)並且我相信不管對「早期的我」，或是對多數人來說，Docker 就是「跑容器的工具」，或是「把應用程式包成 image 的工具」。這個理解沒有錯，但如果今天還只把 Docker 想成就是 docker pull、docker run、Dockerfile，其實會錯過 Docker 這幾年發展出來的很多能力與解決方案。
身為 Docker Captain，自己有一些目標與責任要多分享一下關於 Docker 的內容。其實與其介紹太技術性的內容，或是單獨介紹單一產品與功能。發現好像有個更基本的，就是要讓大家來了解了解一下「Docker 生態系」。
我自己重新整理 Docker 產品與功能時，也很有感覺。Docker 已經不是單一的 container tool，而是一個圍繞開發者工作流程的完整平台。
它處理的已經不止是「怎麼把程式打包成容器跑起來」，而是從本機開發、多人協作、image 管理、CI/CD build、供應鏈安全、測試、到現在很熱門的 AI agent 與本機模型執行，Docker 都慢慢長出對應的工具。Docker 官方也把自己的產品定位成一套整合工具，用來支援 building、deploying，以及 security 相關的問題，充分的具備面對各種開發所需的能力。
所以這篇文章沒有要寫甚麼深入的東西，也不是要把每個產品都完整教學一遍，而是想用「地圖」的方式，帶大家快速看一次：現在的 Docker 到底有哪些東西？各自解決什麼問題？什麼時候會用到？
1. Docker Desktop：不只是圖形化介面，而是本機開發入口
很多人會把 Docker Desktop 想成「Docker 的 GUI」，但我覺得這樣有點低估它。雖然要這樣描述也不能說它錯。
Docker Desktop 比較像是開發者電腦上的 Docker 工作站。它幫你處理本機 container runtime、Docker CLI、Compose、image、volume、network、build、Kubernetes、extensions 等等。對新手來說，它降低了環境安裝門檻；對團隊來說，它讓大家有比較一致的開發環境。
Docker 官方對 Docker Desktop 的描述是 unified development environment，可以在本機 build 與 run containers，也能透過內建 Kubernetes 與 Docker Compose 進行協作與測試，並將映像檔推送到 Docker Hub 或其他 registry。
這也是我覺得 Docker Desktop 最重要的價值：它把很多原本分散的工具整合在一起。你可以在 CLI 操作，也可以在 UI 裡看 container log、image layer、volume、build history、Scout 掃描結果，甚至直接操作一些 AI 相關功能。
2. Docker Compose：從單一容器走向完整應用環境
如果 docker run 是跑單一 container，那 Docker Compose 就是用來描述一組應用服務。
其實 Docker Compose 好像也不必多說，對於開發與維運人員，相信多數都是再熟悉不過的了。
例如一個很常見的開發環境，可能會有：
services:
web:
build: .
ports:
- "8080:8080"
db:
image: postgres:16
environment:
POSTGRES_PASSWORD: example
redis:
image: redis:7Code language: CSS (css)這種情境下，如果每個服務都用 docker run 手動啟動，會很痛苦；但用 Compose，就可以用一個 compose.yaml 描述 services、networks、volumes，再用一個指令啟動整組環境。Docker 官方也明確說 Compose 是用來定義與運行多組容器環境，並把 services、networks、volumes 放在單一 YAML 設定裡管理。
我覺得 Compose 對開發者最大的價值不是「省指令」，而是讓環境變成文件。同時也讓這個環境變成可以做版本控制，可以具備稽核軌跡，提升協作透明度。
一個專案如果附上清楚的 compose.yaml，新加入的工程師不用再問：「我要裝哪個版本的 PostgreSQL？Redis 要怎麼開？API 要連哪個 port？」很多東西都可以直接寫在 Compose 裡。
近年 Compose 也不只是 docker compose up -d 而已。例如 Compose Watch 可以監看檔案變更，並在修改 source code 時同步、重建或刷新 container，讓本機開發流程更接近一般 hot reload 體驗。官方文件也提供 docker compose up --watch 與 docker compose watch 的用法。
3. Docker Build、BuildKit、Buildx：image build 其實可以很進階
建立 image 時，我們會撰寫 Dockerfile 然後進行 docker build，例如：
FROM node:20
COPY . .
RUN npm install
CMD ["npm", "start"]Code language: CSS (css)但有件事情你很可能不知道～ Docker build 的世界其實比這個大很多。
現在 Docker 的 build backend 是 BuildKit。官方文件提到 BuildKit 是 Docker 使用的 builder backend，相比 legacy builder，它提供更好的功能與 build performance，也支援更複雜的 build scenario。
實務上，BuildKit / Buildx 會牽涉到很多重要能力，例如：
docker buildx build --platform linux/amd64,linux/arm64 -t my-app:latest .這代表你可以 build multi-platform image，讓同一個 image 支援 x86 與 ARM 架構。這在 Apple Silicon、雲端 ARM instance、邊緣設備越來越常見的情況下，非常重要。
另外，Docker build 現在也可以產生 SBOM 與 provenance attestations，並可透過 --sbom 與 --provenance 參數控制 SBOM 與 provenance。
例如：
docker buildx build \
--sbom=true \
--provenance=mode=max \
-t my-app:secure .Code language: JavaScript (javascript)這對 DevSecOps 或供應鏈安全來說很重要。因為 image 不再只是「一包可以跑的東西」，而是需要回答：
- 這個 image 裡面有什麼套件？
- 它是怎麼 build 出來的？
- 它的 base image 是什麼？
- build 過程是否可追溯？
有沒有覺得大吃一驚了！
以前這些問題可能要靠額外工具處理，現在 Docker build 本身就越來越靠近 supply chain security 的需求。
4. Docker Build Cloud：把 build 搬到雲端，不只是為了快
本機 build image 很方便，但專案變大後，就會開始遇到一些問題。
例如 build 很慢、multi-arch build 更慢、不同工程師的 cache 不共享、CI runner 資源不足、Apple Silicon 與 x86 build 結果不一致等等。
Docker Build Cloud 就是針對這類問題。它的核心概念是：你還是用熟悉的 Docker build / Buildx 工作流程，但 build 實際上可以交給雲端 builder 執行。（不過要偷偷說一下，我自己是還沒有用過XD）
對團隊來說，我覺得 Build Cloud 的重點不只是「build 比較快」，而是「build 環境比較一致」。
如果每個工程師都在自己的筆電上 build，cache、CPU 架構、網路、套件下載速度都可能不同。但如果團隊使用共用的 cloud builder，就比較容易讓 build 結果與 build 體驗一致。
這對需要大量 build image 的團隊、開源專案維護者、或是要支援多平台 image 的專案，都很值得關注。
5. Docker Hub：不只是放 image 的地方
當我們需要取得 images 的時候，可能會透過以下的指令：
docker pull nginx
docker pull mysql
docker push myname/myimage也就是「下載 image、上傳 image 的地方」，而這些 image 就是在 Docker Hub 上面。
但不僅僅是儲存 images，Docker Hub 實際上是 Docker 生態系裡非常核心的 registry 與協作平台。官方產品頁把 Docker Hub 定位成 repository for container images，提供 pre-built images、image management、team collaboration，以及 verified image repository 等能力。這是一些相當重要的概念，關於上面的許多 Trusted content，未來有機會再和大家分享。
對一般開發者來說，Docker Hub 最直覺的價值是可以快速取得官方 image 或社群 image。例如：
docker pull postgres
docker pull redis
docker pull nginx
docker pull python但對團隊來說，Docker Hub 的價值會變成 image 管理、private repository、organization、access token、CI/CD push image、以及 trusted content。
換句話說，Docker Hub 不是只有「放 image」，而是「讓 image 可以被管理、分享、驗證與交付」的地方。
如果今天要教新手 Docker，我都會開 Docker Hub 來進行許多觀念的解說，不會只是要他們會 docker run，也要理解 image tag、digest、registry、repository、official image、verified publisher 這些概念。因為到了團隊開發與正式部署階段，這些概念會直接影響安全性與可維護性。
6. Docker Scout：從 image 掃描走向軟體供應鏈安全
如果你是資安或 DevSecOps 背景，Docker Scout 應該會是很值得關注的工具。
簡單來說，Docker Scout 是 Docker 針對 container image security 與 software supply chain security 提供的工具。它可以分析 image 裡面的套件與漏洞，提供 remediation 建議，也可以跟 Docker Desktop、Docker Hub、CI/CD 流程整合。
要了解更多，也可以直接看我前幾天發布的文章：
從 Docker Scout 到 Trivy、Grype：常見容器映像檔掃描工具操作與比較
在實務上，我會把 Docker Scout 想成三件事情：
- 第一，它可以幫你看 image 裡面有什麼。
- 第二，它可以幫你知道 image 裡有哪些已知漏洞。
- 第三，它可以協助你判斷這些問題應該怎麼修。
這跟傳統 vulnerability scanner 其實就有點像，但 Docker Scout 比較特別的是它跟 Docker Desktop、Docker Hub 與 image workflow 整合得很深，畢竟是自家的產品。
例如你在本機 build image 後，可以直接在 Docker Desktop 裡看到分析結果；或是在 Docker Hub 裡啟用 Scout，讓 repository image 持續被追蹤。官方文件也提到，如果在 repository 啟用 Docker Scout，Scout 會保存 image metadata snapshot，並在新的 vulnerability data 出現時重新計算安全狀態。
對我來說，這也是 Docker 從「開發工具」延伸到「供應鏈安全工具」的一個代表。
7. Docker Hardened Images：更小、更安全、更適合生產環境的 base image
這個是 Docker 近年主打，並且也是非常重要的產品之一。過去我們常常會說：「image 要盡量小」、「不要在 production image 裡面放 shell、package manager、debug tools」、「盡量用 non-root user」、「減少 attack surface」。
以上都是真的～ 不過呢這些原則大家都知道，但真正要每個團隊自己做好，其實很累。
Docker Hardened Images，也就是 DHI，想解決的就是這件事。官方文件描述 DHI 是由 Docker 維護的 minimal、secure、production-ready container images、Helm charts 與 system packages，目標是降低漏洞並簡化合規問題。
我覺得 DHI 很適合用在企業環境。因為企業在導入 container 時，常常不是不知道安全原則，而是缺少標準化做法。
例如每個團隊都自己選 base image (有的根本隨便亂選)：
FROM ubuntu:latest
FROM node:latest
FROM python:latestCode language: CSS (css)這樣很容易出現 image 過大、套件太多、漏洞太多、tag 不固定、維護責任不清楚等問題。
如果企業有統一的 hardened base image 策略，就可以降低很多後續治理成本。Docker Hardened Images 的概念就是把這些安全基線往前推到 base image 層級。
這對資安團隊也很有幫助，因為與其在上線前掃到一堆漏洞再要求 RD 修，不如一開始就讓大家使用比較安全、比較小、比較可控的 base image。
8. Docker Debug：小 image 不代表不能 debug
很多人做 container security 時會建議 image 裡不要放太多工具，例如不要放 bash、curl、vim、netcat、package manager。
但這時工程師常常會問：「那我要怎麼 debug？」
這是一個很實際的問題。Production image 應該要小、乾淨、安全；可是 troubleshooting 時又需要工具。這兩個需求看起來互相衝突。
Docker Debug 就是用來處理這個矛盾。官方文件說 Docker Debug 可以幫助你維持 small and secure images，同時仍然可以 debug 那些缺少工具的 slim images 或 containers。例如傳統上你可能會用 docker exec -it my-app bash，但如果 image 裡沒有 bash，就會失敗；Docker Debug 則是為這類情境設計。
「我知道 production image 不該塞一堆工具，但真的出問題時我要怎麼查？」
答案不是把所有工具塞回 image，而是使用比較適合的 debug workflow。
9. Testcontainers：用真的服務做測試，而不是永遠 mock
如果你的應用程式會連 PostgreSQL、Redis、Kafka、MongoDB，那你在測試時要怎麼處理這些依賴？
很多團隊一開始會用 mock。但 mock 太多之後，就會出現一個問題：測試通過，不代表真的能跟實際服務整合成功。
Testcontainers 的概念是：測試時直接用 container 啟動真實依賴服務。
Docker 文件描述 Testcontainers 是一組 open source libraries，提供輕量 API 來啟動 local development 與 test dependencies，讓你可以用 real services wrapped in Docker containers 進行測試，而不是只依賴 mocks 或 in-memory services。
例如你寫 Java、Go、Python、Node.js 測試時，可以在測試流程中啟動一個真實的 PostgreSQL container，測完再清掉。這讓 integration test 更接近真實環境。(概念其實很厲害，但我也還沒試過這個產品XD)
而 Testcontainers Desktop 則是輔助本機開發與測試的 companion app。官方文件提到它可以幫助 local development and testing with real dependencies，並提供 runtime selection、debug services、manage container lifecycle、track test sessions 等能力。
如果測試量很大，也可以看 Testcontainers Cloud。它可以把 Testcontainers 測試中需要啟動的 containers offload 到雲端，減少本機或 CI runner 的負擔。從概念上來說，這對 CI/CD 很有意義，因為很多 pipeline 慢不是慢在 unit test，而是慢在 integration test、環境啟動與 container 資源不足。
10. Docker Extensions：把 Docker Desktop 變成可擴充平台
Docker Desktop 還有一個很容易被忽略的東西，是 Docker Extensions。
Docker Extensions 可以把第三方工具整合到 Docker Desktop 裡。官方文件提到 Docker Extensions 可以讓使用者在 Docker Desktop 裡使用 third-party tools，並可擴充 debugging、testing、security、networking 等功能，也可以透過 Extensions SDK 建立自訂 add-ons。
這代表 Docker Desktop 不是封閉工具，而是可以擴充的開發者平台。
對一般使用者來說，可以透過 marketplace 安裝別人做好的 extension。對工具開發者來說，也可以考慮把自己的工具包成 Docker Extension，讓使用者直接在 Docker Desktop 裡操作。其實這個是一個整合性平台成熟發展的代表，必然都會有這樣 Extensions 或 Marketplace 的延伸性，讓你可以很好的擴展與整合需要的內容。
不管你是做資安工具、observability 工具、local dev tool，Docker Extension 都是一個可以思考的發佈方式。
11. Docker Model Runner：用 Docker 的方式跑本機 AI 模型
到了 AI 時代，Docker 也不只是「包 Web App」而已。Docker Model Runner 是 Docker 近年很值得注意的方向。它讓開發者可以用熟悉的 Docker CLI 與 Docker 工具流程來管理、執行與部署 AI models。
要了解更多，也可以直接看我過去發布的影片：
完整解說：Docker Model Runner (DMR) 入門教學 | 本地AI模型新革命 | 本地 LLM 執行環境 | AI模型部署與管理 | OCI Artifact | DevOps
官方文件提到 Docker Model Runner 可以 pull、run、serve large language models 與其他 AI models，來源可以是 Docker Hub、OCI-compliant registry 或 Hugging Face；也支援 OpenAI-compatible 與 Ollama-compatible APIs，並可以把 GGUF、Safetensors 等模型檔作為 OCI Artifacts 發佈到 registry。
這件事很有趣，因為它把「LLM 模型」也放進類似 image / artifact 的管理思維。
以前 Docker 解決的是： 程式怎麼包？環境怎麼一致？服務怎麼啟動？
現在 AI 開發也遇到幾乎一樣的問題，所以現在也可以用類似的解法去處理：
模型怎麼下載？模型怎麼版本化？模型怎麼分享？本機怎麼跑？應用程式怎麼用 API 接上模型？
Docker Model Runner 的價值就在這裡。它讓 AI model workflow 更接近開發者熟悉的 Docker workflow。
例如未來你可以想像一個開發環境同時包含：
services:
app:
build: .
db:
image: postgres:16
model:
# 使用 Docker Model Runner 或相關模型服務Code language: CSS (css)也就是說，Docker 不只管理容器化的應用程式，也開始管理 AI 應用服務需要的模型。
12. Docker MCP Catalog and Toolkit：讓 AI Agent 安全使用工具
如果你最近有在玩 AI Agent，一定會聽過 MCP，也就是 Model Context Protocol。
MCP 的概念是讓 AI application 可以連接外部工具與資料來源，例如 GitHub、database、browser automation、file system、internal API 等等。
但 MCP 也帶來新問題：工具從哪裡來？怎麼安裝？怎麼驗證？怎麼管理權限？怎麼避免每台電腦都設定一遍？
Docker MCP Catalog and Toolkit 就是 Docker 針對這個問題推出的工具組。官方文件提到 Docker MCP Catalog 提供 curated collections of MCP servers，而且 Docker MCP Catalog 有 300+ verified servers，這些 servers 被包成 container images，並包含 versioning、provenance 與 security updates。
Docker 現在透過 MCP Toolkit 則是把 AI agent 需要的 tools 也用 container 管理，解決「我的 agent 工具在每台機器設定都不一樣」的問題。
這對企業特別重要。因為 AI Agent 一旦可以連 GitHub、Slack、Notion、database、cloud API，權限與安全就會變成大問題。Docker MCP Toolkit 的價值不是只有「方便安裝 MCP server」，而是讓 MCP server 的分發、執行、驗證與管理更有秩序。
13. Gordon：Docker 也開始有自己的 AI Agent
Docker 還有一個 AI 功能叫 Gordon。
Gordon 不是一般聊天機器人，而是針對 Docker workflow 設計的 AI 助理。官方文件說 Gordon 可以分析你的 Docker environment、提出解法，並在你允許後執行 commands。它可以解釋 Docker concepts、搜尋 Docker documentation、讀寫修改 Dockerfiles、debug container failures、管理 containers、images、volumes、networks。
簡單來說，以前你遇到 container 掛掉，可能會自己查：
docker ps -a
docker logs my-container
docker inspect my-container
docker exec -it my-container sh現在你可以用比較自然語言的方式問：
docker ai "why is my postgres container crashing on startup?"Code language: JavaScript (javascript)官方文件也提到 Gordon 可以透過 Docker Desktop 或 docker ai CLI 使用，而且它會在執行動作前要求使用者 approval。
我覺得這對新手很有幫助，因為 Docker 的學習曲線常常不是「指令太難」，而是「不知道下一步要查什麼」。
例如 container 沒起來，可能是網路問題、權限問題、甚至是 Typo 問題。新手很難知道要先看哪裡。
Gordon 的價值就是把 Docker troubleshooting 的經驗包進一個 agent 裡，協助你更快找到方向。
當然，AI 工具產生的修改還是要自己 review。尤其是 Dockerfile、compose.yaml、production image、安全設定，不應該完全盲目信任 AI。但作為學習與除錯輔助，Gordon 是很值得嘗試的工具。
要了解更多，也可以直接看我前幾天發布的文章：
Docker 新功能”Ask Gordon”：讓 AI 來幫你除錯與修復容器問題
14. Docker Sandboxes：AI Agent 時代，隔離環境會更重要
能力越大，責任越大（？！），AI Agent 越強，安全問題也越明顯。
以前我們是人自己下指令；現在 AI coding agent 可能會幫你裝套件、改檔案、跑測試、啟動服務、存取網路(甚至之前研討會看到有人分享說幫你打電話、幫你下訂單、幫你關冷氣)。這些能力很方便，但也代表風險變大。
Docker Sandboxes 的方向就是：讓 AI coding agents 在隔離的 microVM sandbox 裡執行。官方文件提到 Docker Sandboxes 會讓每個 sandbox 有自己的 Docker daemon、filesystem 與 network，agent 可以 build containers、install packages、modify files，但不會碰到 host system。是不是有夠神奇厲害！
這其實很符合 Docker 的歷史脈絡。
Docker 一開始解決的是「應用程式執行環境隔離」問題。（當然還有輕量化執行、解決環境相依性也都是重點）
現在 AI Agent 時代，Docker 又回到一個很熟悉的問題：如何讓不完全可信任的程式或工具，在可控環境裡執行？
只是以前那個程式可能是 Web App、database、worker；現在那個程式可能是 AI coding agent。
Docker Sandboxes 幾乎是理所當然會成為目前 Docker 最值得關注的項目之一，尤其是未來企業真的開始讓 Codex、Claude Code、Gemini CLI、Kiro 這類工具進入日常開發流程時，隔離、網路政策、credential isolation、workspace scope 都會變成重要議題。
15. Docker Offload：本機 workflow，雲端資源
Docker Offload 是另一個很有趣的方向。
它的概念是：你仍然使用本機熟悉的 Docker Desktop、Docker CLI、Docker Compose，但 build 或 run container 的資源可以 offload 到雲端。官方文件提到 Docker Offload 是 fully managed service，可以使用既有 Docker Desktop、CLI、Compose，把 local development workflow 延伸到 scalable cloud-powered environment。
這對幾種情境很有用：
- 第一，筆電效能不足。
- 第二，公司使用 VDI，不能跑 nested virtualization。
- 第三，需要比較大的 CPU / memory / GPU 資源。
- 第四，希望開發者維持同樣的 Docker workflow，但背後使用雲端資源。
Docker Offload 的重點是「不要改變開發者習慣」。如果工具要求工程師重新學一套流程，導入阻力就會變大。但如果還是同樣的 docker run、docker compose up，只是執行位置換到雲端，那接受度就會高很多。
結語：Docker 不是只有容器，而是一套開發者工作流
如果你只把 Docker 當成「啟動容器的工具」，那 Docker 的價值大概只停留在 docker run。
但如果你把 Docker 看成一套開發者工作流，它的價值就會完整很多。
從本機開發的 Docker Desktop、Compose，到 image build 的 BuildKit、Buildx、Build Cloud；從 image 分享的 Docker Hub，到供應鏈安全的 Scout、Hardened Images；再到 AI 時代的 Model Runner、MCP Toolkit、Gordon、Sandboxes，Docker 其實已經把自己放在現代軟體開發流程的很多關鍵位置。
Docker 的故事絕對不是停在 container。Container 是它的起點，也是它最強大的支撐，但不是終點。
在 AI 越來越進入開發流程的時代，Docker 其實也會變得更重要(也包含容器的重要性提升)。因為我們會更需要一致的環境、更安全的隔離、更可控的工具鏈、更清楚的 artifacts 管理方式。
如同開頭所提，今天沒有任何太技術性與深入的內容，今天是一場對於 Docker 產品與功能的分享，讓以為 Docker 還停留在只有容器的人，了解目前的 Docker 地圖與故事。
而是應該說：
Docker 是一張從 runtime、develop、build、security，一路延伸到 AI agent 的開發者地圖。
以下附上第二張我把內容丟給 AI 後它所產生的 Docker 地圖 🙂
