比較 App Engine 和 Cloud Run

本指南為熟悉 App Engine 的使用者介紹 Cloud Run。本文將說明無伺服器平台的主要相似之處和差異，協助您做好從 App Engine 標準環境或彈性環境遷移的準備。

總覽

Cloud Run 是 Google Cloud 無伺服器技術的最新演進，以十多年來執行 App Engine 的經驗為基礎。Cloud Run 與 App Engine 標準環境使用許多相同的基礎架構，因此這兩個平台有許多相似之處。

Cloud Run 的設計宗旨是提升 App Engine 體驗，並整合 App Engine 標準環境和彈性環境的許多最佳功能。Cloud Run 服務可處理與 App Engine 服務相同的工作負載，但 Cloud Run 在實作這些服務時，可為客戶提供更多彈性。這項彈性以及與 Google Cloud 和第三方服務的整合功能，也讓 Cloud Run 能夠處理 App Engine 無法執行的工作負載。

比較摘要

App Engine 和 Cloud Run 有許多相似和相異之處，但本總覽著重於與 App Engine 客戶最相關的領域，協助他們開始使用 Cloud Run。

資源模型

Cloud Run 資源模型與 App Engine 非常相似，但有幾個主要差異：

• Cloud Run 沒有頂層的「應用程式」資源，也沒有對應的 default 服務。
• 相同專案中的 Cloud Run 服務可以部署至不同區域。在 App Engine 中，專案中的所有服務都位於相同區域。
• Cloud Run 使用「修訂版本」一詞，而非「版本」，這是為了與 Knative 資源模型保持一致。
• Cloud Run 修訂版本名稱的格式為：SERVICE_NAME-REVISION_SUFFIX，其中 REVISION_SUFFIX 是自動產生，或是使用 --revision-suffix=REVISION_SUFFIX 部署標記設定。
• Cloud Run 修訂版本不可變動，因此您無法像 App Engine 版本一樣重複使用名稱 (使用 --version=VERSION_ID 部署旗標)。
• Cloud Run 服務網址是以服務 ID 為基礎，該 ID 會在首次部署服務時自動產生。服務 ID 的格式為：SERVICE_NAME-<auto-generated identifier>。服務 ID 不得重複，且在服務的整個生命週期中都不會變更。
• 在 Cloud Run 中，預設只會公開服務網址 (SERVICE_IDENTIFIER.run.app 和 https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app)。如要指定修訂版本，請設定流量標記。在 App Engine 中，服務和版本網址都會自動公開。

部署和設定

在 App Engine 中，大部分的設定都是在每次部署時包含的 app.yaml 中完成。這種簡化做法的代價是，雖然可以使用 Admin API 更新少數設定，但大多數變更都需要重新部署服務。

雖然 Cloud Run 有 service.yaml 設定檔，但使用方式與 app.yaml 不同。從來源部署時，無法使用 Cloud Run service.yaml，因為其中一個必要元素是最終容器映像檔的路徑。此外，service.yaml 符合 Knative 規格，對於不熟悉 Kubernetes 樣式設定檔的使用者來說，可能難以閱讀。如要進一步瞭解如何使用 service.yaml 管理設定，請參閱 Cloud Run 說明文件。

對於剛開始使用 Cloud Run 的 App Engine 客戶來說，使用 gcloud CLI 部署標記與 App Engine 的部署時設定管理作業更為一致。

如要在 Cloud Run 中部署新程式碼時設定，請使用 gcloud run deploy 標記：

gcloud run deploy SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

雖然不一定要在每次部署時使用設定標記 (請參閱「管理設定」)，但您可以這麼做，簡化設定管理作業。

在 Cloud Run 中，您也可以使用 gcloud run services update 更新設定，不必重新部署原始碼：

gcloud run services update SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

由於 Cloud Run 修訂版本不可變更，這個指令會使用更新後的設定建立新修訂版本，但會使用與現有修訂版本相同的容器映像檔。

管理設定

如果是 App Engine 部署作業，所有設定都必須為每次部署作業提供，未提供的設定會指派預設值。以 App Engine service-a 為例，版本會使用下表中的 app.yaml 檔案：

runtime: python39
service: service-a
instance_class: F4

runtime: python39
service: service-a

runtime: python39
service: service-a
instance_class: F4
default values:
..
..

runtime: python39
service: service-a
default values:
instance_class: F1
..
..

version1 已設定 instance_class: F4，而未提供 instance_class 值的 version2 則已設定預設的 instance_class: F1。

如果是 Cloud Run，系統會套用您提供的所有設定，但未提供的設定會保留現有值。你只需要為要變更的設定提供值。例如：

gcloud run deploy service-a \
--cpu=4

gcloud run deploy service-a

service: service-a
vCPUs: 4
default values:
..
..

service: service-a
vCPUs: 4
default values:
..
..

在 App Engine 中，如果部署時未設定任何配置，系統會使用所有預設設定建立版本。在 Cloud Run 中，如果部署時沒有設定任何配置，系統會使用與上一個修訂版本相同的配置設定建立修訂版本。如果是 Cloud Run 服務的第一個修訂版本，部署時若未設定任何設定，系統會使用所有預設設定建立修訂版本。

設定預設值

進入點

從來源部署時，App Engine 會從 app.yaml 的 entrypoint 屬性讀取進入點指令。如果未提供進入點，系統會使用執行階段專屬的預設值。從來源部署時，Cloud Run 會使用 Google Cloud 的 Buildpack，但部分語言沒有預設進入點，因此您必須提供進入點，否則建構作業會失敗。舉例來說，Python 建構套件需要 Procfile，或指定 GOOGLE_ENTRYPOINT 建構環境變數。

如要瞭解特定語言的設定需求，請參閱建構套件說明文件。

資源調度

雖然 Cloud Run 和 App Engine 標準環境共用許多相同的資源調度基礎架構，但 Cloud Run 經過簡化，可大幅加快資源調度速度。為簡化程序，可設定的項目僅限於：

• 並行上限
• 執行個體數量上限和下限

Cloud Run 執行個體的目標 CPU 使用率無法設定，固定為 60%。如要進一步瞭解自動調度資源，請參閱 Cloud Run 說明文件。

App Engine 彈性環境使用 Compute Engine 自動調度資源，因此與 App Engine 標準環境和 Cloud Run 相比，資源調度特性差異極大。

閒置執行個體逾時

在 App Engine 中，閒置執行個體會在處理完最後一個要求後，最多維持運作 15 分鐘。Cloud Run 可讓您使用 CPU 分配設定這項行為。如要取得與 App Engine 相同的行為，請將 CPU 分配模式設為「隨時分配 CPU」。或者，使用「只在要求處理期間分配 CPU」，讓閒置執行個體立即關閉 (如果沒有待處理的要求)。

暖機要求

Cloud Run 會使用容器進入點指令自動預熱執行個體，因此您不必手動啟用預熱要求，也不必設定 /_ah/warmup 處理常式。如要在執行個體啟動時執行程式碼 (處理任何要求之前)，您可以採取下列任一做法：

• 設定應用程式以監聽要求
• 設定自訂啟動探針

靜態內容

在 App Engine 標準環境中，您可以從 Cloud Storage 提供靜態內容，或設定處理常式，不必使用運算資源。Cloud Run 沒有提供處理常式選項，因此您可以從 Cloud Run 服務 (與動態內容相同) 或 Cloud Storage 提供內容。

Cloud Run Invoker 角色

Cloud Run 也提供身分與存取權管理 (IAM) 功能，可控管服務的存取權。服務的 IAM 政策繫結可以使用 gcloud CLI、控制台或 Terraform 設定。

如要模擬 App Engine 行為，您可以允許未經驗證的要求，公開發布服務。您可以在部署時設定，或更新現有服務的身分與存取權管理政策繫結。

gcloud run deploy SERVICE_NAME ... --allow-unauthenticated

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member="allUsers" \
--role="roles/run.invoker"

或者，您也可以授予 Cloud Run 叫用者 IAM 角色，藉此控管服務存取權，這項角色可針對個別服務設定。

gcloud run deploy SERVICE_NAME ... --no-allow-unauthenticated
gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

環境變數和中繼資料

App Engine 和 Cloud Run 都會自動設定特定環境變數。下表列出 App Engine 環境變數，以及對應的 Cloud Run 變數。與 App Engine 相比，Cloud Run 僅實作少數環境變數，但中繼資料伺服器提供的資料大致相同。

預設環境變數

常見的中繼資料伺服器路徑

後續步驟

• 快速入門導覽課程：使用 Cloud Run 部署網路服務
• 我的應用程式是否適合 Cloud Run？
• 將 App Engine 自訂網域遷移至 Cloud Load Balancing
• 其他資源：
  • 使用 Docker 從 App Engine 遷移至 Cloud Run (Python：codelab、影片；Java：codelab)
  • 使用建構套件從 App Engine 遷移至 Cloud Run (Python：codelab、影片；Java：codelab)