code {
font-f
border: 1
blockquote {
border-left: 5
de
MYSQL_D
volumes:
Volumes 具名磁碟：資料庫的資料一定要放在具名磁碟，否則容器一刪除，資料就消失了。
Profiles：可以定義不同環境（如 dev、prod）的服務集合，啟動時用 --profile 指定。
3-2 實際案例：搭建 WordPress + MySQL 環境
讓我們做一個 2026 年實務上幾乎每天都在發生的練習：用 Docker Compose 在 3 分鐘內啟動一個 WordPress 站點。建立一個 wordpress-compose/ 資料夾，裡面放入下面的 docker-compose.yml：
name: wp-demo
services:
wordpress:
image: wordpress:6.8-php8.3-apache
ports:
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: wpuser
WORDPRESS_DB_PASSWORD: wppassword
WORDPRESS_DB_NAME: wpdb
volumes:
depends_on:
db:
condition: service_healthy
restart: unless-stopped
db:
image: mysql:8.4
command: --default-authentication-plugin=mysql_native_password
environment:
MYSQL_DATABASE: wpdb
MYSQL_USER: wpuser
MYSQL_PASSWORD: wppassword
MYSQL_ROOT_PASSWORD: rootpassword123
volumes:
healthcheck:
test: ["CMD-SHELL", "mysqladmin ping -h localhost -u root -prootpassword123"]
interval: 5s
timeout: 5s
retries: 20
volumes:
wp-data:
db-data:
啟動方式非常直覺：
docker compose up -d
docker compose ps
打開瀏覽器輸入 http://localhost:8000，你就能看到 WordPress 安裝畫面。完成之後，想要關閉環境只需要：
docker compose down # 停止並移除容器
docker compose down -v # 連同資料一起清除（謹慎使用！）
這就是 Docker Compose 帶給我們的效率革命：基礎設施的描述檔案可以納入版本控制（Git），新成員加入團隊時，只要 git clone 再 docker compose up，獨立的完整開發環境立即重現。
四、Docker 進階實戰：映像檔最佳化與安全防護
只是把應用程式容器化還不夠，2026 年的企業在資安稽核與上線成本控制上，對容器映像檔有更高的要求。本節我們深入探討兩個關鍵主題：映像檔瘦身與安全加固。
4-1 多階段建構（Multi-stage Build）技巧
在過去，我們常需要在 Dockerfile 中安裝大量的編譯工具（例如 gcc、make）來建置程式，這些工具會殘留在最終映像檔中，導致映像檔肥大、漏洞攻擊面增加。多階段建構（Multi-stage Build）完美解決了這個問題。概念很簡單：你可以使用多個 FROM 指令，前面的階段用來「編譯」，最後一個階段只複製編譯好的產物。
以下以 Go 語言程式為例，展示 2026 年最常見的多階段建構寫法：
# ===== 第一階段：編譯 =====
FROM golang:1.24-alpine AS builder
WORKDIR /src
複製 go.mod 與 go.sum（善用快取）
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o /app/my-service .
===== 第二階段：執行 =====
FROM alpine:3.21
安裝憑證（如果要呼叫外部 HTTPS API 需要）
RUN apk --no-cache add ca-certificates tzdata
WORKDIR /root/
COPY --from=builder /app/my-service .
EXPOSE 8080
CMD ["./my-service"]
最終的映像檔只包含「編譯後的執行檔」與最小化的 Alpine Linux 使用者空間，大小可能從原本的 800MB 縮減到 15MB 以內。不僅節省了存放空間，也大幅降低了潛在的安全性弱點。
💡 2026 進階心法：如果你使用的是 Rust、Go、C# 這類可編譯為原生碼的語言，甚至可以考慮「Distroless」（例如 gcr.io/distroless/static）映像檔，它連 Shell 都沒有，駭客即使突破也只能對著空殼發呆，安全性等級再上一層樓。
4-2 映像檔漏洞掃描與最小權限原則
2026 年的職場安全檢查已經將「映像檔漏洞掃描」列為 CI/CD 的必經關卡。最常用的工具包括：
Trivy（最推薦）：由 Aqua Security 開發，開源免費，掃描速度極快，而且支援 OS 套件與語言相依套件（Python、Node.js、Go 等）。
Grype：另一個高效的開源掃描器，與 Syft（產生 SBOM）整合良好。
Docker Scout：內建於 Docker Desktop 與 Docker Hub，企業版整合度佳。
基本掃描使用方式如下：
trivy image --severity HIGH,CRITICAL my-flask-app:v1
除了掃描之外，還必須養成「最小權限」意識：
# 在 Dockerfile 末尾建立非 root 使用者並切換
FROM python:3.12-slim
RUN useradd --create-home --uid 10001 appuser
WORKDIR /app
COPY --chown=appuser:appuser . .
USER appuser
EXPOSE 5000
CMD ["python", "app.py"]
⚠️ 資安鐵則：容器中執行的 process 絕對不要使用 root 權限。2026 年，Kubernetes Pod Security Admission 的 restrictedallowPrivilegeEscalation: false、runAsNonRoot: true）幾乎成了大型企業的預設標準，現在養成習慣，之後接軌 K8s 才不會處處碰壁。
五、Kubernetes 整合實戰：將 Docker 應用推向叢集
恭喜你撐到這一節！前面的 Docker 基礎、Compose、映像檔最佳化，都是為了讓我們能平穩地踏上 Kubernetes 這艘航空母艦。Kubernetes（簡稱 K8s）是當代容器編排的標準，它負責處理多台機器的容器部署、自動擴縮容、服務發現、負載平衡、滾動更新與自癒機制。
5-1 從 Docker 到 Kubernetes 的思維轉變
許多 Docker 初學者第一次接觸 K8s 時會非常受挫，因為概念架構完全不一樣。這裡我用最白話的類比幫你拆解：
| Docker Compose 概念 | Kubernetes 對應概念 | 說明 |
|---|
| Service（服務） | Deployment（部署） | 管理 Pod 的數量與版本，處理滾動更新 |
| Container（容器） | Pod（豆莢） | 最小調度單位，可以包含 1 個或多個容器 |
| Network（自訂網路） | Service（服務抽象層） | 提供穩定 IP 與 DNS 名稱給外部存取 |
| Volume（磁碟掛載） | PersistentVolumeClaim（PVC） | 宣告持久化儲存，Pod 掛掉後資料仍留存 |
| depends_on | Init Containers 或 Healthcheck | 保證相依服務啟動順序 |
| docker compose scale | HorizontalPodAutoscaler（HPA） | 依 CPU/記憶體自動增減 Pod |
簡單說，Docker Compose 偏向「單機多容器」的局部編排，而 K8s 是「多機叢集」的全域調度。當一台機器不夠用、需要做到高可用、自動修復與動態擴縮時，K8s 的價值立刻體現。
5-2 使用 kind / minikube 建立本機叢集
2026 年在自己的開發機上面建立 K8s 叢集，最主流的方案有兩種：
minikube：老牌的單節點或多節點本機叢集工具，適合需要完整 CNI、Dashboard、可能額外掛載目錄的開發者。
kind（Kubernetes in Docker）：顧名思義，它以 Docker 容器模擬 Node 節點。啟動速度極快、資源占用低，非常適合 CI/CD 流程中使用。
我個人偏好在 2026 年的日常開發使用 kind，以下是秒級建立叢集的實戰方式：
# 建立 kind 叢集（預設名稱為 kind）
kind create cluster --name yabao-demo
確認叢集資訊
kubectl cluster-info --context kind-yabao-demo
查看所有節點（理論上會有一個 master 節點，也是 Docker 容器）
kubectl get nodes
5-3 部署第一個 Pod 與 Deployment
現在，讓我們把先前建置的 my-flask-app:v1 映像檔部署到 K8s。首先，將映像檔載入 kind 叢集（因為 kind 內部的容器與你的主機 Docker daemon 是隔離的）
# 將 Docker 映像檔載入 kind 節點
kind load docker-image my-flask-app:v1 --name yabao-demo
接著，建立一個名為 deployment.yaml 的檔案，內容如下：
apiVersion: apps/v1
kind: Deployment
metadata:
name: flask-demo
labels:
app: flask-demo
spec:
replicas: 3
selector:
matchLabels:
app: flask-demo
template:
metadata:
labels:
app: flask-demo
spec:
containers:
image: my-flask-app:v1
ports:
env:
value: "5000"
resources:
requests:
memory: "128Mi"
cpu: "250m"
limits:
memory: "256Mi"
cpu: "500m"
securityContext:
runAsNonRoot: true
runAsUser: 10001
套用設定檔，並查看 Pod 狀態：
kubectl apply -f deployment.yaml
kubectl get pods -o wide
此時你應該會看到 3 個 flask-demo-XXXXX-YYYYY 的 Pod，接著建立 Service 對外暴露：
apiVersion: v1
kind: Service
metadata:
name: flask-demo-svc
spec:
selector:
app: flask-demo
ports:
port: 80 # Service 對外開放的 port
targetPort: 5000 # 轉送到容器的 port
type: NodePort
kubectl apply -f service.yaml
kubectl get svc flask-demo-svc
如果看到 NodePort 隨機分配（例如 31345），您可以直接訪問：
curl http://127.0.0.1:31345
✅ 驗收重點：這個看似簡單的範例，實際上已經涵蓋了 K8s 最核心的機制：宣告式 Desired State（期望狀態）、ReplicaSet 維護 Pod 數量、Service 提供穩定存取。接下來你就可以試著修改 replicas 為 5 再重新 apply，觀察 K8s 如何自動產生新的 Pod！
六、2026 年容器化趨勢與常見陷阱
最後一個章節，我們來整理 2026 年容器化領域的大環境趨勢，以及初學者最容易踩到的雷區，幫助你在職涯上走得比別人更穩。
6-1 2026 年容器化常見地雷
地雷一：將容器當作小型的 VM。這是最多人犯的錯誤。容器是「單一用途的執行進程」，不是可以隨意 SSH 進去亂搞的作業系統。2026 年，不可變基礎設施（Immutable Infrastructure）已經成為主流：在容器中「手工修」任何東西都是邪門歪道，正確做法是修改 Dockerfile 並重新建置新的映像檔。
地雷二：忽略 ephemeral（短生命週期）特性。Pod 隨時可能被刪除、重建、遷移，如果應用程式把重要資料寫在容器內部的檔案系統，那就是在玩火。務必把 Session、上傳檔案、資料庫內容等有狀態資料導出到外部儲存（Volume、物件儲存、雲端資料庫）。
地雷三：不設定資源限制。如果你在 Deployment 中沒有設定 resources.requests 與 resources.limits，一個記憶體洩漏的 Pod 就可能拖垮整台 Node，導致其他 Pod 被 OOM Killer 幹掉。2026 年優秀的 DevOps 工程師，一定會在 application 上線前就設定好資源配額（ResourceQuota）。
地雷四：憑證與密鑰寫在映像檔裡。請務必使用 K8s 的 Secret 物件或外部密鑰管理系統（如 HashiCorp Vault）。映像檔一旦上傳到映像倉庫，裡面的任何機密都會被所有能看到倉庫的人看光。
6-2 後續學習路線圖
恭喜你完成本實戰指南！從 Docker 基礎指令、Dockerfile、Compose 到 K8s 的 Deployment 與 Service，你已經具備了進入雲原生領域的基礎戰力。筆者建議的後續學習路線如下：
熟悉進階 K8s 操作：ConfigMap、Secret、StatefulSet、Ingress Controller 的設定。
學習 GitOps：2026 年，Argo CD 與 Flux 已是 GitOps 的兩大霸主，用 Git 管理叢集狀態是標準做法。
掌握監控維運：延伸學習 Prometheus + Grafana 建立可觀測性（Observability），並加入 OpenTelemetry 追蹤分散式請求。
了解多叢集與雲端服務：當規模擴大後，EKS、GKE、AKS 的整合，以及 Cluster API 的多叢集管理，才是企業徵才時真正的分水嶺。
關注 WASM 與容器融合：近年來 WebAssembly 與容器在 Serverless 場景中的結合越來越緊密（如 SpinKube 專案），建議保持高度關注。
2026 年的技術環境變化雖然快速，但容器化的核心思維「標準化、可攜帶、可預期」仍然不變。希望這篇文章能成為你職涯成長階梯上的一塊穩固磚頭，我們「雅寶社區 · 頂客論壇」的夥伴們共同勉勵，繼續在技術的路上一起進化！
📌 本文同步刊載於《雅寶社區 · 頂客論壇》3C 科技教學版。歡迎轉載分享，務必註明出處。如有任何實戰問題，歡迎在討論區留言板提出，我們一起切磋！
© 2026 雅寶社區 · 頂客論壇 — 初衷不改，技術不息。
[[[[[💬]]]]] 留言討論
歡迎在下方留言，分享您的想法、心得或疑問。所有留言都會透過 GitHub 帳號 進行驗證。
🏠 返回首頁
