將標準環境中的 App Engine 應用程式部署至 Cloud Run

本指南說明如何將標準環境中的現有應用程式部署至 Cloud Run。這些操作說明適用於不使用 App Engine 舊版隨附服務的第二代執行階段。

本指南所述步驟不會影響現有 App Engine 應用程式的功能或流量。新建立的 Cloud Run 服務是 App Engine 服務的副本，可獨立測試。

• 使用 app.yaml 檔案的本機設定 (建議)：選擇這個選項，直接從本機原始碼建構容器映像檔，並部署至 Cloud Run。這可確保您最近對程式碼或設定所做的任何本機修改，都會包含在新的部署作業中。

• 使用先前建構的映像檔：如果您無法存取原始碼，這個選項會很有幫助。選擇這個選項，即可部署與 App Engine 上執行版本完全相同的副本，不必重新建構容器映像檔。如要驗證有效部署項目的行為，而不變更程式碼，這個方法就很實用。

事前準備

1. 確認 App Engine 應用程式執行時未發生錯誤。如果選擇使用本機設定部署，則必須具備 App Engine 原始碼的存取權。

2. 啟用 Cloud Run Admin API 和 Artifact Registry API：

   啟用 API

3. 使用下列指令設定專案和區域：

   gcloud auth login
   gcloud config set project PROJECT_ID
   gcloud config set run/region REGION
   gcloud components update
   

   更改下列內容：

   • PROJECT_ID：您的 Google Cloud 專案 ID。
   • REGION：要部署 Cloud Run 服務的區域。

4. 檢查應用程式中是否有不相容的功能，並在遷移至 Cloud Run 前移除這些功能。如要檢查應用程式是否不相容，而不執行遷移或部署作業，請執行下列指令：

   gcloud beta app migrate-to-run --dry-run
   

   查看相容性檢查結果，並視需要進行建議的變更。

5. 請查看下列 Cloud Run 差異：

   • Cloud Run 使用「Revision」一詞，而非「Version」，代表您每次將變更部署至特定服務。首次將應用程式部署至 Cloud Run 中的服務時，會建立第一個修訂版本。每次部署服務都會建立一個修訂版本。進一步瞭解如何部署至 Cloud Run。

   • 您可以使用 gcloud CLI 或 Google Cloud 控制台，將原始碼部署至 Cloud Run，設定及管理應用程式設定。Cloud Run 不需要檔案式設定，但支援 YAML 設定。

   • 您部署至 Cloud Run 的每項服務，都會使用網址中的 run.app 網域公開存取服務。

   • App Engine 服務預設為公開，但 Cloud Run 服務預設為私人，您必須設定為公開 (未經驗證) 存取。

必要的角色

您可以選擇建立新的服務帳戶，或是在 Cloud Run 中使用與標準環境相同的使用者自行管理服務帳戶。您或管理員必須將下列 IAM 角色授予部署者帳戶和 Cloud Build 服務帳戶。

  gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
      --role=roles/run.builder
  

如要查看與 Cloud Run 相關聯的 IAM 角色和權限清單，請參閱「Cloud Run IAM 角色」和「Cloud Run IAM 權限」。如果 Cloud Run 服務與Google Cloud API (例如 Cloud 用戶端程式庫) 互動，請參閱服務身分設定指南。如要進一步瞭解如何授予角色，請參閱部署權限和管理存取權。

使用 app.yaml 檔案的本機設定

使用先前建構的映像檔

如要使用先前從已部署 App Engine 版本建構的容器映像檔進行部署，而非從本機 app.yaml 檔案重新建構容器映像檔，請按照下列步驟操作：

這項部署作業不需要應用程式的原始碼。

1. 執行下列指令，將服務部署至 Cloud Run。這個指令會使用有效 App Engine 部署作業的容器映像檔，不會擷取本機 app.yaml 檔案的最新變更，因此可能會導致部署作業過時：

   gcloud beta app migrate-to-run --service=SERVICE --version=VERSION --from-image
   

   更改下列內容：

   • SERVICE：App Engine 服務的名稱。
   • VERSION：服務的版本 ID。

   這個指令會擷取指定服務和版本的設定，為 Cloud Run 產生 service.yaml 檔案。如要瞭解詳情，請參閱 gcloud beta app migrate-to-run。

   • 系統提示 Proceed with the deployment? 時，請輸入 Y，匯出現有的 App Engine 容器映像檔，並將服務部署至 Cloud Run。

2. 在網路瀏覽器中開啟服務網址，即可查看已部署的 Cloud Run 服務。

   選用：

   • 如要產生 Cloud Run service.yaml 設定，但不部署服務，請執行下列指令：

     gcloud beta app migrate-to-run --service=SERVICE \
         --version=VERSION \
         --from-image \
         --export-only=EXPORT_PATH
     

     將 EXPORT_PATH 替換為要儲存 service.yaml 檔案的目錄或路徑。

不相容的功能

• 傳入服務：

  inbound_services:
  - warmup
  

  解決方案：從 app.yaml 檔案中刪除 inbound_services 區段。Cloud Run 會使用容器進入點預熱執行個體，因此您不需要設定暖機要求。如要在提供流量前執行初始化程式碼，請將服務設為在啟動時執行，並在監聽要求或使用啟動探測前執行。您也可以設定執行個體數量下限，讓執行個體保持暖機狀態。

• 自訂錯誤頁面：

  error_handlers:
   - file: default_error.html
   - error_code: over_quota
   file: over_quota.html
  

  解決方法：從 app.yaml 檔案中刪除 error_handlers 區段，並採用下列其中一項或兩項策略：

  • 直接在應用程式程式碼中導入錯誤處理機制。擷取標準 HTTP 錯誤代碼 (例如 404 或 500)，並從應用程式邏輯中提供自訂 HTML 錯誤頁面。
  • 如果您將 Cloud Load Balancing 與 Cloud Run 搭配使用，請在負載平衡器層級設定自訂錯誤回應。這樣一來，您就能根據 Cloud Run 服務的回應代碼，從 Cloud Storage 提供自訂錯誤頁面。

• 第二代執行階段的隨附服務：

  app_engine_apis: true
  

  解決方法：從 app.yaml 檔案中刪除 app_engine_apis 設定，並改用 Google Cloud API 或第三方替代方案。詳情請參閱「從隨附服務遷移」。

• 第一代執行階段：

  runtime: python27
  

  解決方法：將應用程式升級至支援的第二代執行階段。詳情請參閱「遷移至第二代執行階段總覽」。

後續步驟

• 瞭解如何管理 Cloud Run 服務。
• 請參閱 Cloud Run 容器執行階段合約，瞭解 Cloud Run 中容器的需求和行為。
• 瞭解如何使用 Secret Manager，為需要 API 金鑰、密碼或其他機密資訊的服務儲存依附元件。