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

在 GCP 上建立網站

內文字級

在 GCP 上建立網站
更新:2026-10-12

課程概述

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

網站部署路徑:同一個網站需求依靜態檔案或伺服器端邏輯、獨立託管或整合式應用服務,分流到 Cloud Storage、Cloud Run、Firebase Hosting 或 App Engine,並共用網域與 TLS 保護

純靜態檔案可以放 Cloud Storage,搭配負載平衡器和 CDN;有後端容器可選 Cloud Run。如果網站本來就搭配 Firebase Auth、Firestore 等服務,可以考慮 Firebase Hosting; 現有程式符合 App Engine 的執行環境時,也值得比較。選完平台,還要處理自訂網域與 HTTPS。

你將學到

  • 使用 Cloud Storage 託管靜態網站
  • 透過 Cloud Run 部署容器化 Web 應用
  • 設定自訂網域與 SSL 憑證
  • 理解不同部署方案的成本與效能差異

核心概念

網站部署方案比較

方案適用類型自動擴展自訂網域免費額度
Cloud Storage純靜態網站自動HTTPS 需搭配 LB5 GB-月的 regional 儲存(限 us-east1/us-west1/us-central1)
Cloud Run動態應用/API0→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["重新確認執行環境與架構限制"]
先分靜態與動態,再看是否需要 Firebase 整合、任意容器或受管 Runtime。自訂網域與 HTTPS 是入口需求,不能單獨決定後端平台。

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
靜態網站 HTTPS 請求從瀏覽器經 Cloud DNS、external Application Load Balancer(圖上印的是舊名 HTTPS 負載平衡器)與受管憑證抵達 Cloud CDN,快取未命中時才回源 Cloud Storage 並填入快取

自訂網域的 TLS 在 external Application Load Balancer(圖上印的是舊名 HTTPS 負載平衡器)終止;Cloud CDN 命中時直接從邊緣回應,未命中才向 Bucket 取回物件並填入快取。公開的是靜態物件讀取權,不應連帶公開 Bucket 的管理權限。

Cloud Run 部署流程

  1. 撰寫 Dockerfile
  2. 建立 Artifact Registry 儲存庫:gcloud artifacts repositories create REPO --repository-format=docker --location=REGION
  3. 使用 Cloud Build 建構映像:gcloud builds submit --tag REGION-docker.pkg.dev/PROJECT/REPO/app
  4. 部署到 Cloud Run:gcloud run deploy app --image REGION-docker.pkg.dev/PROJECT/REPO/app
Cloud Run 安全部署流程:不可變映像先部署成零流量 Revision,通過 Smoke Test 後以 v1 90%、v2 10% 金絲雀分流,依健康指標升至 v2 100% 或回滾 v1 100%

新映像會建立新的 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

延伸學習

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

讀完後,留一個學習紀錄

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

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

留言討論

文章目錄與系列

徽章解鎖!