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

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

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

始める前に

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

必要なロール

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

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

  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 を使用してデプロイする方法については、IntelliJVisual Studio Code のガイドをご覧ください。

Terraform

Terraform を使用する場合、Google Cloud Platform Providergoogle_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」と入力して、記述されている操作を適用することを確認します。

クライアント ライブラリ

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

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(フィンランド) リーフアイコン 低 CO2
  • europe-southwest1(マドリッド) リーフアイコン 低 CO2
  • europe-west1(ベルギー) リーフアイコン 低 CO2
  • europe-west4(オランダ) リーフアイコン 低 CO2
  • europe-west8(ミラノ)
  • europe-west9(パリ) リーフアイコン 低 CO2
  • me-west1(テルアビブ)
  • us-central1(アイオワ) リーフアイコン 低 CO2
  • us-east1(サウスカロライナ)
  • us-east4(北バージニア)
  • us-east5(コロンバス)
  • us-south1(ダラス) リーフアイコン 低 CO2
  • us-west1(オレゴン) リーフアイコン 低 CO2

ティア 2 料金を適用

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

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

デプロイ時に、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. 他のタブを使用して、必要に応じて構成します。

  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 ファイルに保存します。

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

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

gcloud run services replace service.yaml

Cloud Code

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

Terraform

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

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

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

    terraform apply

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

クライアント ライブラリ

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

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(フィンランド) リーフアイコン 低 CO2
  • europe-southwest1(マドリッド) リーフアイコン 低 CO2
  • europe-west1(ベルギー) リーフアイコン 低 CO2
  • europe-west4(オランダ) リーフアイコン 低 CO2
  • europe-west8(ミラノ)
  • europe-west9(パリ) リーフアイコン 低 CO2
  • me-west1(テルアビブ)
  • us-central1(アイオワ) リーフアイコン 低 CO2
  • us-east1(サウスカロライナ)
  • us-east4(北バージニア)
  • us-east5(コロンバス)
  • us-south1(ダラス) リーフアイコン 低 CO2
  • us-west1(オレゴン) リーフアイコン 低 CO2

ティア 2 料金を適用

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

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

他の 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 サービスを含むプロジェクトにコンテナ イメージをデプロイします。

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

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 を使用してサイドカーと通信しています。

Cloud Run マルチコンテナ

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
  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 Build トリガーを使用して Cloud Run サービスのビルドとデプロイを自動化できます。

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