測試及部署應用程式

區域 ID

REGION_ID 是 Google 根據您在建立應用程式時選取的地區所指派的簡寫代碼。雖然某些區域 ID 可能看起來與常用的國家/地區代碼相似，但此代碼並非對應國家/地區或省份。如果是 2020 年 2 月後建立的應用程式，App Engine 網址會包含 REGION_ID.r。如果是在此日期之前建立的現有應用程式，網址中則可選擇加入地區 ID。

進一步瞭解區域 ID。

瞭解如何在本機執行應用程式、進行部署，然後在 App Engine 上測試。

在本機上執行

如要在部署前先測試應用程式，請使用您常用的開發工具，在本機環境中執行應用程式。 舉例來說，您通常可以使用 Flask 的開發伺服器，透過下列指令來執行 Flask 應用程式：

python main.py

您可以使用下列指令啟動 Django 應用程式：

python manage.py runserver

如要模擬 App Engine 實際工作環境，您可以在本機執行完整的網路伺服器閘道介面 (WSGI) 伺服器。在 app.yaml 檔案中使用與 entrypoint 相同的指令，例如：

gunicorn -b :$PORT main:app

部署應用程式

使用 gcloud app deploy 指令，將應用程式部署到 App Engine。

Cloud Build 服務會自動將部署內容建構為容器映像檔，並將映像檔部署至 App Engine 彈性環境。容器中會包含您對執行階段映像檔所進行的任何本機修訂。

如要透過程式部署應用程式，請使用 Admin API。

事前準備

部署應用程式之前：

確保成功部署

如果您啟用更新版健康狀態檢查，但是應用程式並未達到健康狀態良好狀態，則部署將會復原到未部署的狀態。當您將第一個應用程式部署至彈性環境時，可能會因為系統設定虛擬機器 (VM) 和其他基礎架構而發生延遲。完成初始設定後，健康狀態檢查可確保執行個體的健康狀態良好，且已準備好可以接收流量。如果應用程式沒有在指定時間 (依 app.yaml 檔案 liveness_check 區段的 initial_delay_sec 欄位指示) 內達到就緒狀態，部署作業將會失敗並復原到未部署的狀態。

您的應用程式可能需要更多時間才能準備就緒。例如，您可能是透過下載大型檔案或預先載入快取內容來初始化應用程式。如果您使用的是新版健康狀態檢查機制，則可以在 app.yaml 檔案的 readiness_check 區段中，修改 app_start_timeout_sec 組態設定，以此方式來延長時間。

如果部署作業失敗，請確認 Cloud Build API 已在專案中啟用。App Engine 會在您首次部署應用程式時自動啟用這個 API，但如果有人在之後停用 API，部署作業就會失敗。

部署服務

您可以透過部署應用程式各項服務的版本及設定檔，將應用程式部署至 App Engine。

如要部署應用程式服務，請從服務的 app.yaml 檔案所在的目錄執行下列指令：

gcloud app deploy

根據預設，gcloud app deploy 指令只會部署目前目錄中的 app.yaml 檔案。每次執行這項指令時，App Engine 都會為您部署的版本產生唯一 ID，並將該版本部署至您設定 gcloud CLI 所要使用的Google Cloud 專案，再將所有流量轉送至新版本。新版本會成為預設版本。

您可以指定特定檔案、指定版本，或加入其他參數來改變部署指令的預設行為：

  • 您可以個別指定及部署每個檔案，藉此部署服務的其他設定檔，例如：

    gcloud app deploy cron.yaml
gcloud app deploy dispatch.yaml
gcloud app deploy index.yaml

  • 如要指定自訂版本 ID，請使用 --version 標記。

  • 如要避免系統將流量自動轉送至新版本，請使用 --no-promote 標記。

  • 如要部署到特定的 Google Cloud 專案，請使用 --project 標記。

舉例來說，如要將 app.yaml 檔案定義的服務部署至特定的Google Cloud 專案，請為該服務指派自訂版本 ID，並避免將流量轉送至新版本：

gcloud app deploy --project PROJECT_ID --version VERSION_ID --no-promote

詳情請參閱 gcloud app deploy 參考資料。

您可以為 gcloud CLI 設定屬性，並建立及管理 SDK 設定，這樣就不需要在每次進行部署時指定 --project 等標記。

如果您在部署新版本時採用現有版本的名稱，App Engine 會立即將流量遷移至新版本。當 App Engine 將要求載入新版本時，延遲時間會遽增。新版本會覆寫舊版本，您無法將流量遷移至舊版本。如果您部署新版本時採用與先前版本相同的名稱，App Engine 會將新的容器映像檔部署至現有虛擬機器，以便加快部署作業，並在現有虛擬機器上更新應用程式的容器。

部署多項服務

您可以使用相同的部署指令來部署或更新組成應用程式的多項服務。

事前準備：

  • 您必須先將應用程式的某個版本部署到 default 服務，才能建立及部署後續服務。

  • 您必須在每項服務各自對應的 app.yaml 設定檔中指定服務 ID。如要指定服務 ID，請在每個設定檔中加入 service 元素定義。根據預設，從設定檔排除此元素定義會將版本部署至 default 服務。

如要部署多項服務，您必須個別部署每項服務的 app.yaml 檔案，例如：

gcloud app deploy service1/app.yaml
gcloud app deploy service2/app.yaml

您可以透過單一部署指令來指定多個檔案：

gcloud app deploy service1/app.yaml service2/app.yaml

略過檔案

您可以使用 .gcloudignore 檔案，指定部署服務時不要上傳至 Google Cloud的檔案和目錄。如要略過不必隨著部署作業一起上傳的建構構件和其他檔案，這個方法十分實用。

如要進一步瞭解 .gcloudignore 檔案的語法，請參閱 gcloud 參考資料。

手動建構用於部署的容器

如要在 Google Cloud外建構容器映像檔，請按照下列步驟操作：

  1. 將映像檔上傳至 Artifact Registry 存放區。詳情請參閱「推送及拉取映像檔」。
  2. 使用 gcloud app deploy 指令將應用程式部署至 App Engine。

舉例來說，如果您在本機環境中使用 Docker 建構容器映像檔，則可將這些映像檔推送至 Artifact Registry，並在指令的 --image-url 標記中指定映像檔的網址：

gcloud app deploy --image-url LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE

取代：

  • LOCATION 與圖片儲存位置的存放區。

  • PROJECT-ID 替換為您的 Google Cloud 專案 ID。

  • REPOSITORY 與儲存映像檔的存放區名稱。

  • IMAGE 改為您的容器映像檔名稱。

使用自動化持續部署管道

您可以使用 Cloud Build 自動在持續部署管道中進行部署。詳情請參閱 Cloud Build 說明文件中的「部署至 App Engine」和「建立及管理建構觸發條件」相關章節。

Docker 基本映像檔

如果您想建構自訂執行階段應用程式，請參閱「建立 Docker 檔案」。

查看您的應用程式

將應用程式部署至 App Engine 之後，您可以執行下列指令來啟動瀏覽器，並在 https://PROJECT_ID.REGION_ID.r.appspot.com 查看應用程式：

gcloud app browse

在 App Engine 上測試

您可以先在 App Engine 上測試新版本，然後再設定該版本以接收流量。例如，您可採取下列做法來測試 default 服務的新版本：

  1. 將 promote 參數設為 false，部署新版 並加入 --no-promote 標記：

    gcloud app deploy --no-promote

  2. 前往下列網址以存取新版本：

    https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com

    您現在可以在 App Engine 執行階段環境中測試新版本。您可以在Google Cloud 控制台的 記錄檔探索工具中查看應用程式的記錄，藉此進行偵錯。詳情請參閱「寫入應用程式記錄」。

    系統仍會將傳送至 https://PROJECT_ID.REGION_ID.r.appspot.com 的要求轉送至先前設為要接收流量的版本。

  3. 當您要將流量傳送至新版本時，請使用Google Cloud 控制台遷移流量：

    管理版本

    選取您剛剛部署的版本，然後按一下 [Migrate traffic] (遷移流量)。

您可以將網址中的 default 換成服務名稱，即可使用相同程序來測試其他服務的新版本：

https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

如要進一步瞭解如何指定特定服務和版本，請參閱「要求的轉送方式」。

使用建構環境變數

您可以為支援Buildpack 的執行階段設定建構環境變數。

建構環境變數是鍵/值組合，可用來指定要用來部署應用程式的建構包。舉例來說，您可能需要指定編譯器選項。

事前準備：

  • 鍵的開頭必須是大寫 ASCII 字母，且可包含大寫 ASCII 字母、數字和底線。
  • 請避免建立任何含有 GOOGLE_* 鍵前置字元的變數。
  • 下列鍵已預留給 Google 使用：
    • GOOGLE_RUNTIME
    • GOOGLE_RUNTIME_VERSION
    • GOOGLE_ENTRYPOINT
    • GOOGLE_DEVMODE
  • 您可以使用buildpack 支援的任何鍵。

如要搭配 Buildpack 使用環境變數，請在 app.yaml 檔案中指定 build_env_variables 欄位。

進一步瞭解 Buildpack。

使用 Cloud Trace

Cloud Trace 可協助您瞭解要求在應用程式中傳播的情形。您可以查看單項要求的詳細延遲資訊，或是瀏覽整個應用程式的匯總延遲資料。

您可以查看追蹤記錄詳細資料。在追蹤記錄探索器中，您可以依特定 App Engine 服務和版本進行篩選。

疑難排解

以下是部署應用程式時，您可能會看到的常見錯誤訊息：

PERMISSION_DENIED: Operation not allowed
The "appengine.applications.create" permission is required.
如果 Google Cloud 專案缺少必要的 App Engine 應用程式，gcloud app deploy 指令嘗試執行 gcloud app create 指令時可能會失敗。只有具備「擁有者」角色的帳戶才具有建立 App Engine 應用程式的必要權限。
502 Bad Gateway
如果 app.yaml 設定錯誤， Google Cloud 專案可能無法啟動。查看應用程式記錄，瞭解錯誤訊息的詳細資訊。
[13] An internal error occurred while creating a Cloud Storage bucket.

App Engine 會代表您在建立應用程式的同一個區域中，建立預設 Cloud Storage 多地區值區。這個值區用於儲存應用程式內容。當無法建立這個值區時，系統會傳回錯誤，例如在下列情況下：

舉例來說，如果您的 App Engine 應用程式是在 europe-west 地區建立，即使該地區會對應至 europe-west1 位置，您仍必須修改限制，允許 in:eu-locations 中的資源，其中包含所有 EU 區域。這是必要的，因為 App Engine 建立的儲存格是跨區域的。如果 App Engine 應用程式是在 US 區域建立，您必須允許 in:us-locations；如果應用程式是在 ASIA 區域建立，則必須允許 in:asia-locations。

[13] An internal error occurred.

如果您使用共用虛擬私有雲設定的網路設定部署服務，就可能發生此錯誤。建議您嘗試下列做法：

  1. 確認 app.yaml 設定有效。
  2. 請確認您的 App Engine 彈性環境符合共用 VPC 設定的所有要求。請參閱「在共用虛擬私人雲端網路上使用 App Engine 彈性環境」。
  3. 請務必在專案中設定服務帳戶。如果沒有，請務必還原帳戶。共用虛擬私人雲端主專案中的子網路區域必須與建立 App Engine 環境的位置相符。

如果問題仍未解決，請使用 Google Cloud SDK 重新部署服務。請務必新增 --verbosity=debug 旗標。請與Google Cloud 支援團隊聯絡，並提供指令的輸出內容。

IP space of {USER_SUBNETWORK_NAME} is exhausted and needs to be expanded.

如果部署失敗並顯示這則錯誤訊息，表示為 App Engine 服務設定的網路沒有可用來分配給服務新執行個體的位址。如要解決這個問題，請擴大為 App Engine 彈性環境服務設定的子網路的 VPC 範圍。