このドキュメントでは、Cloud Storage バケットを使用して共有 VPC 環境でregional internal Application Load Balancer を設定するための 2 つのサンプル構成を示します。
- 最初の例では、1 つのサービス プロジェクトにロードバランサのすべてのコンポーネントとバックエンドを作成します。
- 2 番目の例では、ロードバランサのフロントエンド コンポーネントと URL マップを 1 つのサービス プロジェクト内に作成し、ロードバランサのバックエンド バケットと Cloud Storage バケットを別のサービス プロジェクト内に作成します。
どちらの例でも、ロードバランサの作成を開始する前に、同じ初期構成を使用して必要なロールを付与し、共有 VPC を設定する必要があります。
その他の有効な共有 VPC アーキテクチャの詳細については、共有 VPC アーキテクチャをご覧ください。
共有 VPC ネットワークを使用しない場合は、Cloud Storage バケットを使用して regional internal Application Load Balancer を設定するをご覧ください。
始める前に
設定が次の前提条件を満たしていることを確認します。
Google Cloud プロジェクトを作成する
1 つのホスト プロジェクトと 2 つのサービス プロジェクトの Google Cloud プロジェクトを作成します。
必要なロール
Cloud Storage バケットを含む共有 VPC 環境で regional internal Application Load Balancer を設定するために必要な権限を取得するには、次の IAM ロールを付与するよう管理者に依頼してください。
-
共有 VPC の設定、ホスト プロジェクトの有効化、サービス プロジェクト管理者へのアクセス権の付与: ホスト プロジェクトに対する Compute 共有 VPC 管理者 （
roles/compute.xpnAdmin） -
ファイアウォール ルールの追加と削除: ホスト プロジェクトに対する Compute セキュリティ管理者 （
roles/compute.securityAdmin） -
共有 VPC ネットワークを使用するためのサービス プロジェクト管理者へのアクセス権:
ホスト プロジェクトの Compute ネットワーク ユーザー （
roles/compute.networkUser） -
ロード バランシング リソースを作成する: サービス プロジェクトに対する Compute ネットワーク管理者 （
roles/compute.networkAdmin） -
Compute Engine インスタンスを作成する: サービス プロジェクトに対する Compute インスタンス管理者 （
roles/compute.instanceAdmin.v1） -
Compute Engine SSL 証明書を作成して変更する: サービス プロジェクトに対する Compute セキュリティ管理者 （
roles/compute.securityAdmin） -
サービス プロジェクトに対する Certificate Manager オーナー （
roles/certificatemanager.owner） Certificate Manager SSL 証明書の作成と変更 -
他のサービス プロジェクトからロードバランサがバックエンド バケットを参照できるようにする:
サービス プロジェクトに対する Compute ロードバランサ サービス ユーザー （
roles/compute.loadBalancerServiceUser）
ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。
必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。
共有 VPC 環境を設定する
共有 VPC 環境を設定するには、ホスト プロジェクトで次の操作を行います。
- ホスト プロジェクトで VPC ネットワークを構成する。
- ホスト プロジェクトでプロキシ専用サブネットを構成する。
- ホスト プロジェクトでファイアウォール ルールを構成する。
- ホスト プロジェクトで共有 VPC を設定する
このセクションの手順は、新しいロードバランサを作成するたびに行う必要はありません。ただし、ロードバランサの作成に進む前に、ここで説明するリソースにアクセスできることを確認する必要があります。
この例では、次の VPC ネットワーク、リージョン、プロキシ専用サブネットを使用します。
ネットワーク。ネットワークは、
lb-networkという名前のカスタムモード VPC ネットワークです。ロードバランサのサブネット。
us-east1リージョンのsubnet-usという名前のサブネットは、プライマリ IP 範囲として10.1.2.0/24を使用します。Envoy プロキシのサブネット。
us-east1リージョンのproxy-only-subnet-usという名前のサブネットは、プライマリ IP 範囲として10.129.0.0/23を使用します。
ホスト プロジェクトの VPC を構成する
ホスト プロジェクトにカスタムモード VPC を構成し、ロードバランサの転送ルールを構成する必要があるリージョンにサブネットを作成します。
この手順は、新しいロードバランサを作成するたびに行う必要はありません。サービス プロジェクトが、プロキシ専用サブネットだけでなく、共有 VPC ネットワーク内のサブネットにもアクセスできることだけを確認する必要があります。
コンソール
Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。
[VPC ネットワークを作成] をクリックします。
[名前] フィールドに「
lb-network」と入力します。[サブネット作成モード] で [カスタム] を選択します。
[新しいサブネット] セクションで、次の情報を入力します。
- [名前] フィールドに「
subnet-us」と入力します。 - [リージョン] リストで [
us-east1] を選択します。 - [IPv4 範囲] フィールドに「
10.1.2.0/24」と入力します。 - [完了] をクリックします。
- [名前] フィールドに「
[作成] をクリックします。
gcloud
gcloud compute networks createコマンドを使用して、lb-networkというカスタム VPC ネットワークを作成します。gcloud compute networks create lb-network \ --subnet-mode=custom \ --project=HOST_PROJECT_IDHOST_PROJECT_IDは、共有 VPC 環境でホスト プロジェクトとして有効になっているプロジェクトに割り当てられたGoogle Cloud プロジェクト ID に置き換えます。gcloud compute networks subnets createコマンドを使用して、us-east1リージョンのlb-networkVPC ネットワークにサブネットを作成します。gcloud compute networks subnets create subnet-us \ --network=lb-network \ --range=10.1.2.0/24 \ --region=us-east1 \ --project=HOST_PROJECT_ID
ホスト プロジェクトでプロキシ専用サブネットを構成する
プロキシ専用サブネットには、 Google Cloud がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスが用意されています。このプロキシは、クライアントからの接続を終端し、バックエンドへの新しい接続を作成します。
このプロキシ専用サブネットは、VPC ネットワークと同じリージョン内のすべての Envoy ベースのロードバランサで使用されます。特定の目的では、リージョンごと、ネットワークごとにアクティブなプロキシ専用サブネットが 1 つだけの場合があります。この例では、us-east1 リージョンにプロキシ専用サブネットを作成します。
コンソール
Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。
作成した VPC ネットワークの名前をクリックします。
[サブネット] タブで [サブネットを追加] をクリックし、次の情報を入力します。
- [名前] フィールドに「
proxy-only-subnet-us」と入力します。 - [リージョン] リストで [
us-east1] を選択します。 - [目的] で、[Regional Managed Proxy] を選択します。
- [IPv4 範囲] フィールドに「
10.129.0.0/23」と入力します。
- [名前] フィールドに「
[追加] をクリックします。
gcloud
gcloud compute networks subnets createコマンドを使用して、us-east1リージョンにプロキシ専用サブネットを作成します。gcloud compute networks subnets create proxy-only-subnet-us \ --purpose=REGIONAL_MANAGED_PROXY \ --role=ACTIVE \ --region=us-east1 \ --network=lb-network \ --range=10.129.0.0/23 \ --project=HOST_PROJECT_ID
ホスト プロジェクトでファイアウォール ルールを構成する
この例では、任意のアドレスから TCP ポート 22 への SSH 受信接続を許可する fw-allow-ssh 上り（内向き）ファイアウォール ルールを使用します。このルールには、送信元の IP 範囲をより限定的に指定できます。たとえば、SSH セッションを開始するシステムの IP 範囲のみを指定できます。この例では、ターゲットタグ allow-ssh を使用して、ファイアウォール ルールが適用される仮想マシン（VM）を識別します。これらのファイアウォール ルールがない場合は、デフォルトの上り（内向き）拒否ルールによってバックエンド インスタンスへの受信トラフィックがブロックされます。
コンソール
Google Cloud コンソールで、[ファイアウォール ポリシー] ページに移動します。
[ファイアウォール ルールを作成] をクリックして、Google Cloud ヘルスチェックを許可するルールを作成します。
次の情報をお知らせください。
- [名前] フィールドに「
fw-allow-ssh」と入力します。 - [ネットワーク] リストで、[lb-network] を選択します。
- [トラフィックの方向] で [上り（内向き）] をオンにします。
- [一致したときのアクション] で [許可] をオンにします。
- [ターゲット] リストで、[指定されたターゲットタグ] を選択します。
- [ターゲットタグ] フィールドに「
allow-ssh」と入力します。 - [ソースフィルタ] リストで、[IPv4 範囲] を選択します。
- [送信元 IPv4 範囲] フィールドに「
0.0.0.0/0」と入力します。 - [プロトコルとポート] で [指定したプロトコルとポート] をオンにします。
- [TCP] チェックボックスをオンにして、ポート番号に「
22」と入力します。
- [名前] フィールドに「
[作成] をクリックします。
gcloud
ネットワーク タグ
allow-sshを使用して、VM との SSH 接続を許可するfw-allow-sshファイアウォール ルールを作成します。source-rangesを省略すると、Google Cloud は任意の送信元としてルールを解釈します。gcloud compute firewall-rules create fw-allow-ssh \ --network=lb-network \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22 \ --project=HOST_PROJECT_ID
ホスト プロジェクトで共有 VPC を設定する
共有 VPC ホスト プロジェクトを有効にして、サービス プロジェクトをホスト プロジェクトに接続し、サービス プロジェクトで共有 VPC ネットワークを使用できるようにします。ホスト プロジェクトに共有 VPC を設定するには、次のページをご覧ください。
上記の手順を完了したら、次のいずれかの設定を行います。
サービス プロジェクトでロードバランサを構成する
この例では、すべてのロード バランシング コンポーネント（転送ルール、ターゲット プロキシ、URL マップ、バックエンド バケット）と Cloud Storage バケットがサービス プロジェクト内に作成される regional internal Application Load Balancer を作成します。
regional internal Application Load Balancerのネットワーク リソース（プロキシ専用サブネットなど）は、ホスト プロジェクトに作成されます。
このセクションでは、ロードバランサとバックエンドを設定する方法について説明します。
このページの例では、エフェメラル IP アドレスの割り振りを許可せずに、 regional internal Application Load Balancerの転送ルールに予約済み IP アドレスを明示的に設定しています。転送ルールの IP アドレスは予約しておくことをおすすめします。
Cloud Storage バケットを構成する
Cloud Storage バケットを構成するプロセスは次のとおりです。
- Cloud Storage バケットを作成します。
- コンテンツをバケットにコピーします。
- バケットを公開します。
Cloud Storage バケットを作成する
この例では、us-east1 リージョンに 2 つの Cloud Storage バケットを作成します。
コンソール
- Google Cloud コンソールで Cloud Storage の [バケット] ページに移動します。
[作成] をクリックします。
[始める] セクションに、命名ガイドラインに沿ったグローバルに一意の名前を入力します。
[データの保存場所の選択] をクリックします。
[ロケーション タイプ] を [リージョン] に設定します。
リージョンのリストから [us-east1] を選択します。
[作成] をクリックします。
[バケット] をクリックして、Cloud Storage バケットのページに戻ります。上記の手順に沿って、us-east1 リージョンに 2 番目のバケットを作成します。
gcloud
gcloud storage buckets createコマンドを使用して、us-east1リージョンにバケットを作成します。gcloud storage buckets create gs://BUCKET1_NAME \ --default-storage-class=standard \ --location=us-east1 \ --uniform-bucket-level-access \ --project=SERVICE_PROJECT_ID
gcloud storage buckets create gs://BUCKET2_NAME \ --default-storage-class=standard \ --location=us-east1 \ --uniform-bucket-level-access \ --project=SERVICE_PROJECT_ID次のように置き換えます。
BUCKET1_NAME: 最初の Cloud Storage バケットの名前BUCKET2_NAME: 2 番目の Cloud Storage バケットの名前SERVICE_PROJECT_ID: サービス プロジェクトに割り当てられた Google Cloud プロジェクト ID
Cloud Storage バケットにコンテンツをコピーする
Cloud Storage バケットにデータを入力するには、Cloud Storage の公開バケットから独自の Cloud Storage バケットにグラフィック ファイルをコピーします。
gcloud storage cp gs://gcp-external-http-lb-with-bucket/three-cats.jpg gs://BUCKET1_NAME/love-to-purr/
gcloud storage cp gs://gcp-external-http-lb-with-bucket/two-dogs.jpg gs://BUCKET2_NAME/love-to-fetch/
Cloud Storage バケットを公開する
公共のインターネット上のすべてのユーザーがバケット内のすべてのオブジェクトを閲覧できるようにするには、プリンシパル allUsers に Storage オブジェクト閲覧者（roles/storage.objectViewer）のロールを付与します。
コンソール
バケット内のすべてのオブジェクトに対するアクセス権をすべてのユーザーに付与するには、バケットごとに次の手順を繰り返します。
- Google Cloud コンソールで Cloud Storage の [バケット] ページに移動します。
バケットのリストで、公開する各バケットのチェックボックスをオンにします。
[権限] ボタンをクリックします。[権限] ダイアログが表示されます。
[権限] ダイアログで、 [プリンシパルを追加] ボタンをクリックします。[アクセスを許可] ダイアログが表示されます。
[新しいプリンシパル] フィールドに「
allUsers」と入力します。[ロールを選択] フィールドで、フィルタ ボックスに「
Storage Object Viewer」と入力し、フィルタされた結果から [Storage オブジェクト閲覧者] を選択します。[保存] をクリックします。
[一般公開アクセスを許可] をクリックします。
gcloud
バケット内のオブジェクトを表示する権限をすべてのユーザーに付与するには、buckets add-iam-policy-binding コマンドを実行します。
gcloud storage buckets add-iam-policy-binding gs://BUCKET1_NAME \
--member=allUsers \
--role=roles/storage.objectViewer
gcloud storage buckets add-iam-policy-binding gs://BUCKET2_NAME \
--member=allUsers \
--role=roles/storage.objectViewer
静的内部 IP アドレスの予約
ロードバランサの転送ルールに静的内部 IP アドレスを予約します。詳細については、静的内部 IP アドレスを予約するをご覧ください。
コンソール
Google Cloud コンソールで、[内部静的 IP アドレスの予約] ページに移動します。
[名前] フィールドに、新しいアドレスの名前を入力します。
[IP バージョン] リストで、[IPv4] を選択します。
[ネットワーク] リストで、[lb-network] を選択します。
[サブネットワーク] リストで、[subnet-us] を選択します。
[リージョン] で [us-east1] を選択します。
[静的 IP アドレス] リストで、[自動的に割り当てる] を選択します。ロードバランサを作成すると、この IP アドレスがロードバランサの転送ルールに関連付けられます。
[予約] をクリックして IP アドレスを予約します。
gcloud
gcloud computeを使用して静的内部 IP アドレスを予約するには、compute addresses createコマンドを使用します。gcloud compute addresses create ADDRESS_NAME \ --region=REGION \ --subnet=subnet-us \ --project=SERVICE_PROJECT_ID次のように置き換えます。
ADDRESS_NAME: このアドレスに付ける名前。REGION: このアドレスを予約するリージョン。このリージョンは、ロードバランサと同じリージョンにする必要があります。例:us-east1SERVICE_PROJECT_ID: サービス プロジェクトに割り当てられた Google Cloudプロジェクト ID。
結果を表示するには、
compute addresses describeコマンドを使用します。gcloud compute addresses describe ADDRESS_NAME
返された IP アドレスをコピーして、以降のセクションで
RESERVED_IP_ADDRESSとして使用します。
SSL 証明書リソースを設定する
リクエスト レスポンス プロトコルとして HTTPS を使用する regional internal Application Load Balancer の場合は、Compute Engine SSL 証明書または Certificate Manager 証明書を使用して SSL 証明書リソースを作成できます。
この例では、次のいずれかのドキュメントの説明に沿って Certificate Manager を使用して SSL 証明書リソースを作成します。
- CA Service を使用してリージョン Google マネージド証明書をデプロイする
- DNS 認証を使用して、リージョン Google マネージド証明書をデプロイする
- リージョン セルフマネージド証明書をデプロイする
証明書を作成したら、証明書を HTTPS ターゲット プロキシに関連付けることができます。
Google マネージド証明書を使用すると、手動による証明書管理に関連するセキュリティ リスクなどの運用オーバーヘッドを削減できるため、Google マネージド証明書を使用することをおすすめします。
バックエンド バケットを使用してロードバランサを構成する
このセクションでは、regional internal Application Load Balancerに次のリソースを作成する方法について説明します。
- 2 つのバックエンド バケット。バックエンド バケットは、前に作成した Cloud Storage バケットのラッパーとして機能します。
- URL マップ
- ターゲット プロキシ
- リージョン IP アドレスを持つ転送ルール。転送ルールには、ロードバランサの転送ルール用に作成されたサブネットの IP アドレスが割り当てられます。プロキシ専用サブネットから転送ルールに IP アドレスを割り当てると、転送ルールの作成に失敗します。
この例では、クライアントとロードバランサの間のリクエスト レスポンス プロトコルとして HTTP または HTTPS を使用できます。HTTPS ロードバランサを作成するには、ロードバランサのフロントエンドに SSL 証明書リソースを追加する必要があります。
gcloud CLI を使用して前述のロード バランシング コンポーネントを作成するには、次の操作を行います。
gcloud beta compute backend-buckets createコマンドを使用して、us-east1リージョンに 2 つのバックエンド バケットを作成します。バックエンド バケットのロード バランシング スキームはINTERNAL_MANAGEDです。gcloud beta compute backend-buckets create backend-bucket-cats \ --gcs-bucket-name=BUCKET1_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --region=us-east1 \ --project=SERVICE_PROJECT_IDgcloud beta compute backend-buckets create backend-bucket-dogs \ --gcs-bucket-name=BUCKET2_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --region=us-east1 --project=SERVICE_PROJECT_IDgcloud beta compute url-maps createコマンドを使用して、受信リクエストをバックエンド バケットに転送する URL マップを作成します。gcloud beta compute url-maps create URL_MAP_NAME \ --default-backend-bucket=backend-bucket-cats \ --region=us-east1 \ --project=SERVICE_PROJECT_IDURL_MAP_NAMEは、URL マップの名前に置き換えます。gcloud beta compute url-maps add-path-matcherコマンドを使用して、URL マップのホストルールとパスルールを構成します。この例では、デフォルトのバックエンド バケットは
backend-bucket-catsで、このバケット内に存在するすべてのパスを処理します。ただし、http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpgをターゲットとするリクエストはbackend-bucket-dogsバックエンドを使用します。たとえば、/love-to-fetch/フォルダがデフォルト バックエンド（backend-bucket-cats）にも存在する場合、/love-to-fetch/*に特定のパスルールがあるため、ロードバランサはbackend-bucket-dogsバックエンドの優先度を上げます。gcloud beta compute url-maps add-path-matcher URL_MAP_NAME \ --path-matcher-name=path-matcher-pets \ --new-hosts=* \ --backend-bucket-path-rules="/love-to-fetch/*=backend-bucket-dogs" \ --default-backend-bucket=backend-bucket-cats \ --region=us-east1 \ --project=SERVICE_PROJECT_IDgcloud compute target-http-proxies createコマンドを使用して、ターゲット プロキシを作成します。HTTP
HTTP トラフィックの場合、リクエストを URL マップに転送するターゲット HTTP プロキシを作成します。
gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \ --url-map=URL_MAP_NAME \ --region=us-east1 \ --project=SERVICE_PROJECT_IDTARGET_HTTP_PROXY_NAMEは、ターゲット HTTP プロキシの名前に置き換えます。HTTPS
HTTPS トラフィックの場合は、リクエストを URL マップに転送するターゲット HTTPS プロキシを作成します。プロキシは、HTTPS ロードバランサの SSL 証明書を保持するロードバランサの一部です。証明書を作成したら、証明書を HTTPS ターゲット プロキシに関連付けることができます。
Certificate Manager 証明書を関連付けるには、次のコマンドを実行します。
gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \ --url-map=URL_MAP_NAME \ --certificate-manager-certificates=CERTIFICATE_NAME \ --region=us-east1 \ --project=SERVICE_PROJECT_ID次のように置き換えます。
TARGET_HTTPS_PROXY_NAME: ターゲット HTTPS プロキシの名前CERTIFICATE_NAME: Certificate Manager を使用して作成した SSL 証明書の名前
gcloud compute forwarding-rules createコマンドを使用して、us-east1リージョンの IP アドレスを持つ転送ルールを作成します。IP アドレスの予約は HTTP 転送ルールでは省略可能ですが、HTTPS 転送ルールでは IP アドレスを予約する必要があります。
この例では、エフェメラル IP アドレスがロードバランサの HTTP 転送ルールに関連付けられています。転送ルールが存在している間は、エフェメラル IP アドレスは変わりません。転送ルールを削除して再作成する必要がある場合は、転送ルールに新しい IP アドレスが割り当てられることがあります。
HTTP
HTTP トラフィックの場合、受信リクエストを HTTP ターゲット プロキシに転送するリージョン転送ルールを作成します。
gcloud compute forwarding-rules create FORWARDING_RULE_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=projects/HOST_PROJECT_ID/global/networks/lb-network \ --subnet=subnet-us \ --subnet-region=us-east1 \ --address=RESERVED_IP_ADDRESS --ports=80 \ --region=us-east1 \ --target-http-proxy=TARGET_HTTP_PROXY_NAME \ --target-http-proxy-region=us-east1 \ --project=SERVICE_PROJECT_ID次のように置き換えます。
FORWARDING_RULE_NAME: 転送ルールの名前RESERVED_IP_ADDRESS: 静的内部 IP アドレスを予約するセクションでコピーした予約済み IP アドレス
HTTPS
HTTPS トラフィックの場合は、受信リクエストを HTTPS ターゲット プロキシに転送するリージョン転送ルールを作成します。
gcloud compute forwarding-rules create FORWARDING_RULE_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=projects/HOST_PROJECT_ID/global/networks/lb-network \ --subnet=subnet-us \ --subnet-region=us-east1 \ --address=RESERVED_IP_ADDRESS \ --ports=443 \ --region=us-east1 \ --target-https-proxy=TARGET_HTTPS_PROXY_NAME \ --target-https-proxy-region=us-east1 \ --project=SERVICE_PROJECT_ID次のように置き換えます。
FORWARDING_RULE_NAME: 転送ルールの名前RESERVED_IP_ADDRESS: 静的内部 IP アドレスを予約するセクションでコピーした予約済み IP アドレス
ロードバランサに HTTP リクエストを送信する
ロード バランシング サービスが実行されたので、内部クライアント VM からロードバランサの転送ルールにリクエストを送信します。
us-east1リージョンにあるロードバランサの転送ルールの IP アドレスを取得します。gcloud compute forwarding-rules describe FORWARDING_RULE_NAME \ --region=us-east1 \ --project=SERVICE_PROJECT_ID返された IP アドレスをコピーして、
FORWARDING_RULE_IP_ADDRESSとして使用します。us-east1リージョンにクライアント VM を作成します。gcloud compute instances create client-a \ --image-family=debian-12 \ --image-project=debian-cloud \ --network=lb-network \ --subnet=subnet-us \ --zone=us-east1-c \ --tags=allow-sshクライアント VM への SSH 接続を確立します。
gcloud compute ssh client-a --zone=us-east1-c
この例では、 regional internal Application Load Balancer には VPC ネットワークの
us-east1リージョンにフロントエンド仮想 IP アドレス（VIP）があります。curl を使用して、そのリージョンの VIP に HTTP リクエストを送信します。curl http://FORWARDING_RULE_IP_ADDRESS/love-to-purr/three-cats.jpg --output three-cats.jpg
curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg
FORWARDING_RULE_IP_ADDRESSは、最初の手順でコピーした IP アドレスに置き換えます。
クロス プロジェクト構成を使用してロードバランサを構成する
このページの前の例では、すべてのロードバランサ コンポーネントとそのバックエンドがサービス プロジェクト内に作成される共有 VPC デプロイを設定しました。
リージョン内部アプリケーション ロードバランサでは、1 つのホストまたはサービス プロジェクトの URL マップが、共有 VPC 環境の複数のサービス プロジェクトにまたがるバックエンド バケットを参照できる共有 VPC デプロイを構成することもできます。
このセクションの手順では、サポートされている以下のいずれかの組み合わせを構成できます。
- ホスト プロジェクトの転送ルール、ターゲット プロキシ、URL マップ、1 つのサービス プロジェクトのバックエンド バケット
- サービス プロジェクトの転送ルール、ターゲット プロキシ、URL マップ、別のサービス プロジェクトのバックエンド バケット
このセクションでは、後者の構成を例として説明します。
設定の概要
この例では、フロントエンドとバックエンドが別のサービス プロジェクトに存在するロードバランサを構成します。
共有 VPC を設定して、この例のネットワーク、サブネット、ファイアウォール ルールを構成するための前提条件をすべて満たす必要があります。まだ行っていない場合は、必要な手順を完了してください。手順については、このページの次のセクションをご覧ください。
サービス プロジェクト B で Cloud Storage バケットとバックエンド バケットを構成する
このセクションの手順はすべて、サービス プロジェクト B で行う必要があります。
バックエンド バケットを作成するには、次の操作を行う必要があります。
- Cloud Storage バケットを作成します。
- コンテンツをバケットにコピーします。
- バケットを公開します。
- バックエンド バケットを作成し、Cloud Storage バケットを参照するようにします。
Cloud Storage バケットを作成する
この例では、Cloud Storage バケットを us-east1 リージョンに作成します。
コンソール
- Google Cloud コンソールで Cloud Storage の [バケット] ページに移動します。
[作成] をクリックします。
[始める] セクションに、命名ガイドラインに沿ったグローバルに一意の名前を入力します。
[データの保存場所の選択] をクリックします。
[ロケーション タイプ] を [リージョン] に設定します。
リージョンのリストから [us-east1] を選択します。
[作成] をクリックします。
[バケット] をクリックして、Cloud Storage バケットのページに戻ります。上記の手順に沿って、us-east1 リージョンに 2 番目のバケットを作成します。
gcloud
gcloud storage buckets create コマンドを使用して、us-east1 リージョンにバケットを作成します。
gcloud storage buckets create gs://BUCKET1_NAME \
--default-storage-class=standard \
--location=us-east1 \
--uniform-bucket-level-access \
--project=SERVICE_PROJECT_B_ID
gcloud storage buckets create gs://BUCKET2_NAME \
--default-storage-class=standard \
--location=us-east1 \
--uniform-bucket-level-access \
--project=SERVICE_PROJECT_B_ID
次のように置き換えます。
BUCKET1_NAME: 最初の Cloud Storage バケットの名前BUCKET2_NAME: 2 番目の Cloud Storage バケットの名前SERVICE_PROJECT_B_ID: サービス プロジェクト B に割り当てられた Google Cloud プロジェクト ID
グラフィック ファイルを Cloud Storage バケットにコピーする
設定をテストするには、Cloud Storage の公開バケットから独自の Cloud Storage バケットにグラフィック ファイルをコピーします。
gcloud storage cp gs://gcp-external-http-lb-with-bucket/three-cats.jpg gs://BUCKET1_NAME/love-to-purr/
gcloud storage cp gs://gcp-external-http-lb-with-bucket/two-dogs.jpg gs://BUCKET2_NAME/love-to-fetch/
Cloud Storage バケットを公開する
公共のインターネット上のすべてのユーザーがバケット内のすべてのオブジェクトを閲覧できるようにするには、プリンシパル allUsers に Storage オブジェクト閲覧者（roles/storage.objectViewer）のロールを付与します。
コンソール
バケット内のすべてのオブジェクトに対するアクセス権をすべてのユーザーに付与するには、バケットごとに次の手順を繰り返します。
- Google Cloud コンソールで Cloud Storage の [バケット] ページに移動します。
バケットのリストで、公開する各バケットのチェックボックスをオンにします。
[権限] ボタンをクリックします。[権限] ダイアログが表示されます。
[権限] ダイアログで、 [プリンシパルを追加] ボタンをクリックします。[アクセスを許可] ダイアログが表示されます。
[新しいプリンシパル] フィールドに「
allUsers」と入力します。[ロールを選択] フィールドで、フィルタ ボックスに「
Storage Object Viewer」と入力し、フィルタされた結果から [Storage オブジェクト閲覧者] を選択します。[保存] をクリックします。
[一般公開アクセスを許可] をクリックします。
gcloud
バケット内のオブジェクトを表示する権限をすべてのユーザーに付与するには、buckets add-iam-policy-binding コマンドを実行します。
gcloud storage buckets add-iam-policy-binding gs://BUCKET1_NAME \
--member=allUsers \
--role=roles/storage.objectViewer
gcloud storage buckets add-iam-policy-binding gs://BUCKET2_NAME \
--member=allUsers \
--role=roles/storage.objectViewer
バックエンド バケットを使用してロードバランサを構成する
バックエンド バケットを作成する手順は次のとおりです。
gcloud beta compute backend-buckets createコマンドを使用して、us-east1リージョンに 2 つのバックエンド バケットを作成します。バックエンド バケットのロード バランシング スキームはINTERNAL_MANAGEDです。gcloud beta compute backend-buckets create backend-bucket-cats \ --gcs-bucket-name=BUCKET1_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --region=us-east1 \ --project=SERVICE_PROJECT_B_IDgcloud beta compute backend-buckets create backend-bucket-dogs \ --gcs-bucket-name=BUCKET2_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --region=us-east1 --project=SERVICE_PROJECT_B_ID
サービス プロジェクト A でロードバランサのフロントエンド コンポーネントを構成する
このセクションの手順はすべて、サービス プロジェクト A で行う必要があります。
サービス プロジェクト A で、次のフロントエンド ロード バランシング コンポーネントを作成します。
- ターゲット プロキシに接続されている SSL 証明書リソースを設定します。詳細については、このドキュメントの SSL 証明書リソースを設定するをご覧ください。
- ロードバランサの転送ルール用に静的内部 IP アドレスを作成して予約します。詳細については、このドキュメントの静的内部 IP アドレスを予約する をご覧ください。
gcloud beta compute url-maps createコマンドを使用して、受信リクエストをサービス プロジェクト B のバックエンド バケットに転送する URL マップを作成します。gcloud beta compute url-maps create URL_MAP_NAME \ --default-backend-bucket=backend-bucket-cats \ --region=us-east1 \ --project=SERVICE_PROJECT_A_ID次のように置き換えます。
URL_MAP_NAME: URL マップの名前SERVICE_PROJECT_A_ID: サービス プロジェクト A に割り当てられた Google Cloudプロジェクト ID
gcloud beta compute url-maps add-path-matcherコマンドを使用して、URL マップのホストルールとパスルールを構成します。この例では、デフォルトのバックエンド バケットは
backend-bucket-catsで、このバケット内に存在するすべてのパスを処理します。ただし、http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpgをターゲットとするリクエストはbackend-bucket-dogsバックエンドを使用します。たとえば、/love-to-fetch/フォルダがデフォルト バックエンド（backend-bucket-cats）にも存在する場合、/love-to-fetch/*に特定のパスルールがあるため、ロードバランサはbackend-bucket-dogsバックエンドの優先度を上げます。gcloud beta compute url-maps add-path-matcher URL_MAP_NAME \ --path-matcher-name=path-matcher-pets \ --new-hosts=* \ --backend-bucket-path-rules="/love-to-fetch/*=projects/SERVICE_PROJECT_B_ID/regional/backendBuckets/backend-bucket-dogs" \ --default-backend-bucket=projects/SERVICE_PROJECT_B_ID/regional/backendBuckets/backend-bucket-cats \ --region=us-east1 --project=SERVICE_PROJECT_A_IDgcloud compute target-http-proxies createコマンドを使用して、ターゲット プロキシを作成します。HTTP
HTTP トラフィックの場合、リクエストを URL マップに転送するターゲット HTTP プロキシを作成します。
gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \ --url-map=URL_MAP_NAME \ --region=us-east1 \ --project=SERVICE_PROJECT_A_IDTARGET_HTTP_PROXY_NAMEは、ターゲット HTTP プロキシの名前に置き換えます。HTTPS
HTTPS トラフィックの場合は、リクエストを URL マップに転送するターゲット HTTPS プロキシを作成します。プロキシは、HTTPS ロードバランサの SSL 証明書を保持するロードバランサの一部です。証明書を作成したら、証明書を HTTPS ターゲット プロキシに関連付けることができます。
Certificate Manager 証明書を関連付けるには、次のコマンドを実行します。
gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \ --url-map=lb-map \ --certificate-manager-certificates=CERTIFICATE_NAME \ --region=us-east1 \ --project=SERVICE_PROJECT_A_ID次のように置き換えます。
TARGET_HTTPS_PROXY_NAME: ターゲット HTTPS プロキシの名前CERTIFICATE_NAME: Certificate Manager を使用して作成した SSL 証明書の名前。
gcloud compute forwarding-rules createコマンドを使用して、us-east1リージョンの IP アドレスを持つ転送ルールを作成します。IP アドレスの予約は HTTP 転送ルールでは省略可能ですが、HTTPS 転送ルールでは IP アドレスを予約する必要があります。
この例では、エフェメラル IP アドレスがロードバランサの HTTP 転送ルールに関連付けられています。転送ルールが存在している間は、エフェメラル IP アドレスは変わりません。転送ルールを削除して再作成する必要がある場合は、転送ルールに新しい IP アドレスが割り当てられることがあります。
HTTP
HTTP トラフィックの場合、受信リクエストを HTTP ターゲット プロキシに転送するリージョン転送ルールを作成します。
gcloud compute forwarding-rules create FORWARDING_RULE_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=projects/HOST_PROJECT_ID/global/networks/lb-network \ --subnet=subnet-us \ --address=RESERVED_IP_ADDRESS --ports=80 \ --region=us-east1 \ --target-http-proxy=TARGET_HTTP_PROXY_NAME \ --target-http-proxy-region=us-east1 \ --project=SERVICE_PROJECT_A_ID次のように置き換えます。
FORWARDING_RULE_NAME: 転送ルールの名前RESERVED_IP_ADDRESS: 予約済みの IP アドレス
HTTPS
HTTPS トラフィックの場合は、受信リクエストを HTTPS ターゲット プロキシに転送するリージョン転送ルールを作成します。
gcloud compute forwarding-rules create FORWARDING_RULE_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=projects/HOST_PROJECT_ID/global/networks/lb-network \ --subnet=subnet-us \ --address=RESERVED_IP_ADDRESS \ --ports=443 \ --region=us-east1 \ --target-https-proxy=TARGET_HTTPS_PROXY_NAME \ --target-https-proxy-region=us-east1 \ --project=SERVICE_PROJECT_A_ID次のように置き換えます。
FORWARDING_RULE_NAME: 転送ルールの名前RESERVED_IP_ADDRESS: 予約済みの IP アドレス
バックエンド バケットを使用する権限を Compute ロードバランサ管理者に付与する
ロードバランサが他のサービス プロジェクトのバックエンド バケットを参照するには、ロードバランサ管理者に compute.backendBuckets.use 権限が必要です。この権限を付与するには、Compute ロードバランサ サービス ユーザー（roles/compute.loadBalancerServiceUser）という IAM 事前定義ロールを使用します。このロールは、サービス プロジェクト管理者が付与する必要があり、サービス プロジェクト レベルまたは個々のバックエンド バケット レベルで適用できます。
この例では、サービス プロジェクト B のサービス プロジェクト管理者は、次のいずれかのコマンドを実行して、サービス プロジェクト A のロードバランサ管理者に compute.backendBuckets.use 権限を付与する必要があります。これは、プロジェクト レベルで（プロジェクト内のすべてのバックエンド バケットの場合）、またはバックエンド バケットごとに行うことができます。
コンソール
プロジェクト レベルの権限
プロジェクト内のすべてのバックエンド バケットに権限を付与するには、次の操作を行います。
この手順を完了するには、compute.regionBackendBuckets.setIamPolicy 権限と resourcemanager.projects.setIamPolicy 権限が必要です。
Google Cloud コンソールで、[IAM] ページに移動します。
プロジェクトを選択します。
[アクセスを許可] をクリックします。
[新しいプリンシパル] フィールドに、プリンシパルのメールアドレスまたはその他の ID を入力します。
[ロールを割り当てる] セクションで、[ロールを追加] をクリックします。
[ロールを選択] ダイアログの [ロールを検索] フィールドに「
Compute Load Balancer Services User」と入力します。[Compute ロードバランサ サービス ユーザー] チェックボックスをオンにします。
[適用] をクリックします。
（省略可）ロールに条件を追加します。
[保存] をクリックします。
個々のバックエンド バケットのリソースレベルの権限
プロジェクト内の個々のバックエンド バケットに権限を付与するには、次の操作を行います。
この手順を完了するには、compute.regionBackendBuckets.setIamPolicy 権限が必要です。
Google Cloud コンソールで、[バックエンド] ページに移動します。
バックエンドのリストから、アクセス権を付与するバックエンド バケットを選択し、[権限] をクリックします。
[プリンシパルを追加] をクリックします。
[新しいプリンシパル] フィールドに、プリンシパルのメールアドレスまたはその他の ID を入力します。
[ロールを選択] リストで、[Compute ロードバランサ サービス ユーザー] を選択します。
[保存] をクリックします。
gcloud
プロジェクト レベルの権限
プロジェクト内のすべてのバックエンド バケットに権限を付与するには、次の操作を行います。
この手順を完了するには、compute.regionBackendBuckets.setIamPolicy 権限と resourcemanager.projects.setIamPolicy 権限が必要です。
gcloud projects add-iam-policy-binding SERVICE_PROJECT_B_ID \
--member="user:LOAD_BALANCER_ADMIN" \
--role="roles/compute.loadBalancerServiceUser"
次のように置き換えます。
SERVICE_PROJECT_B_ID: サービス プロジェクト B に割り当てられた Google Cloudプロジェクト IDLOAD_BALANCER_ADMIN: バインディングを追加するプリンシパル
個々のバックエンド バケットのリソースレベルの権限
バックエンド バケット レベルでは、サービス プロジェクト管理者が次のいずれかのコマンドを使用して Compute ロードバランサ サービス ユーザー ロール（roles/compute.loadBalancerServiceUser）を付与します。
gcloud projects add-iam-policy-bindingコマンドgcloud compute backend-buckets add-iam-policy-bindingコマンド
gcloud projects add-iam-policy-binding コマンドを使用して、Compute ロードバランサ サービス ユーザーのロールを付与します。
この手順を完了するには、compute.regionBackendBuckets.setIamPolicy 権限が必要です。
gcloud projects add-iam-policy-binding SERVICE_PROJECT_B_ID \
--member="user:LOAD_BALANCER_ADMIN" \
--role="roles/compute.loadBalancerServiceUser" \
--condition='expression=resource.name=="projects/SERVICE_PROJECT_B_ID/regions/REGION/backendBuckets/BACKEND_BUCKET_NAME",title=Shared VPC condition'
SERVICE_PROJECT_B_ID: サービス プロジェクト B に割り当てられた Google Cloudプロジェクト IDLOAD_BALANCER_ADMIN: バインディングを追加するプリンシパルREGION: バックエンド バケットが配置されている Google Cloud リージョンBACKEND_BUCKET_NAME: バックエンド バケットの名前
gcloud compute backend-buckets add-iam-policy-binding コマンドを使用して、Compute ロードバランサ サービス ユーザーのロールを付与します。
gcloud compute backend-buckets add-iam-policy-binding BACKEND_BUCKET_NAME \
--member="user:LOAD_BALANCER_ADMIN" \
--role="roles/compute.loadBalancerServiceUser" \
--project=SERVICE_PROJECT_B_ID \
--region=REGION
ロードバランサに HTTP リクエストを送信する
ロード バランシング サービスが実行されたので、内部クライアント VM からロードバランサの転送ルールにリクエストを送信します。
us-east1リージョンにあるロードバランサの転送ルールの IP アドレスを取得します。gcloud compute forwarding-rules describe FORWARDING_RULE_NAME \ --region=us-east1 \ --project=SERVICE_PROJECT_A_ID返された IP アドレスをコピーして、
FORWARDING_RULE_IP_ADDRESSとして使用します。us-east1リージョンにクライアント VM を作成します。gcloud compute instances create client-a \ --image-family=debian-12 \ --image-project=debian-cloud \ --network=lb-network \ --subnet=subnet-us \ --zone=us-east1-c \ --tags=allow-sshクライアント VM への SSH 接続を確立します。
gcloud compute ssh client-a --zone=us-east1-c
この例では、 regional internal Application Load Balancer には VPC ネットワークの
us-east1リージョンにフロントエンド VIP があります。curl を使用して、そのリージョンの VIP に HTTP リクエストを送信します。curl http://FORWARDING_RULE_IP_ADDRESS/love-to-purr/three-cats.jpg --output three-cats.jpg
curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg
FORWARDING_RULE_IP_ADDRESSは、最初の手順でコピーした IP アドレスに置き換えます。