在 GCP 上建立網站
課程概述
上架網站前,先問一件事:它只是 HTML、CSS 和圖片,還是需要後端程式處理請求?答案不同,部署方式就不同。這篇會比較 Cloud Storage、Cloud Run 和 Firebase Hosting,讓你知道什麼情況該從哪裡開始。官方課程的 Lab 則是把網站部署到 Cloud Run、Compute Engine 和 GKE,再把單體網站拆成微服務;Cloud Storage 靜態網站與 Firebase Hosting 不在這些 Lab 裡,是本文另外補充的。

純靜態檔案可以放 Cloud Storage,搭配負載平衡器和 CDN;有後端容器可選 Cloud Run。如果網站本來就搭配 Firebase Auth、Firestore 等服務,可以考慮 Firebase Hosting; 現有程式符合 App Engine 的執行環境時,也值得比較。選完平台,還要處理自訂網域與 HTTPS。
你將學到
- 使用 Cloud Storage 託管靜態網站
- 透過 Cloud Run 部署容器化 Web 應用
- 設定自訂網域與 SSL 憑證
- 理解不同部署方案的成本與效能差異
核心概念
網站部署方案比較
| 方案 | 適用類型 | 自動擴展 | 自訂網域 | 免費額度 |
|---|---|---|---|---|
| Cloud Storage | 純靜態網站 | 自動 | HTTPS 需搭配 LB | 5 GB-月的 regional 儲存(限 us-east1/us-west1/us-central1) |
| Cloud Run | 動態應用/API | 0→N 自動 | 建議搭配 global external Application LB(原 HTTPS LB);內建 domain mapping 仍是 Preview、限部分區域,官方不建議用於正式環境 | 200 萬次請求/月 |
| Firebase Hosting | 靜態網站與單頁應用 | 自動 | 內建支援 | 10 GB 傳輸/月(定價頁寫 360 MB/天) |
| App Engine | 傳統 Web App | 自動 | 內建支援 | F1 實例 28 小時/天(限 Standard) |
表格超出欄寬時,可左右捲動;鍵盤可聚焦表格後用左右方向鍵查看。
流程圖暫時無法顯示。可先查看下方的流程與節點文字,或重新整理頁面後再試。
查看流程與節點文字
箭頭表示流程方向;方括號與引號內是節點名稱,可搭配下方圖解閱讀。
%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 24, "rankSpacing": 32}}}%%
flowchart TD
SITE["盤點頁面內容、後端邏輯、<br/>整合服務與發布方式"] --> STATIC{"只有 HTML、CSS、JS<br/>與靜態資產?"}
STATIC -->|"是"| FIREBASE{"需要 Firebase Auth、<br/>Preview Channel 或整合式 CLI?"}
FIREBASE -->|"是"| HOSTING["Firebase Hosting"]
FIREBASE -->|"否"| STORAGE["Cloud Storage +<br/>external Application LB<br/>(原 HTTPS LB)<br/>+ CDN"]
STATIC -->|"否"| CONTAINER{"應用能包成任意<br/>HTTP 容器?"}
CONTAINER -->|"是"| RUN["Cloud Run"]
CONTAINER -->|"否"| PaaS{"既有框架符合受管 Runtime,<br/>並偏好 PaaS 慣例?"}
PaaS -->|"是"| APP["App Engine"]
PaaS -->|"否"| REDESIGN["重新確認執行環境與架構限制"] Cloud Storage 靜態網站
# 建立 bucket(搭配負載平衡器時,名稱不必和網域相同)
# 像這裡用網域當名稱,要先驗證網域擁有權
gcloud storage buckets create gs://www.example.com --location=us-central1
# 上傳網站檔案
gcloud storage cp -r ./website/* gs://www.example.com/
# 設定網站配置
gcloud storage buckets update gs://www.example.com \
--web-main-page-suffix=index.html \
--web-error-page=404.html
# 設定公開存取
gcloud storage buckets add-iam-policy-binding gs://www.example.com \
--member=allUsers --role=roles/storage.objectViewer

自訂網域的 TLS 在 external Application Load Balancer(圖上印的是舊名 HTTPS 負載平衡器)終止;Cloud CDN 命中時直接從邊緣回應,未命中才向 Bucket 取回物件並填入快取。公開的是靜態物件讀取權,不應連帶公開 Bucket 的管理權限。
Cloud Run 部署流程
- 撰寫 Dockerfile
- 建立 Artifact Registry 儲存庫:
gcloud artifacts repositories create REPO --repository-format=docker --location=REGION - 使用 Cloud Build 建構映像:
gcloud builds submit --tag REGION-docker.pkg.dev/PROJECT/REPO/app - 部署到 Cloud Run:
gcloud run deploy app --image REGION-docker.pkg.dev/PROJECT/REPO/app

新映像會建立新的 Revision,不會覆寫舊版。先用零流量 Revision 做 Smoke Test,再逐步增加 v2 流量;指標惡化時只需把流量切回 v1,不必在事故當下重新建置映像。
實作重點
- 純靜態網站可以先評估 Cloud Storage 搭配 Cloud CDN,並把負載平衡器成本算進去
- 有伺服器端邏輯時,可考慮把應用包成容器部署到 Cloud Run
- 已經使用 Firebase Auth、Firestore 等服務時,可一起評估 Firebase Hosting
- 記得設定 HTTPS,Cloud Run 和 Firebase Hosting 預設提供 SSL
Skill Badge 指引
Lab 連結:Build a Website on Google Cloud — 完成此 lab 可獲得 Skill Badge
延伸學習
- 本系列下一課:App Engine 三種部署方式
- 無伺服器進階:Cloud Run 無伺服器開發
讀完後,留一個學習紀錄
試著用自己的話說出一個重點,以及你會如何運用。實作文章請先核對結果與清理資源,再標記為讀完。
文章進度以你確認讀完的標記為準,可隨時取消。舊版造訪紀錄保留,但不計入讀完;這份自評不代表已掌握內容。