前言

到目前為止，我們花了 19 天練習 CI，把程式碼測過、掃過，確保「不會壞」。
但程式還只是關在 pipeline 裡的考卷，沒真的跑起來。

今天的重點就是：讓程式能安全地走到線上。

這裡有一個常見誤區：
很多人以為 CI/CD 就是「自動部署」，越快越帥。
但如果你只是把漏洞用更快的速度送到 production，那不是 DevSecOps，那是自動化送頭。

所以我們要多一層腦袋：

• 供應鏈安全：Build 在 CI，伺服器只 Pull。
• 最小權限：誰能推、誰能拉，分清楚。
• 邊界控管：Caddy 幫你把所有流量收斂到 HTTPS。

Caddy 是一個反向代理伺服器，最大的好處是能自動幫你申請與續約 HTTPS 憑證，不用再自己跟 Let’s Encrypt 周旋，也能幫忙做流量轉發。

• 健康檢查：上線要等服務真的能回應，才算成功。
• 可回滾：版本同時保留 latest 與 commit SHA，必要時能快速退回。

就像進副本前隊伍先把盾、補、嘲諷都就位，然後才開始打輸出。
這樣才不會一邊衝鋒、一邊把破口一起帶進戰場。

架構概覽

如果把整個流程畫成地圖，大概是這樣：

1. GitHub：程式碼推上去，CI 幫忙建構 Docker image。
2. GHCR（GitHub Container Registry）：image的倉庫，像中央廚房冷藏起來。
3. EC2：伺服器不再炒菜，只拿成品加熱。
4. Caddy：站在門口收流量，幫你簽 HTTPS，確保大家都走安全門進來。
5. App.py：真正跑起來的程式，會對外喊「/healthz 我還活著！」。

整個架構的任務就是把「已經測過的裝備」送到戰場上，並且確保每個流程都有人把關。

為什麼 Build 要待在 CI？

有些人第一次接觸自動部署，腦中會想：
「反正我有 EC2，直接 git pull 再 docker build 不就好了？」

聽起來合理，但其實踩了大坑。

CI/CD 的精神是 供應鏈安全。
Build 這件事，應該在 CI 時就完成，產生一個乾淨的映像丟到 GHCR。
Production（EC2）只做一件事：拉映像、跑起來。

為什麼？因為：

• CI 環境統一，建出來的結果可重現，不會「我這台能跑、你那台炸掉」。
• EC2 少了編譯器、少了額外工具，攻擊面更小。
• 回滾更快：只要換回前一個 tag，不用再等一次 build。

建立AWS EC2

官方定義：Amazon EC2 是 AWS 雲端上的虛擬機器。翻譯成人話，就是「你在 AWS 上租了一台遠端電腦」。

建立步驟：

1. 建好 AWS 帳號後進入 EC2 頁面，點「啟動執行個體」。
   

2. 作業系統選 Amazon Linux，機型選 t3.micro —— 只能說免費真香。

3. 其他設定先不動，直接啟動。

安全群組（Security Group）：

伺服器啟動後，要記得改 inbound rules：

1. HTTP/80/TCP : 0.0.0.0/0
2. HTTPS/443/TCP : 0.0.0.0/0
3. SSH/22/TCP : 0.0.0.0/0（⚠️ 初學者可先暫時這樣，方便 GitHub Actions 連線。但正式環境建議收斂到自己的 IP，或用自託管 Runner / SSM，安全性更高。）

這裡就像開城門：80/443 是對全世界的入口，但 22 是後門，不該長期敞開。測試可以放寬，長遠要記得收回。

邊界與憑證：誰能進來？怎麼進來？

伺服器建好只是第一步，接下來就是思考：
「誰能進來？怎麼進來？」
這就是邊界控管與憑證管理。

在 AWS 裡，邊界的第一道牆是 Security Group。它就像副本的結界：你要指定哪些門能打開，哪些路徑完全封死。

• HTTP / 80 → 大門，人人能走。
• HTTPS / 443 → 鐵門，人人能走但要安全。
• SSH / 22 → 只有守門人能用的密道。

到這裡我們就要出場一位重要 NPC —— Caddy。
它是一個反向代理伺服器，最大賣點是能自動幫你申請與續約 HTTPS 憑證，不用再自己和 Let’s Encrypt 輸入一大串指令。更棒的是，它還能幫你做流量轉發，把外面的請求正確導到內部的服務。

有了 Caddy，你的流量就像進王城：

• 外部訪客一定要從正門進來（HTTPS）。
• Caddy 幫忙驗票、發通行證（憑證）。
• 然後才把人導到正確的區域（你的 App）。

這樣就算有人想從小路鑽進來（HTTP / localhost），也會被 Caddy 轉到安全通道。

健康檢查與回滾：上線也要留後路

部署完不代表萬事大吉。程式跑起來，還得確認它真的能回應。
所以我們讓服務自己提供一個 /healthz 端點，簡單回傳「ok」。CI/CD pipeline 部署完會每隔幾秒去探測，直到收到肯定的回應才算成功。

這就像隊伍進副本前，大家喊一句「狀態良好！」，不然開場就滅團。

版本策略也是另一道保險。每次發佈，我們同時推送 latest 和 commit sha 兩個標籤。

latest 就是線上跑的版本，sha 則是存檔點。

萬一今天更新後服務異常，只要切回上一個 sha，幾分鐘就能回復正常。這比「硬著頭皮重新 build」要快得多，也符合 DevSecOps 強調的「可回滾性」。

這樣一來，整個流程才算完整：不僅能上線，還能撤退。

結論

今天我們把 CI 的練功真正帶進了戰場。
流程不是只有「能部署」，而是帶著護盾、補師、存檔點一起走上去。

• CI 負責鍛造裝備（Build）。
• GHCR 冷藏裝備（Registry）。
• EC2 只是戰場補給站（Run）。
• Caddy 把守城門（HTTPS 入口）。
• 健康檢查是心跳監視器。
• 回滾是最後的保命符。

這就是 DevSecOps：不是更快交付風險，而是更快交付信任。