本頁面說明如何使用單一 gcloud CLI 指令,直接從原始碼將新服務或服務修訂版本部署至 Cloud Run,方法是使用 gcloud run deploy 搭配 --source 旗標。如需部署 Hello World 服務的範例逐步說明,請參閱「從來源部署快速入門導覽課程」。
- 使用建構功能從來源部署 (預設):
這個選項會使用 Google Cloud 的 Buildpacks 和 Cloud Build,自動從原始碼建構容器映像檔,不必在機器上安裝 Docker,也不必設定 Buildpacks 或 Cloud Build。根據預設,Cloud Run 會使用 Cloud Build 提供的預設機型。執行
gcloud run deploy --source也可免去執行gcloud builds submit指令的需要。 - 從原始碼部署,不需建構 (搶先版): 這個選項會直接將構件部署至 Cloud Run,略過 Cloud Build 步驟。因此部署時間較短。
請注意,來源部署作業會使用 Artifact Registry 儲存建構的容器。如果專案在您要部署的區域中,還沒有名為 cloud-run-source-deploy 的 Artifact Registry 存放區,這項功能會自動建立名為 cloud-run-source-deploy 的 Artifact Registry 存放區。
如果原始碼目錄中含有 Dockerfile,系統會使用該 Dockerfile 建構上傳的原始碼。如果原始碼目錄中沒有 Dockerfile,Google Cloud 的 Buildpacks 會自動偵測您使用的語言,並擷取程式碼的依附元件,使用 Google 管理的安全基礎映像檔,製作可立即用於實際工作環境的容器映像檔。
根據預設,只有在部署 Cloud Run 服務時,才會套用安全性修正程式。為服務啟用自動安全性更新後,該服務就會自動接收修補程式,完全不需要停機。進一步瞭解如何設定安全性更新。事前準備
- 請確認您已按照設定頁面的說明,為 Cloud Run 設定新專案。
-
如果尚未啟用,請啟用 Cloud Run Admin API。
啟用 API 時所需的角色
如要啟用 API,您必須具備
serviceusage.services.enable權限。如果您建立了專案,可能已透過「擁有者」角色 (roles/owner) 取得這項權限。否則,您可以透過「服務使用情形管理員」角色 (roles/serviceusage.serviceUsageAdmin) 取得這項權限。瞭解如何授予角色。啟用 Cloud Run Admin API 後,系統會自動建立 Compute Engine 預設服務帳戶。
必要的角色
如要從來源部署,您或管理員必須授予部署者帳戶下列 IAM 角色。
按一下即可查看部署者帳戶的必要角色
如要取得從來源建構及部署所需的權限,請要求管理員授予您下列 IAM 角色:
- 專案的 Cloud Run 原始碼開發人員 (
roles/run.sourceDeveloper) - 專案的服務使用情形用戶 (
roles/serviceusage.serviceUsageConsumer) - Cloud Run 服務身分上的「服務帳戶使用者」 (
roles/iam.serviceAccountUser)
如需與 Cloud Run 相關聯的 IAM 角色和權限清單,請參閱「Cloud Run IAM 角色」和「Cloud Run IAM 權限」。如果 Cloud Run 服務與Google Cloud API (例如 Cloud 用戶端程式庫) 介接,請參閱服務身分設定指南。如要進一步瞭解如何授予角色,請參閱「部署權限」和「管理存取權」。
支援的語言
除了使用 Dockerfile 的來源,從來源部署也支援下列語言,並使用 Google Cloud 的建構包:
| 執行階段 | 來源部署作業 | 設定 |
|---|---|---|
| Go | 部署 Go 服務 | 設定 Go 建構包 |
| Node.js | 部署 Node.js 服務 | 設定 Node.js 建構套件 |
| Python | 部署 Python 服務 | 設定 Python 建構套件 |
| Java (包括 Kotlin、Groovy、Scala) |
部署 Java 服務 | 設定 Java 建構包 |
| .NET | 部署 .NET 服務 | 設定 .NET 建構套件 |
| 小茹 | 部署 Ruby 服務 | 設定 Ruby 建構套件 |
| PHP | 部署 PHP 服務 | 設定 PHP 建構包 |
| 僅限作業系統 | 部署 Go 服務 | 設定僅限 OS 的執行階段 |
進一步瞭解支援的語言版本。
從來源部署並建構
本節說明如何使用 Google Cloud 的 Buildpacks 和 Cloud Build,從原始碼自動建構容器映像檔,不必在機器上安裝 Docker,也不必設定 Buildpacks 或 Cloud Build。
限制
- 從來源部署功能會使用 Artifact Registry 和 Cloud Build,因此這項功能僅適用於 Artifact Registry 支援的區域和 Cloud Build。
- 從來源部署是便利的功能,但無法完全自訂建構作業。如要進一步控管,請使用 Cloud Build 建構容器映像檔 (例如使用
gcloud builds submit),然後使用gcloud run deploy --image等工具部署容器映像檔。 - 使用 Google Cloud 的建構包從來源部署時,來源檔案的「上次修改日期」會設為 1980 年 1 月 1 日。這是 buildpack 的預設行為,旨在支援可重現的建構作業。視語言架構而定,這可能會影響靜態檔案的瀏覽器端快取。如果您的應用程式受到影響,Google 建議在應用程式中停用
etag和Last-ModifiedHTTP 標頭。 - 使用 Google Cloud 的 Buildpacks 從來源部署時,一律會使用
gcr.io/buildpacks/builder:latest。 如果latest沒有您偏好的語言或 OS 設定,請使用特定建構工具,透過偏好的建構工具建立應用程式映像檔。 您可以使用 Kotlin 和其他 JVM 語言 (例如 Java),從來源部署服務。使用的語言必須符合下列規則:
- 您可以使用 Maven 或 Gradle 建構應用程式。
- 建構檔案包含產生類別所需的所有外掛程式。
使用建構作業部署前
從來源部署並建構前,請先完成下列事項:
請按照「事前準備」一節的步驟操作。
-
如果尚未啟用,請啟用 Cloud Build API。
啟用 API 時所需的角色
如要啟用 API,您必須具備
serviceusage.services.enable權限。如果您建立了專案,可能已透過「擁有者」角色 (roles/owner) 取得這項權限。否則,您可以透過「服務使用情形管理員」角色 (roles/serviceusage.serviceUsageAdmin) 取得這項權限。瞭解如何授予角色。
必要的角色
如要透過建構作業從來源部署,您或管理員必須將下列 IAM 角色授予 Cloud Build 服務帳戶。
按一下即可查看 Cloud Build 服務帳戶的必要角色
除非您覆寫此行為,否則 Cloud Build 會自動使用預設的 Compute Engine 服務帳戶做為預設的 Cloud Build 服務帳戶,以建構原始碼和 Cloud Run 資源。如要讓 Cloud Build 建構來源,請要求管理員在專案中,將 Cloud Run 建構工具 (roles/run.builder) 授予 Compute Engine 預設服務帳戶:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \ --role=roles/run.builder
將 PROJECT_NUMBER 替換為 Google Cloud專案編號,並將 PROJECT_ID 替換為 Google Cloud專案 ID。如需如何尋找專案 ID 和專案編號的詳細操作說明,請參閱「建立及管理專案」。
將 Cloud Run 建構工具角色授予 Compute Engine 預設服務帳戶後,需要幾分鐘才能傳播。
如需與 Cloud Run 相關聯的 IAM 角色和權限清單,請參閱「Cloud Run IAM 角色」和「Cloud Run IAM 權限」。如果 Cloud Run 服務與Google Cloud API (例如 Cloud 用戶端程式庫) 介接,請參閱服務身分設定指南。如要進一步瞭解如何授予角色,請參閱「部署權限」和「管理存取權」。
使用建構作業部署
如要從原始碼部署,請按一下分頁,查看如何使用所選工具的操作說明。
gcloud
-
在 Google Cloud 控制台中啟用 Cloud Shell。
控制台底部會開啟 Cloud Shell 工作階段,並顯示指令列提示。 Google Cloud Cloud Shell 是已安裝 Google Cloud CLI 的殼層環境,並已針對您目前的專案設定好相關值。工作階段可能要幾秒鐘的時間才能初始化。
切換至來源目錄。來源目錄會使用 Dockerfile (如有),但並非必要。
建構及部署服務:
gcloud run deploy SERVICE --source .
將
SERVICE替換為您要使用的服務名稱。系統提示安裝必要 API 時,請輸入
y。這項操作每個專案只需執行一次。如果尚未如設定頁面所述,為平台和區域設定預設值,請提供這些資訊,以回應其他提示。等待建構及部署作業完成。完成後,Cloud Run 會顯示成功訊息。
部署後,這個服務修訂版本會處理 100% 的流量。
Compose
您可以將 Compose 規格儲存在 YAML 檔案中,然後使用單一 gcloud 指令,從原始碼將其部署為 Cloud Run 服務。
切換至來源目錄。來源目錄會使用 Dockerfile (如有),但這並非必要條件。
在專案目錄中,建立包含服務定義的
compose.yaml檔案。services: web: build: . ports: - "8080:8080"
您也可以指定更多設定選項,例如環境變數、密鑰和磁碟區掛接。
部署服務
如要部署服務,請執行
gcloud run compose up指令:gcloud run compose up compose.yaml回應
y任何提示,安裝必要元件或啟用 API。選用:公開發布服務 允許未經驗證的存取要求。
部署完成後,系統會顯示 Cloud Run 服務網址。複製這個網址並貼到瀏覽器,即可查看正在執行的容器。您可以從 Google Cloud 控制台停用預設驗證。
從來源部署,不必建構
您可以略過 Cloud Build 步驟,直接將原始碼構件部署至 Cloud Run。運作方式是將應用程式的預先封裝封存檔直接上傳至 Cloud Storage bucket,而不是從來源建構容器映像檔。Cloud Run 接著會取得這個封存檔,並直接在基礎映像檔上執行。這種做法可大幅縮短部署時間。限制
部署至來源 (不含建構作業) 僅支援下列項目:
- Cloud Run 服務。
- 支援的執行階段 (不支援 Dockerfile)。
- 來源封存檔 (.tar.gz) 大小不得超過 250 MiB。
- 二進位檔 (例如 Go 二進位檔) 或指令碼 (例如 Python 指令碼) 必須與 x86 架構相容。
- 來源必須是獨立性質,並封裝所有依附元件。執行階段基礎映像檔只包含最基本的作業系統和少數語言程式庫。
不建構就部署
如要使用「deploy without build」功能,請按照下列步驟操作:
- 請確認您已完成「事前準備」部分的步驟。
啟用 Cloud Run 和 Cloud Storage API:
gcloud services enable run.googleapis.com \ storage.googleapis.com
您必須先在本機安裝應用程式依附元件,才能部署應用程式,因為系統不會安裝這些元件 (不會建構)。
不建構就部署
本節說明如何直接將構件部署至 Cloud Run,而不使用建構程序。
gcloud
如要部署本機來源目錄,請使用 --no-build 旗標,告知 deploy 指令略過 Cloud Build 步驟:
gcloud beta run deploy SERVICE_NAME \ --source APPLICATION_PATH \ --no-build \ --base-image=BASE_IMAGE \ --command=COMMAND \ --args=ARG
更改下列內容:
SERVICE_NAME:Cloud Run 服務名稱。APPLICATION_PATH:應用程式在本機檔案系統中的位置。BASE_IMAGE:要用於應用程式的執行階段基礎映像檔。例如:us-central1-docker.pkg.dev/serverless-runtimes/google-24-full/runtimes/nodejs24。您也可以使用僅含 OS 的基礎映像檔 (例如
osonly24),部署預先編譯的二進位檔,不必設定其他語言專屬的執行階段元件。詳情請參閱建構套件說明文件中的「僅限 OS 的執行階段」。COMMAND:容器啟動時執行的指令。ARG:傳送至容器指令的引數。如果使用多個引數,請在各自的行中指定。
YAML
您可以將服務規格儲存在 YAML 檔案中,然後使用 gcloud CLI 或 Google Cloud 控制台service.yaml編輯器部署。
建立儲存空間 bucket 來存放應用程式:
gcloud storage buckets create gs://BUCKET_NAME --location=BUCKET_LOCATION
更改下列內容:
使用 zip 或 tar 建立應用程式來源的封存檔, 例如:
tar -cvzf ARCHIVE_NAME APPLICATION_PATH
更改下列內容:
ARCHIVE_NAME:要建立的封存檔名稱。例如:app.tar.gz。APPLICATION_PATH:應用程式在本機檔案系統中的位置。例如:~/my-application。如要封存目前的工作目錄,請將這個值設為*。
將應用程式封存檔上傳至 Cloud Storage:
gcloud storage cp ARCHIVE_NAME gs://BUCKET_NAME
更改下列內容:
ARCHIVE_NAME:先前建立的封存檔本機路徑。例如:app.tar.gz。BUCKET_NAME:先前建立的 bucket 名稱。例如:my-bucket。
建立新的
service.yaml檔案,並加入以下內容:apiVersion: serving.knative.dev/v2 kind: Service metadata: name: SERVICE_NAME spec: template: metadata: annotations: run.googleapis.com/sources: '{"": "gs://BUCKET_NAME/ARCHIVE_NAME"}' run.googleapis.com/base-images: '{"": "BASE_IMAGE"}' spec: containers: - image: scratch command: - COMMAND args: - ARG1 - ARG-N runtimeClassName: run.googleapis.com/linux-base-image-update更改下列內容:
SERVICE_NAME:Cloud Run 服務的名稱。服務名稱長度不得超過 49 個半形字元,且每個區域和專案的服務名稱不得重複。BUCKET_NAME:先前建立的 bucket 名稱。例如:my-bucket。ARCHIVE_NAME:先前建立的封存檔本機路徑。例如:app.tar.gz。BASE_IMAGE:要用於應用程式的執行階段基礎映像檔。例如:us-central1-docker.pkg.dev/serverless-runtimes/google-24-full/runtimes/nodejs24。您也可以使用僅含 OS 的基礎映像檔 (例如
osonly24),部署預先編譯的二進位檔,不必設定其他語言專屬的執行階段元件。詳情請參閱建構套件說明文件中的「僅限 OS 的執行階段」。COMMAND:容器啟動時要執行的指令。ARG1:傳送至容器指令的引數。如果使用多個引數,請在各自的行中指定,例如如下所示的ARG-N。
部署新服務:
gcloud run services replace service.yaml
REST API
如要使用 REST API 部署,請按照下列步驟操作:
curl -H "Content-Type: application/json" \
-H "Authorization: Bearer ACCESS_TOKEN" \
-X POST \
-d '{"template": {"containers": [{"command": ["COMMAND"], "args": ["ARG1"], "image": "scratch", "baseImageUri": "BASE_IMAGE", "sourceCode": {"cloudStorageSource": {"bucket": "'GCS_BUCKET_NAME", "object":"ARCHIVE_NAME"}}}]}}' \
https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services?serviceId=SERVICE_NAME
更改下列內容:
- ACCESS_TOKEN:帳戶的有效存取權杖,該帳戶具備部署服務的 IAM 權限。舉例來說,如果您已登入 gcloud,可以使用
gcloud auth print-access-token擷取存取權杖。在 Cloud Run 容器執行個體中,您可以使用容器執行個體中繼資料伺服器擷取存取權杖。 - COMMAND:容器啟動時要執行的指令。
- ARG1:傳送至容器指令的引數。如果使用多個引數,請在各自的行中指定,例如如下所示的
ARG-N。 BASE_IMAGE:要用於應用程式的執行階段基本映像檔。例如:
us-central1-docker.pkg.dev/serverless-runtimes/google-24-full/runtimes/nodejs24。您也可以使用僅含 OS 的基礎映像檔 (例如
osonly24),部署預先編譯的二進位檔,不必設定其他語言專屬的執行階段元件。詳情請參閱建構套件說明文件中的「僅限 OS 的執行階段」。BUCKET_NAME:先前建立的 bucket 名稱。例如:
my-bucket。ARCHIVE_NAME:先前建立的封存檔本機路徑。例如:
app.tar.gz。PROJECT-ID: Google Cloud 專案 ID。
REGION:服務的 Google Cloud 區域。
SERVICE_NAME:Cloud Run 服務的名稱。服務名稱長度不得超過 49 個半形字元,且每個區域和專案的服務名稱不得重複。
Terraform
如要瞭解如何套用或移除 Terraform 設定,請參閱「基本 Terraform 指令」。
在 Terraform 設定的google_cloud_run_v2_service 資源中新增下列項目:resource "google_storage_bucket_object" "source_tar" {
provider = google-beta
name = "ARCHIVE_NAME"
bucket = "BUCKET_NAME"
source = "ARCHIVE_PATH"
}
resource "google_cloud_run_v2_service" "default" {
provider = google-beta
name = "SERVICE_NAME"
location = "REGION"
deletion_protection = false
template {
containers {
image = "scratch"
base_image_uri = "BASE_IMAGE"
command = ["COMMAND"]
args = ["ARG1"]
source_code {
cloud_storage_source {
bucket = "BUCKET_NAME"
object = google_storage_bucket_object.source_tar.name
generation = google_storage_bucket_object.source_tar.generation
}
}
}
}
}
更改下列內容:
ARCHIVE_NAME:檔案在 Cloud Storage bucket 中顯示的名稱。例如:source-code.tar.gz。BUCKET_NAME:要上傳來源封存檔的 bucket 名稱。例如:my-source-bucket。ARCHIVE_PATH:先前建立的封存檔案本機路徑。例如,./app.tar.gz。這個封存檔必須採用 GZIP 格式 (.tar.gz)。SERVICE_NAME:Cloud Run 服務的名稱REGION:bucket 和服務的 Google Cloud 區域。例如 europe-west1。這兩項資源必須位於同一個區域,以免發生擷取逾時問題。BASE_IMAGE:要用於應用程式的執行階段基礎映像檔。例如:us-central1-docker.pkg.dev/serverless-runtimes/google-24-full/runtimes/nodejs24。COMMAND:容器啟動時要執行的指令。ARG1:傳送至容器指令的引數。
MCP
您可以使用 AI 代理程式,透過官方 Cloud Run MCP 伺服器部署服務,無論是否使用儲存空間 bucket 皆可。
為獲得最佳成效,請先告知代理程式偏好使用 MCP 工具而非 gcloud CLI,再開始使用這個 MCP 伺服器。
如要設定 Cloud Run 遠端 MCP 伺服器,請按照「使用 Cloud Run 遠端 MCP 伺服器」指南中的操作說明進行。
使用儲存空間 bucket
如要建立儲存空間值區並部署服務,請使用下列提示指示代理程式:
Create storage bucket "my-bucket" for my source code and deploy service "my-app" to Cloud Run from source in this current directory.代理程式會使用
deploy_service_from_archive工具,直接將原始碼從獨立原始碼封存檔傳遞至 Cloud Run,加快部署速度。您也可以指示代理程式重複使用現有的 Cloud Storage bucket 做為原始碼。
沒有 Storage bucket
如要部署大小在 50 MiB 以下且沒有外部依附元件的程式碼片段,請使用下列提示,指示代理部署時不使用儲存空間 bucket:
Deploy service "my-app" to Cloud Run from source in this current directory.代理程式會使用
deploy_service_from_file_contents工具,將原始碼直接從本機來源檔案傳遞至 Cloud Run。
使用 /deploy 提示
您可以使用 /deploy 提示,透過 Cloud Run MCP 伺服器快速部署服務。你可能需要瀏覽聊天機器人選單,才能找到所需工具或提示。
如要將目前的工作目錄部署至 Cloud Run,請執行下列 /deploy 提示:
/deploySERVICE_NAME\ --projectPROJECT_ID\ --regionREGION\
更改下列內容:
SERVICE_NAME:Cloud Run 服務名稱PROJECT_ID: Google Cloud 專案 IDREGION:區域名稱
從原始碼部署應用程式 (不建構) 的範例
本節將舉例說明如何從來源部署,而不使用建構作業。
Node.js
建立 Node.js 服務:
建立名為
helloworld的新目錄,然後切換至該目錄:mkdir helloworld cd helloworld
使用以下內容建立
package.json檔案:在同一個目錄中建立
index.js檔案,然後將下列幾行內容複製到檔案中:這段程式碼會建立基本的網路伺服器,用於監聽
PORT環境變數定義的通訊埠。在
helloworld目錄中執行下列指令,在本機安裝服務依附元件:npm install
在
helloworld目錄中,使用--no-build旗標部署服務,這個旗標會告知deploy指令略過 Cloud Build 步驟:gcloud beta run deploy helloworld \ --source . \ --region=REGION \ --no-build \ --base-image=nodejs24 \ --command=node \ --args=index.js
更改下列內容:
REGION:服務部署的區域。
Python
建立 Python 服務:
建立名為
helloworld的新目錄,然後切換至該目錄:mkdir helloworld cd helloworld建立名為
main.py的檔案,然後將下列程式碼貼入該檔案:這段程式碼會以「Hello World」問候語回應要求。容器中的 Gunicorn 網路伺服器會處理 HTTP。直接由本機環境叫用之後,此程式碼會建立基本的網路伺服器,以便監聽
PORT環境變數定義的通訊埠。建立名為
requirements.txt的檔案,然後將下列程式碼貼入該檔案:這段程式碼會新增範例所需的套件。
內嵌依附元件:
pip3 install -r requirements.txt --target=./vendor
使用 gcloud CLI 部署服務。
--no-build旗標會告知deploy指令略過 Cloud Build 步驟:gcloud beta run deploy helloworld \ --source . \ --region=REGION \ --no-build \ --base-image=python314 \ --command=python \ --args=main.py \ --set-env-vars PYTHONPATH=./vendor
將 REGION 替換為部署服務的區域。
Go
使用僅限 OS 的執行階段建立及部署 Go 服務:
建立名為
helloworld的新目錄,然後切換至該目錄:mkdir helloworld cd helloworld從專案目錄初始化
go.mod檔案,以宣告 Go 模組:go mod init github.com/GoogleCloudPlatform/golang-samples/run/helloworld建立名為
main.go的新檔案,然後將下列程式碼貼入該檔案:執行下列指令,建構以 Linux OS (例如
linux/amd64) 為目標的二進位檔:GOOS="linux" GOARCH=amd64 go build main.go使用 gcloud CLI 部署服務。
--no-build旗標會告知deploy指令略過 Cloud Build 步驟:gcloud beta run deploy helloworld \ --source . \ --region=REGION \ --no-build \ --base-image=osonly24 \ --command=./main
將 REGION 替換為部署服務的區域。
疑難排解
本節提供一些提示,說明如何從來源部署,而不使用建構作業。
本機開發
從來源部署而不使用建構作業,與將程式碼或可執行檔掛接至基礎映像檔類似。
例如:
複製所有內容:
cp -R python/hello-world/ workspace
以超級使用者身分執行基本映像檔,並掛接來源。如需從主體機器執行 curl,可以視需要加入
-p 8080:8080。docker run -it -v "LOCAL_PATH" -u 0 us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/python314 /bin/bash`
將 LOCAL_PATH 替換為本機來源檔案的位置。
執行伺服器:
python main.py
執行記錄
執行記錄有助於排解部署失敗問題。在 Google Cloud 控制台中,依序前往「可觀測性」>「記錄」。
Cloud Storage 存取遭拒
如果 Cloud Run 服務在嘗試存取 Cloud Storage 物件時發生「權限遭拒」錯誤,請將 roles/storage.objectViewer 角色授予 Cloud Run 服務帳戶:
gcloud projects add-iam-policy-binding PROJECT \ --member="SERVICE_ACCOUNT" \ --role="roles/storage.objectViewer"
更改下列內容:
- PROJECT:您的 Google Cloud 專案 ID。
- SERVICE_ACCOUNT:您的 Cloud Run 服務帳戶。
例如:
service-123@serverless-robot-staging.iam.gserviceaccount.com。
自動從來源建構
為避免本機來源出現未納入版本的變更,Google 建議您在變更推送到 Git 存放區時自動部署。為簡化這項作業,您可以連結 Cloud Run 服務並設定持續部署。將 GitHub 存放區連結至 Cloud Run 後,您就能設定建構作業並部署存放區,不必編寫 Dockerfile 或建構檔案。
如要設定自動建構,請按照持續建構頁面所述設定自動化,並務必選擇使用建構套件建構來源的選項。停用部署健康狀態檢查
根據預設,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 服務後,您可以執行下列操作:
瞭解原始碼部署設定:
您可以使用 Cloud Build 觸發條件,自動執行 Cloud Run 服務的建構與部署作業: