上記画像は「WordPress」を「GCP」マルチリージョンのロードバランサーで運用する最終形です。
また「Google Cloud CDN」を挟み「GCPのVMインスタンス」と「Google Cloud Storage」利用し、サーバー負荷の軽減も行っています。
第8回は赤枠内、ロードバランサー用の「固定IPアドレス」をDNSへ「置き換え設定」したあと、WordPressのウェブサイトに「https」でアクセスできるようにするまでを行ないます。
GCPのロードバランサーを利用した「tokyo2020unofficial.com」の設定です。
ロードバランサーを利用していない「投票2020」の設定はこちらの目次です。
ロードバランサーはランニングコストが高いので一時休止しています。気分次第で記事は更新していきます。
第8回 【WordPress_ロードバランサー】 GCP でロードバランサーの「固定IPアドレス」を設定し、「https」でアクセスできるようにする。
環境：Debian 9 php 7.0 Apache 2.4.25 MySQL 5.7 Cocoon
目的：ロードバランサーの作成です。同時に「https化」対応「GoogleのマネージドSSL証明書」取得。
第7回までに、ロードバランサー（負荷分散）を作成しました。
「第8回」では、
- ロードバランサーの「固定IPアドレス」をDNSへ「置き換え設定」
- ロードバランサーに必要なファイアウォール ルールの設定
- WordPress管理画面で「https」へURLを変更します。
- 「第8回」の設定をすべて行なっても、このままではリダイレクトループによって、管理画面へのアクセスができなくなります。「第9回」と必ずセットで設定するようにしてください。
- 「http→https」301リダイレクト正規化は「第9回」で書きます。
「http→https」301リダイレクト正規化について：
「ロードバランサー」や「CDN」の背後にある「WordPress」は通常の正規化では「301リダイレクト」ができません。「WordPress」「wp-config.php」ファイルの編集が必要です。
httpsでアクセスできるようになるまで。
- 第7回ロードバランサーの作成
- 第7回バックエンド
「第6回」までに作成した「admin インスタンスグループ」を配置。
- 第7回フロントエンド
ロードバランサーの「固定IPアドレス」取得
「GoogleのマネージドSSL証明書」取得
- 第8回Cloud DNS
ロードバランサーの「固定IPアドレス」を設定。
- 第8回ファイアウォールルール
ロードバランサー用にヘルスチェックのルートを設定。
- 第8回WordPress
一般設定「http」→「https」へ書き換え。
- 第9回「http→https」301リダイレクト正規化
リダイレクトループ回避
この条件が必要になります。
1.1 「ロードバランサー」の「IPアドレス」確認
- 「ロードバランサー」の「IPアドレス」を確認するために、
「メニュー」「ネットワークサービス」「負荷分散」の順番でクリックして、次へ。
1.2 「名前」をクリック
- 「赤枠の名前部分」をクリックして、次へ。
1.3 「ロードバランサー」の「IPアドレス」コピー
- 「プロトコル」の「IPポート」には、
- 「例、34.84.67.43:80」
- 「例、34.84.67.43:443」
と表示されていますが、「34.84.67.43」は同一です。
この「IPアドレス例、34.84.67.43」をコピーして、次へ。
1.4 「Cloud DNS」で「IPアドレス」を置き換え
なぜ「IPアドレス」を置き換えるのか？
- 「DNS設定」の「①wwwなし」と「②wwwあり」を「鉛筆マーク」で編集を行ないます。
- WinSCPでアクセスするIPアドレスは変更しません。このロードバランサーの「IPアドレス」はあくまでも「ロードバランサーの代表となるIPアドレス」です。
- WinSCPで直接編集する「WordPressが格納されているVMインスタンスのIPアドレス」は変更されていませんので変えてしまわないように気をつけてください。
1.5 「Cloud DNS」で「①wwwなし」の置き換え
- 上の赤枠は何も入力しません。
- 「ロードバランサー」の「IPアドレス」「例、34.84.67.43」を入力して、次へ。
1.6 「Cloud DNS」で「②wwwあり」の置き換え
- 上の赤枠に「www」を入力します。
- 「ロードバランサー」の「IPアドレス」「例、34.84.67.43」を入力して、次へ。
1.7 ロードバランサーの状況確認
- この時点では「赤枠の正常」が「0/1」となり「異常」という状態です。
- 下記画面は正常です。
- 「なぜ異常なのか？」ファイアウォールの設定を行なっていないからです。続きます。
GCPのロードバランサーを設定する上で、強烈にはまったところです。
- 設定は正しいはずなのに。
- いくら待っても正常にならない。
- 正しい設定は、ものすごく小さくしか「Google公式」に書いてない。
「GCPロードバランサー」では、ファイアウォールの設定を新たに作成しなければなりません。「ヘルスチェック用」の設定です。
1.8 ファイアウォールの設定
- 「メニュー」「VPCネットワーク」「ファイアウォール」「ファイアウォール ルールを作成」をクリックして、次へ。
1.9 ファイアウォール設定①
- 設定画面上部です。
- 名前は任意です。「例、allow-health-checks」など「ヘルスチェック用」とわかるようにしたほうが良いです。
1.10 ファイアウォール設定②
- 設定画面中部です。
- 「ターゲット」をクリックすると、プルダウンで下記項目が表示されます。一番上の「ネットワーク上のすべてのインスタンス」を選択して、次へ。
1.11 ファイアウォール設定③
- 設定画面下部です。
「ソースIPの範囲」を2つ設定します。
- 「35.191.0.0/16」
- 「130.211.0.0/22」
この値は「Google公式の絶対値」です。例ではありません。
Google公式：ヘルスチェックのファイアウォール ルール
https://cloud.google.com/load-balancing/docs/health-checks?hl=ja#fw-rule
- 入力方法は、「35.191.0.0/16」を入力し「Tabキー」を押します。
- 次に「130.211.0.0/22」を入力して、次へ進みます。
- 「プロトコルとポート」は「指定したプロトコルとポート」を選択し「tcp」にチェックを入れ作成ボタンを押して、次へ。
1.12 ファイアウォール作成完了確認
- 自分で作成した「ファイアウォール ルール」の名前で作成ができていたら設定完了です。
1.13 ロードバランサーの正常動作確認
ファイアウォール設定で「ヘルスチェック用」の「ファイアウォールルール」が作成されると、ロードバランサーの背後にあるVMインスタンスへのヘルスチェックが通るようになります。
- 「メニュー」「ネットワークサービス」「負荷分散」をクリックして、次へ。
1.14 ロードバランサー（負荷分散）画面
- 「バックエンド」の緑のチェックマークを確認します。
- 「ロードバランサー」の中身が正常かどうかを確認するため「名前部分」をクリックして、次へ
1.15 ロードバランサー詳細画面
- 赤枠部分「1/1」となっていれば正常に動作しています。
- 赤枠部分「0/1」となっていたら正常に動作はしていません。
- これまでに作成してきた「adminインスタンスグループ」の設定に間違いはないか。
- 「adminインスタンスグループ」の中にある「VMインスタンス」は正常に動作しているか。
- 確認方法①：該当のVMインスタンスの右側にある「SSH」ボタンをクリックして起動するかどうか、起動できなければ異常発生です。「インスタンスグループ」を再作成します。
- 確認方法②：該当のVMインスタンスをクリックして「モニタリング」タブをクリックすると起動しているかどうか「CPU使用率」などで確認できます。
- 確認方法③：該当のVMインスタンスに外部からアクセスする。「WinSCP」を起動してWordPressが格納されているVMインスタンスにアクセスできるかどうか。（今まで設定してきたWinSCPに変更を加えずにログインができるかどうかという意味です。）
1.16 独自ドメインの「https」でアクセス
- ここで、独自ドメインの「https」でアクセスします。
- 下記画面「例、https://www.tokyo2020unofficial.com/」へアクセスします。赤色の部分は独自ドメインに置き換えてください。
- 成功すると、この時点ではレイアウトが崩れたサイトが表示されます。理由は、WordPress側の設定で「https」へ変更していないからです。
1.17 独自ドメインの「http」で管理画面へアクセス
下記画面「例、http://www.tokyo2020unofficial.com/wp-admin/」へアクセスします。赤色の部分は独自ドメインに置き換えてください。
「http」と「https」を間違えないようにアクセスします。
1.18 WordPress管理画面でURLを「https」へ変更
- 「2つのURL」を両方とも「https」へ変更します。
- 上の「WordPressアドレス（URL）」は管理画面用です。
- 下の「サイトアドレス（URL）」は一般のユーザーが外部からアクセスするアドレスです。
- 「変更を保存」をクリックして、次へ。
1.19 上記の「2つのURL」を変更し設定を保存
- 設定を保存した瞬間、下記のような画面となり、アクセスできなくなります。
- 正しい設定をしようとするとこの画面になります。すぐには反映しません。
「管理画面」、「ウェブサイト」のURL両方ともアクセスできない時間が長く不安になるポイントです。早いと10分程度ですが、初回は大体数十分、長いと1日以上かかります。
1.20 「https」でアクセス
- 独自ドメインのウェブサイト「例、https://www.tokyo2020unofficial.com/」にアクセスできるようになったら、管理画面へアクセスできるかどうか確認しますので、次へ。
1.21 「https」で管理画面へログイン
- 下記画面「例、https://www.tokyo2020unofficial.com/wp-admin/」へアクセスします。
- WordPressの管理画面にアクセスできたら設定完了です。
1.23 さいごに
「SSL証明書作成、ロードバランサー外部IPアドレス置換、ファイアウォールルール作成」までがスムーズに行えなかった場合、SSL証明書の確認に失敗しているときがあります。ハザードマークの「FALED_NOT_VISABLE」が表示されます。
失敗していたら「第7回」に戻り「ロードバランサーの編集」「フロントエンド設定」でSSL証明書を新たに作成します。
次は「第9回」です
第9回 【WordPress_Load_Balancing】 ロードバランサーでhttp→https化した後、301リダイレクト正規化し、リダイレクトループを回避する方法。
【コメント】 ※「メールアドレス不要」