内部 HTTP(S) ロードバランサで HTTP から HTTPS へのリダイレクトを設定する

この例では、ポート 80 へのすべてのリクエストがそれぞれの HTTPS サービスにリダイレクトされる方法を示しています。

外部負荷分散に HTTP から HTTPS へのリダイレクトを設定する方法については、外部 HTTP(S) ロードバランサの HTTP から HTTPS へのリダイレクトを設定するをご覧ください。

HTTP から HTTPS へのリダイレクトを共有 IP アドレスで使用するには、HTTPS トラフィック用と HTTP トラフィック用の 2 つのロードバランサを作成する必要があります。各ロードバランサには独自の転送ルールと URL マップがありますが、IP アドレスは共通です。HTTP ロードバランサの場合、フロントエンドは HTTPS ロードバランサのバックエンドにトラフィックをリダイレクトするため、バックエンドを構成する必要はありません。

次の例は、すべてのリクエストをポート 80 からポート 443 にリダイレクトする方法を示しています。

HTTP トラフィックを HTTPS にリダイレクトするには、次のことを行う必要があります。

予約済みの共有内部 IP アドレスを使用して、通常の内部 HTTPS ロードバランサを作成します。
内部 HTTPS ロードバランサをテストして、機能していることを確認します。
トラフィックを内部 HTTPS ロードバランサにリダイレクトします。
これを行うには、フロントエンドを持つ部分的な内部 HTTP ロードバランサを追加する必要があります。フロントエンドは、受信したリクエストを内部 HTTPS ロードバランサにリダイレクトします。この処理では次のものが使用されます。
- HTTPS ロードバランサと同じ予約済みの内部 IP アドレスを使用して転送ルール（手順 1 を参照）
- ターゲット HTTP プロキシ
- HTTPS ロードバランサにトラフィックをリダイレクトする URL マップ

次の図のように、HTTPS ロードバランサは、想定されるロードバランサコンポーネントを含む通常のロードバランサです。

HTTP ロードバランサには、HTTPS ロードバランサと同じ IP アドレスが設定され、URL マップにリダイレクト命令が指定されています。

内部 HTTP から HTTPS へのリダイレクト構成（クリックして拡大） — 内部 HTTP から HTTPS へのリダイレクト構成

内部 HTTPS ロードバランサを作成する

このプロセスは、内部 HTTP(S) ロードバランサの設定と同様です。

内部 HTTP(S) ロードバランサの設定は、次の 2 つの部分に分かれます。

前提となる作業を行う（必要なアカウントに適切な権限を付与し、Virtual Private Cloud（VPC）ネットワークを準備するなど）。
ロードバランサのリソースを設定する。

このガイドに進む前に、次の内容を理解しておいてください。

内部 HTTP(S) ロードバランサの概要（制限事項セクションを含む）
VPC ファイアウォールルールの概要

権限

このガイドに従うには、プロジェクト内でインスタンスを作成してネットワークを変更できる必要があります。そのためにはプロジェクトのオーナーまたは編集者であるか、または次の Compute Engine IAM のロールをすべて持っている必要があります。

タスク	必要なロール
ネットワーク、サブネット、ロードバランサコンポーネントの作成	Compute ネットワーク管理者
ファイアウォールルールの追加と削除	Compute セキュリティ管理者
インスタンスの作成	Compute インスタンス管理者

詳細については、次のガイドをご覧ください。

ネットワークとサブネットを構成する

ロードバランサのバックエンド用とロードバランサのプロキシ用の 2 つのサブネットが存在する VPC ネットワークが必要です。内部 HTTP(S) ロードバランサはリージョンです。VPC ネットワーク内のトラフィックは、送信元がロードバランサと同じリージョンのサブネット内にある場合、ロードバランサに転送されます。

この例では、次の VPC ネットワーク、リージョン、サブネットを使用します。

ネットワーク。ネットワークは、lb-network という名前のカスタムモードの VPC ネットワークです。
バックエンドのサブネット。us-west1 リージョンの backend-subnet という名前のサブネット。プライマリ IP 範囲として 10.1.2.0/24 を使用します。
プロキシのサブネット。us-west1 リージョンの proxy-only-subnet という名前のサブネット。プライマリ IP 範囲として 10.129.0.0/23 を使用します。

また、グローバルアクセスを示すため、この例では別のリージョンとサブネットに 2 つ目のテストクライアント VM を作成します。

リージョン: europe-west1
サブネット: europe-subnet（プライマリ IP アドレス範囲は 10.3.4.0/24）

ネットワークとサブネットを構成する

コンソール

Google Cloud コンソールの [VPC ネットワーク] ページに移動します。

[VPC ネットワーク] に移動
[VPC ネットワークを作成] をクリックします。
[名前] に「lb-network」と入力します。
[サブネット] セクションで、[サブネット作成モード] を [カスタム] に設定します。
ロードバランサのバックエンド用のサブネットを作成します。[新しいサブネット] セクションに、次の情報を入力します。
- 名前: backend-subnet
- リージョン: us-west1
- IP アドレス範囲: 10.1.2.0/24
[完了] をクリックします。
[サブネットを追加] をクリックします。
グローバルアクセスを示すためにサブネットを作成します。[新しいサブネット] セクションに、次の情報を入力します。
- 名前: europe-subnet
- リージョン: europe-west1
- IP アドレス範囲: 10.3.4.0/24
[完了] をクリックします。
[作成] をクリックします。

gcloud

gcloud compute networks create コマンドを使用してカスタム VPC ネットワークを作成します。
```
gcloud compute networks create lb-network --subnet-mode=custom
```
gcloud compute networks subnets create コマンドを使用して、us-west1 リージョンの lb-network ネットワークにサブネットを作成します。
```
gcloud compute networks subnets create backend-subnet \
    --network=lb-network \
    --range=10.1.2.0/24 \
    --region=us-west1
```
gcloud compute networks subnets create コマンドを使用して、europe-west1 リージョンの lb-network ネットワークにサブネットを作成します。
```
gcloud compute networks subnets create europe-subnet \
    --network=lb-network \
    --range=10.3.4.0/24 \
    --region=europe-west1
```

API

networks.insert メソッドに POST リクエストを送信します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
 "routingConfig": {
   "routingMode": "REGIONAL"
 },
 "name": "lb-network",
 "autoCreateSubnetworks": false
}

subnetworks.insert メソッドに POST リクエストを送信します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks

{
 "name": "backend-subnet",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/us-west1",
}

subnetworks.insert メソッドに POST リクエストを送信します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/europe-west1/subnetworks

{
 "name": "europe-subnet",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "ipCidrRange": "10.3.4.0/24",
 "region": "projects/PROJECT_ID/regions/europe-west1",
}

プロキシ専用サブネットを構成する

このプロキシ専用サブネットは、lb-network の us-west1 リージョン内のすべてのリージョン Envoy ベースのロードバランサ用です。

コンソール

Google Cloud Console を使用している場合は、しばらく待ってから、[ロードバランシング] ページでプロキシ専用サブネットを作成できます。

プロキシ専用サブネットを今すぐ作成する場合は、次の手順を行います。

Google Cloud コンソールの [VPC ネットワーク] ページに移動します。

[VPC ネットワーク] に移動
VPC ネットワークの名前 lb-network をクリックします。
[サブネットを追加] をクリックします。
[名前] に「proxy-only-subnet」と入力します。
[リージョン] で、us-west1 を選択します。
[目的] を [リージョンマネージドプロキシ] に設定します。
[IP アドレス範囲] に「10.129.0.0/23」と入力します。
[追加] をクリックします。

gcloud

gcloud compute networks subnets create コマンドを使用して、プロキシ専用サブネットを作成します。

gcloud compute networks subnets create proxy-only-subnet \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=us-west1 \
  --network=lb-network \
  --range=10.129.0.0/23

API

subnetworks.insert メソッドを使用してプロキシ専用サブネットを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/us-west1/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "region": "projects/PROJECT_ID/regions/us-west1",
  "purpose": "REGIONAL_MANAGED_PROXY",
  "role": "ACTIVE"
}

ファイアウォールルールを構成する

この例では、次のファイアウォールルールを使用します。

fw-allow-ssh。負荷分散されたインスタンスに適用される内向きルール。任意のアドレスから TCP ポート 22 への SSH 接続を許可します。このルールには、送信元の IP 範囲をより限定的に指定できます。たとえば、SSH セッションを開始するシステムの IP 範囲を指定できます。この例では、ターゲットタグ allow-ssh を使用して、ファイアウォールルールが適用される VM を識別します。
fw-allow-health-check。 ロードバランスされたインスタンスに適用される上り（内向き）ルール。これによって、Google Cloud ヘルスチェックシステム（130.211.0.0/22 と 35.191.0.0/16）からのすべての TCP トラフィックが許可されます。この例では、ターゲットタグ load-balanced-backend を使用して、ファイアウォールルールが適用される VM を識別しています。
fw-allow-proxies。ロードバランスされたインスタンスに適用される上り（内向き）ルール。内部 HTTP(S) ロードバランサが管理するプロキシからポート 80、443、8080 への TCP トラフィックを許可します。この例では、ターゲットタグ load-balanced-backend を使用して、ファイアウォールルールが適用される VM を識別します。

これらのファイアウォールルールがない場合は、デフォルトの上り（内向き）拒否ルールによってバックエンドインスタンスへの受信トラフィックがブロックされます。

ターゲットタグは、バックエンドインスタンスを定義します。ターゲットタグがない場合、ファイアウォールルールは VPC ネットワーク内のすべてのバックエンドインスタンスに適用されます。バックエンド VM を作成する場合は、マネージドインスタンスグループの作成の説明に沿って、指定したターゲットタグを忘れずに含めてください。

コンソール

Google Cloud コンソールで [ファイアウォールルール] ページに移動します。

ファイアウォールルールに移動
[ファイアウォールルールを作成] をクリックして、SSH 接続の受信を許可するルールを作成します。
- 名前: fw-allow-ssh
- ネットワーク: lb-network
- トラフィックの方向: 上り（内向き）
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ: allow-ssh
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲: 0.0.0.0/0
- プロトコルとポート:
  - 指定されたプロトコルとポートを選択します。
  - [TCP] チェックボックスをオンにして、ポート番号に「22」と入力します。
[作成] をクリックします。
[ファイアウォールルールを作成] をもう一度クリックして、Google Cloud ヘルスチェックを許可するルールを作成します。
- 名前: fw-allow-health-check
- ネットワーク: lb-network
- トラフィックの方向: 上り（内向き）
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ: load-balanced-backend
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲: 130.211.0.0/22 と 35.191.0.0/16
- プロトコルとポート:
  - 指定されたプロトコルとポートを選択します。
  - [TCP] チェックボックスをオンにして、ポート番号に「80」と入力します。
    このルールは、ヘルスチェックに使用されているプロトコルとポートのみに制限することをおすすめします。プロトコルとポートに tcp:80 を使用すると、Google Cloud はポート 80 で HTTP を使用して VM に接続できますが、ポート 443 では HTTPS を使用して VM に接続することはできません。
[作成] をクリックします。
[ファイアウォールルールを作成] をもう一度クリックをして、ロードバランサのプロキシサーバーがバックエンドに接続できるようにするルールを作成します。
- 名前: fw-allow-proxies
- ネットワーク: lb-network
- トラフィックの方向: 上り（内向き）
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ: load-balanced-backend
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲: 10.129.0.0/23
- プロトコルとポート:
  - 指定されたプロトコルとポートを選択します。
  - [TCP] チェックボックスをオンにして、ポート番号に「80, 443, 8080」と入力します。
[作成] をクリックします。

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
```
Google Cloud ヘルスチェックを許可する fw-allow-health-check ルールを作成します。この例では、ヘルスチェックプローブからのすべての TCP トラフィックを許可します。ただし、必要に応じてポートの範囲を狭く構成することもできます。
```
gcloud compute firewall-rules create fw-allow-health-check \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=load-balanced-backend \
    --rules=tcp
```
内部 HTTP(S) ロードバランサのプロキシにバックエンドへの接続を許可する fw-allow-proxies ルールを作成します。source-ranges を、プロキシ専用サブネットの割り振り範囲に設定します（例: 10.129.0.0/23）。
```
gcloud compute firewall-rules create fw-allow-proxies \
  --network=lb-network \
  --action=allow \
  --direction=ingress \
  --source-ranges=source-range \
  --target-tags=load-balanced-backend \
  --rules=tcp:80,tcp:443,tcp:8080
```

API

firewalls.insert メソッドに POST リクエストを送り、fw-allow-ssh ファイアウォールルールを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-allow-ssh",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "sourceRanges": [
   "0.0.0.0/0"
 ],
 "targetTags": [
   "allow-ssh"
 ],
 "allowed": [
  {
    "IPProtocol": "tcp",
    "ports": [
      "22"
    ]
  }
 ],
"direction": "INGRESS"
}

firewalls.insert メソッドに POST リクエストを送り、fw-allow-health-check ファイアウォールルールを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-allow-health-check",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "sourceRanges": [
   "130.211.0.0/22",
   "35.191.0.0/16"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp"
   }
 ],
 "direction": "INGRESS"
}

firewalls.insert メソッドのプロキシサブネット内で TCP トラフィックを許可する fw-allow-proxies ファイアウォールルールを作成します。PROJECT_ID は、実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-allow-proxies",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "sourceRanges": [
   "10.129.0.0/23"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "80"
     ]
   },
 {
     "IPProtocol": "tcp",
     "ports": [
       "443"
     ]
   },
   {
     "IPProtocol": "tcp",
     "ports": [
       "8080"
     ]
   }
 ],
 "direction": "INGRESS"
}

内部 HTTPS ロードバランサリソースを作成する

この例では、マネージドインスタンスグループ内の Compute Engine 上の仮想マシンバックエンドを使用します。代わりに、他のサポートされているバックエンドタイプを使用することもできます。

HTTP サーバーを使用してインスタンステンプレートを作成する

gcloud

gcloud compute instance-templates create l7-ilb-backend-template \
    --region=us-west1 \
    --network=lb-network \
    --subnet=backend-subnet \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://metadata.google.internal/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

ゾーンにマネージドインスタンスグループを作成する

gcloud

gcloud compute instance-groups managed create l7-ilb-backend \
    --zone=us-west1-a \
    --size=2 \
    --template=l7-ilb-backend-template

HTTP ヘルスチェックを作成する

gcloud

gcloud compute health-checks create http l7-ilb-basic-check \
     --region=us-west1 \
     --use-serving-port

バックエンドサービスを作成

gcloud

gcloud compute backend-services create l7-ilb-backend-service \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=l7-ilb-basic-check \
    --health-checks-region=us-west1 \
    --region=us-west1

バックエンドサービスにバックエンドを追加する

gcloud

gcloud compute backend-services add-backend l7-ilb-backend-service \
    --balancing-mode=UTILIZATION \
    --instance-group=l7-ilb-backend \
    --instance-group-zone=us-west1-a \
    --region=us-west1

URL マップの作成

gcloud

gcloud compute url-maps create l7-ilb-service-url-map \
    --default-service=l7-ilb-backend-service \
    --region=us-west1

リージョン SSL 証明書を作成します。

次の例は、gcloud を使用してセルフマネージド SSL 証明書を作成する方法を示しています。詳細については、セルフマネージド SSL 証明書の使用および Google マネージド SSL 証明書の使用をご覧ください。

gcloud

gcloud compute ssl-certificates create CERTIFICATE_NAME \
    --certificate=CERTIFICATE_FILE \
    --private-key=PRIVATE_KEY_FILE \
    --region=us-west1

リージョン SSL 証明書を使用してターゲットプロキシを作成します。

gcloud

gcloud compute target-https-proxies create l7-ilb-https-proxy \
    --url-map=l7-ilb-service-url-map \
    --region=us-west1 \
    --ssl-certificates=l7-ilb-cert

転送ルール用の共有 IP アドレスを予約する

gcloud

gcloud compute addresses create NAME \
    --addresses=10.1.2.99 \
    --region=us-west1 \
    --subnet=backend-subnet \
    --purpose=SHARED_LOADBALANCER_VIP

HTTPS 転送ルールを作成する

gcloud

gcloud compute forwarding-rules create l7-ilb-https-forwarding-rule \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=backend-subnet \
    --address=10.1.2.99 \
    --ports=443 \
    --region=us-west1 \
    --target-https-proxy=l7-ilb-https-proxy \
    --target-https-proxy-region=us-west1

HTTP(S) ロードバランサをテストする

この時点で、ロードバランサ（バックエンドサービス、URL マップ、転送ルールを含む）の準備は完了しています。このロードバランサをテストして、期待どおりに動作することを確認します。

クライアント VM インスタンスを作成して接続をテストします。

gcloud

gcloud compute instances create l7-ilb-client-us-west1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --network=lb-network \
    --subnet=backend-subnet \
    --zone=us-west1-a \
    --tags=allow-ssh

SSH 経由でクライアント VM に接続します。

gcloud

gcloud compute ssh l7-ilb-client-us-west1-a \
    --zone=us-west1-a

Curl を使用して HTTPS ロードバランサに接続します。

curl -k -s 'https://10.1.2.99:443' --connect-to 10.1.2.99:443

出力例:

Page served from: l7-ilb-backend-850t

100 個のリクエストを送信し、すべて負荷分散されていることを確認します。

{
  RESULTS=
  for i in {1..100}
  do
      RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443)"
  done
  echo "***"
  echo "*** Results of load-balancing to 10.1.2.99: "
  echo "***"
  echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
  echo
}

出力例:

***
*** Results of load-balancing to 10.1.2.99:
***
     51  l7-ilb-backend-https-850t
     49  l7-ilb-backend-https-w11t
    100 Page served from

HTTPS ロードバランサへのトラフィックのリダイレクト

部分 HTTP ロードバランサには、ポート 80 からポート 443 にトラフィックをリダイレクトする共有 IP アドレスがあります。

コンソール

ロードバランサのタイプを選択する

Google Cloud コンソールの [ロードバランシング] ページに移動します。

[ロードバランシング] に移動
[HTTP(S) 負荷分散] カードで [構成を開始] をクリックします。
[インターネット接続または内部専用] セクションで、[VM またはサーバーレスサービス間のみ] を選択します。この設定は、ロードバランサが内部であることを意味します。
[続行] をクリックします。

ロードバランサの準備

ロードバランサの名前に「l7-ilb-http-redirect」と入力します。
[リージョン] で、us-west1 を選択します。
[ネットワーク] で lb-network を選択します。

バックエンドサービスの構成

[バックエンドの構成] をクリックします。
[バックエンドサービスの選択] メニューで、既存のバックエンドサービス l7-ilb-backend-service を選択します。
[OK] をクリックします。

URL マップの構成

[ルーティングルール] をクリックします。
[モード] で、[詳細なホストとパスのルール] を選択します。
[ホストとパスのルールを追加] をクリックします。
[ホスト] を * に設定します。

[パスマッチャー（一致、アクション、サービス）] に、次のコードを入力します。

name: matcher1
defaultUrlRedirect:
  pathRedirect: /
  httpsRedirect: true
  hostRedirect: 10.1.2.99:443
  redirectResponseCode: PERMANENT_REDIRECT

l7-ilb-backend-service が、ホストとパスが一致しなかった場合に使用される唯一のバックエンドサービスであることを確認します。

トラフィック管理の詳細については、内部 HTTP(S) ロードバランサのトラフィック管理の設定をご覧ください。

HTTP 用にフロントエンドを構成する

[フロントエンドの構成] をクリックします。
転送ルールの名前を l7-ilb-forwarding-rule に設定します。
[プロトコル] を HTTP に設定します。
[サブネットワーク] を [backend-subnet] に設定します。
[ポート] を 80 に設定します。
[IP アドレス] メニューで、HTTPS ロードバランサ転送ルール用に予約された共有 IP NAME を選択します。
[完了] をクリックします。

構成を確認する

[確認と完了] をクリックします。
ロードバランサの構成を確認します。
省略可: [同等のコード] をクリックして、ロードバランサの作成に使用する REST API リクエストを表示します。
[作成] をクリックします。

gcloud

トラフィックリダイレクト構成を含む YAML ファイルを作成して、新しい URL マップを作成します。

defaultService: regions/us-west1/backendServices/l7-ilb-backend-service
kind: compute#urlMap
name: l7-ilb-redirect-url-map
hostRules:
- hosts:
 - '*'
 pathMatcher: matcher1
pathMatchers:
- name: matcher1
 defaultUrlRedirect:
       hostRedirect: 10.1.2.99:443
       pathRedirect: /
       redirectResponseCode: PERMANENT_REDIRECT
       httpsRedirect: True

YAML ファイルを新しい URL マップにインポートします。

gcloud compute url-maps import l7-ilb-redirect-url-map \
   --source=/tmp/url_map.yaml \
   --region=us-west1

HTTP ロードバランサのターゲットプロキシを作成します。

gcloud compute target-http-proxies create l7-ilb-http-proxy \
   --url-map=l7-ilb-redirect-url-map \
   --region=us-west1

新しい転送ルールと共有 IP アドレスを作成します。

gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
   --load-balancing-scheme=INTERNAL_MANAGED \
   --network=lb-network \
   --subnet=backend-subnet \
   --address=10.1.2.99 \
   --ports=80 \
   --region=us-west1 \
   --target-http-proxy=l7-ilb-http-proxy \
   --target-http-proxy-region=us-west1

トラフィックのリダイレクトをテストする

クライアント VM に接続します。

gcloud compute ssh l7-ilb-client-us-west1-a \
   --zone=us-west1-a

HTTP リクエストをポート 80 の 10.1.2.99 に送信し、トラフィックがリダイレクトされることを想定します。
```
curl -L -k 10.1.2.99
```
サンプル出力を表示します。
```
Page served from: l7-ilb-backend-w11t
```
-vvv を追加すると、詳細が表示されます。

curl -L -k 10.1.2.99 -vvv

* Rebuilt URL to: 10.1.2.99/
*   Trying 10.1.2.99...
* TCP_NODELAY set
* Connected to 10.1.2.99 (10.1.2.99) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.1.2.99
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 308 Permanent Redirect
< location: https://10.1.2.99:443/
< date: Fri, 07 Aug 2020 05:07:18 GMT
< via: 1.1 google
< content-length: 0
<
* Curl_http_done: called premature == 0
* Connection #0 to host 10.1.2.99 left intact
* Issue another request to this URL: 'https://10.1.2.99:443/'
*   Trying 10.1.2.99...
* TCP_NODELAY set
* Connected to 10.1.2.99 (10.1.2.99) port 443 (#1)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
...
...
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: O=Google TESTING; CN=test_cert_1
*  start date: Jan  1 00:00:00 2015 GMT
*  expire date: Jan  1 00:00:00 2025 GMT
*  issuer: O=Google TESTING; CN=Intermediate CA
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x561a6b0e3ea0)
> GET / HTTP/1.1
> Host: 10.1.2.99
> User-Agent: curl/7.52.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< date: Fri, 07 Aug 2020 05:07:18 GMT
< server: Apache/2.4.25 (Debian)
< last-modified: Thu, 06 Aug 2020 13:30:21 GMT
< etag: "2c-5ac357d7a47ec"
< accept-ranges: bytes
< content-length: 44
< content-type: text/html
< via: 1.1 google
<
Page served from: l7-ilb-backend-https-w11t
* Curl_http_done: called premature == 0
* Connection #1 to host 10.1.2.99 left intact

次のステップ

内部 HTTP(S) ロードバランサの仕組みを確認する。内部 HTTP(S) ロードバランサの概要をご覧ください。
内部 HTTP(S) ロードバランサに必要なプロキシ専用サブネットのリソースを管理する。内部 HTTP(S) ロードバランサのプロキシ専用サブネットをご覧ください。
ロードバランサの設定をクリーンアップする。

内部 HTTP(S) ロードバランサで HTTP から HTTPS へのリダイレクトを設定する

内部 HTTPS ロードバランサを作成する

権限

ネットワークとサブネットを構成する

ネットワークとサブネットを構成する

コンソール

gcloud

API

プロキシ専用サブネットを構成する

コンソール

gcloud

API

ファイアウォール ルールを構成する

コンソール

gcloud

API

内部 HTTPS ロードバランサ リソースを作成する

HTTP サーバーを使用してインスタンス テンプレートを作成する

gcloud

ゾーンにマネージド インスタンス グループを作成する

gcloud

HTTP ヘルスチェックを作成する

gcloud

バックエンド サービスを作成

gcloud

バックエンド サービスにバックエンドを追加する

gcloud

URL マップの作成

gcloud

リージョン SSL 証明書を作成します。

gcloud

リージョン SSL 証明書を使用してターゲット プロキシを作成します。

gcloud

転送ルール用の共有 IP アドレスを予約する

gcloud

HTTPS 転送ルールを作成する

gcloud

HTTP(S) ロードバランサをテストする

gcloud

gcloud

HTTPS ロードバランサへのトラフィックのリダイレクト

コンソール

ロードバランサのタイプを選択する

ロードバランサの準備

バックエンド サービスの構成

URL マップの構成

HTTP 用にフロントエンドを構成する

構成を確認する

gcloud

トラフィックのリダイレクトをテストする

次のステップ

ファイアウォールルールを構成する

内部 HTTPS ロードバランサリソースを作成する

HTTP サーバーを使用してインスタンステンプレートを作成する

ゾーンにマネージドインスタンスグループを作成する

バックエンドサービスを作成

バックエンドサービスにバックエンドを追加する

リージョン SSL 証明書を使用してターゲットプロキシを作成します。

バックエンドサービスの構成