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

程式碼先建成映像,掃描後存進 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 |
--cpu | CPU 數量 | 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,再做尖峰壓測"] 
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

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
延伸學習
- PCA 相關:運算服務選擇
- 本系列下一課:Firebase 無伺服器應用開發
讀完後,留一個學習紀錄
試著用自己的話說出一個重點,以及你會如何運用。實作文章請先核對結果與清理資源,再標記為讀完。
文章進度以你確認讀完的標記為準,可隨時取消。舊版造訪紀錄保留,但不計入讀完;這份自評不代表已掌握內容。