從原始碼部署服務

本頁面說明如何使用單一 gcloud CLI 指令 gcloud run deploy 搭配 --source 旗標，直接從原始碼將新服務或服務修訂版本部署至 Cloud Run。如需部署 Hello World 服務的逐步範例，請參閱「從原始碼部署快速入門導覽課程」。

注意： 如未提供 --image 或 --source 旗標，部署指令預設會部署原始碼。

這項功能有兩種使用方式：

• Deploy from source with build (透過建構作業從來源部署) (預設)：這個選項會使用 Google Cloud 的 Buildpack 和 Cloud Build，自動從原始碼建構容器映像檔，您不必在機器上安裝 Docker，也不必設定 Buildpack 或 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 所需的角色

  您必須具備 serviceusage.services.enable 權限，才能啟用 API。如果您建立了專案，可能已透過「擁有者」角色 (roles/owner) 取得這項權限。否則，您可以透過「Service Usage 管理員」角色 (roles/serviceusage.serviceUsageAdmin) 取得這項權限。瞭解如何授予角色。

  啟用 API

  啟用 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 的 buildpack 部署下列語言：

執行階段	來源部署作業	設定
Go	部署 Go 服務	設定 Go buildpack
Node.js	部署 Node.js 服務	設定 Node.js buildpack
Python	部署 Python 服務	設定 Python buildpack
Java (包括 Kotlin、Groovy、Scala)	部署 Java 服務	設定 Java Buildpack
.NET	部署 .NET 服務	設定 .NET buildpack
小茹	部署 Ruby 服務	設定 Ruby buildpack
PHP	部署 PHP 服務	設定 PHP buildpack
僅限 OS	部署 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 的 buildpack 從來源部署時，會將來源檔案的上次修改日期設為 1980 年 1 月 1 日。這是 buildpack 的預設行為，旨在支援可重現的建構作業。視語言架構而定，這可能會影響靜態檔案的瀏覽器端快取。如果您的應用程式受到影響，Google 建議您在應用程式中停用 etag 和 Last-Modified HTTP 標頭。
• 使用 Google Cloud 的 Buildpack 從來源部署時，一律會使用 gcr.io/buildpacks/builder:latest。如果 latest 不支援您偏好的語言或 OS 設定，請使用特定建構工具，透過偏好的建構工具建立應用程式映像檔。

• 您可以使用 Kotlin 和其他 JVM 語言 (例如 Java)，從原始碼部署服務。您使用的語言必須符合下列規則：

  • 您可以使用 Maven 或 Gradle 建構應用程式。
  • 建構檔案包含產生類別所需的所有外掛程式。

使用建構作業部署前

使用建構作業從來源部署前，請先完成下列事項：

• 按照「事前準備」中的步驟操作。

• 啟用 Cloud Build API (如果尚未啟用)。

  啟用 API 所需的角色

  您必須具備 serviceusage.services.enable 權限，才能啟用 API。如果您建立了專案，可能已透過「擁有者」角色 (roles/owner) 取得這項權限。否則，您可以透過「Service Usage 管理員」角色 (roles/serviceusage.serviceUsageAdmin) 取得這項權限。瞭解如何授予角色。

  啟用 API

必要的角色

如要透過建構作業從來源部署，您或管理員必須將下列 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:[e-mail] \
      --role=roles/run.builder
  

將 PROJECT_NUMBER 替換為 Google Cloud專案編號，並將 PROJECT_ID 替換為 Google Cloud專案 ID。如需尋找專案 ID 和專案編號的詳細操作說明，請參閱「建立及管理專案」。

將 Cloud Run 建構工具角色授予 Compute Engine 預設服務帳戶後，需要幾分鐘的時間才會生效。

注意：

iam.automaticIamGrantsForDefaultServiceAccounts 組織政策限制可防止系統自動將編輯者角色授予預設服務帳戶。如果組織是在 2024 年 5 月 3 日後建立，系統預設會強制執行這項限制。

強烈建議您強制執行這項限制，停用自動角色授予功能。停用此功能後，您必須決定要將哪些角色授予預設服務帳戶，然後自行授予這些角色。

如果預設服務帳戶已具備「編輯者」角色，建議您將「編輯者」角色替換為權限較少的角色。如要安全修改服務帳戶的角色，請使用 Policy Simulator 查看變更會造成的影響，然後授予及撤銷適當的角色。

如要查看與 Cloud Run 相關聯的 IAM 角色和權限清單，請參閱「Cloud Run IAM 角色」和「Cloud Run IAM 權限」。如果 Cloud Run 服務與Google Cloud API (例如 Cloud 用戶端程式庫) 互動，請參閱服務身分設定指南。如要進一步瞭解如何授予角色，請參閱部署權限和管理存取權。

使用建構作業部署

如要從原始碼部署，請按一下分頁標籤，查看所選工具的操作說明。

gcloud

1. 在 Google Cloud 控制台啟用 Cloud Shell。

   啟用 Cloud Shell

   Google Cloud 控制台底部會開啟 Cloud Shell 工作階段，並顯示指令列提示。Cloud Shell 是已安裝 Google Cloud CLI 的殼層環境，並已設定適用於您目前專案的值。工作階段可能要幾秒鐘的時間才能初始化。

2. 切換至來源目錄。來源目錄會使用 Dockerfile (如有)，但這並非必要。

3. 建構及部署服務：

   gcloud run deploy SERVICE --source .

   將 SERVICE 替換為您要為服務指定的名稱。

4. 如果系統提示您安裝必要 API，請回覆 y。每個專案只需執行一次這項操作。如果您尚未按照設定頁面所述設定預設值，請提供平台和區域，回應其他提示。

5. 等候建構及部署作業完成。完成後，Cloud Run 會顯示成功訊息。

部署後，這個服務修訂版本會處理 100% 的流量。

Compose

您可以將 Compose 規格儲存在 YAML 檔案中，然後使用單一 gcloud 指令，從原始碼部署為 Cloud Run 服務。

1. 切換至來源目錄。來源目錄會使用 Dockerfile (如有)，但這並非必要。

2. 在專案目錄中，建立包含服務定義的 compose.yaml 檔案。

   services:
     web:
       build: .
       ports:
         - "8080:8080"

   您也可以指定更多設定選項，例如環境變數、Secret 和磁碟區掛接。

部署服務

1. 如要部署服務，請執行 gcloud run compose up 指令：

   gcloud run compose up compose.yaml

2. 請按照提示y安裝必要元件或啟用 API。

3. 選用：如要允許未經驗證的使用者存取服務，請公開服務。

部署完成後，系統會顯示 Cloud Run 服務網址。複製這個網址並貼到瀏覽器，即可查看執行中的容器。您可以透過 Google Cloud 控制台停用預設驗證。

部署預先建構的來源

預覽 ：不建構直接部署

這項功能適用《服務專屬條款》中「一般服務條款」一節的《正式發布前產品條款》。正式發布前功能是依「原樣」提供，支援服務可能受限。 詳情請參閱推出階段說明。

您可以直接將預先建構的原始碼構件部署至 Cloud Run，略過 Cloud Build 步驟。這種做法不需從來源建構容器映像檔，而是直接將預先封裝的應用程式封存檔上傳至 Cloud Storage bucket。Cloud Run 接著會取得這個封存檔，並直接在基礎映像檔上執行。這種做法可讓您在本機快速開發及疊代，大幅縮短部署時間。

限制

部署預先建構的來源時，僅支援下列項目：

• Cloud Run 服務。
• 支援的執行階段 (不支援 Dockerfile)。
• 來源封存檔 (.tar.gz) <= 250 MiB。
• 二進位檔 (例如 Go 二進位檔) 或指令碼 (例如 Python 指令碼) 必須與 x86 架構相容。
• 來源必須是獨立的，且所有依附元件都已封裝。執行階段基礎映像檔僅包含最低限度的作業系統和一些語言程式庫。

部署預先建構的來源前

如要使用「不建構即部署」功能，請按照下列步驟操作：

• 請確認您已完成「事前準備」一節中的步驟。

• 啟用 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/runtimes/nodejs24。您也可以使用簡短別名 nodejs24。

  您也可以部署預先編譯的二進位檔，而不必使用僅限 OS 的基礎映像檔 (例如 osonly24) 設定其他特定語言的執行階段元件。詳情請參閱 Buildpack 說明文件中的「僅限 OS 執行階段」一節。

• COMMAND：容器啟動時執行的指令。選用。 如未指定指令，基本映像檔會在執行階段推論容器啟動指令。

• ARG：傳送至容器指令的引數。如要使用多個引數，請在各行分別指定。選用。如未指定引數，基本映像檔會在執行階段推論任何引數。

YAML

您可以將服務規格儲存在 YAML 檔案中，然後使用 gcloud CLI 或 Google Cloud 控制台service.yaml編輯器部署。

1. 建立儲存空間 bucket 來存放應用程式：

   gcloud storage buckets create gs://BUCKET_NAME --location=BUCKET_LOCATION
   

   更改下列內容：

   • BUCKET_NAME：您要為 bucket 指定的名稱，須符合命名規定。例如：my-bucket。
   • BUCKET_LOCATION：bucket 的位置。例如：US。

2. 使用 zip 或 tar 建立應用程式來源的封存檔，例如：

   tar -cvzf ARCHIVE_NAME APPLICATION_PATH
   

   更改下列內容：

   • ARCHIVE_NAME：要建立的封存檔名稱。例如：app.tar.gz。
   • APPLICATION_PATH：應用程式在本機檔案系統中的位置。例如：~/my-application。如要封存目前使用的目錄，請將這個值設為 *。

3. 將應用程式封存檔上傳至 Cloud Storage：

   gcloud storage cp ARCHIVE_NAME gs://BUCKET_NAME
   

   更改下列內容：

   • ARCHIVE_NAME：先前建立的封存檔本機路徑。例如：app.tar.gz。
   • BUCKET_NAME：先前建立的值區名稱。例如：my-bucket。

4. 建立新的 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：先前建立的值區名稱。例如：my-bucket。
   • ARCHIVE_NAME：先前建立的封存檔本機路徑。例如：app.tar.gz。

   • BASE_IMAGE：要用於應用程式的執行階段基本映像檔。例如：us-central1-docker.pkg.dev/serverless-runtimes/google-24/runtimes/nodejs24。

     您也可以部署預先編譯的二進位檔，而不必使用僅限 OS 的基礎映像檔 (例如 osonly24) 設定其他特定語言的執行階段元件。詳情請參閱 Buildpack 說明文件中的「僅限 OS 執行階段」一節。

   • COMMAND：容器啟動時要執行的指令。選用。如未指定指令，基本映像檔會在執行階段推論容器啟動指令。

   • ARG1：傳送至容器指令的引數。如要使用多個引數，請在各行分別指定，例如 ARG-N。選用。如未指定引數，基本映像檔會在執行階段推論任何引數。

5. 部署新服務：

   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/runtimes/nodejs24。

  您也可以部署預先編譯的二進位檔，而不必使用僅限 OS 的基礎映像檔 (例如 osonly24) 設定其他特定語言的執行階段元件。詳情請參閱 Buildpack 說明文件中的「僅限 OS 執行階段」一節。

• BUCKET_NAME：先前建立的值區名稱。例如：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/runtimes/nodejs24。
• COMMAND：容器啟動時要執行的指令。選用。如未指定指令，基礎映像檔會在執行階段推論容器啟動指令。
• ARG1：傳送至容器指令的引數。選用。如未指定引數，基礎映像檔會在執行階段推論任何引數。

MCP

您可以使用 AI 代理，透過官方 Cloud Run MCP 伺服器部署服務，無論是否使用 Storage bucket 皆可。

為取得最佳結果，請先指示代理優先使用 MCP 工具，而非 gcloud CLI，再開始使用這個 MCP 伺服器。

1. 如要設定 Cloud Run 遠端 MCP 伺服器，請按照「使用 Cloud Run 遠端 MCP 伺服器」指南中的操作說明操作。

   • 使用儲存空間 bucket

     如要建立儲存空間 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，且沒有外部依附元件，請使用下列提示，指示代理在不使用 Storage 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 提示：

/deploy SERVICE_NAME \
    --project PROJECT_ID \
    --region REGION \

更改下列內容：

• SERVICE_NAME：Cloud Run 服務的名稱
• PROJECT_ID： Google Cloud 專案 ID
• REGION：區域名稱

部署預先建構來源的範例

本節舉例說明如何從來源部署，而不使用建構作業。

Node.js

建立 Node.js 服務：

1. 建立名為 helloworld 的新目錄，然後切換至該目錄：

   mkdir helloworld
   cd helloworld
   

2. 使用以下內容建立 package.json 檔案：

   {
     "name": "helloworld",
     "description": "Simple hello world sample in Node",
     "version": "1.0.0",
     "private": true,
     "main": "index.js",
     "type": "module",
     "scripts": {
       "start": "node index.js"
     },
     "engines": {
       "node": ">=16.0.0"
     },
     "author": "Google LLC",
     "license": "Apache-2.0",
     "dependencies": {
       "express": "^5.2.1"
     }
   }
   

3. 在同一個目錄中建立 index.js 檔案，然後將下列幾行內容複製到檔案中：

   import express from 'express';
   const app = express();
   
   app.get('/', (req, res) => {
     const name = process.env.NAME || 'World';
     res.send(`Hello ${name}!`);
   });
   
   const port = parseInt(process.env.PORT) || 8080;
   app.listen(port, () => {
     console.log(`helloworld: listening on port ${port}`);
   });

   這段程式碼會建立基本的網路伺服器，用於監聽 PORT 環境變數定義的通訊埠。

4. 在 helloworld 目錄中執行下列指令，在本機安裝服務依附元件：

   npm install

5. 在 helloworld 目錄中，使用 --no-build 旗標部署服務，指示 deploy 指令略過 Cloud Build 步驟：

   gcloud beta run deploy helloworld \
    --source . \
    --region=REGION \
    --no-build \
    --base-image=nodejs24 \
    

   更改下列內容：

   • REGION：部署服務的區域。

Python

建立 Python 服務：

1. 建立名為 helloworld 的新目錄，然後切換至該目錄：

   mkdir helloworld
   cd helloworld
   

2. 建立名為 main.py 的檔案，將下列程式碼貼入其中：

   import os
   
   from flask import Flask
   
   app = Flask(__name__)
   
   
   @app.route("/")
   def hello_world():
       """Example Hello World route."""
       name = os.environ.get("NAME", "World")
       return f"Hello {name}!"
   
   
   if __name__ == "__main__":
       app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))

   這段程式碼會以「Hello World」問候語回應要求。HTTP 處理作業是由容器中的 Gunicorn 網路伺服器完成。直接由本機環境叫用之後，此程式碼會建立基本的網路伺服器，以便監聽 PORT 環境變數定義的通訊埠。

3. 建立名為 requirements.txt 的檔案，將下列程式碼貼入其中：

   Flask==3.1.3; python_version >= '3.9'
   gunicorn==23.0.0
   Werkzeug==3.1.9; python_version >= '3.10'
   

   這段程式碼會新增範例所需的套件。

4. 內嵌依附元件：

   pip3 install -r requirements.txt --target=./vendor
   

5. 使用 gcloud CLI 部署服務。--no-build 旗標會指示 deploy 指令略過 Cloud Build 步驟：

   gcloud beta run deploy helloworld \
     --source . \
     --region=REGION \
     --no-build \
     --base-image=python314 \
   

將 REGION 替換為服務部署區域。

Go

使用僅限 OS 的執行階段，建立及部署 Go 服務：

1. 建立名為 helloworld 的新目錄，然後切換至該目錄：

   mkdir helloworld
   cd helloworld
   

2. 從專案目錄初始化 go.mod 檔案，宣告 Go 模組：

   go mod init github.com/GoogleCloudPlatform/golang-samples/run/helloworld
   

3. 建立名為 main.go 的新檔案，將下列程式碼貼入其中：

   
   // Sample run-helloworld is a minimal Cloud Run service.
   package main
   
   import (
   	"fmt"
   	"log"
   	"net/http"
   	"os"
   )
   
   func main() {
   	log.Print("starting server...")
   	http.HandleFunc("/", handler)
   
   	// Determine port for HTTP service.
   	port := os.Getenv("PORT")
   	if port == "" {
   		port = "8080"
   		log.Printf("defaulting to port %s", port)
   	}
   
   	// Start HTTP server.
   	log.Printf("listening on port %s", port)
   	if err := http.ListenAndServe(":"+port, nil); err != nil {
   		log.Fatal(err)
   	}
   }
   
   func handler(w http.ResponseWriter, r *http.Request) {
   	name := os.Getenv("NAME")
   	if name == "" {
   		name = "World"
   	}
   	fmt.Fprintf(w, "Hello %s!\n", name)
   }
   

4. 執行下列指令，建構以 Linux OS (例如 linux/amd64) 為目標的二進位檔：

   GOOS="linux" GOARCH=amd64 go build main.go
   

5. 使用 gcloud CLI 部署服務。--no-build 旗標會指示 deploy 指令略過 Cloud Build 步驟：

   gcloud beta run deploy helloworld \
     --source . \
     --region=REGION \
     --no-build \
     --base-image=osonly24 \
     --command=./main
   

將 REGION 替換為服務部署區域。

疑難排解

本節提供一些提示，說明如何排解不使用建構作業，直接從來源部署的問題。

本機開發

從來源部署而不使用建構作業，其運作方式類似於將程式碼或執行檔掛接至基礎映像檔。

例如：

1. 複製所有內容：

   cp -R python/hello-world/ workspace

2. 以超級使用者身分執行基礎映像檔，並掛接來源。如需從主機機器執行 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 替換為本機來源檔案的位置。

3. 執行伺服器：

   python main.py

執行記錄

執行記錄檔有助於排解部署失敗問題。在Google Cloud 控制台中，依序前往「Observability」(觀測能力) >「Logs」(記錄)。

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 服務帳戶。例如：[e-mail]。

自動從原始碼建構

為避免本機來源中出現未建立版本的變更，Google 建議您在變更推送至 Git 存放區時自動部署。為簡化這項作業，您可以連結並設定 Cloud Run 服務的持續部署。將 GitHub 存放區連結至 Cloud Run 後，您就能設定建構作業及部署存放區，不必編寫 Dockerfile 或建構檔案。

如要設定自動建構作業，請按照持續建構頁面中的說明設定自動化功能，並務必選擇使用 buildpack 建構來源的選項。

停用部署作業健康狀態檢查

根據預設，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 服務後，您可以執行下列操作：

• 漸進式推出、復原修訂版本、流量遷移
• 查看服務記錄
• 監控服務效能
• 設定記憶體上限
• 設定環境變數
• 變更服務並行設定
• 管理服務
• 管理服務修訂版本

瞭解原始碼部署設定：

• 自動更新基本映像檔
• 建構環境變數
• 建構服務帳戶
• 建構 worker 集區

您可以使用 Cloud Build 自動建構觸發條件，自動建構及部署 Cloud Run 服務：

• 設定持續部署