このページでは、コンテナ イメージを新しい 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 つのリビジョンをデプロイする] を選択し、コンテナ イメージを指定します。
継続的デプロイを自動化する場合は、[ソース リポジトリから新しいリビジョンを継続的にデプロイする] を選択し、継続的デプロイの手順の説明に従ってください。
必要なサービス名を入力します。サービス名は 49 文字以下で、リージョンとプロジェクトごとに一意である必要があります。サービス名は後から変更することはできません。この名前は一般公開されます。
サービスのリージョンを選択します。リージョン セレクタには、料金階層とドメイン マッピングの可用性が示され、カーボン フットプリントの影響が最も低いリージョンがハイライト表示されます。
必要に応じて CPU 割り当てと料金を設定します。
フォームの Ingress 設定を必要に応じて設定します。
[認証] で、次の構成を行います。
- 公開 API またはウェブサイトを作成する場合は、[認証されていない呼び出しを許可する] を選択します。これをオンにすると、IAM 起動元ロールに特別な
allUser
が割り当てられます。サービスの作成後に、IAM を使用してこの設定を編集できます。 - 認証で保護された安全なサービスが必要な場合は、[認証が必要] を選択します。
- 公開 API またはウェブサイトを作成する場合は、[認証されていない呼び出しを許可する] を選択します。これをオンにすると、IAM 起動元ロールに特別な
[コンテナ、ボリューム、ネットワーキング、セキュリティ] をクリックして、該当するタブでその他のオプション設定を指定します。
サービスの構成が完了したら、[作成] をクリックしてイメージを Cloud Run にデプロイし、デプロイの完了を待ちます。
表示された URL リンクをクリックして、デプロイしたサービスで一意の安定したエンドポイントを開きます。
gcloud
-
In the Google Cloud console, 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.
コンテナ イメージをデプロイするには:
次のコマンドを実行します。
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
コマンドを実行時に確認のプロンプトが表示されます。デプロイが完了するまで待ちます。正常に完了すると、デプロイされたサービスの URL が成功のメッセージと一緒に表示されます。
run/region
gcloud
プロパティで設定した場所とは異なる場所にデプロイする場合は、次のようにします。gcloud run deploy SERVICE --region REGION
YAML
サービス仕様を YAML
ファイルに保管してから、gcloud CLI を使用してデプロイできます。
次の内容の新しいファイルを
service.yaml
という名前で作成します。apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE spec: template: spec: containers: - image: IMAGE
次のように置き換えます。
- SERVICE は、Cloud Run サービスの名前に置き換えます。サービス名は 49 文字以下で、リージョンとプロジェクトごとに一意である必要があります。
- IMAGE は、コンテナ イメージの URL に置き換えます。
環境変数やメモリ上限など他の構成を指定することもできます。
次のコマンドを使用して新しいサービスをデプロイします。
gcloud run services replace service.yaml
(省略可能)サービスへの未認証アクセスを許可したい場合は、サービスを一般公開にします。
Cloud Code
Cloud Code を使用してデプロイする方法については、IntelliJ と Visual Studio Code のガイドをご覧ください。
Terraform
Terraform を使用する場合、Google Cloud Platform Provider の google_cloud_run_v2_service
リソースを使用して Terraform 構成でサービスを定義します。
この内容で
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
スタンザを削除します。Terraform を初期化します。
terraform init
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
既存のサービスの新しいリビジョンをデプロイするには:
サービスリストで更新したいサービスをクリックして、サービスの詳細を表示します。
[新しいリビジョンの編集とデプロイ] をクリックして、リビジョンのデプロイ フォームを表示します。
必要に応じて、デプロイする新しいコンテナ イメージの URL を入力します。
必要に応じてコンテナを構成します。
必要に応じて CPU 割り当てと料金を設定します。
必要に応じて、リクエスト タイムアウトと同時実行を指定します。
必要に応じて実行環境を指定します。
他のタブを使用して、必要に応じて構成します。
すべてのトラフィックを新しいリビジョンに送信するには、[このリビジョンをすぐに利用する] を選択します。新しいリビジョンを段階的にロールアウトする場合は、そのチェックボックスをオフにします。これにより、新しいリビジョンにトラフィックが送信されないデプロイになります。デプロイ後、段階的なロールアウトの説明に従って操作します。
[デプロイ] をクリックして、デプロイが完了するまで待ちます。
gcloud
-
In the Google Cloud console, 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.
コンテナ イメージをデプロイするには:
次のコマンドを実行します。
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 を使用します。
デプロイが完了するまで待ちます。正常に完了すると、デプロイされたサービスの 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 を使用して既存のサービスの新しいリビジョンをデプロイする方法については、IntelliJ と Visual Studio Code のガイドをご覧ください。
Terraform
新しいサービスのデプロイの例で説明されているように Terraform を設定していることを確認します。
構成ファイルに変更を行います。
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 プロジェクトのコンテナ イメージをデプロイできます。
Google Cloud コンソールで、Cloud Run サービスのプロジェクトを開きます。
[Google 提供のロール付与を含む] を選択します。
Cloud Run サービス エージェントのメールアドレスをコピーします。このアドレスには、@serverless-robot-prod.iam.gserviceaccount.com という接尾辞が付いています。
使用する Container Registry を所有するプロジェクトを開きます。
[追加] をクリックして、新しいプリンシパルを追加します。
[新しいプリンシパル] フィールドに、先ほどコピーしたサービス アカウントのメールアドレスを貼り付けます。
Container Registry を使用している場合は、[ロールを選択] プルダウン メニューで、[ストレージ] -> [Storage オブジェクト閲覧者] を選択します。Artifact Registry を使用している場合は、[Artifact Registry] -> [Artifact Registry 読み取り] のロールを選択します。
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
を使用してサイドカーと通信しています。
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 サービスに複数のサイドカーをデプロイできます。
タブをクリックして、使用するツールでの手順を確認してください。
コンソール
-
- 既存のサービスにデプロイするには、サービスリストでそのサービスをクリックして開き、[新しいリビジョンの編集とデプロイ] をクリックして、リビジョンのデプロイ フォームを表示します。
- 新しいサービスにデプロイするには、[サービスを作成] をクリックします。
新しいサービスの場合は、以下の操作を行います。
- デプロイする Ingress コンテナ イメージのサービス名と URL を指定します。
- [コンテナ、ボリューム、ネットワーキング、セキュリティ] をクリックします。
[コンテナの編集] カードで、必要に応じて Ingress コンテナを構成します。
[コンテナを追加] をクリックして、Ingress コンテナとともに追加するサイドカー コンテナを構成します。サイドカーがサービス内の別のコンテナに依存している場合は、[コンテナの起動順序] プルダウン メニューで順序を指定します。デプロイするサイドカー コンテナごとに、この手順を繰り返します。
すべてのトラフィックを新しいリビジョンに送信するには、[このリビジョンをすぐに利用する] を選択します。段階的にロールアウトする場合は、このチェックボックスをオフにします。これにより、新しいリビジョンにトラフィックが送信されないデプロイになります。デプロイ後、段階的なロールアウトの説明に従って操作します。
新しいサービスの場合は [作成]、既存のサービスの場合は [デプロイ] をクリックして、デプロイが完了するまで待ちます。
gcloud
Google Cloud CLI の container
パラメータはプレビュー版です。
-
In the Google Cloud console, 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.
複数のコンテナをサービスにデプロイするには、次のコマンドを実行します。
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
デプロイが完了するまで待ちます。正常に完了すると、デプロイされたサービスの 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 サービスを複数の環境にデプロイすることもできます。