第 1 章：導論 — DevOps 在解決什麼問題 + 全貌

這一章在做什麼？ 先把「DevOps 到底在解決什麼問題」用白話講清楚，再預覽這整份教學要帶你蓋出來的東西：一條從「改 code」到「上線運行並被監控」的自動化交付線。做完這章，你會對全貌有清楚的地圖、把帳號與費用防護準備好，並確認手上那個 Go 後端能跑。

為什麼先看全貌？ DevOps 工具很多（GitHub Actions、Terraform、Kubernetes…），新手最容易迷失在「這個工具跟那個工具到底什麼關係」。先有一張地圖，後面每一章你都知道自己正站在哪。

這章沒有要安裝一堆東西，重點是建立心智地圖 + 把費用防護（預算警示）先設好。

步驟 1：DevOps 在解決什麼問題？

想像你（前端轉後端的開發者）剛把 Go app 寫好，要讓它上線給人用。沒有 DevOps 的世界長這樣：

你在自己電腦手動 docker build、手動上傳、手動登入伺服器、手動重啟……每次發版都緊張兮兮。
「在我電腦明明會跑啊」——環境不一致，上線就爆。
改一行 code 要等好幾天才敢上線，因為沒人敢保證不會弄壞。
線上出事了，沒有人發現，直到使用者來罵。

DevOps 就是用「自動化 + 工具」把上面這些手動、易錯、緩慢的環節，變成一條可靠的輸送帶。 開發者只要專心 git push，剩下的測試、打包、部署、監控，都交給機器自動完成。

白話定義：DevOps＝把「寫好的程式」自動且可靠地送到「正式環境運行並持續監看」的一整套做法與工具。它不是某一個軟體，而是一串工具的組合（這份教學會逐一介紹）。

步驟 2：幾個你會一直聽到的詞（先有概念就好）

名詞	白話解釋
CI（持續整合）	每次 push，自動跑測試與 build，及早抓出問題。
CD（持續交付/部署）	測試通過後，自動打包並部署到環境，不用人工手動上線。
Pipeline（管線）	把上面這些步驟串成一條「輸送帶」：push → 測試 → build → 部署 → 監控。
Registry（倉庫）	存放 build 好的容器 image 的地方（我們用 GHCR）。
IaC（基礎設施即程式碼）	用「程式碼/設定檔」描述雲端資源，而不是在網頁點來點去（我們用 Terraform）。
容器編排	自動管理一大堆容器（啟動、重啟、擴縮、更新），代表作是 Kubernetes。
可觀測性 / 監控	讓你「看得見」服務的健康、流量、延遲（我們用 Prometheus + Grafana）。
YAML	一種用縮排表示結構的設定檔格式，DevOps 到處都是它（第 3 章會逐行教）。

看不懂沒關係，每個都會在對應章節第一次用到時詳細展開。

步驟 3：本教學的全貌（架構圖）

我們要蓋的最終樣貌如下。左邊是你（開發者），一路往右是程式碼如何自動流到使用者面前並被監控：

flowchart LR
    dev["開發者 (本機)"] -->|"git push"| repo["GitHub Repo"]
    repo -->|"觸發"| ci["GitHub Actions<br/>CI：跑測試 + build"]
    ci -->|"build & 推送 image"| ghcr["GHCR<br/>容器 registry"]
    ci -->|"CD：自動部署"| app["Cloud Run / GKE<br/>(GCP)"]
    ghcr -->|"pull image"| app
    tf["Terraform<br/>(IaC)"] -.->|"佈建"| app
    tf -.->|"佈建"| db["Cloud SQL<br/>PostgreSQL"]
    app -->|"連線"| db
    app -->|"/metrics"| prom["Prometheus"]
    prom --> graf["Grafana<br/>儀表板"]
    user(("使用者")) -->|"HTTP"| app

照著箭頭走一遍（這就是後面 10 章的順序）：

開發者 → GitHub Repo：你 git push（第 3 章把 code 推上 GitHub）。
GitHub Repo → GitHub Actions：push 觸發自動化，跑測試與 build（第 3 章 CI）。
GitHub Actions → GHCR：build 出 Docker image 並推到容器倉庫（第 4 章 CD）。
Terraform 佈建 GCP：用程式碼把雲端資源（運算服務、資料庫）開出來（第 5 章 IaC）。
GHCR → Cloud Run / GKE：部署時從倉庫拉 image 跑起來（第 6 章 Cloud Run、第 8 章 GKE）。
App → Cloud SQL：應用連上雲端 PostgreSQL（第 6、8 章；用完即刪）。
App → Prometheus → Grafana：收集指標、做成儀表板（第 9 章監控）。
使用者 → App：真實流量打進來；第 10 章把整條線串成一鍵自動化。

🔁 前端類比：你或許用過 Vercel/Netlify——push 上去就自動 build & 部署，那其實就是一套「幫你包好的 DevOps pipeline」。這份教學是把那層魔法「拆開來自己組一遍」，從 CI 到雲到監控，每個齒輪你都會懂。

步驟 4：最終目錄結構

整份教學會在前一份的 code/（你的 Go 後端 repo）裡，長出這些 DevOps 相關檔案（標注哪一章建立）：

code/                              ← 把這個資料夾當成「你的 GitHub repo 根目錄」
├── .github/
│   └── workflows/
│       ├── ci.yml                 # 第 3 章：測試 + build
│       └── cd.yml                 # 第 4 章：build & 推 GHCR（第 6、10 章擴充為自動部署）
├── terraform/                     # 第 5、6、8 章：IaC
│   ├── versions.tf                #   指定 provider 版本
│   ├── variables.tf               #   可調參數（專案 ID、region…）
│   ├── main.tf                    #   實際資源
│   └── outputs.tf                 #   輸出（服務網址等）
├── k8s/                           # 第 7、8 章：Kubernetes manifest
│   ├── namespace.yaml
│   ├── postgres.yaml              #   in-cluster Postgres（本機/省錢用）
│   ├── deployment.yaml            #   app 的 Pod 規格
│   ├── service.yaml               #   對外存取
│   └── configmap.yaml / secret.yaml
├── monitoring/                    # 第 9 章
│   └── values.yaml                #   Prometheus/Grafana 的 Helm 設定
│
├── internal/...                   # 既有 Go app（第 9 章會加 /metrics）
├── cmd/api/main.go                # 既有
├── migrations/                    # 既有
├── Dockerfile                     # 第 2 章優化
├── .dockerignore                  # 第 2 章
├── docker-compose.yml             # 既有（本機開發）
├── go.mod / go.sum                # 既有
└── .gitignore                     # 既有（會確認 .env 有被排除）

重點觀念：.github/workflows/ 必須放在 repo 根目錄，GitHub Actions 才會自動偵測。所以我們把 code/ 視為你的 repo 根目錄——之後 push 的就是這個資料夾。

步驟 5：前置準備

5-1 確認手上的 Go 後端能跑

DevOps 是長在「能跑的 app」上面的。先確認前一份教學的成果還健在：

cd ../code            # 從 devops/ 切到 code/（你的後端專案）
cp .env.example .env  # 還沒有 .env 的話
docker compose up -d db
go run ./cmd/api

另開一個終端機：

curl http://localhost:8080/health

看到 {"status":"ok"} 就代表地基穩固。確認完可以 Ctrl+C 停掉、docker compose down 收掉。

5-2 GitHub 帳號

去 https://github.com 註冊/登入。第 3 章會帶你把 code/ 推成一個 GitHub repo。現在有帳號即可。

5-3 Google Cloud 帳號 + 開通帳單

用個人 Google 帳號登入 https://console.cloud.google.com（公司/學校帳號常被組織政策擋住權限）。
首次登入可領 $300 美元、90 天的免費試用額度。
建立一個新專案（Project）：左上專案選單 → 新增專案，取名例如 nlt-devops，記下 Project ID（之後 Terraform 會用到，例如 nlt-devops-123456）。
確認專案已連結帳單帳戶（Billing account）——很多服務沒開帳單無法使用。

開通帳單不代表會被亂扣款：有試用額度頂著，且我們下一步就設預算警示。但「沒開帳單」會讓後面很多 GCP 功能直接不能用。

步驟 6：💸 先設好費用防護（最重要的一步）

在碰任何雲端資源之前，先設「預算警示」。這是新手避免帳單暴衝的安全氣囊。

GCP Console → 左側選單 → 帳單（Billing） → 預算與快訊（Budgets & alerts） → 建立預算。
範圍：選你的專案。
金額：設一個小額上限，例如 USD 5（純粹當警戒線；你主要花的是試用額度）。
門檻快訊：勾選 50% / 90% / 100%，並確認警示會寄到你的 email。
儲存。

之後只要花費接近門檻，你就會收到信，不會某天醒來看到天價帳單。

💸 省錢與安全三原則（請記住，整份教學都會用到）

優先用 free tier / 試用額度、能縮到零的服務（例如 Cloud Run 沒流量時不算錢）。

用完即刪：每個雲端章節結尾都有 terraform destroy / 刪除步驟，當次學完就拆掉。

絕不把密碼/金鑰 commit 上 GitHub：.env、service account 金鑰一律靠 .gitignore 排除，敏感值用 GitHub Secrets（第 4 章起會用到）。

✅ 如何驗證這一章成功

逐項確認，全部打勾再進第 2 章：

# 1) 基本工具在
git --version        # 預期：git version 2.x
docker --version     # 預期：Docker version 2x.x

# 2) 既有後端能跑（在 code/ 底下）
cd ../code && docker compose up -d db && go run ./cmd/api
# 另一個終端機：
curl http://localhost:8080/health
# 預期：{"status":"ok"}

[ ] git 與 docker 指令可用。
[ ] curl /health 回 {"status":"ok"}（既有 app 健在）。
[ ] 有 GitHub 帳號。
[ ] 有 GCP 專案、已連結帳單、已設定預算警示（收得到測試門檻的觀念）。

全部完成，代表地基與費用防護就緒。🎉

🧯 常見錯誤 / 踩雷點

症狀	原因	解法
GCP 很多功能點不動、API 啟用失敗	專案沒連結帳單帳戶	Billing → 連結帳單帳戶（有試用額度頂著，不會亂扣）
無法建立專案 / 權限被擋	用了公司或學校的 Google 帳號（受組織政策限制）	改用個人 Google 帳號
擔心帳單暴衝	沒設預算警示	照步驟 6 設定預算與門檻快訊（USD 5 當警戒線）
之後 region 選來選去、費用/延遲怪怪的	不同章節用了不同 region	統一一個 region（本教學建議 `asia-east1` 台灣，或 `us-central1`），之後 Terraform 變數固定它
`curl /health` 連不上	DB 容器沒起 / app 沒跑 / port 被占	先 `docker compose up -d db`，再 `go run ./cmd/api`，確認 8080 沒被占用
不小心把 `.env` 推上 GitHub	`.gitignore` 沒涵蓋	確認 `code/.gitignore` 有 `.env`；已外洩的金鑰要立刻撤換

下一步 → 第 2 章：從既有容器化 app 出發，優化 Docker image 我們會把前一份的 Dockerfile 再精煉（更小的 base image、層快取、非 root、健康檢查），把 image 體積壓下來——image 越小，之後每次 CI build 與部署就越快、攻擊面越小。