區域 ID
REGION_ID 是 Google 根據您在建立應用程式時選取的地區所指派的縮寫代碼。此代碼不對應至國家/地區或省份,即使部分區域 ID 可能與常用的國家/地區和省份代碼相似。如果是 2020 年 2 月後建立的應用程式,App Engine 網址會包含 REGION_ID.r。如果是這段時間前建立的現有應用程式,網址可選擇是否包含地區 ID。
進一步瞭解區域 ID。
本指南為熟悉 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。
| App Engine 標準環境 | App Engine 彈性環境 | Cloud Run | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 術語 | 應用程式 | 不適用 | |||||||||||||||||||
| 服務 | 服務 | ||||||||||||||||||||
| 版本 | 修訂版本 | ||||||||||||||||||||
網址端點 |
|||||||||||||||||||||
| 應用程式網址
( default 服務)
|
https://PROJECT_ID.REGION_ID.r.appspot.com
|
不適用 | |||||||||||||||||||
| 服務網址 |
https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
|
|
|||||||||||||||||||
| 版本/修訂版本網址 |
https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
|
|
|||||||||||||||||||
資源調度 |
|||||||||||||||||||||
| 自動調整資源配置 | 是 | 是 | 是 | ||||||||||||||||||
| 手動調整資源配置 | 是 | 是 | 是 | ||||||||||||||||||
| 將資源調度率降至零 | 是 | 否 | 是 | ||||||||||||||||||
| 暖機要求 | 可設定 | 否 | 自動 | ||||||||||||||||||
| 閒置執行個體逾時 (完成最後一個要求後) | 最多 15 分鐘 | 取決於「帳單」設定。使用以執行個體為依據的計費方式,模擬 App Engine 行為 | |||||||||||||||||||
| 要求逾時 |
|
60 分鐘 | 可設定最長 60 分鐘 (預設為 5 分鐘) | ||||||||||||||||||
部署作業 |
|||||||||||||||||||||
| 從來源 | 是 | 是 | |||||||||||||||||||
| 容器映像檔 | 否 | 是 (自訂執行階段) | 是 | ||||||||||||||||||
| 邊車容器 | 否 | 可以。Sidecar 會與主要容器並行執行,處理網路要求。 | |||||||||||||||||||
| 健康狀態檢查 | 自動:App Engine 會對執行個體執行就緒和有效性檢查。 | 可設定。您可以在 Cloud Run 資源設定中明確定義啟動和存活探查,並指定探查類型 (TCP、HTTP 和 gRPC)、路徑、通訊埠、初始延遲、週期、逾時、成功門檻和失敗門檻等詳細資料。 | |||||||||||||||||||
運算資源 |
|||||||||||||||||||||
| vCPU |
|
最多 80 個 vCPU | 最多 8 個 vCPU | ||||||||||||||||||
| 記憶體 | 每個 vCPU 最多 6.5 GB | 最多 32 GB | |||||||||||||||||||
| GPU | 否 | 可以。每個 Cloud Run 執行個體可設定一個 GPU。 | |||||||||||||||||||
| 磁碟區掛接 | 否 | 可以。您可以將 Cloud Storage 值區掛接到容器的檔案系統中。 | |||||||||||||||||||
定價模式 |
|||||||||||||||||||||
| 按要求次數計費 | 否 |
否,使用以執行個體為基礎的帳單時,不會有這類費用。 是,使用以要求為準的計費方式時。 |
|||||||||||||||||||
| 閒置執行個體數量下限 | 與有效執行個體相同的費用 | 閒置最少量執行個體的費用較低(請參閱「計費容器執行個體時間」) | |||||||||||||||||||
| 承諾使用折扣 (CUD) | 否 | 是 | |||||||||||||||||||
| 以執行個體為依據的計費方式 (每小時執行個體費用) | F4/B4 執行個體:$0.2 美元 |
|
|
||||||||||||||||||
安全性 |
|||||||||||||||||||||
| 輸入設定 | 是 | 是 | 是 | ||||||||||||||||||
| 呼叫者角色 | 否 | 是 | |||||||||||||||||||
| IAP | 是 | 是 | 是 | ||||||||||||||||||
| 防火牆 | 是 | 是 | 使用 Google Cloud Armor 進行設定 | ||||||||||||||||||
| Secret Manager | 可以,但須使用 Cloud 用戶端程式庫。 | 可以。您可以將每個密鑰掛接為磁碟區,或使用環境變數傳遞密鑰。 | |||||||||||||||||||
連線能力 |
|||||||||||||||||||||
| 自訂網域 | 是 | 是 | 是 | ||||||||||||||||||
| 虛擬私有雲連線 (包括共用虛擬私有雲) | 是 | 不適用 | 是 | ||||||||||||||||||
| 虛擬私有雲輸出設定 | 是 | 不適用 | 是 | ||||||||||||||||||
| 多區域負載平衡 | 否 | 是 | |||||||||||||||||||
| 伺服器串流 | 否 | 是 | |||||||||||||||||||
存取 Google Cloud 服務 |
|||||||||||||||||||||
| Cloud SQL | 是 | 是 | 是 | ||||||||||||||||||
| Cloud 用戶端程式庫 | 如果您在 App Engine 中使用 Cloud 用戶端程式庫,遷移至 Cloud Run 時不需要進行任何變更。這些用戶端程式庫的用途極為廣泛,代表應用程式具有更高的可攜性。 | ||||||||||||||||||||
| App Engine 舊版套裝組合服務 | 是 (僅限 Java、Python、Go、PHP) | 否 | 否 | ||||||||||||||||||
資源模型
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 檔案:
| App Engine 服務 - 版本 1 | App Engine 服務 - 版本 2 |
|---|---|
| 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: |
version1 已設定 instance_class: F4,而未提供 instance_class 值的 version2 則已設定預設的 instance_class: F1。
如果是 Cloud Run,系統會套用您提供的所有設定,但未提供的設定會保留現有值。你只需要為要變更的設定提供值。例如:
| Cloud Run 服務 - 修訂版本 1 | Cloud Run 服務 - 修訂版本 2 |
|---|---|
| 部署指令 | |
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 Engine 彈性環境 | Cloud Run |
|---|---|---|---|
| 運算資源 | F1 | 1 個 vCPU,0.6 GB | 1 個 vCPU,512 MB |
| 並行要求數量上限 | 10 | 無 | 80 |
| 要求逾時 |
|
60 分鐘 | 5 分鐘 |
| CPU 使用率目標 | 60% | 50% | 60% |
| 執行個體數量上限 | 無 | 20 | 100 |
| 執行個體數量下限 | 0 | 2 | 0 |
進入點
從來源部署時,App Engine 會從 app.yaml 的 entrypoint 屬性讀取進入點指令。如果未提供進入點,系統會使用執行階段專屬的預設值。從來源部署時,Cloud Run 會使用 Google Cloud 的 Buildpack,但部分語言沒有預設進入點,因此您必須提供進入點,否則建構作業會失敗。舉例來說,Python 建構套件需要 Procfile,或指定 GOOGLE_ENTRYPOINT 建構環境變數。
如要瞭解特定語言的設定需求,請參閱建構套件說明文件。
健康狀態檢查
在 App Engine 中,健康狀態檢查大多由平台自動執行及管理。App Engine 會執行有效性和完備性檢查,判斷執行個體是否正常運作,以及是否準備好處理流量。如果執行個體持續未通過自動檢查,App Engine 會終止該執行個體,並換成新的執行個體,確保服務不中斷。
Cloud Run 提供更精細的控制選項,可設定啟動和存活探查。您可以透過這些探測定義健康狀態良好的執行個體,這對複雜的微服務至關重要。
在 Cloud Run 中,您可以設定下列探針:
啟動探測作業可定義容器何時啟動,並準備好處理流量。設定啟動探測時,系統會停用有效性檢查,直到啟動成功為止,確保有效性探測不會干擾應用程式啟動。
有效性探測作業會判斷何時應重新啟動容器。舉例來說,應用程式執行時若發生死結,但無法繼續運作,有效性探測就會偵測到這個問題。在這種情況下重新啟動容器,可確保應用程式在發生錯誤時仍可使用。
詳情請參閱「為服務設定容器健康狀態檢查」。
資源調度
雖然 Cloud Run 和 App Engine 標準環境共用類似的資源調度基礎架構,但 Cloud Run 經過簡化,可加快資源調度速度,並提供資源調度至零的功能。因此可設定的選項較少。這項簡化作業會將可設定的項目限制為:
如果是 Cloud Run 執行個體,目標 CPU 使用率無法設定,一律為 60%。詳情請參閱「關於 Cloud Run 服務中的執行個體自動調度」。
App Engine 彈性環境使用 Compute Engine 自動調度器,因此資源調度特性與 App Engine 標準環境和 Cloud Run 大不相同。
將 App Engine 的縮放控制項遷移至 Cloud Run
本節說明如何將現有的 App Engine 縮放設定對應至 Cloud Run。
執行個體數量下限 (暖機)
將特定數量的執行個體維持在暖機狀態,以處理基準流量並避免冷啟動。
| 設定環境 | 設定 |
|---|---|
| App Engine 標準環境 | min_instances: N |
| App Engine 彈性環境 | automatic_scaling:min_num_instances: N |
| Cloud Run | 服務層級:scaling.min_instance_count: N 修訂版本層級: template.scaling.min_instance_count: N |
遷移策略:在服務層級設定暖機的執行個體數量下限。如果將流量導向特定修訂版本,修訂版本層級的設定會覆寫服務層級的預設值。您可以使用這項設定,先以不同的最低執行個體計數測試新修訂版本,再將其升級至正式版。
執行個體數量上限
為控管費用和保護下游依附元件,請設定執行個體總數的硬性限制。
| 設定環境 | 設定 |
|---|---|
| App Engine 標準環境 | max_instances: N |
| App Engine 彈性環境 | automatic_scaling:max_num_instances: N |
| Cloud Run | 服務層級:scaling.max_instance_count: N 修訂版本層級: template.scaling.max_instance_count: N |
遷移策略:在服務層級設定全域限制。Cloud Run 會強制執行服務層級和修訂版本層級設定中較低的設定。詳情請參閱「為服務設定執行個體數量上限」。
並行
定義單一執行個體的要求容量。
| 設定環境 | 設定 |
|---|---|
| App Engine 標準環境 | max_concurrent_requests: N |
| App Engine 彈性環境 | automatic_scaling:target_concurrent_requests: N |
| Cloud Run | template.maxInstanceRequestConcurrency: N |
遷移策略:請採用下列其中一種遷移策略:
從 Cloud Run 執行個體容量預設值 80 開始,然後執行負載測試,找出 Cloud Run 上應用程式的穩定並行限制。調整這個值是有效的方法,可盡可能提升 Cloud Run 的效能和成本效益。根據測試結果,將值調低至 80 以下。詳情請參閱「設定每個執行個體的並行要求數量上限」。
在 App Engine 標準環境中使用現有的設定值,每個執行個體預設為 10 個並行要求。這是安全的選項,因為這是應用程式已知的有效設定。不過,由於自動調度資源程序會建立超出負載處理需求量的執行個體,因此可能會導致 Cloud Run 執行個體的使用率大幅降低,進而產生較高的費用。
CPU 使用率
CPU 負載超過特定門檻時進行擴充。
| 設定環境 | 設定 |
|---|---|
| App Engine 標準環境 | target_cpu_utilization: 0.X |
| App Engine 彈性環境 | automatic_scaling:cpu_utilization:target_utilization: N |
| Cloud Run | 沒有直接對應項目 (固定為約 60%) |
遷移策略:您無法設定這個值。Cloud Run 的自動調度器會將作用中執行個體的 CPU 使用率維持在 60% 左右。與 App Engine 不同,Cloud Run 只會在處理要求時分配 CPU,否則會將 CPU 使用率調降至零。在 App Engine 標準環境中,無論您設定的資源調度類型為何,App Engine 都會確保執行個體持續有 CPU 可用。
如果應用程式會在要求之間執行任何背景工作,例如在基本或手動資源調度中使用背景執行緒,請在 Cloud Run 中設定以執行個體為準的計費方式,避免背景處理工作遭到暫停。
要求的處理量
應用程式達到並行上限時,請根據要求輸送量調度資源。
| 設定環境 | 設定 |
|---|---|
| App Engine 標準環境 | target_throughput_utilization: 0.X |
| App Engine 彈性環境 | 無法使用 |
| Cloud Run | 考慮調整 template.maxInstanceRequestConcurrency 設定 |
遷移策略:Cloud Run 自動調度器會嘗試將每個執行個體的並行要求數維持在 maxInstanceRequestConcurrency 值的 60%。設定這個值時,您會隱含定義觸發擴充事件的目標輸送量。
延遲時間
定義觸發擴充作業的使用者等待時間範圍。App Engine 會部分回應要求排隊。
| 設定環境 | 設定 |
|---|---|
| App Engine 標準環境 | min_pending_latency 和 max_pending_latency |
| App Engine 彈性環境 | 無法使用 |
| Cloud Run | 沒有直接對應的項目 |
遷移策略:Cloud Run 會在要求開始排隊和延遲時間飆升前,自動調度資源。如果發生延遲時間尖峰,請考慮調整 template.maxInstanceRequestConcurrency 值,確保能更快擴充。
閒置執行個體
用途:在 App Engine 中,閒置執行個體設定會控管預先暖機的閒置執行個體集區,吸收流量尖峰並控管費用。
| 設定環境 | 設定 |
|---|---|
| App Engine 標準環境 | min_idle_instances: N 或 max_idle_instances: N |
| App Engine 彈性環境 | 無法使用 |
| Cloud Run | 沒有直接對應的項目 |
遷移策略:您無法在 Cloud Run 中設定個別的閒置執行個體數量下限或上限。如要讓執行個體保持暖機狀態,隨時可處理流量,並減少 Cloud Run 中的冷啟動情形,請使用 scaling.min_instance_count 設定,確保系統一律會執行指定數量的容器。詳情請參閱「關於 Cloud Run 服務中的執行個體自動調度資源」。
閒置執行個體逾時
在 App Engine 中,閒置執行個體會在最後一個要求傳送完畢後,繼續運作約 15 分鐘。Cloud Run 會使用帳單設定控制這項行為。
如要達到與 App Engine 類似的計費行為 (即在要求處理程序以外分配 CPU),請在 Cloud Run 中使用以執行個體為準的計費方式。
或者,您也可以使用以要求為依據的計費模式,只在要求處理期間分配 CPU。採用這項設定時,執行個體在收到最後一個要求後,仍會保持運作最多 15 分鐘,但 CPU 會在這段閒置時間內受到節流。
基本資源配置
| 設定環境 | 設定 |
|---|---|
| App Engine 標準環境 | basic_scaling: max_instances: N |
| App Engine 彈性環境 | 無法使用 |
| Cloud Run | 預設為自動調整資源配置。scaling.min_instance_count: 0 scaling.max_instance_count: N |
在 App Engine 標準環境中設定 basic_scaling 時,系統會在收到要求時建立執行個體,並在一段時間沒有活動後將執行個體數量調度為零。您可以在 Cloud Run 中使用自動調整資源配置,將 min-instances 設為 0,即可複製這項行為。
手動調整資源配置
執行固定數量的執行個體,並停用自動調度資源。
| 設定環境 | 設定 |
|---|---|
| App Engine 標準環境 | manual_scaling: instances: N |
| App Engine 彈性環境 | manual_scaling: instances: N |
| Cloud Run | scalingMode: MANUALmanualInstanceCount: N |
遷移策略:Cloud Run 中有手動調整規模的直接對應項目。在 Cloud Run 中,將服務層級的資源調度模式設為 MANUAL,並使用 manualInstanceCount 指定要執行的確切執行個體數量。這與完全停用自動調度功能的效果相同。詳情請參閱 Cloud Run 中的手動調整規模。
等待期
設定擴充事件發生後的冷卻期,避免在冷卻期內發生其他事件。
| 設定環境 | 設定 |
|---|---|
| App Engine 標準環境 | 無法使用 |
| App Engine 彈性環境 | automatic_scaling:cool_down_period_sec: N |
| Cloud Run | 沒有直接對應的項目 |
遷移策略:無須制定。Cloud Run 會根據需求和使用率自動調度資源,並有效率地做出反應,不需手動設定冷卻期。
暖機要求
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 行為,您可以允許未經驗證的要求,公開發布服務。您可以在部署時設定,也可以更新現有服務的身分與存取權管理政策繫結。
部署作業
使用 --allow-unauthenticated 部署標記:
gcloud run deploy SERVICE_NAME ... --allow-unauthenticated
現有服務
使用 gcloud run services add-iam-policy-binding 指令:
gcloud run services add-iam-policy-binding SERVICE_NAME \ --member="allUsers" \ --role="roles/run.invoker"
其中 SERVICE_NAME 是 Cloud Run 服務名稱。
或者,您也可以授予 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"
其中 SERVICE_NAME 是服務名稱,MEMBER_TYPE 則是主體類型。例如:user:email@domain.com。
如需 MEMBER_TYPE 的可接受值清單,請參閱「主體 ID」。
現有服務
gcloud run services add-iam-policy-binding SERVICE_NAME \ --member=MEMBER_TYPE \ --role="roles/run.invoker"
其中 SERVICE_NAME 是服務名稱,MEMBER_TYPE 則是主體類型。例如:user:email@domain.com。
如需 MEMBER_TYPE 的可接受值清單,請參閱「主體 ID」。
環境變數和中繼資料
App Engine 和 Cloud Run 都會自動設定特定環境變數。下表列出 App Engine 環境變數,以及對應的 Cloud Run 環境變數。與 App Engine 相比,Cloud Run 僅實作少數環境變數,但中繼資料伺服器提供的資料大致相同。
預設環境變數
| App Engine 名稱 | {[cloud_run_name]} 名稱 | 說明 |
|---|---|---|
GAE_SERVICE
|
K_SERVICE
|
目前服務的名稱。在 App Engine 中,如果未指定,這會設為 `default`。 |
GAE_VERSION
|
K_REVISION
|
服務目前的版本標籤。 |
PORT
|
PORT
|
接受 HTTP 要求的通訊埠。 |
| 不適用 | K_CONFIGURATION
|
建立修訂版本的 Cloud Run 設定名稱。 |
GOOGLE_CLOUD_PROJECT
|
不適用 | 與應用程式相關聯的 Google Cloud 專案 ID。 |
GAE_APPLICATION
|
App Engine 應用程式的 ID。這個 ID 的前置字串為「區域代碼~」,例如在歐洲部署的應用程式為「e~」。 | |
GAE_DEPLOYMENT_ID
|
目前部署作業的 ID。 | |
GAE_ENV
|
App Engine 環境。如果是標準環境,請設為 `standard`。 | |
GAE_INSTANCE
|
執行服務的執行個體 ID。 | |
GAE_MEMORY_MB
|
應用程式程序可用的記憶體量,以 MB 為單位。 | |
NODE_ENV (僅適用於 Node.js 執行階段)
|
在部署服務時設定為 production。 | |
GAE_RUNTIME
|
在 app.yaml 檔案中指定的執行階段。 |
常見的中繼資料伺服器路徑
| 路徑 | 說明 | 範例 |
|---|---|---|
/computeMetadata/v1/project/project-id
|
服務所屬專案的專案 ID | test_project |
/computeMetadata/v1/project/numeric-project-id
|
服務所屬專案的專案編號 | 12345678912 |
/computeMetadata/v1/instance/id
|
容器執行個體的專屬 ID (記錄中也提供)。 | 16a61494692b7432806a16
(英數字元字串) |
/computeMetadata/v1/instance/region
** 不適用於 App Engine 彈性環境 |
這項服務的區域,傳回 projects/PROJECT_NUMBER/regions/REGION
|
projects/12345678912/regions/us-central1 |
/computeMetadata/v1/instance/service-accounts/default/email
|
這項服務的執行階段服務帳戶電子郵件地址。 | service_account@test_project.iam.gserviceaccount.com |
/computeMetadata/v1/instance/service-accounts/default/token
|
為這項服務的服務帳戶產生 OAuth2 存取權杖。這個端點會傳回含有 access_token 屬性的 JSON 回應。 |
{ "access_token":"<TOKEN>", "expires_in":1799, "token_type":"Bearer" } |