HTTP から HTTPS へのリダイレクトの設定

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

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

  1. HTTPS LB1 を作成します(ここでは web-map-https とします)。
  2. LB1 をテストします。
  3. LB1 で使用されているのと同じ IP アドレスと URL マップで構成されたリダイレクトを使用して、HTTP LB2(バックエンドなし)(ここでは web-map-http)を作成します。
  4. リダイレクトをテストします。

次の図のように、LB1 は、予想されるロードバランサ コンポーネントを備えた通常の HTTPS ロードバランサ コンポーネントです。

LB2 は、LB1 と同じ IP アドレスを持つ HTTP ロードバランサであり、URL マップにリダイレクト命令が指定されていますが、バックエンドは存在しません。

HTTP から HTTPS へのリダイレクト構成(クリックして拡大)
HTTP から HTTPS へのリダイレクト構成

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

基本的な HTTPS ロードバランサ(LB1)の設定

この例では、HTTPS ロードバランサの設定とテストについて説明します。

この設定ガイドでは、Cloud CDN を有効にしたシンプルな外部 HTTPS ロードバランサを作成する方法を説明します。ロードバランサには次のリソースがあります。

IPv6 と SSL 証明書の設定を含むコンテンツ ベースのマルチリージョンの例については、マルチ リージョンのコンテンツ ベースの外部 HTTPS ロードバランサの設定をご覧ください。

一般的なコンセプトについては、外部 HTTP(S) 負荷分散の概要をご覧ください。

GKE を使用している場合、ロードバランサは通常、Kubernetes Ingress コントローラによって構成されます。詳細については、外部負荷分散向け Ingress の構成をご覧ください。

HTTPS ロードバランサのトポロジ

このガイドでは、次の図に示す構成を作成します。

シンプルな HTTPS 負荷分散(クリックして拡大)
シンプルな HTTPS 負荷分散(クリックして拡大)

この図のイベントの順序は次のとおりです。

  1. クライアントが転送ルールで定義された外部 IPv4 アドレスにコンテンツのリクエストを送信します。
  2. ロードバランサは、リクエストをキャッシュの配信が可能かどうかを確認します。可能な場合、ロードバランサはリクエストされたコンテンツをキャッシュから配信します。できない場合は、処理を続行します。
  3. 転送ルールによって、リクエストがターゲット HTTPS プロキシに振り向けられます。
  4. ターゲット プロキシは、URL マップのルールを使用して、単一のバックエンド サービスがすべてのリクエストを受信していることを確認します。
  5. ロードバランサは、このバックエンド サービスにはインスタンス グループが 1 つのみ存在していることを確認し、このグループに属する仮想マシン(VM)インスタンスの 1 つにリクエストを振り向けます。
  6. その結果、その VM によって、ユーザーがリクエストしたコンテンツが配信されます。
Cloud CDN を有効にしたシンプルな HTTP(S) 負荷分散(クリックして拡大)
Cloud CDN を有効にしたシンプルな HTTP(S) 負荷分散(クリックして拡大)

始める前に

設定が前提条件を満たしていることを確認します。

SSL 証明書リソースを設定する

次の説明に従って、SSL 証明書リソースを作成します。

Google マネージド証明書を使用することをおすすめします。

この例では、SSL 証明書リソース www-ssl-cert をすでに利用していることを前提としています。

権限を設定する

このガイドの手順を完了するには、プロジェクト内に Compute Engine インスタンス、ファイアウォール ルール、予約済み IP アドレスを作成する権限が必要になります。プロジェクトのオーナーまたは編集者ロール、あるいは次に示す Compute Engine IAM ロールが必要です。

タスク 必要なロール
インスタンスの作成 インスタンス管理者
ファイアウォール ルールの追加と削除 セキュリティ管理者
ロードバランサのコンポーネントの作成 ネットワーク管理者
プロジェクトの作成(省略可) プロジェクト作成者

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

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

Compute Engine バックエンドでロードバランサを設定するには、VM がインスタンス グループに属している必要があります。このガイドでは、Apache が稼働している Linux VM からなるマネージド インスタンス グループを作成し、負荷分散を設定する方法について説明します。

このマネージド インスタンス グループの VM で外部 HTTPS ロードバランサのバックエンド サーバーを実行します。わかりやすく説明するために、バックエンド サーバーはそれぞれ独自のホスト名を提供します。

Console

  1. Google Cloud Console で、[インスタンス グループ] ページに移動します。

    [インスタンス グループ] ページに移動

  2. [インスタンス グループを作成] をクリックします。
  3. 左側で [新しいマネージド インスタンス グループ] を選択します。
  4. [名前] に「lb-backend-example」と入力します。
  5. [ロケーション] で [シングルゾーン] を選択します。
  6. [リージョン] で、使用するリージョンを選択します。この例では us-east1 を使用しています。
  7. [ゾーン] で us-east1-b を選択します。
  8. [インスタンス テンプレート] で [新しいインスタンス テンプレートを作成] を選択します。
  9. [名前] に「lb-backend-template」と入力します。
  10. [ブートディスク] が Debian GNU/Linux 9 (stretch) などの Debian イメージに設定されていることを確認します。これらの手順では、apt-get などの Debian でのみ使用できるコマンドを使用します。
  11. [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] の [管理] タブで、次のスクリプトを [起動スクリプト] フィールドに挿入します。

    #! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    
  12. [ネットワーキング] タブで、ネットワーク タグを追加します。allow-health-check

  13. [保存して次へ] をクリックします。

  14. [自動スケーリング モード] で [自動スケーリングしない] を選択します。

  15. [インスタンスの数] に「2」と入力します。

  16. 新しいインスタンス グループを作成するには、[作成] をクリックします。

gcloud

  1. テンプレートを作成します。

    gcloud compute instance-templates create lb-backend-template \
       --region=us-east1 \
       --network=default \
       --subnet=default \
       --tags=allow-health-check \
       --image-family=debian-9 \
       --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://169.254.169.254/computeMetadata/v1/instance/name)"
         echo "Page served from: $vm_hostname" | \
         tee /var/www/html/index.html
         systemctl restart apache2'
    
  2. そのテンプレートに基づいてマネージド インスタンス グループを作成します。

    gcloud compute instance-groups managed create lb-backend-example \
       --template=lb-backend-template --size=2 --zone=us-east1-b
    

インスタンス グループへの名前付きポートの追加

インスタンス グループに HTTP サービスを定義し、ポート名を該当するポートにマッピングします。負荷分散サービスが構成されると、名前を指定したポートにトラフィックが転送されます。

Console

  1. Google Cloud Console で、[インスタンス グループ] ページに移動します。

    [インスタンス グループ] ページに移動

  2. インスタンス グループの名前(この例では lb-backend-example)をクリックし、[グループを編集] をクリックします。
  3. [ポート名のマッピングを指定する] をクリックします。
  4. [項目を追加] をクリックします。
  5. ポート名に「http」と入力します。ポート番号に「80」と入力します。
  6. [保存] をクリックします。

gcloud

gcloud compute instance-groups set-named-ports コマンドを使用します。

gcloud compute instance-groups set-named-ports lb-backend-example \
    --named-ports http:80 \
    --zone us-east1-b

ファイアウォール ルールの構成

この例では、ファイアウォール ルール fw-allow-health-check を作成します。これは Google Cloud ヘルスチェック システム(130.211.0.0/2235.191.0.0/16)からのトラフィックを許可する上り(内向き)ルールです。この例では、ターゲットタグ allow-health-check を使用して VM が識別されます。

Console

  1. Google Cloud Console で [ファイアウォール] ページに移動します。

    [ファイアウォール] ページに移動

  2. [ファイアウォール ルールを作成] をクリックして、2 つ目のファイアウォール ルールを作成します。
  3. [名前] に「fw-allow-health-check」と入力します。
  4. [ネットワーク] で Default を選択します。
  5. [ターゲット] で [指定されたターゲットタグ] を選択します。
  6. [ターゲットタグ] フィールドに「allow-health-check」を入力します。
  7. [ソースフィルタ] を IP ranges に設定します。
  8. [ソース IP の範囲] を 130.211.0.0/2235.191.0.0/16 に設定します。
  9. [プロトコルとポート] で [指定したプロトコルとポート] をオンにします。
  10. [tcp] チェックボックスをオンにし、ポート番号に「80」と入力します。
  11. [作成] をクリックします。

gcloud

gcloud compute firewall-rules create fw-allow-health-check \
    --network=default \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=allow-health-check \
    --rules=tcp:80

外部 IP アドレスの予約

インスタンスが稼働し始めたので、次にロードバランサにユーザーが接続する際に使用するグローバル静的外部 IP アドレスを設定します。

Console

  1. Google Cloud Console で、[外部 IP アドレス] ページに移動します。

    [外部 IP アドレス] ページに移動

  2. IPv4 アドレスを予約するには、[静的アドレスを予約] をクリックします。
  3. [名前] に「lb-ipv4-1」と入力します。
  4. [ネットワーク サービス階層] に [プレミアム] を設定します。
  5. [IP バージョン] を IPv4 に設定します。
  6. [タイプ] を [グローバル] に設定します。
  7. [予約] をクリックします。

gcloud

gcloud compute addresses create lb-ipv4-1 \
    --ip-version=IPV4 \
    --global

予約されている IPv4 アドレスをメモします。

gcloud compute addresses describe lb-ipv4-1 \
    --format="get(address)" \
    --global

ロードバランサの設定

この例では、クライアントとロードバランサの間で HTTPS を使用しているため、プロキシを構成する SSL 証明書リソースが 1 つ以上必要になります。Google マネージド証明書を使用することをおすすめします。

Console

  1. Google Cloud Console で、[負荷分散] ページに移動します。

    [負荷分散] ページに移動

  2. [ロードバランサを作成] をクリックします。
  3. [HTTP(S) 負荷分散] で [構成を開始] をクリックします。
  4. [インターネットから自分の VM へ] をオンにし、[続行] をクリックします。
  5. ロードバランサの名前に「web-map-https」を入力します。
  6. [バックエンドの構成] をクリックします。
    1. [バックエンド サービスとバックエンド バケットの作成または選択] で [バックエンド サービス] > [バックエンド サービスを作成] の順に選択します。
    2. バックエンド サービスの名前(web-backend-service など)を追加します。
    3. [プロトコル] で、HTTP を選択します。
    4. [名前付きポート] に「http」と入力します。
    5. [バックエンド] > [新しいバックエンド] > [インスタンス グループ] で、インスタンス グループ lb-backend-example を選択します。
    6. [ポート番号] に「80」と入力します。
    7. 他のデフォルト設定は残します。
    8. [ヘルスチェック] で [ヘルスチェックを作成] を選択し、ヘルスチェックの名前(http-basic-check など)を追加します。
    9. プロトコルを HTTP に設定し、[保存して次へ] をクリックします。
    10. [Cloud CDN を有効にする] を選択します。
    11. 他のデフォルト設定は残します。
    12. [作成] をクリックします。
  7. [ホストとパスのルール] で、デフォルト設定をそのまま使用します。
  8. [フロントエンド構成] で、次の値を使用します。
    1. [プロトコル] を HTTPS に設定します。
    2. [IP アドレス] を前の手順で作成した lb-ipv4-1 に設定します。
    3. [ポート] を 443 に設定し、HTTPS トラフィックを許可します。
    4. [証明書] プルダウン リストをクリックし、プライマリ SSL 証明書を選択します。
    5. [完了] をクリックします。
  9. [確認と完了] をクリックします。
  10. ロードバランサの構成が完了したら、[作成] をクリックします。
  11. ロードバランサの作成が完了するまで待ちます。
  12. ロードバランサの名前をクリックします。
  13. [ロードバランサの詳細] 画面で、ロードバランサの IP: ポートをメモします。

gcloud

  1. ヘルスチェックを作成します。
        gcloud compute health-checks create http http-basic-check \
            --port 80
        
  2. バックエンド サービスを作成します。
        gcloud compute backend-services create web-backend-service \
            --protocol=HTTP \
            --port-name=http \
            --health-checks=http-basic-check \
            --global
        
  3. インスタンス グループをバックエンドとしてバックエンド サービスに追加します。
        gcloud compute backend-services add-backend web-backend-service \
            --instance-group=lb-backend-example \
            --instance-group-zone=us-east1-b \
            --global
        
  4. デフォルトのバックエンド サービスに受信リクエストをルーティングする URL マップを作成します。
        gcloud compute url-maps create web-map-https \
            --default-service web-backend-service
        
  5. まだ作成していない場合は、次に示すようにグローバル SSL 証明書リソースを作成します。

    次の例では、certificate-file という証明書ファイルと private-key-file という秘密鍵ファイルがあることを前提としています。この例では、www-ssl-cert という SSL 証明書リソースを作成します。

        gcloud compute ssl-certificates create www-ssl-cert \
            --certificate=certificate-file \
            --private-key=private-key-file \
            --global
        
  6. URL マップにリクエストをルーティングするターゲット HTTPS プロキシを作成します。プロキシはロードバランサの一部であり、HTTPS 負荷分散用の SSL 証明書を保持するため、この手順で証明書も読み込みます。
        gcloud compute target-https-proxies create https-lb-proxy \
            --url-map web-map-https --ssl-certificates www-ssl-cert
        
  7. 受信リクエストをプロキシにルーティングするグローバル転送ルールを作成します。
        gcloud compute forwarding-rules create https-content-rule \
            --address=lb-ipv4-1\
            --global \
            --target-https-proxy=https-lb-proxy \
            --ports=443
        

Cloud CDN を有効にする

バックエンド サービスの作成時に Cloud CDN をまだ有効にしていない場合は、バックエンド サービスを更新することで有効にできます。

gcloud compute backend-services update web-backend-service \
    --enable-cdn \
    --cache-mode=CACHE_MODE

CACHE_MODE を次のいずれかに置き換えます。

  • CACHE_All_STATIC: 静的コンテンツを自動的にキャッシュに保存します。キャッシュ不可としてマークされている(Cache-Control レスポンス ヘッダー内の privateno-store、または no-cache のディレクティブ)レスポンスは、キャッシュに保存されません。動的コンテンツをキャッシュに保存するには、コンテンツに有効なキャッシュ ヘッダーが含まれている必要があります。これは、すべての新しい Cloud CDN 対応バックエンドのデフォルトの動作です。

  • USE_ORIGIN_HEADERS(デフォルト): コンテンツをキャッシュに保存するには、送信元で有効なキャッシュ ヘッダーを設定する必要があります。これらのヘッダーがないレスポンスは Google のエッジでキャッシュに保存されません。リクエストごとに送信元を完全に通過する必要があるため、パフォーマンスに影響が及び、送信元サーバーの負荷が増加する可能性があります。これは、既存のすべての Cloud CDN 対応バックエンドのデフォルトの動作です。

  • FORCE_CACHE_ALL: Cache-Control レスポンス ヘッダー内の privateno-store、または no-cache のディレクティブを無視して、すべてのコンテンツをキャッシュに保存します。この結果、ユーザー単位の(ユーザーを特定可能な)限定公開コンテンツがキャッシュに保存される場合があります。これを有効にするのは、限定公開コンテンツまたは動的コンテンツを配信していないバックエンド(Cloud Storage バケットなど)に限定する必要があります。

送信元からの静的レスポンスを自動的にキャッシュに保存するには、CACHE_ALL_STATIC キャッシュ モード設定を使用します。

HTTP キャッシュ ディレクティブを使用して、キャッシュへの保存をレスポンスごとに制御するには、元のヘッダー(USE_ORIGIN_HEADERS)を使用するようにキャッシュ モードを設定します。Cloud CDN が認識するキャッシュ ディレクティブ、および Cloud CDN によってキャッシュに保存されないコンテンツについては、キャッシュ可能なコンテンツキャッシュに保存できないコンテンツをご覧ください。

送信元がユーザーごとに動的なコンテンツを配信していない場合は、送信元からのすべてのレスポンスをキャッシュに保存することをおすすめします。これを行うには、FORCE_CACHE_ALL モードを使用します。このモードでは、コンテンツ タイプやキャッシュ ディレクティブに関係なく、すべてのレスポンスがキャッシュに保存されます。

バックエンドで Cloud CDN を有効にする際に明示的にキャッシュ モードを選択しなかった場合は、API と gcloud コマンドライン ツールがデフォルトで USE_ORIGIN_HEADERS に設定され、Cloud Console がデフォルトで CACHE_ALL_STATIC に設定されます。

インスタンスに送信されるトラフィックのテスト

負荷分散サービスが稼働中になったので、転送ルールへトラフィックを送信できます。また、各インスタンスに分散されるトラフィックを監視できます。

Console

  1. Google Cloud Console で、[負荷分散] ページに移動します。

    [負荷分散] ページに移動

  2. 作成したロードバランサをクリックします。
  3. [バックエンド] セクションで、VM が正常であることを確認します。[正常] 列には、両方の VM が正常であること(2/2)が示されます。それ以外の場合は、最初にページを再読み込みしてみてください。VM が正常な状態であることが Cloud Console に表示されるまでに時間がかかる場合があります。数分経ってもバックエンドが正常に動作しない場合は、ファイアウォールの構成と、バックエンド VM に割り当てられているネットワーク タグを確認します。
  4. Google マネージド証明書を使用している場合は、証明書リソースのステータスが ACTIVE であることを確認します。詳しくは、Google マネージド SSL 証明書リソースのステータスをご覧ください。
  5. Cloud Console でバックエンド インスタンスが正常であることを確認したら、https://IP_ADDRESS にアクセスし、ウェブブラウザでロードバランサをテストできます。IP_ADDRESS は、ロードバランサの IP アドレスに置き換えます。
  6. テストに自己署名証明書を使用した場合、ブラウザに警告が表示されます。自己署名証明書を受け付けるためには、ブラウザで明示的に設定する必要があります。
  7. ページを提供したインスタンスの名前とそのゾーン(Page served from: lb-backend-example-xxxx など)を示すコンテンツを含むページがブラウザで表示されます。お使いのブラウザでこのページがレンダリングされない場合は、このガイドの構成設定を確認してください。

Cloud CDN を無効にする

Console

単一のバックエンド サービスに対して Cloud CDN を無効にする

  1. Google Cloud Console で、[Cloud CDN] ページに移動します。

    [Cloud CDN] ページに移動

  2. 送信元の行の右側で [メニュー] をクリックし、[編集] を選択します。
  3. Cloud CDN の使用を停止するバックエンド サービスのチェックボックスをオフにします。
  4. [更新] をクリックします。

送信元のすべてのバックエンド サービスに対して Cloud CDN を削除する

  1. Cloud Console で、[Cloud CDN] ページに移動します。

    [Cloud CDN] ページに移動

  2. 送信元の行の右側で [メニュー] をクリックし、[削除] を選択します。
  3. 確認のため、もう一度 [削除] をクリックします。

gcloud

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-enable-cdn

Cloud CDN を無効にしても、キャッシュの無効化や消去は行われません。Cloud CDN を無効にして再度有効にすると、キャッシュに保存されたコンテンツの大半はキャッシュに残っています。コンテンツがキャッシュから配信されないようにするには、コンテンツの無効化が必要です。

完了すると、Cloud Console に HTTPS ロードバランサに関する情報が次のように表示されます。

HTTPS ロードバランサ

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

LB1 を作成し、動作確認を完了したところで、LB2(バックエンドが存在しない部分的な HTTP ロードバランサ)を作成して HTTP トラフィックを LB1 にリダイレクトできます。

この例では、301 レスポンス コードを使用しています。別のレスポンス コードを使用することもできます。

リダイレクトを構成するには、Google Cloud Console を使用するか、YAML ファイルをインポートします。

gcloud コマンドライン ツールを使用する場合は、ターゲット HTTP プロキシがトラフィックをリダイレクトする URL マップを参照している必要があります。Cloud Console を使用している場合、この処理は自動的に行われます。

コンソール

構成を開始する

  1. Google Cloud Console で、[負荷分散] ページに移動します。

    [負荷分散] に移動

  2. [HTTP(S) 負荷分散] で [設定を開始] をクリックします。
  3. [インターネットから自分の VM へ] をオンにし、[続行] をクリックします。
  4. ロードバランサの [名前] に「web-map-http」と入力します。
  5. ウィンドウを開いたままにして続行します。

バックエンド構成をスキップする

  1. [バックエンドの構成] セクションをスキップします。
    このロードバランサにバックエンドは必要ありません。

URL マップでリダイレクトを構成する

  1. ページの左側の列で、[ホストとパスのルール] をクリックします。
  2. [詳細なホストとパスのルール(URL リダイレクト、URL の書き換え)] を選択します。
  3. [アクション] で、[クライアントを別のホスト / パスにリダイレクト] を選択します。
  4. [パス リダイレクト] で、[フルパスのリダイレクト] を選択します。
  5. [リダイレクト レスポンス コード] で、[301 - Moved Permanently] を選択します。
  6. [HTTPS リダイレクト] で、[有効] を選択します。
  7. [完了] をクリックします。
  8. ロードバランサ構成ページを開いたままにして続行します。

LB1 で使用されているのと同じ IP アドレスで HTTP 転送ルールを構成する

  1. ロードバランサの構成ページで、[フロントエンドの構成] をクリックします。
  2. [名前] に「http-content-rule」と入力します。
  3. [プロトコル] を HTTP に設定します。
  4. [IP バージョン] を IPv4 に設定します。
  5. [IP アドレス] に、HTTPS ロードバランサに使用した IP アドレスを設定します。
  6. [ポート] が 80 に設定され、HTTP トラフィックが許可されていることを確認します。
  7. [完了] をクリックします。
  8. ウィンドウを開いたままにして続行します。

構成を確認する

  1. 左側のパネルで、[確認と完了] をクリックします。
  2. 現在の設定と作成しようとしている内容を比較します。
  3. 設定に問題がない場合は、[作成] をクリックします。

gcloud

  1. YAML ファイル /tmp/web-map-http.yaml を作成します。この例では、レスポンス コードとして MOVED_PERMANENTLY_DEFAULT を使用しています。

    kind: compute#urlMap
    name: web-map-http
    defaultUrlRedirect:
       redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
       httpsRedirect: True
    
  2. YAML ファイルをインポートして、HTTP ロードバランサの URL マップを作成します。この URL マップの名前は web-map-http です。

    gcloud compute url-maps import web-map-http \
       --source /tmp/web-map-http.yaml \
       --global
    

    既存の URL マップを更新する場合、次のプロンプトが表示されます。

    Url Map [web-map-http] will be overwritten.
    
    Do you want to continue (Y/n)?
    

    続行するには [Y] を押します。

  3. URL マップが更新されていることを確認します。HTTP ロードバランサの URL マップは次のようになります。

    gcloud compute url-maps describe web-map-http
    
    creationTimestamp: '2020-03-23T10:53:44.976-07:00'
    defaultUrlRedirect:
     httpsRedirect: true
     redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
    fingerprint: 3A5N_RLrED8=
    id: '2020316695093397831'
    kind: compute#urlMap
    name: web-map-http
    selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps/web-map-http
    
  4. web-map-http を URL マップとして使用して、新しいターゲット HTTP プロキシを作成するか、既存のターゲット HTTP プロキシを更新します。

    gcloud compute target-http-proxies create http-lb-proxy \
       --url-map=web-map-http \
       --global
    

    または

    gcloud compute target-http-proxies update http-lb-proxy \
       --url-map=web-map-http \
       --global
    
  5. 受信リクエストをプロキシにルーティングするグローバル転送ルールを作成します。

    gcloud compute forwarding-rules create http-content-rule \
       --address=lb-ipv4-1 \ # Same IP address used for HTTPS load balancer
       --global \
       --target-http-proxy=http-lb-proxy \
       --ports=80
    

完了すると、Cloud Console に次の 2 つのロードバランサが表示されます。

両方のロードバランサ

Cloud Console には、web-map-httpロードバランサに関する情報が次のように表示されます。

HTTP ロードバランサ

HTTP から HTTPS へのリダイレクトをテストする

両方のロードバランサで使用している予約済みの IP アドレスをメモします。

gcloud compute addresses describe lb-ipv4-1 \
    --format="get(address)" \
    --global

この例では、予約済みの IP アドレスが 34.98.77.106 であるとしています。http://34.98.77.106/ URL は https://34.98.77.106/ にリダイレクトされます。

数分経過したら、次の curl コマンドを実行してテストします。34.98.77.106 は、予約済みの IP アドレスに置き換えてください。

curl 34.98.77.106:80

出力例:

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://34.98.77.106/">here</A>.
</BODY></HTML>