「這個在我電腦上明明沒問題，為什麼你的環境跑不了？」

這句話大概是軟體開發史上最讓人崩潰的一句話了。在我職業生涯的早期，每次新進一個同事，就要花半天甚至整天陪他設定開發環境。

後來我開始認真用 Docker，這個問題幾乎消失了。

我們的舊系統有多亂？

一個中等規模的 B2B 系統，後端的依賴通常包含：

• SQL Server（有特定版本要求）
• Redis（用來做快取和 Session）
• RabbitMQ（訊息佇列）
• 一個或多個自己寫的後端服務（可能 Port 還不一樣）
• Nginx（本機模擬 Reverse Proxy）

過去要讓這一切跑起來，你需要一份長達 3 頁的安裝說明文件，而且這份文件通常是過期的。

Docker Compose 的解決方案

現在我的標準做法是在每個專案的根目錄放一個 docker-compose.yml：

version: '3.9'
services:
  db:
    image: mcr.microsoft.com/mssql/server:2022-latest
    environment:
      SA_PASSWORD: "YourStr0ngPassword!"
      ACCEPT_EULA: "Y"
    ports:
      - "1433:1433"
    volumes:
      - sqldata:/var/opt/mssql

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

  rabbitmq:
    image: rabbitmq:3-management
    ports:
      - "5672:5672"
      - "15672:15672"  # Management UI

  api:
    build: ./src/YourApi
    depends_on:
      - db
      - redis
      - rabbitmq
    ports:
      - "5000:80"
    environment:
      ConnectionStrings__Default: "Server=db;..."
      Redis__Connection: "redis:6379"

volumes:
  sqldata:

現在新同事加入，只需要安裝 Docker Desktop，然後在專案根目錄執行：

docker compose up -d

等個 1 到 2 分鐘，整個開發環境就全部啟動了。沒有安裝說明文件，沒有版本衝突，沒有「我的系統上沒有這個功能」。

幾個實戰踩坑的筆記

1. Volume 的資料持久化

SQL Server 的資料如果沒有掛 Volume，每次 docker compose down 就會清空。記得在 services.db 加上 volumes: - sqldata:/var/opt/mssql，並且在最底部定義 volumes: sqldata:。

2. 服務啟動順序

depends_on 只保證「容器啟動了」，不代表「服務準備好了」。SQL Server 啟動後還需要幾秒鐘才能接受連線。最好在你的應用啟動邏輯中加入重試機制（Retry with exponential backoff）。

3. 環境變數管理

不要把密碼寫死在 docker-compose.yml 裡，而是用 .env 檔案搭配 ${VARIABLE_NAME} 的方式引用，並把 .env 加入 .gitignore。

# .env（加入 .gitignore）
MSSQL_SA_PASSWORD=YourStr0ngPassword!

---

容器化改善了我們團隊的協作效率，也讓 CI/CD 的部署流程變得更加可預測。如果你的專案還在用「上板說明文件」來設定環境，我真心推薦你花一個下午試試看 Docker Compose。