VPC ネットワークによるダイレクト VPC 下り（外向き）

サーバーレス VPC アクセス コネクタなしでダイレクト VPC 下り（外向き）を使用することで、Cloud Run サービスまたはジョブが VPC ネットワークにトラフィックを送信できるようにします。

始める前に

  • プロジェクトに VPC ネットワークがない場合は作成します。

  • 共有 VPC を使用する場合は、共有 VPC ネットワークへの接続をご覧ください。

  • VPC サブネットを使用する場合、サブネットは /24 以上である必要があります。

  • Cloud Run 全体で使用できる十分な IP アドレスを確保するには、次の条件に注意してください。

    • Cloud Run のサービスまたはリビジョンをデプロイするサブネットでは、少なくとも数百個の IP アドレスが使用できる状態になっている必要があります。
    • 安定した状態で、サブネットを使用する Cloud Run インスタンスの合計数が 100 以上の場合、インスタンス数の少なくとも 4 倍の IP アドレスを予約します。リビジョンがスケールダウンされると、Cloud Run は最大 20 分間 IP アドレスを保持します。たとえば、revision 1 でインスタンス数が 100 から 0 にスケールダウンされ、revision 2 で 0 から 100 にスケールアップされるようにリビジョンをアップグレードすると、スケールダウン後、最大 20 分間 Cloud Run は revision 1 の IP アドレスを保持します。この 20 分間は 800 個以上の IP アドレス（(100 + 100) * 4）が予約されている必要があります。

制限事項

Cloud Run のサービスとジョブには、次の制限が適用されます。

  • Cloud Run の使用量割り当てにより、ダイレクト VPC 下り（外向き）を使用するように構成できるインスタンスの最大数を制限します。最大数は、Cloud Run のリビジョンまたはジョブ実行ごとに構成されます。デフォルトの上限を増やすには、割り当てを増やす方法をご覧ください。Google Cloud コンソールを使用して割り当てを確認できます。

  • Cloud Run のサービスとジョブでは、ネットワーク インフラストラクチャのメンテナンス イベント中に接続が切断される可能性があります。ときどき発生する接続リセットを処理できるクライアント ライブラリを使用することをおすすめします。
  • 第 2 世代の実行環境でダイレクト VPC 下り（外向き）を有効にすると、コンテナのコールド スタート時間が長くなる可能性があります。
次の制限は、Cloud Run のジョブにのみ適用され、サービスには適用されません。
  • ジョブを適切に実行するため、ダイレクト VPC 下り（外向き）は、8 個を超える同時インスタンスを必要としないジョブでのみ使用し、1,024 個以上の IP アドレスを予約するようにしてください。

ダイレクト VPC 下り（外向き）では、次のものはサポートされていません。

  • VPC フローログとファイアウォール ルールのロギングでは、Cloud Run サービスまたはリビジョンの名前は提供されません。
  • Packet Mirroring
  • Network Intelligence Center
  • IPv6 トラフィック
  • 宛先リソースに適用される上り（内向き）ファイアウォール ルールでのネットワーク タグの使用。
  • 宛先リソースに適用される上り（内向き）ファイアウォール ルールでのソース サービス アカウントとしてのサービス ID の使用。
  • ファイアウォール ルールでは、Cloud Run ワークロードに適用されている Resource Manager タグを使用できません。
  • Cloud Run ジョブの実行時間が 1 時間を超えると、接続が切断される可能性があります。これは、マシン間でジョブを移行するメンテナンス イベント中に発生する可能性があります。コンテナは、イベントの 10 秒前に SIGTSTP シグナルを受け取り、イベント後に SIGCONT シグナルを受け取ります。コンテナが SIGCONT シグナルを受信したら、接続を再試行してください。

リージョン

ダイレクト VPC 下り（外向き）でサポートされているリージョンの一覧については、ダイレクト VPC 下り（外向き）リージョンをご覧ください。

ダイレクト VPC 下り（外向き）では、次のリージョンはサポートされていません。

  • asia-northeast3
  • asia-southeast1

IP アドレスの割り振り

VPC ネットワークに Cloud Run サービスやジョブを配置するには、ネットワークとサブネットを 1 つ指定する必要があります。Cloud Run はサブネットから IP アドレスを割り振ります。

この IP アドレスは一時的なものであるため、個別の IP に基づくポリシーは作成しないでください。IP に基づくポリシー（ファイアウォール ルールなど）を作成する必要がある場合は、サブネット全体の IP アドレス範囲を使用する必要があります。

サービスやジョブが使用するネットワークやサブネットを変更するには、新しいサービス リビジョンをデプロイするか、新しいネットワークとサブネット値を使用して新しいジョブタスクを実行します。

スケールアップ

トラフィックが急増したとき速やかにスケールアップできるようにするため、Cloud Run では事前に IP アドレスを割り振ります。

どの時点においても、割り振られる IP アドレスは、存在するインスタンス数より多くなるはずです。Cloud Run が十分な IP アドレスを取得できるようにするには、サブネットで少なくとも数百個の IP アドレスが使用できる状態になっている必要があります。すべての Cloud Run サービスとジョブのサブネットの合計数が 100 を超える場合、IP アドレスの合計数をその 4 倍以上にすることをおすすめします。Cloud Run が追加の IP アドレスを割り振ることができない場合、新しい IP アドレスを使用できるようになるまでサービス インスタンスやジョブタスクを開始できません。IP アドレス空間が限定されている場合は、サポートされている IP 範囲で他の選択肢をご覧ください。IP の割り振り管理を効率よく簡単に行うには、同じサブネットに複数のサービスやジョブを配置してください。

スケールダウン

Cloud Run では、すべてのサービスやジョブがゼロにスケールダウンされた後でも、サービスやジョブを速やかにスケールアップする必要がある場合に備え、サブネットの IP アドレスの一部が予約されています。

そのサブネットを削除するには、Cloud Run のサービスまたはジョブを削除するか再デプロイして、サブネットの使用を停止した後、1～2 時間待ちます。

サポートされている IP 範囲

Cloud Run では、サブネットで次の IPv4 範囲をサポートしています。

  • RFC 1918（推奨）
    • 10.0.0.0/8
    • 172.16.0.0/12
    • 192.168.0.0/16
  • RFC 6598
    • 100.64.0.0/10
  • クラス E（オンプレミスの設定では非推奨）
    • 240.0.0.0/4

IAM 権限を設定する

次のいずれかの方法で、Cloud Run が VPC ネットワークにアクセスできるようにします。

  • Cloud Run サービス エージェントのロール: デフォルトでは、Cloud Run サービス エージェントには、必要な権限を含む Cloud Run サービス エージェントのロール（roles/run.serviceAgent）が付与されています。

  • カスタム権限: より詳細に制御するには、プロジェクトに対する次の追加権限を Cloud Run サービス エージェントに付与します。

    • compute.networks.get
    • compute.subnetworks.get
    • プロジェクトまたは特定のサブネットに対する compute.subnetworks.use
    • compute.addresses.get
    • compute.addresses.list
    • compute.addresses.createInternal
    • compute.addresses.deleteInternal

  • Compute ネットワーク ユーザー ロール: デフォルトの Cloud Run サービス エージェント ロールまたはカスタム権限を使用しない場合は、次のコマンドを実行して、Cloud Run サービス エージェント サービス アカウントに Compute ネットワーク ユーザーロール（roles/compute.networkUser）を付与します。

    gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com" \
--role "roles/compute.networkUser"

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

    • PROJECT_ID: オブジェクトの ID。
    • PROJECT_NUMBER: Cloud Run サービスまたはジョブをデプロイするプロジェクト番号。

サービスをデプロイする

ダイレクト VPC 下り（外向き）を使用すると、Cloud Run サービスはサーバーレス VPC アクセス コネクタを使用せずに VPC ネットワークにトラフィックを送信できます。サービス自体と同様に、ネットワーク費用もゼロにスケーリングされます。また、Cloud Run サービス リビジョンでネットワーク タグを直接使用して、よりきめ細かいネットワーク セキュリティを実現できます。

サービスにダイレクト VPC 下り（外向き）を構成するには、Google Cloud コンソール、Google Cloud CLI、または YAML を使用します。

コンソール

  1. Cloud Run に移動します。

  2. デプロイ先の新しいサービスを構成する場合は、[サービスを作成] をクリックします。既存のサービスを構成してデプロイする場合は、サービスをクリックし、[新しいリビジョンの編集とデプロイ] をクリックします。

  3. 新しいサービスを構成する場合は、必要に応じて最初のサービス設定のページに入力してから、[コンテナ、ボリューム、ネットワーキング、セキュリティ] をクリックしてサービス構成ページを開きます。

  4. [ネットワーキング] タブをクリックします。

  5. [アウトバウンド トラフィック用の VPC に接続する] をクリックします。

  6. [VPC に直接トラフィックを送信] をクリックします。

  7. [ネットワーク] フィールドで、トラフィックを送信する VPC ネットワークを選択します。

  8. [サブネット] フィールドで、サービスが IP アドレスを受信するサブネットを選択します。 同じサブネットに複数のサービスをデプロイできます。

  9. 省略可: サービスに関連付けるネットワーク タグの名前を入力します。ネットワーク タグは、リビジョン レベルで指定されます。サービス リビジョンには、network-tag-2 などの異なるネットワーク タグを設定できます。

  10. [トラフィック ルーティング] で、次のいずれかを選択します。

    • プライベート IP へのリクエストだけを VPC に転送し、VPC ネットワーク経由で内部アドレスにのみトラフィックを送信します。
    • すべてのトラフィックを VPC にルーティングする。すべてのアウトバウンド トラフィックを VPC ネットワーク経由で送信します。

  11. [作成] または [デプロイ] をクリックします。

  12. サービスが VPC ネットワーク上にあることを確認するには、サービスをクリックして、[ネットワーキング] タブをクリックします。ネットワークとサブネットが [VPC] カードに一覧表示されます。

    これで、ファイアウォール ルールで許可されるように、Cloud Run サービスから VPC ネットワーク上の任意のリソースにリクエストを送信できます。

gcloud

Google Cloud CLI からコネクタなしで Cloud Run サービスをデプロイするには:

  1. プロジェクトで Compute Engine API が有効になっていることを確認します。

    gcloud services enable compute.googleapis.com

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

    gcloud beta run deploy SERVICE_NAME \
--image=IMAGE_URL \
--network=NETWORK \
--subnet=SUBNET \
--network-tags=NETWORK_TAG_NAMES \
--vpc-egress=EGRESS_SETTING \
--region=REGION

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

    • SERVICE_NAME: Cloud Run サービスの名前。
    • IMAGE_URL: コンテナ イメージへの参照（us-docker.pkg.dev/cloudrun/container/hello:latest など）。Artifact Registry を使用する場合は、リポジトリ REPO_NAME がすでに作成されている必要があります。URL の形式は REGION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG です。
    • NETWORK: VPC ネットワークの名前。
    • SUBNET: サブネットの名前。複数のサービスまたはジョブを同じサブネットにデプロイまたは実行できます。
    • （省略可）NETWORK_TAG_NAMES: サービスに関連付けるネットワーク タグのカンマ区切り名。サービスの場合、ネットワーク タグはリビジョン レベルで指定されます。サービス リビジョンには、network-tag-2 などの異なるネットワーク タグを設定できます。
    • EGRESS_SETTING: 下り（外向き）設定値。
      • all-traffic: すべてのアウトバウンド トラフィックを VPC ネットワーク経由で送信します。
      • private-ranges-only: VPC ネットワーク経由で内部アドレスにのみトラフィックを送信します。
    • REGION: サービスのリージョン。

  3. サービスが VPC ネットワーク上にあることを確認するには、次のコマンドを実行します。

    gcloud beta run services describe SERVICE_NAME \
--region=REGION

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

    • SERVICE_NAME: 実際のサービスの名前。
    • REGION: 前の手順で指定したサービスのリージョン。

    出力には、ネットワークの名前、サブネット、下り（外向き）設定が含まれます。次に例を示します。

    VPC access:
  Network:       default
  Subnet:        subnet
  Egress:        private-ranges-only

これで、ファイアウォール ルールで許可されるように、Cloud Run サービスから VPC ネットワーク上の任意のリソースにリクエストを送信できます。

YAML

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

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

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE_NAME
  annotations:
    run.googleapis.com/launch-stage: BETA
  labels:
    cloud.googleapis.com/location: REGION
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'
        run.googleapis.com/vpc-access-egress: EGRESS_SETTING
    spec:
      containers:
      - image: IMAGE

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

    • SERVICE_NAME: Cloud Run サービスの名前。サービス名は 49 文字以下で、リージョンとプロジェクトごとに一意である必要があります。
    • REGION: Cloud Run サービスのリージョン。サブネットのリージョンと一致する必要があります。
    • NETWORK: VPC ネットワークの名前。
    • SUBNET: サブネットの名前。複数のサービスまたはジョブを同じサブネットにデプロイまたは実行できます。
    • （省略可）NETWORK_TAG_NAMES: サービスに関連付けるネットワーク タグの名前。サービスの場合、ネットワーク タグはリビジョン レベルで指定されます。サービス リビジョンには、network-tag-2 などの異なるネットワーク タグを設定できます。
    • EGRESS_SETTING: 下り（外向き）設定値。
      • all-traffic: すべてのアウトバウンド トラフィックを VPC ネットワーク経由で送信します。
      • private-ranges-only: VPC ネットワーク経由で内部アドレスにのみトラフィックを送信します。
    • IMAGE: サービス コンテナ イメージの URL。

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

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

    gcloud run services replace service.yaml

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

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

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

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

gcloud run services replace service.yaml

ジョブを作成する

ダイレクト VPC 下り（外向き）を使用すると、Cloud Run ジョブはサーバーレス VPC アクセス コネクタを使用せずに VPC ネットワークにトラフィックを送信できます。

ジョブにダイレクト VPC 下り（外向き）を構成するには、Google Cloud コンソール、Google Cloud CLI、または YAML を使用します。

コンソール

  1. Cloud Run に移動します。

  2. 新しいジョブを構成する場合は、[ジョブ] タブをクリックし、必要に応じて初期ジョブ設定ページを入力します。既存のジョブを構成する場合は、ジョブをクリックして [編集] をクリックします。

  3. [コンテナ、変数とシークレット、接続、セキュリティ] をクリックして、ジョブのプロパティ ページを開きます。

  4. [接続] タブをクリックします。

  5. [アウトバウンド トラフィック用の VPC に接続する] をクリックします。

  6. [VPC に直接トラフィックを送信] をクリックします。

  7. [ネットワーク] フィールドで、トラフィックを送信する VPC ネットワークを選択します。

  8. [サブネット] フィールドで、ジョブが IP アドレスを受信するサブネットを選択します。同じサブネットで複数のジョブを実行できます。

  9. [トラフィック ルーティング] で、次のいずれかを選択します。

    • プライベート IP へのリクエストだけを VPC に転送し、VPC ネットワーク経由で内部アドレスにのみトラフィックを送信します。
    • すべてのトラフィックを VPC にルーティングする。すべてのアウトバウンド トラフィックを VPC ネットワーク経由で送信します。

  10. 省略可: サービスに関連付けるネットワーク タグの名前を入力します。ネットワーク タグは、リビジョン レベルで指定されます。サービス リビジョンには、network-tag-2 などの異なるネットワーク タグを設定できます。

  11. 省略可: ジョブに関連付けるネットワーク タグの名前を入力します。ジョブの場合、ネットワーク タグは実行レベルで指定されます。ジョブ実行ごとに異なるネットワーク タグ（network-tag-2 など）を設定できます。

  12. [作成] または [更新] をクリックします。

  13. ジョブが VPC ネットワーク上にあることを確認するには、ジョブをクリックして [構成] タブをクリックします。ネットワークとサブネットが [VPC] カードに一覧表示されます。

    これで、ファイアウォール ルールで許可されているように、Cloud Run ジョブを実行して、VPC ネットワーク上の任意のリソースにリクエストを送信できます。

gcloud

Google Cloud CLI からコネクタなしで Cloud Run ジョブを作成するには:

  1. プロジェクトで Compute Engine API が有効になっていることを確認します。

    gcloud services enable compute.googleapis.com

  2. 次のコマンドを使用して Cloud Run ジョブを作成します。

    gcloud run jobs create JOB_NAME \
--image=IMAGE_URL \
--network=NETWORK \
--subnet=SUBNET \
--network-tags=NETWORK_TAG_NAMES \
--vpc-egress=EGRESS_SETTING \
--region=REGION

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

    • JOB_NAME: Cloud Run ジョブの名前。
    • IMAGE_URL: コンテナ イメージへの参照（us-docker.pkg.dev/cloudrun/container/job:latest など）。
    • NETWORK: VPC ネットワークの名前。
    • SUBNET: サブネットの名前。複数のサービスまたはジョブを同じサブネットにデプロイまたは実行できます。
    • （省略可）NETWORK_TAG_NAMES: ジョブに関連付けるネットワーク タグの名前。ジョブの場合、ネットワーク タグは実行レベルで指定されます。ジョブ実行ごとに異なるネットワーク タグ（network-tag-2 など）を設定できます。
    • EGRESS_SETTING: 下り（外向き）設定値。
      • all-traffic: すべてのアウトバウンド トラフィックを VPC ネットワーク経由で送信します。
      • private-ranges-only: VPC ネットワーク経由で内部アドレスにのみトラフィックを送信します。
    • REGION: ジョブのリージョン。

  3. ジョブが VPC ネットワーク上にあることを確認するには、次のコマンドを実行します。

    gcloud run jobs describe JOB_NAME \
  --region=REGION

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

    • JOB_NAME: ジョブの名前。
    • REGION: 前の手順で指定したジョブのリージョン。

    出力には次のようなネットワークまたはサブネットの名前が表示されます。

    VPC network:
  Network:       default
  Subnet:        default

これで、ファイアウォール ルールで許可されているように、Cloud Run ジョブを実行して、VPC ネットワーク上の任意のリソースにリクエストを送信できます。

YAML

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

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

    apiVersion: run.googleapis.com/v1
kind: Job
metadata:
  name: JOB_NAME
  annotations:
    run.googleapis.com/launch-stage: BETA
  labels:
    cloud.googleapis.com/location: REGION
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'
        run.googleapis.com/vpc-access-egress: EGRESS_SETTING
    spec:
      containers:
      - image: IMAGE

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

    • JOB_NAME: Cloud Run ジョブの名前。ジョブ名は 49 文字以下で、リージョンとプロジェクトごとに一意である必要があります。
    • REGION: Cloud Run ジョブのリージョン。サブネットのリージョンと一致する必要があります。
    • NETWORK: VPC ネットワークの名前。
    • SUBNET: サブネットの名前。複数のサービスまたはジョブを同じサブネットにデプロイまたは実行できます。
    • （省略可）NETWORK_TAG_NAMES: ジョブに関連付けるネットワーク タグの名前。ジョブの場合、ネットワーク タグは実行レベルで指定されます。ジョブ実行ごとに異なるネットワーク タグ（network-tag-2 など）を設定できます。
    • EGRESS_SETTING: 下り（外向き）設定値。
      • all-traffic: すべてのアウトバウンド トラフィックを VPC ネットワーク経由で送信します。
      • private-ranges-only: VPC ネットワーク経由で内部アドレスにのみトラフィックを送信します。
    • IMAGE: ジョブのコンテナ イメージの URL。

  2. 次のコマンドを実行して、新しいジョブをデプロイします。

    gcloud run jobs replace job.yaml

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

gcloud run jobs describe JOB --format export > job.yaml

ジョブ構成 YAML ファイルで、spec.template 子属性を必要に応じて変更し、リビジョン設定を更新して再デプロイします。

gcloud run jobs replace job.yaml

ファイアウォール ルールでアクセスを制限する

VPC ファイアウォール ルールを使用して、VPC ネットワーク内のリソースへのアクセスを制限します。これらの制限を追加するには、次のいずれかの方法を使用します。

  • サブネットの IP 範囲を使用して、サービスまたはジョブを参照する上り（内向き）ファイアウォール ルールを作成します。

  • サービスまたはジョブを参照する下り（外向き）ファイアウォール ルールを作成します。

    下り（外向き）ファイアウォール ルールで、リンクされたサービス アカウントのサービス ID、サブネットの IP 範囲、または関連するネットワーク タグを使用して、サービスまたはジョブを参照します。

下り（外向き）ネットワーク タグ

下り（外向き）ファイアウォール ルールでネットワーク タグを使用して、ネットワーク セキュリティを強化します。

コンソール

ネットワーク タグをサービスまたはジョブに関連付けるには:

  1. Google Cloud コンソールで [Cloud Run] ページに移動します。

    Cloud Run に移動

  2. ネットワーク タグを関連付けるサービスまたはジョブをクリックし、[新しいリビジョンの編集とデプロイ]（サービスの場合）または [編集]（ジョブの場合）をクリックします。

  3. [ネットワーキング] タブ（サービスの場合）または [接続] タブ（ジョブの場合）をクリックします。

  4. [アウトバウンド トラフィック用の VPC に接続する] と [VPC に直接トラフィックを送信] が選択されていることを確認します。

  5. [サブネット] フィールドで、サービスが IP アドレスを受信するサブネットを選択します。複数のサービスまたはジョブを同じサブネットにデプロイまたは実行できます。

  6. [ネットワーク タグ] フィールドに、サービスまたはジョブに関連付けるネットワーク タグの名前を入力します。

  7. [デプロイ] または [更新] をクリックします。

サービスの場合、ネットワーク タグはリビジョン レベルで指定されるため、サービス リビジョンごとに異なるネットワーク タグのセットを使用できます。ジョブの場合、ジョブ実行の作成時にジョブに設定されていた同じネットワーク タグがジョブ実行に設定されます。

gcloud

ネットワーク タグをサービスまたはジョブに関連付けるには、gcloud beta run deploy コマンドを使用します。

gcloud beta run deploy SERVICE_JOB_NAME \
    --image=IMAGE_URL \
    --network=NETWORK \
    --subnet=SUBNET \
    --network-tags=NETWORK_TAG_NAMES \
    --region=REGION

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

  • SERVICE_JOB_NAME: サービスまたはジョブの名前。
  • IMAGE_URL: サービスまたはジョブのイメージ URL。
  • NETWORK: VPC ネットワークの名前。
  • SUBNET: サブネットの名前。複数のサービスまたはジョブを同じサブネットにデプロイまたは実行できます。
  • NETWORK_TAG_NAMES: ネットワーク タグの名前またはネットワーク タグのカンマ区切りリスト。
  • REGION: リージョンの名前。

サービスの場合、ネットワーク タグはリビジョン レベルで指定されるため、サービス リビジョンごとに異なるネットワーク タグのセットを使用できます。ジョブの場合、ジョブ実行の作成時にジョブに設定されていた同じネットワーク タグがジョブ実行に設定されます。

サービスを接続解除する

コンソール

  • VPC ネットワークからサービスを削除するには:

    1. Cloud Run に移動します。

    2. 削除するサービスをクリックし、[新しいリビジョンの編集とデプロイ] をクリックします。

    3. [ネットワーキング] タブをクリックします。

    4. [アウトバウンド トラフィック用の VPC に接続する] をクリアします。

    5. [デプロイ] をクリックします。

    6. サービスが VPC ネットワークに存在しなくなったことを確認するには、[ネットワーキング] タブをクリックします。ネットワークとサブネットが [VPC] カードに表示されなくなります。

  • サービスを VPC ネットワークに接続したまま、ネットワーク タグのみを削除するには:

    1. 削除するネットワーク タグを含むサービスをクリックし、[新しいリビジョンの編集とデプロイ] をクリックします。

    2. [ネットワーキング] タブをクリックします。

    3. サービスとの関連付けを解除したいネットワーク タグの名前をクリアします。

    4. [デプロイ] をクリックします。

gcloud

  • VPC ネットワークからサービスを削除するには、次のコマンドを実行します。

    gcloud beta run services update SERVICE_NAME --region=REGION \
--clear-network

  • VPC ネットワークに接続したままネットワーク タグのみを削除するには、次のコマンドを実行します。

    gcloud beta run services update SERVICE_NAME --region=REGION \
--clear-network-tags

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

    • SERVICE_NAME: Cloud Run サービスの名前。
    • REGION: Cloud Run サービスのリージョン。

YAML

  • VPC ネットワークからサービスを削除するには:

    1. service.yaml ファイルから次の内容を削除します。

      run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'

      ここで

      • NETWORK: VPC ネットワークの名前。
      • SUBNET: サブネットの名前。
      • （省略可）NETWORK_TAG_NAMES: サービスに関連付けられているネットワーク タグの名前。

    2. 次のコマンドを実行して、サービス リビジョンをデプロイします。

      gcloud run services replace service.yaml

  • サービスを VPC ネットワークに接続したまま、ネットワーク タグのみを削除するには:

    1. 次の例に示すように、service.yaml ファイルの内容から tags 変数を削除します。network 変数と subnetwork 変数はそのままにします。

      run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET"}]'

      ここで

      • NETWORK: VPC ネットワークの名前。
      • SUBNET: サブネットの名前。

    2. 次のコマンドを実行して、サービス リビジョンをデプロイします。

      gcloud run services replace service.yaml

ジョブを切断する

コンソール

  • VPC ネットワークからジョブを削除するには:

    1. Cloud Run に移動します。

    2. 削除するジョブをクリックし、[新しいリビジョンの編集とデプロイ] をクリックします。

    3. [接続] タブをクリックします。

    4. [アウトバウンド トラフィック用の VPC に接続する] をクリアします。

    5. [更新] をクリックします。

    6. ジョブが VPC ネットワークに存在しないことを確認するには、[構成] タブをクリックします。ネットワークとサブネットが [VPC] カードに表示されなくなります。

  • ジョブを VPC ネットワークに接続したまま、ネットワーク タグのみを削除するには:

    1. 削除するネットワーク タグを含むジョブをクリックし、[新しいリビジョンの編集とデプロイ] をクリックします。

    2. [接続] タブをクリックします。

    3. ジョブとの関連付けを解除したいネットワーク タグの名前をクリアします。

    4. [更新] をクリックします。

gcloud

  • VPC ネットワークからジョブを削除するには、次のコマンドを実行します。

    gcloud run jobs update JOB_NAME --region=REGION \
  --clear-network

  • ジョブを VPC ネットワークに接続したままネットワーク タグのみを削除するには、次のコマンドを実行します。

    gcloud run jobs update JOB_NAME --region=REGION \
  --clear-network-tags

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

    • JOB_NAME: Cloud Run ジョブの名前。
    • REGION: Cloud Run ジョブのリージョン。

YAML

  • VPC ネットワークからジョブを削除するには:

    1. job.yaml ファイルから次の内容を削除します。

      run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'

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

      • NETWORK: VPC ネットワークの名前。
      • SUBNET: サブネットの名前。
      • （省略可）NETWORK_TAG_NAMES: ジョブをネットワーク タグに関連付けている場合、ネットワーク タグの名前。

    2. 次のコマンドを実行して、ジョブを再デプロイします。

      gcloud run jobs replace job.yaml

  • ジョブを VPC ネットワークに接続したまま、ネットワーク タグのみを削除するには:

    1. 次の例に示すように、job.yaml ファイルの内容から tags 変数を削除します。network 変数と subnetwork 変数はそのままにします。

      run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET"}]'

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

      • NETWORK: VPC ネットワークの名前。
      • SUBNET: サブネットの名前。

    2. 次のコマンドを実行して、ジョブを再デプロイします。

      gcloud run jobs replace job.yaml

トラブルシューティング

サブネットを削除できない

サブネットを削除するには、そのサブネットを使用するすべてのリソースを先に削除する必要があります。Cloud Run がサブネットを使用している場合は、Cloud Run のサービスまたはジョブを VPC ネットワークから切断します。サブネットを削除する前に別のサブネットに移動することもできます。

ダイレクト VPC のサブネットで IP アドレスが不足する

VPC ネットワークのサブネットで IP アドレスが不足した場合、Cloud Logging によってログに記録されます。この場合、Cloud Run は追加の IP アドレスが利用可能になるまで、サービス インスタンスやジョブタスクを開始できません。

割り振られた IP アドレスを表示する

Cloud Run が割り振った IP アドレスを確認するには、Google Cloud コンソールの [IP アドレス] ページに移動するか、Google Cloud CLI から次のコマンドを実行します。

gcloud compute addresses list