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

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

デプロイに必要な権限

次のいずれかが必要です。

  • オーナー
  • 編集者
  • Cloud Run 管理者ロールとサービス アカウント ユーザー ロールの両方
  • この権限のリストを含むカスタムロール

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

Container Registry または Artifact Registry に保存されているコンテナ イメージを使用できます。次の種類のコンテナ イメージのみを使用できます。

別の種類のコンテナ レジストリにコンテナ イメージを保存する場合は、サポートされていないレジストリからイメージをデプロイするの手順に沿って操作してください。

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

タグ(たとえば、gcr.io/my-project/my-image:latest)または正確なダイジェスト(たとえば、gcr.io/my-project/my-image@sha256:41f34ab970ee...)でコンテナ イメージを指定できます。

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

コンテナはコンソールや gcloud コマンドラインを使用してデプロイするか、または YAML 構成ファイルからデプロイできます。

任意のツールを使用して、手順のタブでクリックします。

Console

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

  1. Cloud Run に移動します

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

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

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

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

    2. 任意のサービス名を入力します。サービス名がリージョンとプロジェクトごと、またはクラスタごとに一意である必要があります。サービス名は後で変更することはできず、Cloud Run を使用時に一般公開されます。

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

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

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

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

    7. [認証] で次の操作を行います。

      • 公開 API またはウェブサイトを作成する場合は、[認証されていない呼び出しを許可する] を選択します。これをオンにすると、IAM 起動元ロールに特別な allUser が割り当てられます。サービスの作成後に、IAM を使用してこの設定を編集できます。
      • 認証で保護された安全なサービスが必要な場合は、[認証が必要] を選択します。
  3. [コンテナ、変数とシークレット、接続、セキュリティ] をクリックし、該当するタブでその他のオプション設定を指定します。

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

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

コマンドライン

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

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

    gcloud run deploy SERVICE --image IMAGE_URL

    • SERVICE を、デプロイ先のサービスの名前に置き換えます。サービスがまだ存在しない場合、デプロイ中にこのコマンドによってサービスが作成されます。このパラメータは省略できますが、省略するとサービス名の入力を求められます。
    • IMAGE_URL は、コンテナ イメージへの参照(us-docker.pkg.dev/cloudrun/container/hello:latest など)に置き換えます。--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 サービスの名前に置き換えます。
    • 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_service リソースを使用して Terraform 構成でサービスを定義できます。

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

    provider "google" {
        project = "PROJECT-ID"
    }
    
    resource "google_cloud_run_service" "default" {
        name     = "SERVICE"
        location = "REGION"
    
        metadata {
          annotations = {
            "run.googleapis.com/client-name" = "terraform"
          }
        }
    
        template {
          spec {
            containers {
              image = "gcr.io/PROJECT-ID/IMAGE"
            }
          }
        }
     }
    
     data "google_iam_policy" "noauth" {
       binding {
         role = "roles/run.invoker"
         members = ["allUsers"]
       }
     }
    
     resource "google_cloud_run_service_iam_policy" "noauth" {
       location    = google_cloud_run_service.default.location
       project     = google_cloud_run_service.default.project
       service     = google_cloud_run_service.default.name
    
       policy_data = data.google_iam_policy.noauth.policy_data
    }
    

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

    • PROJECT-ID は、Google Cloud プロジェクト ID に置き換えます。
    • REGION は、Google Cloud リージョンに置き換えます。
    • SERVICE は、Cloud Run サービスの名前に置き換えます。
    • IMAGE は、コンテナ イメージの名前に置き換えます。

    上記の構成では公開アクセスが可能になります(--allow-unauthenticated と同等)。サービスを非公開にするには、google_iam_policy スタンザと google_cloud_run_service_iam_policy スタンザを削除します。

  2. Terraform を初期化します。

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

    terraform apply

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

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(オランダ)
  • europe-west8(ミラノ)
  • europe-west9(パリ) リーフアイコン 低 CO2
  • us-central1(アイオワ) リーフアイコン 低 CO2
  • us-east1(サウスカロライナ)
  • us-east4(北バージニア)
  • us-east5(コロンバス)
  • us-south1(ダラス)
  • us-west1(オレゴン) リーフアイコン 低 CO2

ティア 2 料金を適用

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

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

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

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

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

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

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

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

Console

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

  1. Cloud Run に移動します

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

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

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

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

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

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

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

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

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

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

  4. すべてのトラフィックを新しいリビジョンに送信するには、[このリビジョンをすぐに利用する] のチェックボックスをオンにします。新しいリビジョンを段階的に展開するには、チェックボックスをオフにします。これにより新しいリビジョンにトラフィックが送信されないデプロイになります。デプロイ後に段階的な展開の手順に従ってください。

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

コマンドライン

コマンドラインを使用するには、gcloud CLI を設定しておく必要があります。

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

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

    gcloud run deploy SERVICE --image IMAGE_URL

    • SERVICE は、デプロイ先のサービスの名前に置き換えます。このパラメータは省略できますが、省略するとサービス名の入力を求められます。
    • IMAGE_URL は、コンテナ イメージへの参照(us-docker.pkg.dev/cloudrun/container/hello:latest など)に置き換えます。

      リビジョン サフィックスは、新しいリビジョンに自動的に割り当てられます。独自のリビジョン サフィックスを指定する場合は、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 と入力して、記述されている操作を適用することを確認します。

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(オランダ)
  • europe-west8(ミラノ)
  • europe-west9(パリ) リーフアイコン 低 CO2
  • us-central1(アイオワ) リーフアイコン 低 CO2
  • us-east1(サウスカロライナ)
  • us-east4(北バージニア)
  • us-east5(コロンバス)
  • us-south1(ダラス)
  • us-west1(オレゴン) リーフアイコン 低 CO2

ティア 2 料金を適用

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

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

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

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

  1. コンソールで、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 Run にデプロイするには、docker push を使用して Artifact Registry にイメージを一時的に push します。コンテナ イメージはデプロイ時に Cloud Run によってインポートされます。デプロイ後は、docker image rm を使用して Artifact Registry からイメージを削除します。

次のステップ

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

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