本頁面說明如何將容器映像檔部署至新的 Cloud Run 服務,或現有 Cloud Run 服務的新修訂版本。
部署時,Cloud Run 會匯入容器映像檔。只要容器映像檔副本用於提供服務的修訂版本,Cloud Run 就會保留該副本。啟動新的 Cloud Run 執行個體時,系統不會從容器存放區提取容器映像檔。
如需部署新服務的逐步範例,請參閱「部署範例容器快速入門導覽課程」。
事前準備
如果您的專案受到網域限制組織政策限制,無法進行未經驗證的叫用,則必須按照「測試私人服務」一節所述的方式存取已部署的服務。
必要的角色
如要取得部署 Cloud Run 服務所需的權限,請要求管理員授予您下列 IAM 角色:
- Cloud Run 開發人員 (
roles/run.developer) 在 Cloud Run 服務上 - 服務身分上的服務帳戶使用者 (
roles/iam.serviceAccountUser) - 部署容器映像檔的 Artifact Registry 存放區具備 Artifact Registry 讀取者 (
roles/artifactregistry.reader) 角色 -
如果您使用跨專案服務帳戶部署服務:
服務身分識別的服務帳戶權杖建立者 (
roles/iam.serviceAccountTokenCreator)
如要查看與 Cloud Run 相關聯的 IAM 角色和權限清單,請參閱「Cloud Run IAM 角色」和「Cloud Run IAM 權限」。如果 Cloud Run 服務與Cloud de Confiance API (例如 Cloud 用戶端程式庫) 介接,請參閱服務身分設定指南。如要進一步瞭解如何授予角色,請參閱「部署權限」和「管理存取權」。
支援的 Container Registry 和映像檔
您可以直接使用儲存在 Artifact Registry 中的容器映像檔,或 Docker Hub 或 GitHub Container Registry 中的公開映像檔。Google 建議使用 Artifact Registry。GitHub Container Registry 和 Docker Hub 映像檔的公開映像檔最多會快取一小時。
您可以設定 Artifact Registry 遠端存放區,使用其他公開或私人註冊資料庫 (例如 JFrog Artifactory 或 Nexus) 的容器映像檔,或 GitHub Container Registry 的私人映像檔。
只有在部署熱門容器映像檔 (例如 Docker 官方映像檔或 Docker 贊助的 OSS 映像檔) 時,才應考慮使用 Docker Hub。 為提高可用性,Google 建議使用 Artifact Registry 遠端存放區部署這些 Docker Hub 或 GitHub Container Registry 映像檔。
從 Docker Hub 或具有外部存放區的 Artifact Registry 遠端存放區部署時,Cloud Run 不支援大於 9.9 GB 的容器映像檔層。
部署新服務
您可以透過標記 (例如 us-docker.pkg.dev/my-project/container/my-image:latest) 或確切摘要 (例如 us-docker.pkg.dev/my-project/container/my-image@sha256:41f34ab970ee...) 指定容器映像檔。
首次部署服務時會建立服務的第一個修訂版本。請注意修訂版本無法變更。如果您透過容器映像檔標記進行部署,這會變成摘要,而修訂版本一律會提供這個特別的摘要。
控制台
如何部署容器映像檔:
前往 Cloud de Confiance 控制台的 Cloud Run 頁面:
點選「Deploy container」(部署容器),顯示「Create service」(建立服務) 表單。
輸入服務名稱。服務名稱不得超過 49 個字元,且每個區域和專案的服務名稱不得重複。服務名稱設定後即無法變更,且會公開顯示。
在「Region」(區域) 欄位中, 使用預設值。
在「驗證」下方,設定下列項目:
- 如要建立公開 API 或網站,請選取「允許公開存取」。選取這個選項會將 IAM Invoker 角色指派給特殊 ID
allUser。服務建立完成後,您可以使用 IAM 編輯這項設定。 - 如要透過驗證機制保護服務,請選取「Require authentication」(需要驗證)。
- 如要建立公開 API 或網站,請選取「允許公開存取」。選取這個選項會將 IAM Invoker 角色指派給特殊 ID
視需要設定帳單。
在「服務調度」下方,如果您使用預設的 Cloud Run自動調度資源,可以選擇指定最少和最多執行個體,或設定調度控制項。如果您使用手動調整資源配置,請指定服務的執行個體數量。
視需要設定表單中的「Ingress」設定。
按一下「Containers, Networking, Security」(容器、網路、安全性),在適當的分頁中設定其他選用設定:
設定完服務後,按一下「建立」,將映像檔部署至 Cloud Run,並等待部署完成。
按一下顯示的網址連結,開啟已部署服務的專屬穩定端點。
gcloud
-
在 Cloud de Confiance 控制台中啟用 Cloud Shell。
Cloud de Confiance 控制台底部會開啟 Cloud Shell 工作階段,並顯示指令列提示。Cloud Shell 是已安裝 Google Cloud CLI 的殼層環境,並已設定適用於您目前專案的值。工作階段可能要幾秒鐘的時間才能初始化。
如何部署容器映像檔:
請執行下列指令:
gcloud run deploy SERVICE --image IMAGE_URL更改下列內容:
- SERVICE:要部署的服務名稱。服務名稱不得超過 49 個字元,且每個區域和專案的服務名稱不得重複。如果服務尚未存在,這項指令會在部署期間建立服務。您可以完全省略這個參數,但系統會提示您輸入服務名稱。
IMAGE_URL:容器映像檔的參照,例如us-docker.pkg.dev/cloudrun/container/hello:latest。如果使用 Artifact Registry,則必須先建立存放區 REPO_NAME。網址格式為LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG。請注意,如果未提供--image標記,部署指令會嘗試從原始碼部署。
如要建立公開 API 或網站,請使用
--allow-unauthenticated標記,允許公開存取服務。這 會將 Cloud Run Invoker IAM 角色 指派給allUsers。您也可以指定--no-allow-unauthenticated來禁止公開存取。如果省略任一標記,系統會在執行deploy指令時提示您確認。等待部署作業完成。成功完成時,畫面會顯示成功訊息,還有已部署服務的網址。
請注意,如要部署到與使用
run/regiongcloud屬性設定的位置不同的位置,請使用:gcloud run deploy SERVICE --region REGION
YAML
您可以將服務規格儲存在 YAML 檔案中,然後使用 gcloud CLI 部署。
建立新的
service.yaml檔案,並加入以下內容:apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE spec: template: spec: containers: - image: IMAGE
更改下列內容:
- SERVICE:Cloud Run 服務的名稱。服務名稱不得超過 49 個字元,且每個區域和專案的服務名稱不得重複。
- IMAGE:容器映像檔的網址。
您也可以指定更多設定,例如環境變數或記憶體限制。
使用下列指令部署新服務:
gcloud run services replace service.yamlgcloud run services replace指令預設會使用service.yaml檔案 (如有)。如要允許未經驗證的存取要求,可以公開發布服務。
Terraform
如要瞭解如何套用或移除 Terraform 設定,請參閱「基本 Terraform 指令」。
在 Terraform 設定的google_cloud_run_v2_service 資源中新增下列項目: provider "google" {
project = "PROJECT-ID"
}
resource "google_cloud_run_v2_service" "default" {
name = "SERVICE"
location = "REGION"
client = "terraform"
template {
containers {
image = "IMAGE_URL"
}
}
}
resource "google_cloud_run_v2_service_iam_member" "noauth" {
location = google_cloud_run_v2_service.default.location
name = google_cloud_run_v2_service.default.name
role = "roles/run.invoker"
member = "allUsers"
}
更改下列內容:
- PROJECT-ID: Cloud de Confiance 專案 ID
- REGION: Cloud de Confiance 區域
- SERVICE:Cloud Run 服務的名稱。服務名稱不得超過 49 個半形字元,且每個區域和專案的服務名稱不得重複。
IMAGE_URL:容器映像檔的參照,例如us-docker.pkg.dev/cloudrun/container/hello:latest。如果您使用 Artifact Registry,則必須先建立存放區 REPO_NAME。網址格式為LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
這項設定允許公開存取 (等同於 --allow-unauthenticated)。如要將服務設為私有,請移除 google_cloud_run_v2_service_iam_member 節。
用戶端程式庫
如要從程式碼部署新服務,請按照下列步驟操作:
REST API
如要部署新服務,請將 POST HTTP 要求傳送至 Cloud Run Admin API service 端點。
例如,使用 curl:
curl -H "Content-Type: application/json" \ -H "Authorization: Bearer ACCESS_TOKEN" \ -X POST \ -d '{template: {containers: [{image: "IMAGE_URL"}]}}' \ https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services?serviceId=SERVICE
更改下列內容:
- ACCESS_TOKEN:帳戶的有效存取權杖,該帳戶具備部署服務的 IAM 權限。舉例來說,如果您已登入 gcloud,可以使用
gcloud auth print-access-token擷取存取權杖。在 Cloud Run 容器例項中,您可以使用容器例項中繼資料伺服器擷取存取權杖。 IMAGE_URL:容器映像檔的參照,例如us-docker.pkg.dev/cloudrun/container/hello:latest。如果您使用 Artifact Registry,則必須先建立存放區 REPO_NAME。網址格式為LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG。- SERVICE:要部署的服務名稱。服務名稱不得超過 49 個半形字元,且每個區域和專案的服務名稱不得重複。
- REGION:服務的 Cloud de Confiance 區域。
- PROJECT-ID: Cloud de Confiance 專案 ID。
Cloud Run 位置
Cloud Run 具有區域性,這表示執行 Cloud Run 服務的基礎架構位於特定區域,並由 Google 負責管理,實現該區域內所有可用區之間的備援可用性。
選擇 Cloud Run 服務的執行區域時,主要考量因素是延遲時間、可用性或耐久性需求。原則上可以選擇距離使用者最近的區域,但也應考慮 Cloud Run 服務所用其他 Cloud de Confiance產品的位置。如果跨多個位置一起使用產品,可能會影響服務的延遲時間和成本。 Cloud de Confiance
Cloud Run 可在下列地區使用:
採用級別 1 定價
asia-east1(臺灣) <asia-northeast1(東京)asia-northeast2(大阪)asia-south1(印度孟買)asia-southeast3(曼谷)europe-north1(芬蘭)低二氧化碳排放2
europe-north2(斯德哥爾摩)低二氧化碳排放2
europe-southwest1(馬德里)低二氧化碳排放
europe-west1(比利時)低二氧化碳排放2
europe-west4(荷蘭)低二氧化碳排放
europe-west8(米蘭)低二氧化碳排放
europe-west9(巴黎)低二氧化碳排放2
me-west1(特拉維夫) <0xnorthamerica-south1(墨西哥)us-central1(愛荷華州)低二氧化碳排放2
us-east1(南卡羅來納州)us-east4(北維吉尼亞州) <us-east5(哥倫布) <0x0us-south1(達拉斯)低二氧化碳排放2
us-west1(奧勒岡州)低二氧化碳排放2
採用級別 2 定價
africa-south1(約翰尼斯堡) <0xasia-east2(香港)asia-northeast3(韓國首爾)asia-southeast1(新加坡) <asia-southeast2(雅加達)asia-south2(印度德里)australia-southeast1(雪梨) <0x0Aaustralia-southeast2(墨爾本)europe-central2(波蘭華沙)低二氧化碳2
europe-west10(柏林) <0x0Aeurope-west12(杜林)低二氧化碳排放
europe-west2(英國倫敦)低二氧化碳排放
europe-west3(德國法蘭克福)europe-west6(瑞士蘇黎世)低二氧化碳2
me-central1(杜哈)me-central2(達曼) <0x0Anorthamerica-northeast1(蒙特婁)低二氧化碳排放2
northamerica-northeast2(多倫多)低二氧化碳排放2
southamerica-east1(巴西聖保羅)低二氧化碳排放2
southamerica-west1(智利聖地牙哥)低二氧化碳排放2
us-west2(洛杉磯)us-west3(鹽湖城)us-west4(拉斯維加斯) <0x
如果您已建立 Cloud Run 服務,可以在Cloud de Confiance 控制台的 Cloud Run 資訊主頁中查看區域。
部署現有服務的新修訂版本
您可以使用 Cloud de Confiance 控制台、gcloud指令列或 YAML 設定檔部署新修訂版本。
請注意,即使容器映像檔沒有變更,只要變更任何設定,系統就會建立新的修訂版本。每個建立的修訂版本都無法變更。
部署時,Cloud Run 會匯入容器映像檔。只要容器映像檔用於提供服務的修訂版本,Cloud Run 就會保留該副本。
控制台
如何部署現有服務的新修訂版本:
在 Cloud de Confiance 控制台中,前往 Cloud Run 的「Services」(服務) 頁面:
在服務清單中,按一下要更新的服務。
在「Containers」(容器) 分頁中,您可以設定下列項目:
在「Networking」(網路) 分頁中,您可以設定下列項目:
在「安全性」分頁中,您可以設定下列項目:
在「縮放」分頁中,您可以設定下列項目:
依序點選「查看差異並重新部署」和「部署變更」,即可部署變更。
gcloud
-
在 Cloud de Confiance 控制台中啟用 Cloud Shell。
Cloud de Confiance 控制台底部會開啟 Cloud Shell 工作階段,並顯示指令列提示。Cloud Shell 是已安裝 Google Cloud CLI 的殼層環境,並已設定適用於您目前專案的值。工作階段可能要幾秒鐘的時間才能初始化。
如何部署容器映像檔:
執行下列指令:
gcloud run deploy SERVICE --image IMAGE_URL更改下列內容:
- SERVICE:要部署至的服務名稱。您可以完全省略這個參數,但如果省略,系統會提示您輸入服務名稱。
IMAGE_URL:容器映像檔的參照,例如us-docker.pkg.dev/cloudrun/container/hello:latest。如果您使用 Artifact Registry,則必須先建立存放區 REPO_NAME。網址格式為LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG。
新修訂版本會自動指派修訂版本後置字元。如要提供自己的修訂版本尾碼,請使用 gcloud CLI 參數 --revision-suffix。
等待部署作業完成。成功完成時,畫面會顯示成功訊息,還有已部署服務的網址。
YAML
如要下載或查看現有服務的設定,請使用下列指令將結果儲存至 YAML 檔案:
gcloud run services describe SERVICE --format export > service.yaml在服務設定 YAML 檔案中,視需要修改任何 spec.template 子項屬性,更新修訂版本設定,然後部署新修訂版本:
gcloud run services replace service.yamlgcloud run services replace 指令預設會使用 service.yaml 檔案 (如有)。
Terraform
請務必按照「部署新服務」範例中的說明設定 Terraform。
變更設定檔。
套用 Terraform 設定:
terraform apply輸入
yes,確認要套用所述動作。
用戶端程式庫
如要透過程式碼部署新的修訂版本,請按照下列步驟操作:
REST API
如要部署新修訂版本,請將 PATCH HTTP 要求傳送至 Cloud Run Admin API service 端點。
例如,使用 curl:
curl -H "Content-Type: application/json" \ -H "Authorization: Bearer ACCESS_TOKEN" \ -X PATCH \ -d '{template: {containers: [{image: "IMAGE_URL"}]}}' \ https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services/SERVICE
更改下列內容:
- ACCESS_TOKEN:帳戶的有效存取權杖,該帳戶具有部署修訂版本的 IAM 權限。
舉例來說,如果您已登入 gcloud,可以使用
gcloud auth print-access-token擷取存取權杖。在 Cloud Run 容器例項中,您可以使用容器例項中繼資料伺服器擷取存取權杖。 IMAGE_URL:容器映像檔的參照,例如us-docker.pkg.dev/cloudrun/container/hello:latest。如果您使用 Artifact Registry,則必須先建立存放區 REPO_NAME。網址格式為LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG。- SERVICE:要部署至的服務名稱。
- REGION:服務的 Cloud de Confiance 區域。
- PROJECT-ID: Cloud de Confiance 專案 ID。
Cloud Run 位置
Cloud Run 具有區域性,這表示執行 Cloud Run 服務的基礎架構位於特定區域,並由 Google 負責管理,實現該區域內所有可用區之間的備援可用性。
選擇 Cloud Run 服務的執行區域時,主要考量因素是延遲時間、可用性或耐久性需求。原則上可以選擇距離使用者最近的區域,但也應考慮 Cloud Run 服務所用其他 Cloud de Confiance產品的位置。如果跨多個位置一起使用產品,可能會影響服務的延遲時間和成本。 Cloud de Confiance
Cloud Run 可在下列地區使用:
採用級別 1 定價
asia-east1(臺灣) <asia-northeast1(東京)asia-northeast2(大阪)asia-south1(印度孟買)asia-southeast3(曼谷)europe-north1(芬蘭)低二氧化碳排放
europe-north2(斯德哥爾摩)低二氧化碳排放2
europe-southwest1(馬德里)低二氧化碳排放
europe-west1(比利時)低二氧化碳排放2
europe-west4(荷蘭)低二氧化碳排放2
europe-west8(米蘭)低二氧化碳排放
europe-west9(巴黎)低二氧化碳排放
me-west1(特拉維夫) <0xnorthamerica-south1(墨西哥)us-central1(愛荷華州)低二氧化碳排放
us-east1(南卡羅來納州) <us-east4(北維吉尼亞州) <us-east5(哥倫布) <0x0us-south1(達拉斯)低二氧化碳排放2
us-west1(奧勒岡州)低二氧化碳排放2
採用級別 2 定價
africa-south1(約翰尼斯堡) <0xasia-east2(香港)asia-northeast3(韓國首爾)asia-southeast1(新加坡) <asia-southeast2(雅加達)asia-south2(印度德里)australia-southeast1(雪梨) <0x0Aaustralia-southeast2(墨爾本)europe-central2(波蘭華沙)低二氧化碳
europe-west10(柏林)europe-west12(杜林)低二氧化碳排放2
europe-west2(英國倫敦)低二氧化碳排放2
europe-west3(德國法蘭克福)europe-west6(瑞士蘇黎世)低二氧化碳2
me-central1(杜哈) <0x0Ame-central2(達曼) <0x0Anorthamerica-northeast1(蒙特婁)低二氧化碳排放2
northamerica-northeast2(多倫多)低二氧化碳排放
southamerica-east1(巴西聖保羅)低二氧化碳排放2
southamerica-west1(智利聖地牙哥)低二氧化碳排放2
us-west2(洛杉磯) <0x0us-west3(鹽湖城)us-west4(拉斯維加斯) <0x
如果您已建立 Cloud Run 服務,可以在Cloud de Confiance 控制台的 Cloud Run 資訊主頁中查看區域。
使用模擬測試驗證設定
您可以使用 --dry-run 旗標驗證服務設定,而不必部署或保留變更。
指定 --dry-run 旗標時,指令會執行下列動作:
- 驗證設定。
- 如果您是從來源部署,則會略過建構程序。
- 不會設定身分與存取權管理政策。
- 列印驗證成功訊息。
如要驗證容器映像檔部署作業,請按照下列步驟操作:
gcloud beta run deploy SERVICE \ --image IMAGE_URL \ --dry-run
更改下列內容:
- SERVICE:要部署的服務名稱。
IMAGE_URL:容器映像檔的參照,例如us-docker.pkg.dev/cloudrun/container/hello:latest。如果您使用 Artifact Registry,則必須先建立存放區 REPO_NAME。網址格式為LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG。
從其他 Cloud de Confiance 專案部署映像檔
如要從其他 Cloud de Confiance 專案部署映像檔,您或管理員必須將必要的 IAM 角色授予部署者帳戶和 Cloud Run 服務代理程式。
如要瞭解部署者帳戶的必要角色,請參閱「必要角色」。
如要將必要角色授予 Cloud Run 服務代理,請參閱下列操作說明:
在 Cloud de Confiance 控制台中,開啟 Cloud Run 服務的專案。
勾選「包含 Google 提供的角色授予項目」。
複製 Cloud Run 服務代理的電子郵件地址。後置字串為 @serverless-robot-prod.s3ns.iam.gserviceaccount.com
開啟擁有您要使用之 Container Registry 的專案。
按一下「新增」,新增主體。
在「新增主體」欄位,貼上先前複製的服務帳戶電子郵件地址。
在「選取角色」選單中,依序點選「Artifact Registry」->「Artifact Registry 讀取者」。
將容器映像檔部署到含有您的 Cloud Run 服務的專案。
部署其他登錄檔中的映像檔
如要部署未儲存在 Artifact Registry 或 Docker Hub 的公開/私人容器映像檔,或 GitHub Container Registry 中的非公開映像檔,請設定 Artifact Registry 遠端存放區。
Artifact Registry 遠端存放區可讓您:
- 部署任何公開容器映像檔。
- 從需要驗證的私人存放區部署容器映像檔,例如 JFrog Artifactory 或 Nexus。
或者,如果無法使用 Artifact Registry 遠端存放區,您可以暫時使用 docker push 將容器映像檔提取並推送至 Artifact Registry,然後部署至 Cloud Run。Cloud Run 會在部署時匯入容器映像檔,因此部署完成後,您可以從 Artifact Registry 刪除映像檔。
將多個容器部署至服務 (Sidecar)
在 Cloud Run 部署作業中,如果使用 Sidecar,會有一個進入容器,負責處理您在容器通訊埠指定的所有傳入 HTTPS 要求,以及一或多個 Sidecar 容器。sidecar 無法監聽 ingress 容器通訊埠的傳入 HTTP 要求,但可以使用 localhost 通訊埠與其他 sidecar 和 ingress 容器通訊。使用的本機主機通訊埠會因容器而異。
在下圖中,Ingress 容器使用 localhost:5000 與 Sidecar 通訊。
![]()
每個執行個體最多可部署 10 個容器,包括 Ingress 容器。 執行個體中的所有容器共用相同的網路命名空間,也可以使用記憶體內共用磁碟區共用檔案,如圖所示。
您可以在第一代或第二代執行環境中部署多個容器。
如果您使用以要求為準的計費方式 (Cloud Run 預設),只有在下列情況下,系統才會為 Sidecar 分配 CPU:
- 執行個體正在處理至少一項要求。
- 輸入容器正在啟動。
如果 Sidecar 必須在要求處理作業以外使用 CPU (例如收集指標),請將服務的帳單設定為按執行個體計費。詳情請參閱「帳單設定 (服務)」。
如果使用以要求為準的計費方式,請設定啟動探查,確保 Sidecar 在啟動時不會受到 CPU 節流。
您可以建立自訂組織政策,規定所有部署作業都必須使用特定 Sidecar。
用途
Cloud Run 服務中,sidecar 的用途包括:
- 應用程式監控、記錄和追蹤
- 在應用程式容器前方使用 Nginx、Envoy 或 Apache2 做為 Proxy
- 新增驗證和授權篩選器 (例如 Open Policy Agent)
- 執行 AlloyDB Auth Proxy 等輸出連線 Proxy
部署含有邊車容器的服務
您可以使用Cloud de Confiance 控制台、Google Cloud CLI、YAML 或 Terraform,將多個 Sidecar 部署至 Cloud Run 服務。
控制台
如要部署含有 Sidecar 的新服務,請按照下列步驟操作:
前往 Cloud de Confiance 控制台的 Cloud Run「Services」(服務) 頁面:
點選「Deploy container」(部署容器),顯示「Create service」(建立服務) 表單。
提供要部署的服務名稱和 Ingress 容器映像檔網址。
按一下「容器、網路、安全性」。
在「Edit container」(編輯容器) 資訊卡中,視需要設定 Ingress 容器。
按一下「新增容器」,然後設定要與 Ingress 容器一起新增的邊車容器。如果 sidecar 依附於服務中的其他容器,請在「Container start-up order」(容器啟動順序) 選單中指明。針對您部署的每個邊車容器重複這個步驟。
點選「建立」。
如要設定具有 Sidecar 的現有服務,請按照下列步驟操作:
前往 Cloud de Confiance 控制台的 Cloud Run「Services」(服務) 頁面:
如要部署至現有服務,請按一下該服務。
按一下「容器」分頁標籤。
按一下「Add container」(新增容器),然後設定要與 Ingress 容器一併新增的邊車容器。如果 Sidecar 依附於服務中的另一個容器,請在「容器啟動順序」選單中指出這點。針對您部署的每個邊車容器重複這個步驟。
按一下「查看差異並重新部署」。
如要將所有流量傳送至新修訂版本,請選取「Serve this revision immediately」(立即提供這個修訂版本)。如要逐步推出,請取消勾選該核取方塊。這樣一來,部署作業就不會將任何流量傳送至新修訂版本。部署後,請按照逐步推出的操作說明進行。
按一下「Deploy changes」(部署變更)。
gcloud
-
在 Cloud de Confiance 控制台啟用 Cloud Shell。
Cloud de Confiance 控制台底部會開啟 Cloud Shell 工作階段,並顯示指令列提示。Cloud Shell 是已安裝 Google Cloud CLI 的殼層環境,並已設定適用於您目前專案的值。工作階段可能要幾秒鐘的時間才能初始化。
如要將多個容器部署至服務,請執行下列指令:
gcloud run deploy SERVICE \ --container INGRESS_CONTAINER_NAME \ --image='INGRESS_IMAGE' \ --port='CONTAINER_PORT' \ --container SIDECAR_CONTAINER_NAME \ --image='SIDECAR_IMAGE'
更改下列內容:
- SERVICE:要部署的服務名稱。您可以完全省略這個參數,但如果省略,系統會提示您輸入服務名稱。
- INGRESS_CONTAINER_NAME:接收要求的容器名稱,例如
app。 INGRESS_IMAGE:應接收要求的容器映像檔參照,例如us-docker.pkg.dev/cloudrun/container/hello:latest。- CONTAINER_PORT:ingress 容器監聽傳入要求的通訊埠。與單一容器服務不同,如果服務包含 Sidecar,則沒有預設的 Ingress 容器通訊埠。您必須明確設定 Ingress 容器的容器通訊埠,且只有一個容器可以公開通訊埠。
- SIDECAR_CONTAINER_NAME:Sidecar 容器的名稱,例如
sidecar。 SIDECAR_IMAGE:對 Sidecar 容器映像檔的參照
如要在部署指令中設定每個容器,請在
container參數後提供每個容器的設定,例如:gcloud run deploy SERVICE \ --container CONTAINER_1_NAME \ --image='INGRESS_IMAGE' \ --set-env-vars=KEY=VALUE \ --port='CONTAINER_PORT' \ --container SIDECAR_CONTAINER_NAME \ --image='SIDECAR_IMAGE' \ --set-env-vars=KEY_N=VALUE_N
等待部署作業完成。成功完成後,系統會顯示成功訊息,以及已部署服務的網址。
YAML
以下操作說明會提供 Cloud Run 服務 (含 sidecar) 的基本 YAML 檔案。建立名為 service.yaml 的檔案,並在其中加入下列內容:
apiVersion: serving.knative.dev/v1 kind: Service metadata: annotations: name: SERVICE spec: template: spec: containers: - image: INGRESS_IMAGE ports: - containerPort: CONTAINER_PORT - image: SIDECAR_IMAGE
更改下列內容:
- SERVICE:Cloud Run 服務的名稱。 服務名稱不得超過 49 個半形字元。
- CONTAINER_PORT:ingress 容器監聽傳入要求的通訊埠。與單一容器服務不同,如果服務包含 Sidecar,則沒有預設的 Ingress 容器通訊埠。您必須明確設定 Ingress 容器的容器通訊埠,且只有一個容器可以公開通訊埠。
INGRESS_IMAGE:應接收要求的容器映像檔參照,例如us-docker.pkg.dev/cloudrun/container/hello:latest。SIDECAR_IMAGE:對 Sidecar 容器映像檔的參照。如要指定多個 Sidecar,請在 YAML 的containers陣列中新增更多元素。
更新 YAML 檔案,加入輸入和邊車容器後,請使用下列指令部署至 Cloud Run:
gcloud run services replace service.yamlgcloud run services replace 指令預設會使用 service.yaml 檔案 (如有)。
Terraform
如要瞭解如何套用或移除 Terraform 設定,請參閱「基本 Terraform 指令」。
在 Terraform 設定的google_cloud_run_v2_service 資源中新增下列項目:resource "google_cloud_run_v2_service" "default" {
name = "SERVICE"
location = "REGION"
ingress = "INGRESS_TRAFFIC_ALL"
template {
containers {
name = "INGRESS_CONTAINER_NAME"
ports {
container_port = CONTAINER_PORT
}
image = "INGRESS_IMAGE"
depends_on = ["SIDECAR_CONTAINER_NAME"]
}
containers {
name = "SIDECAR_CONTAINER_NAME"
image = "SIDECAR_IMAGE"
}
}
}
CONTAINER_PORT 代表 Ingress 容器監聽傳入要求的通訊埠。與單一容器服務不同,如果服務包含 Sidecar,則 Ingress 容器沒有預設通訊埠。您必須明確設定 Ingress 容器的容器通訊埠,且只有一個容器可以公開通訊埠。
部署作業可用的重要 Sidecar 功能
啟動訂單
如果 Deployment 中有多個容器,且某些容器必須先啟動,其他容器才能啟動,您可以指定容器啟動順序。
如果容器依附於其他容器,您必須在部署作業中使用健康狀態檢查。如果使用健康狀態檢查,Cloud Run 會按照容器啟動順序檢查每個容器的健康狀態,確保每個容器都通過檢查,才會按照順序啟動下一個容器。如果不使用健康狀態檢查,即使所依附的容器未執行,健康狀態良好的容器也會啟動。
在 Sidecar 之間交換檔案資料
單一執行個體中的多個容器可以存取共用的記憶體內磁碟區,每個容器都能透過您建立的掛接點存取該磁碟區。這項功能通常用於在容器之間共用檔案,例如遙測輔助容器可以從應用程式容器收集記錄。
在 Sidecar 之間通訊
同一執行個體的兩個容器可以在本機網路上相互通訊。
請參考以下範例服務:
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: example
spec:
template:
spec:
containers:
- name: ingress
image: ...
ports:
- containerPort: 8080
- name: sidecar
image: ...
這項服務的每個執行個體都會執行兩個容器:一個名為 ingress,另一個名為 sidecar。
傳送至服務的要求會傳送至通訊埠 8080 上的 ingress 容器。
如果服務有多個容器,只能將其中一個容器設為處理所有傳入要求的輸入容器,且必須是已設定 containerPort 的容器。
容器 ingress 和 sidecar 可以在 http://localhost 上互相通訊。舉例來說,如果容器 sidecar 在通訊埠 5000 上監聽要求,容器 ingress 就能透過 http://localhost:5000 與其通訊。
由於容器已命名,容器甚至可以使用容器名稱彼此通訊。舉例來說,如果容器 sidecar 在通訊埠 5000 上監聽要求,則容器 ingress 可以使用 http://sidecar:5000 與 sidecar 通訊。
調整容器以適用於 Cloud Run
您建構或找到的大部分容器,都會與 Cloud Run 容器執行階段合約相容。不過,您可能需要變更部分容器,以簡化本機開發作業,或預期完全控制機器,才能讓容器與 Cloud Run 執行環境相容。
將掛接點移至 Cloud Run 設定
容器的初始化指令碼必須假設掛接作業已完成,才能呼叫容器。您必須將所有掛接作業移至 Cloud Run 資源設定。
盡可能切換為非超級使用者
請盡量使用不依賴或使用超級使用者的容器。這項做法可降低 Cloud Run 服務的安全性風險、縮小容器的攻擊面、限制攻擊者存取檔案系統的權限,並遵循最低權限原則。
請在 Dockerfile 中使用 USER 指令,切換至權限較低的 ID,因為預設是以根身分執行。Cloud Run 會使用 Dockerfile 中指定的使用者執行容器。
稽核 setuid 二進位檔的使用情形
在 Cloud Run 容器中執行 setuid 二進位檔會失敗。
如果您在本機使用 Docker 或 Podman,請使用 --cap-drop=setuid 引數。
或者,驗證您依附的二進位檔是否未設定 setuid 位元。
確認根容器與使用者命名空間相容
在使用者命名空間下執行程式碼時 (例如使用 Docker 的 userns-remap 功能、在 無根 Podman 中執行容器,或使用 docker run 指令中的 --userns-remap=default 引數,將這些變更部署至執行 Google Container-Optimized OS 的 VM),評估程式碼,在本機或 VM 中測試變更。
停用部署作業健康狀態檢查
根據預設,Cloud Run 會啟動執行個體,並等待啟動探測通過,藉此檢查部署作業是否健康。如果健康狀態檢查失敗,系統會將修訂版本標示為不健康,且不會將流量導向該版本。
如果不需要或想加快部署速度,可以停用部署健康狀態檢查:
gcloud
如要停用部署作業健康狀態檢查,請使用 --no-deploy-health-check 旗標:
gcloud run deploy --image IMAGE_URL --no-deploy-health-check
更改下列內容:
IMAGE_URL:容器映像檔的參照,例如us-docker.pkg.dev/cloudrun/container/hello:latest。如果使用 Artifact Registry,則必須先建立存放區 REPO_NAME。網址格式為LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG。
如果先前已停用部署健康狀態檢查,請使用 --deploy-health-check 重新啟用。
YAML
如要停用部署健康狀態檢查,請將值為 'true' 的 run.googleapis.com/health-check-disabled 註解新增至 spec.template.metadata.annotations。
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: SERVICE
spec:
template:
metadata:
annotations:
run.googleapis.com/health-check-disabled: 'true'
Terraform
如要停用部署作業健康狀態檢查,請在 template 區塊中將 health_check_disabled 引數設為 true。
resource "google_cloud_run_v2_service" "default" {
name = "SERVICE"
...
template {
health_check_disabled = true
...
}
}
後續步驟
您在部署新服務後,可以進行下列作業:
- 漸進式推出、復原修訂版本、流量遷移
- 查看服務記錄
- 監控服務成效
- 設定記憶體上限
- 設定環境變數
- 變更服務並行設定
- 管理服務
- 管理服務修訂版本
- Cloud Run OpenTelemetry Sidecar 範例
- 使用二進位授權,只部署受信任的映像檔 (預先發布版)
您可以使用 Cloud Build 自動建構觸發條件,自動執行 Cloud Run 服務的建構與部署作業:
您也可以使用 Cloud Deploy 設定持續推送軟體更新管道,將 Cloud Run 服務部署至多個環境: