Docker 與 Docker Compose 完全指南：從容器化到微服務部署實戰

在現代軟體開發中，容器化技術已成為不可或缺的核心技能。Docker 作為容器化的領導者，不僅解決了「在我的電腦上可以運行」的經典問題，更為微服務架構、CI/CD 流程、雲端部署奠定了基礎。而 Docker Compose 則進一步簡化了多容器應用的管理與編排。

本文將深入探討 Docker 與 Docker Compose 的核心概念、設定檔語法、實際應用場景，並提供完整的實務範例。無論您是剛接觸容器化技術的開發者，還是希望深化 DevOps 技能的工程師，都能從中獲得實用的知識與技巧。

Docker 核心概念深度解析

容器化技術的本質

容器化是一種作業系統層級的虛擬化技術，它將應用程式及其相依性封裝在一個輕量級、可移植的容器中。與傳統虛擬機器相比，容器共享主機的核心，因此具有更高的效能和資源利用率。

graph TD
    A[物理主機] --> B[主機作業系統]
    B --> C[Docker Engine]
    C --> D[容器 1]
    C --> E[容器 2]
    C --> F[容器 3]
    
    D --> D1[應用程式 A]
    D --> D2[函式庫與相依性]
    
    E --> E1[應用程式 B]
    E --> E2[函式庫與相依性]
    
    F --> F1[應用程式 C]
    F --> F2[函式庫與相依性]

Docker 架構組成

Docker 採用客戶端-伺服器架構，主要包含以下組件：

Docker Client：使用者介面，負責與 Docker Daemon 通訊
Docker Daemon (dockerd)：核心服務，管理映像檔、容器、網路和儲存
Docker Registry：映像檔倉庫，如 Docker Hub、私有 Registry
Docker Objects：映像檔 (Images)、容器 (Containers)、網路 (Networks)、儲存卷 (Volumes)

Dockerfile 深度剖析

Dockerfile 的設計哲學

Dockerfile 是定義映像檔建置過程的純文字腳本，每個指令都會在映像檔中建立一個新的層（Layer）。理解這個「層」的概念，是寫出高品質 Dockerfile 的基礎。

Docker 映像檔是由多個唯讀層疊加而成的聯合文件系統（Union File System）。每執行一個 RUN、COPY、ADD 指令，就會建立一個新層並記錄該層的變化。這個設計帶來了兩個重要特性：

層級快取（Layer Caching）：Docker 建置映像檔時，對每個指令會計算其「快取鍵」（來自指令內容 + 父層的 hash）。若快取鍵相同，則直接沿用已有的層，跳過實際建置。這意味著指令的排列順序直接影響建置速度——變化頻率低的指令應排在前面，頻繁變化的（如複製原始碼）排在後面。一旦某層快取失效，後續所有層都必須重新建置。

共享儲存：相同的層可以被多個映像檔共享。在一台機器上拉取多個基於 node:18-alpine 的映像檔，這個基礎層只需儲存一份，大幅節省磁碟空間和網路傳輸量。

多階段建置：現代 Dockerfile 的核心技術

多階段建置（Multi-stage Build）是解決「建置環境污染最終映像檔」問題的關鍵手段。

以一個 Go 應用為例：建置 Go 程式需要完整的 Go 編譯工具鏈（數百 MB），但運行只需要一個靜態二進位執行檔（幾 MB）。多階段建置允許你在一個 Dockerfile 中定義多個 FROM 階段，最終只保留你需要的部分：

# 第一階段：建置環境（完整工具鏈，僅用於編譯）
FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download          # 先下載依賴（利用快取層）
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o main .

# 第二階段：生產環境映像檔（極度精簡）
FROM alpine:latest
RUN apk --no-cache add ca-certificates tzdata
RUN adduser -D -s /bin/sh appuser
WORKDIR /root/
COPY --from=builder /app/main .   # 只複製編譯產物
RUN chown appuser:appuser main
USER appuser                       # 以非 root 身份執行
EXPOSE 8080
HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost:8080/health || exit 1
CMD ["./main"]

這個 Dockerfile 體現了三個關鍵安全與效能原則：

最終映像檔不含 Go 工具鏈，攻擊面極小
使用非 root 使用者執行，即使容器被突破也難以提權
HEALTHCHECK 讓 Docker 能自動偵測並替換不健康的容器

層級快取的實際影響

快取策略是 Dockerfile 優化中最常被忽視的面向。考慮套件安裝的順序：若將 COPY . .（複製全部原始碼）放在 npm install 之前，每次任何一個原始碼文件改動，都會觸發套件重新安裝——即使 package.json 完全沒變。正確做法是先只複製依賴定義文件，安裝後再複製所有原始碼，讓套件安裝層保持穩定的快取，只有原始碼變更時才重新建置應用程式本身。

.dockerignore 文件是另一個常被忽略的優化點，其作用類似 .gitignore：將 node_modules/、build/、.git/ 等目錄排除在建置上下文（Build Context）之外，避免這些龐大的目錄被傳輸到 Docker Daemon，大幅加速建置速度。

Docker Compose 詳細解析

Docker Compose 的核心價值

Docker Compose 解決了多容器應用編排的複雜性問題。在微服務架構中，一個完整的應用可能包含：

Web 伺服器容器
資料庫容器
快取容器
訊息佇列容器
監控容器

手動管理這些容器的啟動順序、網路連接、資料持久化是極其複雜的，Docker Compose 提供了宣告式配置（Declarative Configuration）來簡化這個過程——你描述「應用應該是什麼樣子」，而不是「如何讓它變成那樣」。

Docker Compose 的核心組成

一個完整的 docker-compose.yml 由四個頂層區塊構成，各自解決不同問題：

services（服務）：定義應用的每個組件。每個服務對應一個容器（或多個副本），你可以在這裡指定映像來源（拉取或建置）、環境變數、端口映射、磁碟掛載、依賴關係等。服務名稱也自動成為容器間的 DNS 主機名——backend 服務可以直接用 http://backend:8080 訪問 frontend 服務，無需配置 IP。

networks（網路）：Docker Compose 預設為所有服務建立一個共用的 bridge 網路。但在需要隔離的場景下（如資料庫不應被前端直接訪問），可以定義多個網路，每個服務加入不同的網路集合。設定 internal: true 的網路完全隔離於外部，只有同一網路中的服務才能互相通訊，大幅縮小攻擊面。

volumes（儲存卷）：容器的文件系統在容器刪除後消失，volumes 是持久化數據的唯一標準方式。對於資料庫數據目錄（如 /var/lib/postgresql/data），必須掛載 volume；對應用程式的上傳文件、日誌等也應使用 volume。命名 volume 由 Docker 管理存儲位置，比直接掛載主機路徑更具可移植性。

secrets（密鑰）：直接在 environment 中寫入密碼是嚴重的安全漏洞，因為環境變數很容易洩漏（docker inspect、日誌、錯誤訊息都可能暴露）。Docker Secrets 將敏感數據以加密方式存儲，並以文件形式（/run/secrets/<name>）掛載到容器中，使用時由應用程序讀取文件內容，而非環境變量。

服務依賴與啟動順序

depends_on 是控制服務啟動順序的核心機制，但它有一個常被誤解的限制：depends_on 只等待依賴服務的容器啟動，不等待服務內的進程就緒。

資料庫容器啟動（Docker 層面）和 PostgreSQL 接受連線（應用層面）之間可能有十幾秒的差距。若後端服務在 PostgreSQL 還在初始化時就嘗試連接，連線會失敗。正確的做法是結合 healthcheck 使用 condition: service_healthy——只有當健康檢查通過（表明資料庫真正就緒）後，依賴的服務才會啟動。

services:
  backend:
    depends_on:
      postgres:
        condition: service_healthy   # 等待 PostgreSQL 健康檢查通過

  postgres:
    image: postgres:15-alpine
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      retries: 5
      start_period: 30s              # 給容器額外的啟動寬限時間

環境管理策略

容器化應用通常需要在開發、測試、生產三種環境中運行，各環境的配置差異顯著（資料庫地址、API 密鑰、日誌等級、資源限制等）。最佳實踐是採用「基礎 + 覆蓋」的分層策略：

docker-compose.yml 定義所有環境共用的服務結構；docker-compose.dev.yml 覆蓋開發環境的特定配置（如掛載本地代碼熱重載、開放調試端口）；docker-compose.prod.yml 覆蓋生產環境配置（如資源限制、日誌策略、副本數量）。使用時：

# 開發環境：合並基礎和開發覆蓋
docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d

# 測試環境
docker compose -f docker-compose.yml -f docker-compose.test.yml up -d

這種策略的優點是每個環境的差異都顯式記錄在版本控制中，避免了「靠腦袋記住要改哪些設定」的脆弱性。

關鍵指令速查

Docker Compose 的日常操作只需掌握幾個核心指令：

docker compose up -d：背景啟動所有服務（-d 為 detached 模式）
docker compose down：停止並移除容器、網路；加 -v 同時刪除 volumes
docker compose logs -f <service>：即時追蹤服務日誌
docker compose exec <service> sh：進入運行中的容器（調試神器）
docker compose ps：查看所有服務狀態
docker compose restart <service>：重啟特定服務而不影響其他服務

實際應用場景深度分析

場景一：微服務開發環境

微服務架構要解決的核心問題是如何讓多個獨立服務既能各自開發，又能組合為整體運行。Docker Compose 在開發環境中的最大價值，是讓「本地啟動整個系統」從數小時的配置工作縮減為一條指令。

典型的微服務 Compose 配置會組合：API Gateway（統一入口，路由到各服務）、多個業務服務（各有獨立資料庫）、共享的基礎設施服務（Redis 快取、Kafka 訊息佇列）。每個業務服務的資料庫相互隔離（user-db、order-db 等），遵循微服務「每個服務自管資料」的原則，避免服務間通過資料庫直接耦合。

開發環境的特殊配置重點是熱重載（Hot Reload）：通過 volume 掛載本地代碼目錄到容器中，應用程序監聽文件變更後自動重啟（Node.js 通常用 nodemon，Go 用 air）。這樣開發者在本地修改代碼，無需重建映像就能立即看到效果。

場景二：CI/CD 測試環境

CI 管線中使用 Docker Compose 的關鍵需求是環境隔離與快速啟動。每次 CI 執行都應在完全乾淨的環境中運行，避免測試間相互污染。

最佳實踐是使用 tmpfs（RAM 文件系統）掛載資料庫數據目錄，這樣測試用的資料庫完全在記憶體中運行，速度比磁碟 I/O 快 10-100 倍，CI 結束後自動清理，無需手動重置。

場景三：生產環境部署

生產環境的 Compose 配置與開發環境有根本性差異，核心關注點是穩定性、安全性和資源控制。

資源限制（deploy.resources）是生產必備配置。不設置限制的容器在資源競爭時可能佔用所有 CPU 或記憶體，導致同一主機上其他服務雪崩。limits 設定硬上限，reservations 設定保留量以保證服務基本運行。

重啟策略（restart_policy）決定容器崩潰後的行為。on-failure 表示只在異常退出時重啟（正常退出代碼 0 不重啟），配合 max_attempts 防止無限重啟死循環耗盡資源。

效能優化與安全性考量

映像檔大小優化

映像檔大小直接影響 CI/CD 流水線速度、部署時間和攻擊面。基礎映像的選擇是最重要的決策：

Alpine Linux 是最常用的精簡基底，體積僅 5MB，大多數常見工具都有 alpine 版本（node:18-alpine、python:3.11-alpine）。Alpine 使用 musl libc 而非標準 glibc，極少數場景下可能導致相容性問題，但在 99% 的 Web 服務場景中完全透明。

Distroless 映像（由 Google 維護）比 Alpine 更進一步——它只包含應用程序和其直接運行時依賴，不包含 shell、包管理器等工具。這使得攻擊者即使突破容器也難以執行多步驟攻擊（因為沒有 wget、curl 等工具）。缺點是調試困難，需要分開調試和生產映像。

FROM scratch 是 Go 等編譯型語言的終極方案，直接以空映像為基礎，只放入靜態鏈接的二進制文件。映像可以小到幾 MB，但只適用於自包含的靜態可執行文件。

容器安全的核心原則

以非 root 使用者運行是容器安全的最基本要求。預設情況下，容器進程以 root（UID 0）運行，若容器被突破，攻擊者等同於獲得主機的 root 等效能力（取決於 Docker 配置）。在 Dockerfile 中建立專用用戶（RUN adduser -D appuser）並在最後一層切換（USER appuser），可以將攻擊者的能力限制在最小化範圍。

最小化映像內容也是重要原則：不安裝不需要的工具，不保留建置工具，不包含開發依賴。攻擊者無法利用不存在的工具。多階段建置天然實現了這一點。

掃描映像檔漏洞：Docker Hub、AWS ECR 等倉庫都提供內建的漏洞掃描；Trivy 是最流行的開源工具，可以在 CI 中對每次建置的映像做 CVE 掃描。定期更新基礎映像版本，以獲取上游的安全修補。

監控與日誌管理

健康檢查的設計原則

HEALTHCHECK 指令定義 Docker 如何判斷容器是否健康。設計良好的健康檢查端點（通常是 /health 或 /healthz）應該：

快速響應：健康檢查應在毫秒級完成，不應執行耗時的資料庫查詢。如需驗證依賴連通性，用獨立的就緒探針（Readiness Probe）
反映真實狀態：不僅確認進程在運行，還應檢查關鍵依賴（資料庫連線池是否正常、記憶體是否超閾值）
適當的頻率與容忍度：start_period 給予應用足夠的啟動時間，避免在應用初始化期間觸發不必要的重啟；retries 允許偶發失敗，防止抖動（flapping）

日誌策略

容器化應用的日誌最佳實踐是寫入 stdout/stderr 而非文件，讓 Docker 的日誌驅動統一處理。這樣做的好處是：日誌格式標準化、不需要在容器內管理日誌輪替、可以用 docker logs 直接查看、易於接入集中式日誌系統。

生產環境應配置 json-file 日誌驅動的 max-size 和 max-file 限制，防止日誌文件無限增長吃滿磁碟。對於需要集中日誌分析的場景，Loki + Promtail（輕量）或 ELK Stack（功能豐富）都是成熟方案。

故障排除指南

診斷思路

容器化環境的問題診斷通常遵循「由外到內」的層次：

容器是否在運行？：docker compose ps 查看狀態。若容器反覆重啟（Restarting）說明啟動後立即崩潰，查看日誌找原因
日誌說什了什麼？：docker compose logs <service> 是第一個看的地方。大多數啟動問題的根因（端口衝突、配置文件錯誤、依賴未就緒）都會在日誌中體現
網路是否連通？：docker compose exec <service> ping <other-service> 測試容器間連通性。若無 ping，用 wget -qO- http://<other-service>:port/health 也可以
環境變數是否正確？：docker compose exec <service> env | grep DB_ 驗證特定環境變數值，排除配置錯誤