跳至主要內容
Study Jam:雲端基礎實作 — 第 7/10 篇

Cloud Run 無伺服器開發

內文字級

Cloud Run 無伺服器開發
更新:2026-10-12

課程概述

程式在本機能跑,離「別人打得開」還差幾步:建成容器映像、放進 Artifact Registry、部署到 Cloud Run,最後確認流量和擴縮設定。這堂課就沿著這條路走一次,弄清楚每一步在做什麼。

Cloud Run 交付與執行架構:原始碼與 Dockerfile 經建置和弱點掃描產生不可變映像,存入 Artifact Registry 後部署成 Revision;HTTPS 流量在版本間分配,各版本依請求與並發量自動擴縮

程式碼先建成映像,掃描後存進 Artifact Registry,再部署成一個 Revision。請求進來時, Cloud Run 可以把流量分給不同版本,並依負載增加實例。CPU、記憶體、並發數和實例上下限都會影響服務怎麼擴縮,也會影響費用與延遲。

你將學到

  • 使用 Cloud Build 建構容器映像
  • 將映像推送至 Artifact Registry
  • 部署並配置 Cloud Run 服務
  • 設定自動擴展、並發與資源限制
  • 管理環境變數與密鑰

核心概念

Cloud Run 部署流程

原始碼 → Dockerfile → Cloud Build → Artifact Registry → Cloud Run

關鍵配置項

配置說明預設值
--max-instances最大實例數100
--min-instances最小實例數(避免冷啟動)0
--concurrency每實例並發請求數80 × vCPU 數(gcloud/Terraform 新建服務時;主控台預設 80)
--memory記憶體512Mi
--cpuCPU 數量1
--timeout請求逾時300s

表格超出欄寬時,可左右捲動;鍵盤可聚焦表格後用左右方向鍵查看。

查看流程與節點文字

箭頭表示流程方向;方括號與引號內是節點名稱,可搭配下方圖解閱讀。

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 24, "rankSpacing": 32}}}%%
flowchart TD
  PROFILE["量測延遲 SLO、請求時間、<br/>CPU/Memory 與下游容量"] --> COLD{"冷啟動延遲<br/>可以接受?"}
  COLD -->|"否"| WARM["設定 min-instances<br/>並縮短初始化路徑"]
  COLD -->|"是"| ZERO["保留 scale to zero<br/>降低閒置成本"]
  PROFILE --> WORK{"單一實例能否安全地<br/>同時處理多個請求?"}
  WORK -->|"否/CPU 密集"| LOW["降低 concurrency<br/>或增加 CPU/Memory"]
  WORK -->|"是/I/O 密集"| HIGH["逐步提高 concurrency<br/>並觀察尾端延遲"]
  PROFILE --> GUARD["依 DB 連線與 API 配額<br/>設定 max-instances,再做尖峰壓測"]
Min Instances 解決冷啟動,Concurrency 決定單一實例承載方式,Max Instances 則保護資料庫與外部 API。三者應由同一組 SLO、壓測與下游上限共同決定。
Cloud Run 同時請求先填入現有實例的 Concurrency 槽位,沒有空位時才擴增實例;Max Instances 限制總容量以保護下游資料庫

Concurrency 是單一實例能同時處理的請求數,不是每秒吞吐量。Cloud Run 預設以 CPU 與並發使用率 60% 為目標調整實例數,不會等到實例滿載才擴增; Max Instances 則是保護下游的保險絲,避免服務瞬間擴張把資料庫連線用盡。

Artifact Registry vs Container Registry

新的容器映像放在 Artifact Registry;Container Registry 已於 2025 年 3 月 18 日停止服務,不能再寫入映像。以下從建立儲存庫開始,接著建置映像並部署服務:

# 建立 Artifact Registry 倉庫
gcloud artifacts repositories create my-repo \
  --repository-format=docker \
  --location=us-central1

# 建構並推送映像
gcloud builds submit --tag us-central1-docker.pkg.dev/PROJECT/my-repo/app

# 部署到 Cloud Run
gcloud run deploy my-service \
  --image us-central1-docker.pkg.dev/PROJECT/my-repo/app \
  --region us-central1 \
  --allow-unauthenticated
Cloud Run Secret 安全邊界:Secret Manager 透過 Secret Accessor 角色授權 Revision 使用的 Service Account,執行期才以環境變數或掛載檔案取得 Secret,禁止寫入程式碼、映像或明文設定

Secret 不應跟著 Source 或 Docker Image 永久封裝;Revision 使用的 Service Account 必須先通過 IAM, 執行期才從 Secret Manager 取得指定版本。輪替到 Secret v2 後部署新 Revision,回滾路徑仍然清楚。

減少冷啟動

  • 設定 --min-instances=1 保持至少一個暖實例
  • 確認 startup CPU boost 有開(用 gcloud 新建的服務預設啟用),並減少啟動時要載入的相依套件
  • 映像大小本身不影響啟動時間(Cloud Run 以串流方式載入映像);精簡映像主要是為了減少安全弱點
  • 不常用的物件改用 lazy initialization:全域變數的初始化都在啟動時執行,會拉長啟動時間;代價是新實例的頭幾個請求會慢一些

實作重點

  • Cloud Run 預設的 request-based billing 只在處理請求、實例啟動與關閉時計費;設了最小實例數時,閒置的最小實例另以 idle 費率計費;改用 instance-based billing(原稱 CPU always allocated)則實例的整個生命週期都計費
  • 容器必須監聽 PORT 環境變數指定的連接埠
  • 敏感資訊放在 Secret Manager,再依需要掛載為環境變數或檔案
  • 善用 Cloud Run 的 revision 機制做金絲雀部署

Skill Badge 指引

Lab 連結:Develop Serverless Applications on Cloud Run(原名 Serverless Cloud Run Development)— 完成此 lab 可獲得 Skill Badge

延伸學習

Study Jam:雲端基礎實作 — 第 7 篇/共 10 篇 查看系列全覽 →

讀完後,留一個學習紀錄

試著用自己的話說出一個重點,以及你會如何運用。實作文章請先核對結果與清理資源,再標記為讀完。

文章進度以你確認讀完的標記為準,可隨時取消。舊版造訪紀錄保留,但不計入讀完;這份自評不代表已掌握內容。

留言討論

文章目錄與系列

徽章解鎖!