Cloud Run へのコンテナ イメージのデプロイ

このページでは、コンテナ イメージを新しい Cloud Run サービスにデプロイする方法、または既存の Cloud Run サービスの新しいリビジョンにデプロイする方法について説明します。

新しいサービスをデプロイするチュートリアルの例については、クイックスタート: サンプル コンテナをデプロイするをご覧ください。

始める前に

ドメイン制限の組織のポリシーでプロジェクトの未認証呼び出しが制限されている場合は、プライベート サービスのテストの説明に従って、デプロイされたサービスにアクセスする必要があります。

必要なロール

Cloud Run サービスのデプロイに必要な権限を取得するには、次の IAM ロールを付与するよう管理者に依頼してください。

• Cloud Run サービスに対する Cloud Run デベロッパー（roles/run.developer）
• サービス ID に対するサービス アカウント ユーザー（roles/iam.serviceAccountUser）

Cloud Run に関連付けられている IAM ロールと権限のリストについては、Cloud Run IAM ロールと Cloud Run IAM 権限をご覧ください。Cloud Run サービスが Google Cloud APIs（Cloud クライアント ライブラリなど）と連携している場合は、サービス ID の構成ガイドをご覧ください。ロールの付与の詳細については、デプロイ権限とアクセスの管理をご覧ください。

サポートされているコンテナ レジストリとイメージ

Artifact Registry または Docker Hub に保存されているコンテナ イメージを直接使用できます。Google では Artifact Registry の使用をおすすめします。

Artifact Registry リモート リポジトリを設定することで、他の公開または限定公開のレジストリ（JFrog Artifactory、Nexus、GitHub Container Registry など）のコンテナ イメージを使用できます。

Docker の公式イメージや Docker が提供する OSS イメージなど、一般的なコンテナ イメージをデプロイする場合にのみ、Docker Hub の使用を検討してください。可用性を高めるには、これらの Docker Hub イメージを Artifact Registry リモート リポジトリ経由でデプロイすることをおすすめします。

新しいサービスをデプロイする

タグ（たとえば、us-docker.pkg.dev/my-project/container/my-image:latest）または正確なダイジェスト（たとえば、us-docker.pkg.dev/my-project/container/my-image@sha256:41f34ab970ee...）でコンテナ イメージを指定できます。

サービスに初めてデプロイすると、最初のリビジョンが作成されます。リビジョンは変更されません。コンテナ イメージタグからデプロイすると、ダイジェストに解決され、リビジョンは常にこの特定のダイジェストを処理します。

使用するツールのタブをクリックして、手順を確認してください。

Console

コンテナ イメージをデプロイするには:

1. Cloud Run に移動します。

2. [サービスを作成] をクリックして、[サービスの作成] フォームを表示します。

   1. フォームで、デプロイ オプションを選択します。

      1. コンテナを手動でデプロイする場合は、[既存のコンテナ イメージから 1 つのリビジョンをデプロイする] を選択し、コンテナ イメージを指定します。

      2. 継続的デプロイを自動化する場合は、[ソース リポジトリから新しいリビジョンを継続的にデプロイする] を選択し、継続的デプロイの手順の説明に従ってください。

   2. 必要なサービス名を入力します。サービス名は 49 文字以下で、リージョンとプロジェクトごとに一意である必要があります。サービス名は後から変更することはできません。この名前は一般公開されます。

   3. サービスのリージョンを選択します。リージョン セレクタには、料金階層とドメイン マッピングの可用性が示され、カーボン フットプリントの影響が最も低いリージョンがハイライト表示されます。

   4. 必要に応じて CPU 割り当てと料金を設定します。

   5. [自動スケーリング] で、最小インスタンスと最大インスタンスを指定します。

   6. フォームの Ingress 設定を必要に応じて設定します。

   7. [認証] で、次の構成を行います。

      • 公開 API またはウェブサイトを作成する場合は、[認証されていない呼び出しを許可する] を選択します。これをオンにすると、IAM 起動元ロールに特別な allUser が割り当てられます。サービスの作成後に、IAM を使用してこの設定を編集できます。
      • 認証で保護された安全なサービスが必要な場合は、[認証が必要] を選択します。

3. [コンテナ、ボリューム、ネットワーキング、セキュリティ] をクリックして、該当するタブでその他のオプション設定を指定します。

   • 同時実行
   • コンテナ構成
   • CPU 制限
   • メモリ制限
   • リクエスト タイムアウト
   • シークレット
   • 環境変数
   • 実行環境
   • HTTP/2
   • ラベル
   • サービス アカウント
   • Cloud SQL 接続
   • VPC 接続

4. サービスの構成が完了したら、[作成] をクリックしてイメージを Cloud Run にデプロイし、デプロイの完了を待ちます。

5. 表示された URL リンクをクリックして、デプロイしたサービスで一意の安定したエンドポイントを開きます。

gcloud

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. コンテナ イメージをデプロイするには:

   1. 次のコマンドを実行します。

      gcloud run deploy SERVICE --image IMAGE_URL

      • SERVICE は、デプロイ先のサービスの名前に置き換えます。サービス名は 49 文字以下で、リージョンとプロジェクトごとに一意である必要があります。サービスがまだ存在しない場合、デプロイ中にこのコマンドによってサービスが作成されます。このパラメータは省略できますが、省略するとサービス名の入力を求められます。
      • IMAGE_URL は、コンテナ イメージへの参照（us-docker.pkg.dev/cloudrun/container/hello:latest など）に置き換えます。Artifact Registry を使用する場合は、リポジトリ REPO_NAME がすでに作成されている必要があります。URL の形式は LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG です。--image フラグを指定しないと、deploy コマンドはソースコードからのデプロイを試行します。

      公開 API またはウェブサイトを作成する場合は、--allow-unauthenticated フラグを使用してサービスに対する未認証の呼び出しを許可します。これにより、Cloud Run 呼び出し元の IAM ロールを allUsers に割り当てます。--no-allow-unauthenticated を指定して、未認証の呼び出しを禁止することもできます。いずれかのフラグを省略すると、deploy コマンドを実行時に確認のプロンプトが表示されます。

   2. デプロイが完了するまで待ちます。正常に完了すると、デプロイされたサービスの URL が成功のメッセージと一緒に表示されます。

   run/region gcloud プロパティで設定した場所とは異なる場所にデプロイする場合は、次のようにします。

   gcloud run deploy SERVICE --region REGION

YAML

サービス仕様を YAML ファイルに保管してから、gcloud CLI を使用してデプロイできます。

1. 次の内容の新しいファイルを service.yaml という名前で作成します。

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: SERVICE
   spec:
     template:
       spec:
         containers:
         - image: IMAGE

   次のように置き換えます。

   • SERVICE は、Cloud Run サービスの名前に置き換えます。サービス名は 49 文字以下で、リージョンとプロジェクトごとに一意である必要があります。
   • IMAGE は、コンテナ イメージの URL に置き換えます。

   環境変数やメモリ上限など他の構成を指定することもできます。

2. 次のコマンドを使用して新しいサービスをデプロイします。

   gcloud run services replace service.yaml

3. （省略可能）サービスへの未認証アクセスを許可したい場合は、サービスを一般公開にします。

Cloud Code

Cloud Code を使用してデプロイする方法については、IntelliJ と Visual Studio Code のガイドをご覧ください。

Terraform

Terraform を使用する場合、Google Cloud Platform Provider の google_cloud_run_v2_service リソースを使用して Terraform 構成でサービスを定義します。

1. この内容で main.tf ファイルを新規作成します。

   provider "google" {
     project = "PROJECT-ID"
   }
   
   resource "google_cloud_run_v2_service" "default" {
     name     = "SERVICE"
     location = "REGION"
     client   = "terraform"
   
     template {
       containers {
         image = "IMAGE"
       }
     }
   }
   
   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 は、Google Cloud プロジェクト ID に置き換えます。
   • REGION は、Google Cloud リージョンに置き換えます。
   • SERVICE は、Cloud Run サービスの名前に置き換えます。サービス名は 49 文字以下で、リージョンとプロジェクトごとに一意である必要があります。
   • IMAGE_URL: コンテナ イメージへの参照（us-docker.pkg.dev/cloudrun/container/hello:latest など）。Artifact Registry を使用する場合は、リポジトリ REPO_NAME がすでに作成されている必要があります。URL の形式は LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG です。

   この構成では公開アクセスが可能になります（--allow-unauthenticated と同等）。サービスを非公開にするには、google_cloud_run_v2_service_iam_member スタンザを削除します。

2. Terraform を初期化します。

   terraform init

3. Terraform 構成を適用します。

   terraform apply

   「yes」と入力して、記述されている操作を適用することを確認します。

クライアント ライブラリ

コードから新しいサービスをデプロイするには:

• Go
• Java
• Node.js
• Python
• Ruby
• PHP
• .NET

REST API

新しいサービスをデプロイするには、Cloud Run Admin API の service エンドポイントに POST HTTP リクエストを送信します。

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 がすでに作成されている必要があります。URL の形式は LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG です。
• SERVICE は、デプロイ先のサービスの名前に置き換えます。サービス名は 49 文字以下で、リージョンとプロジェクトごとに一意である必要があります。
• REGION は、サービスの Google Cloud リージョンに置き換えます。
• PROJECT-ID は、Google Cloud プロジェクト ID に置き換えます。

Cloud Run のロケーション

Cloud Run はリージョナルです。つまり、Cloud Run サービスを実行するインフラストラクチャは特定のリージョンに配置され、そのリージョン内のすべてのゾーンで冗長的に利用できるように Google によって管理されます。

レイテンシ、可用性、耐久性の要件を満たしていることが、Cloud Run サービスを実行するリージョンを選択する際の主な判断材料になります。一般的には、ユーザーに最も近いリージョンを選択できますが、Cloud Run サービスで使用されている他の Google Cloud サービスのロケーションも考慮する必要があります。使用する Google Cloud サービスが複数のロケーションにまたがっていると、サービスの料金だけでなくレイテンシにも影響することがあります。

Cloud Run は、次のリージョンで利用できます。

ティア 1 料金を適用

• asia-east1（台湾）
• asia-northeast1（東京）
• asia-northeast2（大阪）
• europe-north1（フィンランド） 低 CO₂
• europe-southwest1（マドリッド） 低 CO₂
• europe-west1（ベルギー） 低 CO₂
• europe-west4（オランダ） 低 CO₂
• europe-west8（ミラノ）
• europe-west9（パリ） 低 CO₂
• me-west1（テルアビブ）
• us-central1（アイオワ） 低 CO₂
• us-east1（サウスカロライナ）
• us-east4（北バージニア）
• us-east5（コロンバス）
• us-south1（ダラス） 低 CO₂
• us-west1（オレゴン） 低 CO₂

ティア 2 料金を適用

• africa-south1（ヨハネスブルグ）
• asia-east2（香港）
• asia-northeast3（ソウル、韓国）
• asia-southeast1（シンガポール）
• asia-southeast2 （ジャカルタ）
• asia-south1（ムンバイ、インド）
• asia-south2（デリー、インド）
• australia-southeast1（シドニー）
• australia-southeast2（メルボルン）
• europe-central2（ワルシャワ、ポーランド）
• europe-west10（ベルリン） 低 CO₂
• europe-west12（トリノ）
• europe-west2（ロンドン、イギリス） 低 CO₂
• europe-west3（フランクフルト、ドイツ） 低 CO₂
• europe-west6（チューリッヒ、スイス） 低 CO₂
• me-central1（ドーハ）
• me-central2（ダンマーム）
• northamerica-northeast1（モントリオール） 低 CO₂
• northamerica-northeast2（トロント） 低 CO₂
• southamerica-east1（サンパウロ、ブラジル） 低 CO₂
• southamerica-west1（サンティアゴ、チリ） 低 CO₂
• us-west2（ロサンゼルス）
• us-west3（ソルトレイクシティ）
• us-west4（ラスベガス）

Cloud Run サービスをすでに作成している場合は、Google Cloud コンソールの Cloud Run ダッシュボードにリージョンが表示されます。

OK

デプロイ時に、Cloud Run サービス エージェントがデプロイされたコンテナにアクセスできる必要があります（デフォルトの場合）。

各サービスには一意で永続的な URL があります。この URL は、新しいリビジョンをサービスにデプロイしても変わりません。

既存のサービスの新しいリビジョンをデプロイする

新しいリビジョンをデプロイするには、Google Cloud コンソール、gcloud コマンドライン、または YAML 構成ファイルを使用します。

構成設定を変更すると、コンテナ イメージに変更がない場合でも、新しいリビジョンが作成されます。作成されたリビジョンは変更できません。

タブをクリックして、使用するツールでの手順を確認してください。

Console

既存のサービスの新しいリビジョンをデプロイするには:

1. Cloud Run に移動します。

2. サービスリストで更新したいサービスをクリックして、サービスの詳細を表示します。

3. [新しいリビジョンの編集とデプロイ] をクリックして、リビジョンのデプロイ フォームを表示します。

   1. 必要に応じて、デプロイする新しいコンテナ イメージの URL を入力します。

   2. 必要に応じてコンテナを構成します。

   3. 必要に応じて CPU 割り当てと料金を設定します。

   4. [容量] で、メモリ上限と CPU 上限を指定します。

   5. 必要に応じて、リクエスト タイムアウトと同時実行を指定します。

   6. 必要に応じて実行環境を指定します。

   7. [自動スケーリング] で、最小インスタンスと最大インスタンスを指定します。

   8. 他のタブを使用して、必要に応じて構成します。

      • シークレット
      • 環境変数
      • HTTP/2
      • ラベル
      • サービス アカウント
      • Cloud SQL 接続
      • VPC 接続

4. すべてのトラフィックを新しいリビジョンに送信するには、[このリビジョンをすぐに利用する] を選択します。新しいリビジョンを段階的にロールアウトする場合は、そのチェックボックスをオフにします。これにより、新しいリビジョンにトラフィックが送信されないデプロイになります。デプロイ後、段階的なロールアウトの説明に従って操作します。

5. [デプロイ] をクリックして、デプロイが完了するまで待ちます。

gcloud

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. コンテナ イメージをデプロイするには:

   1. 次のコマンドを実行します。

      gcloud run deploy SERVICE --image IMAGE_URL

      • SERVICE は、デプロイ先のサービスの名前に置き換えます。このパラメータは省略できますが、省略するとサービス名の入力を求められます。
      • IMAGE_URL は、コンテナ イメージへの参照（us-docker.pkg.dev/cloudrun/container/hello:latest など）に置き換えます。Artifact Registry を使用する場合は、リポジトリ REPO_NAME がすでに作成されている必要があります。URL の形式は LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG です。

      リビジョン サフィックスは、新しいリビジョンに自動的に割り当てられます。独自のリビジョン サフィックスを指定する場合は、gcloud CLI パラメータ --revision-suffix を使用します。

   2. デプロイが完了するまで待ちます。正常に完了すると、デプロイされたサービスの URL が成功のメッセージと一緒に表示されます。

YAML

注意: 次の手順では、既存のサービス構成を YAML ファイルで指定された構成に置き換えます。そのため、YAML を使用してリビジョン変更を行う場合、Google Cloud コンソールや gcloud CLI を使用した構成変更もしないでください。YAML を使用するとこれらが上書きされる可能性があるためです。

既存のサービスの構成をダウンロードや表示する場合は、次のコマンドを使用して結果を YAML ファイルに保存します。

gcloud run services describe SERVICE --format export > service.yaml

サービス構成 YAML ファイルで、任意の spec.template 子属性を変更してリビジョン設定を更新してから、新しいリビジョンをデプロイします。

gcloud run services replace service.yaml

Cloud Code

Cloud Code を使用して既存のサービスの新しいリビジョンをデプロイする方法については、IntelliJ と Visual Studio Code のガイドをご覧ください。

Terraform

新しいサービスのデプロイの例で説明されているように Terraform を設定していることを確認します。

1. 構成ファイルに変更を行います。

2. Terraform 構成を適用します。

   terraform apply

   yes と入力して、記述されている操作を適用することを確認します。

   注: 構成の変更が必要でない限り、新しいリビジョンは作成されません。

クライアント ライブラリ

コードから新しいリビジョンをデプロイするには:

• Go
• Java
• Node.js
• Python
• Ruby
• PHP
• .NET

REST API

新しいリビジョンをデプロイするには、Cloud Run Admin API の service エンドポイントに PATCH HTTP リクエストを送信します。

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 がすでに作成されている必要があります。URL の形式は LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG です。
• SERVICE は、デプロイ先のサービスの名前に置き換えます。
• REGION は、サービスの Google Cloud リージョンに置き換えます。
• PROJECT-ID は、Google Cloud プロジェクト ID に置き換えます。

Cloud Run のロケーション

Cloud Run はリージョナルです。つまり、Cloud Run サービスを実行するインフラストラクチャは特定のリージョンに配置され、そのリージョン内のすべてのゾーンで冗長的に利用できるように Google によって管理されます。

レイテンシ、可用性、耐久性の要件を満たしていることが、Cloud Run サービスを実行するリージョンを選択する際の主な判断材料になります。一般的には、ユーザーに最も近いリージョンを選択できますが、Cloud Run サービスで使用されている他の Google Cloud サービスのロケーションも考慮する必要があります。使用する Google Cloud サービスが複数のロケーションにまたがっていると、サービスの料金だけでなくレイテンシにも影響することがあります。

Cloud Run は、次のリージョンで利用できます。

ティア 1 料金を適用

• asia-east1（台湾）
• asia-northeast1（東京）
• asia-northeast2（大阪）
• europe-north1（フィンランド） 低 CO₂
• europe-southwest1（マドリッド） 低 CO₂
• europe-west1（ベルギー） 低 CO₂
• europe-west4（オランダ） 低 CO₂
• europe-west8（ミラノ）
• europe-west9（パリ） 低 CO₂
• me-west1（テルアビブ）
• us-central1（アイオワ） 低 CO₂
• us-east1（サウスカロライナ）
• us-east4（北バージニア）
• us-east5（コロンバス）
• us-south1（ダラス） 低 CO₂
• us-west1（オレゴン） 低 CO₂

ティア 2 料金を適用

• africa-south1（ヨハネスブルグ）
• asia-east2（香港）
• asia-northeast3（ソウル、韓国）
• asia-southeast1（シンガポール）
• asia-southeast2 （ジャカルタ）
• asia-south1（ムンバイ、インド）
• asia-south2（デリー、インド）
• australia-southeast1（シドニー）
• australia-southeast2（メルボルン）
• europe-central2（ワルシャワ、ポーランド）
• europe-west10（ベルリン） 低 CO₂
• europe-west12（トリノ）
• europe-west2（ロンドン、イギリス） 低 CO₂
• europe-west3（フランクフルト、ドイツ） 低 CO₂
• europe-west6（チューリッヒ、スイス） 低 CO₂
• me-central1（ドーハ）
• me-central2（ダンマーム）
• northamerica-northeast1（モントリオール） 低 CO₂
• northamerica-northeast2（トロント） 低 CO₂
• southamerica-east1（サンパウロ、ブラジル） 低 CO₂
• southamerica-west1（サンティアゴ、チリ） 低 CO₂
• us-west2（ロサンゼルス）
• us-west3（ソルトレイクシティ）
• us-west4（ラスベガス）

Cloud Run サービスをすでに作成している場合は、Google Cloud コンソールの Cloud Run ダッシュボードにリージョンが表示されます。

OK

他の Google Cloud プロジェクトからイメージをデプロイする

正しい IAM 権限を設定されている場合は、他の Google Cloud プロジェクトのコンテナ イメージをデプロイできます。

1. Google Cloud コンソールで、Cloud Run サービスのプロジェクトを開きます。

   [IAM] ページに移動

2. [Google 提供のロール付与を含む] を選択します。

3. Cloud Run サービス エージェントのメールアドレスをコピーします。このアドレスには、@serverless-robot-prod.iam.gserviceaccount.com という接尾辞が付いています。

4. 使用する Container Registry を所有するプロジェクトを開きます。

   [IAM] ページに移動

5. [追加] をクリックして、新しいプリンシパルを追加します。

6. [新しいプリンシパル] フィールドに、先ほどコピーしたサービス アカウントのメールアドレスを貼り付けます。

7. Container Registry を使用している場合は、[ロールを選択] プルダウン メニューで、[ストレージ] -> [Storage オブジェクト閲覧者] を選択します。Artifact Registry を使用している場合は、[Artifact Registry] -> [Artifact Registry 読み取り] のロールを選択します。

8. Cloud Run サービスを含むプロジェクトにコンテナ イメージをデプロイします。

   注: セキュリティを強化するには、コンテナ イメージを含む Cloud Storage バケットまたは Artifact Registry リポジトリにのみアクセス権を付与します。

他のレジストリからイメージをデプロイする

Artifact Registry または Docker Hub に保存されていない公開コンテナ イメージまたは限定公開コンテナ イメージをデプロイするには、Artifact Registry のリモート リポジトリを設定します。

Artifact Registry リモート リポジトリを使用すると、次のことが可能になります。

• 公開コンテナ イメージをデプロイします（例: GitHub Container Registry（ghcr.io））。
• 認証を必要とする限定公開リポジトリ（JFrog Artifactory や Nexus など）からコンテナ イメージをデプロイします。

サービスに複数のコンテナをデプロイする（サイドカー）

サイドカーを使用した Cloud Run のデプロイでは、指定したコンテナポートですべての受信 HTTPS リクエストを処理する Ingress コンテナが 1 つ存在します。さらに、1 つ以上のサイドカー コンテナが存在します。サイドカーは、Ingress コンテナポートで受信 HTTP リクエストをリッスンできませんが、サイドカー相互の通信は可能です。また、localhost ポートを使用して Ingress コンテナと通信を行います。使用される localhost ポートは、使用しているコンテナによって異なります。

次の図では、Ingress コンテナは、localhost:5000 を使用してサイドカーと通信しています。

Ingress コンテナを含め、インスタンスごとに最大 10 個のコンテナをデプロイできます。図に示すように、インスタンス内のすべてのコンテナは同じネットワーク名前空間を共有しています。また、メモリ内共有ボリュームを介してファイルを共有することもできます。

複数のコンテナを第 1 世代または第 2 世代の実行環境にデプロイできます。

ユースケース

Cloud Run サービスのサイドカーのユースケースは次のとおりです。

• アプリケーションのモニタリング、ロギング、トレース
• アプリケーション コンテナの前面で Nginx、Envoy、または Apache2 をプロキシとして使用する
• 認証と認可のフィルタの追加（Open Policy Agent など）
• Alloy DB Auth Proxy などのアウトバウンド接続プロキシの実行

サイドカー コンテナを使用したサービスのデプロイ

Google Cloud コンソール、Google Cloud CLI、YAML、または Terraform を使用して、Cloud Run サービスに複数のサイドカーをデプロイできます。

タブをクリックして、使用するツールでの手順を確認してください。

コンソール

1. Cloud Run に移動します。

   • 既存のサービスにデプロイするには、サービスリストでそのサービスをクリックして開き、[新しいリビジョンの編集とデプロイ] をクリックして、リビジョンのデプロイ フォームを表示します。
   • 新しいサービスにデプロイするには、[サービスを作成] をクリックします。

2. 新しいサービスの場合は、以下の操作を行います。

   1. デプロイする Ingress コンテナ イメージのサービス名と URL を指定します。
   2. [コンテナ、ボリューム、ネットワーキング、セキュリティ] をクリックします。

3. [コンテナの編集] カードで、必要に応じて Ingress コンテナを構成します。

4. [コンテナを追加] をクリックして、Ingress コンテナとともに追加するサイドカー コンテナを構成します。サイドカーがサービス内の別のコンテナに依存している場合は、[コンテナの起動順序] プルダウン メニューで順序を指定します。デプロイするサイドカー コンテナごとに、この手順を繰り返します。

5. すべてのトラフィックを新しいリビジョンに送信するには、[このリビジョンをすぐに利用する] を選択します。段階的にロールアウトする場合は、このチェックボックスをオフにします。これにより、新しいリビジョンにトラフィックが送信されないデプロイになります。デプロイ後、段階的なロールアウトの説明に従って操作します。

6. 新しいサービスの場合は [作成]、既存のサービスの場合は [デプロイ] をクリックして、デプロイが完了するまで待ちます。

gcloud

Google Cloud CLI の container パラメータはプレビュー版です。

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. 複数のコンテナをサービスにデプロイするには、次のコマンドを実行します。

   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 コンテナが受信リクエストをリッスンするポートに置き換えます。単一コンテナのサービスとは異なり、サイドカーを含むサービスには、Ingress コンテナのデフォルト ポートがありません。Ingress コンテナのコンテナポートを明示的に構成する必要があります。ポートを公開できるのは 1 つのコンテナのみです。
   • SIDECAR_CONTAINER_NAME は、サイドカー コンテナの名前（sidecar など）に置き換えます。
   • SIDECAR_IMAGE は、サイドカー コンテナ イメージへの参照に置き換えます。

   deploy コマンドで各コンテナを構成する場合は、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

   重要: --container フラグを使用する場合は、コンテナレベル以外のフラグをすべてコンテナレベルのフラグの前に指定する必要があります。そうしないと、deploy コマンドが失敗し、エラー メッセージが表示されます。たとえば、gcloud run services deploy service --execution-environment=gen2 --container app --memory=1G というコマンドでは、--container フラグの前に --execution-environment フラグを渡す必要があります。

3. デプロイが完了するまで待ちます。正常に完了すると、デプロイされたサービスの URL が成功のメッセージと一緒に表示されます。

YAML

以下では、サイドカーを使用した Cloud Run サービスの基本的な YAML ファイルを作成します。service.yaml という名前のファイルを作成し、次のコードを追加します。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
  name: SERVICE_NAME
spec:
  template:
    spec:
      containers:
      - image: INGRESS_IMAGE
        ports:
          - containerPort: CONTAINER_PORT
      - image: SIDECAR_IMAGE
      

次のように置き換えます。

• SERVICE は、Cloud Run サービスの名前に置き換えます。サービス名は 49 文字以下で指定する必要があります。
• CONTAINER_PORT は、Ingress コンテナが受信リクエストをリッスンするポートに置き換えます。単一コンテナのサービスとは異なり、サイドカーを含むサービスには、Ingress コンテナのデフォルト ポートがありません。Ingress コンテナのコンテナポートを明示的に構成する必要があります。ポートを公開できるのは 1 つのコンテナのみです。
• INGRESS_IMAGE は、リクエストを受信するコンテナ イメージへの参照（us-docker.pkg.dev/cloudrun/container/hello:latest など）に置き換えます。
• SIDECAR_IMAGE は、サイドカー コンテナ イメージへの参照に置き換えます。複数のサイドカーを指定するには、YAML の containers 配列に要素を追加します。

Ingress コンテナとサイドカー コンテナが含まれるように YAML を更新したら、次のコマンドを使用して Cloud Run にデプロイします。

gcloud 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 コンテナが受信リクエストをリッスンするポートを表します。単一コンテナのサービスとは異なり、サイドカーを含むサービスには、Ingress コンテナのデフォルト ポートがありません。Ingress コンテナのコンテナポートを明示的に構成する必要があります。ポートを公開できるのは 1 つのコンテナのみです。

サイドカーを使用したデプロイで使用できる注目の機能

一部のコンテナが Deployment の他のコンテナよりも先に起動しなければならない依存関係がある場合は、複数のコンテナを含む Deployment にコンテナの起動順序を指定できます。

他のコンテナに依存するコンテナがある場合は、Deployment でヘルスチェックを使用する必要があります。ヘルスチェックを使用すると、Cloud Run はコンテナの起動順序を追跡し、各コンテナの健全性を検査します。Cloud Run は、この順序で次のコンテナを起動する前に、各コンテナが正常な状態であることを確認します。ヘルスチェックを使用しない場合は、依存しているコンテナが実行されていない場合でも、正常なコンテナが起動します。

1 つのインスタンス内の複数のコンテナが、共有するメモリ内ボリュームにアクセスできます。このボリュームは、作成したマウント ポイントを介して各コンテナからアクセスできます。

次のステップ

新しいサービスをデプロイしたら、次のことを行うことができます。

• 段階的なロールアウト、ロールバックの修正、トラフィックの移行
• サービスログを表示する
• サービスのパフォーマンスをモニタリングする
• メモリ制限を設定する
• 環境変数を設定する
• サービスの同時実行を変更する
• サービスを管理する
• サービスのリビジョンを管理する
• Cloud Run OpenTelemetry サイドカーの例
• Binary Authorization で信頼できるイメージのみをデプロイする（プレビュー）

Cloud Build トリガーを使用して Cloud Run サービスのビルドとデプロイを自動化できます。

• 継続的デプロイを設定する

Cloud Deploy を使用して継続的デリバリー パイプラインを設定し、Cloud Run サービスを複数の環境にデプロイすることもできます。

• Cloud Deploy を使用してアプリを Cloud Run にデプロイする