ウェブサイトが正常に動作しているにもかかわらず、Lightsail ロードバランサーがヘルスチェックに失敗するのはなぜですか？

所要時間2分

Bitnami スタックのある Lightsail インスタンスに Amazon Lightsail ロードバランサーを使用しています。ウェブサイトが正常に動作しているにもかかわらず、ロードバランサーのヘルスチェックが失敗しています。

簡単な説明

ヘルスチェックを実行するには、Lightsail ロードバランサーは URL http://ipaddress:80/healthcheckpath のレスポンスをチェックします。ステータスコードが 200 OK の場合、ヘルスチェックは合格です。Lightsail ロードバランサーでは、このレスポンスチェックをカスタマイズすることはできません。インスタンスが HTTPS リダイレクトを強制している場合、http://ipaddress:80/healthcheckpath は 200 OK の代わりに 301 または 302 のレスポンスステータスコードを返します。その結果、ヘルスチェックが失敗します。

WordPress マルチサイトインスタンスでも同じ問題が発生する可能性があります。これらのインスタンスはデフォルトで http://ipaddress:80/healthcheckpath を http://ipaddress.nip.io/healthcheckpath にリダイレクトするためです。

解決策

**注:**ファイルパスは、Bitnami スタックがネイティブ Linux システムパッケージ (アプローチ A) を使用するか、自己完結型インストール (アプローチ B) を使用するかによって異なります。

Bitnami のインストールタイプを確認するには、次のコマンドを実行します。

test ! -f "/opt/bitnami/common/bin/openssl" && echo "Approach A: Using system packages." || echo "Approach B: Self-contained installation."

この問題を解決するために使用する手順は、以下によって異なります。

Really Simple SSL などの WordPress アプリケーションプラグインを使用してリダイレクトを設定しました。
Web サーバーのリダイレクトルールを使用してリダイレクションを設定しました。
WordPress マルチサイトスタックインスタンスを使用しています。

WordPress アプリケーションプラグインを使用してリダイレクトを設定しました

Web サイトのドキュメントルートに HTML ファイルを作成します。次に、ロードバランサーのヘルスチェック設定を変更して、HTML ファイルをヘルスチェックファイルとして追加します。アプリケーションレベルのリダイレクトは、元のアプリケーションの一部である HTML ファイルにのみ影響するため、HMTL ファイルをヘルスチェックファイルとして追加する必要があります。

Lightsail インスタンスに接続します。
Web サイトファイルを保存する Web サイトのドキュメントルートの場所に移動します。
アプローチ A の Bitnami スタックでは、ドキュメントルートの場所は /opt/Bitnami/APPNAME/ (たとえば、/opt/bitnami/wordpress) です。
アプローチ B の Bitnami スタックでは、ドキュメントルートの場所は /opt/bitnami/apps/APPNAME/htdocs (たとえば、/opt/bitnami/apps/wordpress/htdocs) です。
LAMP Bitnami スタックでは、ドキュメントルートの場所は /opt/bitnami/apache2/htdocs です。
空の HTML ファイルをアップロードするか、次のコマンドを実行して空の HTML ファイルを作成します。
```
touch health.html
```
Lightsail コンソールを開きます。
**[ネットワーキング]**を選択します。
ロードバランサーを選択します。
ターゲットインスタンスタブで、[ヘルスチェックのカスタマイズ] を選択します。
health.html というパスを入力し、[保存] を選択します。
http://ipaddress:80/health.html が 200 OK レスポンスを返すことを確認してください。KeyCDN ウェブサイトの HTTP ヘッダーチェッカーを使用してください。
数分待ってから、ヘルスチェックに合格することを確認します。

Web サーバーのリダイレクトルールを使用してリダイレクションを設定しました。

Web サーバーのリダイレクトルールに例外ルールを追加して、元の Web サイトファイルのみがリダイレクトされ、ヘルスチェックファイルはリダイレクトされないようにします。

「WordPressアプリケーションプラグインを使用してリダイレクトを設定する」セクションの手順 1 〜 7 を実行します。

HTTPS リダイレクトルールを追加したウェブサーバーファイルを開き、RewriteRule で始まる行の前に次の行を追加します。

RewriteCond expr "! %{REQUEST_URI} -strmatch '*health.html’ "

リダイレクトルールの例は次のとおりです。

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond expr "! %{REQUEST_URI} -strmatch '*health.html’ "
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}

次の場所にあるルールに前の行を追加します。
アプローチ A の Bitnami スタック: /opt/bitnami/apache2/conf/bitnami/bitnami.conf と、/opt/bitnami/apache2/conf/vhosts/ ディレクトリにある -vhost.conf で終わるすべてのファイル。
アプローチ B のビットナミスタック: /opt/bitnami/apache2/conf/bitnami/bitnami.conf

Web サービスを再起動します。

sudo /opt/bitnami/ctlscript.sh restart

http://ipaddress:80/health.html が 200 OK レスポンスを返すことを確認してください。KeyCDN ウェブサイトでこの HTTP ヘッダーチェッカーを使用してください。
数分待ってから、ヘルスチェックに合格することを確認します。

WordPress マルチサイトスタックインスタンスを使用しています

この問題を解決するには、次のステップを実行してください。

「WordPressアプリケーションプラグインを使用してリダイレクトを設定する」セクションの手順 1 〜 7 を実行します。

/opt/bitnami/apache2/conf/vhosts/wordpress-vhost.conf ファイルを開き、# BEGIN nip.io redirection の下に次の行を追加します。

RewriteCond expr "! %{REQUEST_URI} -strmatch '*health.html' "

行が追加されたルールの例を以下に示します。

# BEGIN nip.io redirection
RewriteEngine On
RewriteCond %{HTTP_HOST} ^([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})(:[0-9]{1,5})?$
RewriteCond expr "! %{REQUEST_URI} -strmatch '*health.html'"
RewriteRule ^/?(.*) %{REQUEST_SCHEME}://%1.nip.io%2/$1 [L,R=302,NE]
# END nip.io redirection

Web サービスを再起動します。