部署 Cloud Run 函式時,系統會自動協調底層 Google Cloud 服務 (包括 Cloud Storage、Cloud Build 和 Artifact Registry),封裝並執行程式碼。瞭解這些服務互動,有助於設定必要的 Identity and Access Management 權限、追蹤資源依附元件,以及排解部署或建構問題。
事前準備
請參閱「Cloud Run 部署選項和資源模型」指南,熟悉 Cloud Run functions 和原始碼部署概念。
架構總覽
將函式的原始碼部署至 Cloud Run functions 時,該原始碼會儲存在 Cloud Storage bucket 中。Cloud Build 接著會自動在容器映像檔中建構原始碼,並將該映像檔推送至 Artifact Registry 映像檔存放區。Cloud Run functions 需要執行容器來執行函式時,會存取這個映像檔。
在下圖中,Cloud Run functions 方塊代表使用 Cloud Run Admin API 或 Cloud Functions API,在 Cloud Run 中部署的函式。一般來說,較新的函式會使用 Cloud Run Admin API 部署,較舊的函式則會使用 Cloud Functions API 部署。
視部署函式時使用的 API 而定,會發生下列情況:
如果您使用 Cloud Run Admin API 部署函式,會發生下列情況:
原始碼會上傳至沒有保留期限的 Cloud Storage bucket。
- 如果您使用預設加密機制,系統會自動產生 bucket 名稱,並命名為
run-sources-PROJECT_ID-REGION。 - 如果您使用客戶自行管理的加密金鑰 (CMEK) 保護資料,系統不會自動產生 bucket 名稱,您必須提供 bucket 名稱。
- 如果您使用預設加密機制,系統會自動產生 bucket 名稱,並命名為
原始碼會提交至 Cloud Build,由 Google Cloud 的 buildpack 和 Functions Framework 建立容器映像檔。請注意,Cloud Build 服務帳戶會建構容器映像檔。Cloud Run 預設會使用 Cloud Build 提供的
e2-standard-2機器類型。接著,系統會透過自動建立的 bucket
REGION-docker.pkg.dev/PROJECT_ID/cloud-run-source-deploy,將容器映像檔上傳至 Artifact Registry。映像檔會以服務的形式部署至 Cloud Run。
您可以使用 Eventarc、Pub/Sub 或其他 HTTP 觸發條件,觸發或叫用函式。
如果您使用 Cloud Functions API (第 2 代) 部署函式,會發生下列情況:
原始碼會上傳至沒有保留期限的 Cloud Storage bucket。
bucket 名稱會自動產生,格式如下:
- 如果您使用預設加密機制,系統會將這個 bucket 命名為
gcf-v2-sources-PROJECT_NUMBER-REGION。 - 如果您使用 CMEK 保護資料,則系統會將 bucket 命名為
gcf-sources-PROJECT_NUMBER-REGION-CMEK_KEY_HASH。
- 如果您使用預設加密機制,系統會將這個 bucket 命名為
原始碼會提交至 Cloud Build,由 Google Cloud 的 buildpack 和 Functions Framework 建立容器映像檔。請注意,Cloud Build 服務帳戶會建構容器映像檔。Cloud Run 預設會使用 Cloud Build 提供的
e2-standard-2機器類型。接著,系統會透過自動建立的 bucket
REGION-docker.pkg.dev/PROJECT_ID/gcf-artifacts,將容器映像檔上傳至 Artifact Registry。映像檔會以服務的形式部署至 Cloud Run。
您可以使用 Eventarc、Pub/Sub 或其他 HTTP 觸發條件,觸發或叫用函式。
後續步驟
- 瞭解不同類型的函式,以及觸發函式的選項。
- 如果您先前使用 Cloud Functions API 建立函式,請參閱 Cloud Run functions 比較指南,瞭解兩個 Cloud Run functions 版本之間的差異。