昨天我們聊了 藍綠部署 (Blue-Green Deployment)。那種方式很帥：兩套環境先備好，最後一刀切換，像是棒球場上換整個投手群。

但如果你沒有兩倍的資源怎麼辦？
或者你希望「慢慢換，隨時能喊停」呢？

這時候，就輪到今天的主角登場：滾動更新 (Rolling Update)。

滾動更新是什麼？

簡單一句：新舊版本交替出現，逐個替換，直到最後全數換完。

• 藍綠部署：一次切換 → 「舊隊伍下去，新隊伍全上」。
• 滾動更新：慢慢替換 → 「一個一個換下來，新人上場，直到全部換完」。

你可以把它想成《進擊的巨人》裡換兵線：不是瞬間整隊調防，而是小隊一批批換班，前線永遠有人頂著。

為什麼要滾動更新？

因為它解決了三個痛點：

1. 不中斷服務
   就算有一半在更新，另一半還在跑，流量不中斷。

2. 不用雙倍資源
   不像藍綠需要維護兩套完整環境，滾動更新只需要容器副本數大於 1，就能邊跑邊換。

3. 隨時喊停
   如果新版本有 bug，滾動更新可以卡在中間，不用全軍覆沒。

實作：用 docker-compose 模擬

雖然滾動更新通常跟 Kubernetes 綁在一起，但也能用 Docker 的 update_config 來體驗：

services:
  app:
    image: ghcr.io/you/yourapp:latest
    deploy:
      replicas: 3
      update_config:
        parallelism: 1   # 一次只更新 1 個容器
        delay: 10s       # 更新間隔
      restart_policy:
        condition: on-failure

這代表：

• 有 3 個容器副本在跑。
• 更新時會一個一個替換（不是一次全部 kill 掉）。
• 每換一個會等 10 秒，再換下一個。

更新過程就像一場接力賽：有人在跑，有人慢慢換新鞋。

滾動更新雖然穩，但也有地雷：

1. 健康檢查必須要有
   不然就變成「慢動作自殺」──壞版本還是會一個一個被推上線。
   建議用 /healthz 之類的 endpoint，確保容器真的能服務流量才換下一個。

2. 版本標記要清楚
   新舊版本會共存一段時間，沒有標記就會混亂。
   例如 log 裡應該能分辨這是 v1 還是 v2。

3. 回滾策略要備好
   如果更新到一半發現爆炸，要能馬上停掉，把已更新的容器換回舊版本。
   這通常靠 CI/CD 裡的「固定 tag（commit SHA）」來實現。

總結

• 藍綠部署：快狠準，像是一次換整支隊伍，但需要兩倍資源。
• 滾動更新：穩紮穩打，像是輪流換人打副本，資源花費低，但要能忍受新舊版本共存。

在現實中，

• 小團隊 / 資源有限：滾動更新更適合。
• 大流量 / 不能出錯：藍綠部署更常見。

兩者沒有絕對好壞，只有在什麼場景下選哪個更合理。

就像打副本，有時候需要全員全力爆發，有時候更需要穩定輪替。
滾動更新，就是那種穩穩踩節拍，不求快但求穩的打法。