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

App Engine 三種部署方式

內文字級

App Engine 三種部署方式
更新:2026-10-12

課程概述

想把網站部署上去,又不想自己維護 VM,App Engine 是一個選項。不過開始前得先選 Standard 或 Flexible:兩者能調整的執行環境、啟動速度和成本都不同。選好後,再看直接部署、版本分流與自動化發布怎麼做。官方課程的三個 Lab 則是分別用 Python、Go、PHP 部署 App Engine 應用;版本分流與 Cloud Build 自動化不在 Lab 裡,是本文另外補充的。

App Engine 執行環境與部署方式:Standard 沙箱啟動快並可縮至零,Flexible 以可自訂容器跑在受管 VM;部署可直接上線、以多版本分流,或由版本控制觸發建置測試與自動部署

Standard 啟動快,也可以縮到零,但執行環境限制較多;Flexible 可自訂執行環境、執行背景程序,代價是至少維持一個 VM。部署時可以直接上線,也可以先保留舊版、逐步分流。 即使用 Git 觸發建置與部署,也要先想好怎麼把流量切回舊版。

你將學到

  • 區分 App Engine Standard 與 Flexible 環境
  • 使用 gcloud app deploy 部署應用程式
  • 透過 app.yaml 配置運行環境
  • 管理版本與流量分配

核心概念

Standard vs Flexible 環境

特性StandardFlexible
啟動時間秒級分鐘級
縮放至零支援不支援(最少 1 實例)
支援語言Python、Java、Go、Node.js、PHP、Ruby任何語言(自訂 runtime)
SSH 存取不支援支援
定價模式按實例小時計費按 VM 資源計費
背景程序不支援支援

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

app.yaml 的 runtime、handlers、scaling、instance_class 與環境變數經部署驗證後,建立 App Engine Service 之下的新 Version 與執行 Instance

app.yaml 是部署契約:Runtime、路由、擴縮與實例規格都先經驗證,錯誤會在部署前被擋下。設定一旦改變就建立新 Version,舊版仍保留供分流或回滾,不會被原地改寫。

三種部署模式

模式一:基本部署

gcloud app deploy app.yaml --version=v1

模式二:多版本與流量分配

# 部署新版本但不切換流量
gcloud app deploy --no-promote --version=v2

# 分配流量(A/B 測試)
gcloud app services set-traffic default --splits v1=0.7,v2=0.3

模式三:CI/CD 自動化

透過 Cloud Build 觸發器,在程式碼推送後自動部署:

# cloudbuild.yaml
steps:
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    args: ['gcloud', 'app', 'deploy', 'app.yaml', '--quiet']
查看流程與節點文字

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

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 24, "rankSpacing": 32}}}%%
flowchart TD
  CHANGE["程式碼或 app.yaml 變更"] --> PIPELINE["直接執行或由 Cloud Build<br/>測試並部署 --no-promote"]
  PIPELINE --> VERSION["建立不可變新 Version,<br/>舊 Version 繼續服務"]
  VERSION --> SMOKE{"零流量 Smoke Test<br/>是否通過?"}
  SMOKE -->|"否"| FIX["保留舊流量,修正後部署新版本"]
  SMOKE -->|"是"| CANARY["依 Cookie/IP/Random<br/>分配少量流量到新版本"]
  CANARY --> HEALTH{"錯誤率、延遲與業務指標正常?"}
  HEALTH -->|"是"| PROMOTE["逐步升至 100% 並清理舊版本"]
  HEALTH -->|"否"| ROLLBACK["流量切回已知良好的舊版本"]
部署只建立版本,真正的上線是流量決策。先以零流量驗證,再小比例觀察;異常時切回舊版本,不在事故中重新建置。
App Engine 多版本流量分配:Traffic Split 依 Cookie、IP 或 Random 把 90% 流量送往 v1、10% 送往 v2,再依健康指標升級 v2 或回滾 v1

多版本發布改的是 Service 的流量比例,不是 Version 本身。選定一致的分流方式後先讓少量使用者 進入 v2;健康才 Promote 到 100%,異常則立即把流量切回仍存在的 v1。

實作重點

  • 每個 GCP 專案只能有一個 App Engine 應用,且建立後不可更改 region
  • Standard 環境適合流量不穩定的應用(可縮放至零節省成本)
  • 使用 gcloud app versions list 管理版本,避免舊版本持續計費
  • Standard 環境在 app.yaml 用 instance_class 控制實例規格;Flexible 環境改用 resources(cpu、memory_gb)

Skill Badge 指引

Lab 連結:Deploy and Manage Applications on Google App Engine(原名 App Engine: 3 Ways)— 完成此 lab 可獲得 Skill Badge

延伸學習

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

讀完後,留一個學習紀錄

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

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

留言討論

文章目錄與系列

徽章解鎖!