ウェブサイトが正常に実行しているのに、Lightsail ロードバランサーのヘルスチェックが失敗するのはなぜですか。

簡単な説明

Lightsail ロードバランサーは、URL http://ipaddress:80/healthcheckpath のレスポンスをチェックしてヘルスチェックを実行します。レスポンスステータスコードが 200 OK の場合、ヘルスチェックは通ります。このレスポンスチェックは、Lightsail ロードバランサーではカスタマイズできません。インスタンスで HTTPS リダイレクトが強制される場合、http://ipaddress:80/healthcheckpath は 200 OK ではなく 301 または 302 レスポンスステータスコードを返します。これがヘルスチェックの障害につながります。

WordPress マルチサイトインスタンスでも同じ問題が発生する可能性があります。これは、これらのインスタンスが URL 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 アプリケーションプラグインを使用して設定されます。
• リダイレクトはウェブサーバーのリダイレクトルールを使用して設定されます。
• WordPress マルチサイトスタックインスタンスを使用しています。

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

ウェブサイトのドキュメントルートに HTML ファイルを作成します。次に、ロードバランサーのヘルスチェック設定を変更して、そのファイルをヘルスチェックファイルとして追加します。アプリケーションレベルのリダイレクトは、もともとアプリケーションの一部ではない HTML ファイルに通常影響しないため、この方法を使用する必要があります。

1.    Lightsail インスタンスに接続します。

2.    ウェブサイトファイルを保存しているウェブサイトのドキュメントルートの場所に移動します。

アプローチ 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 です。

3.    アップロードするか、次のコマンドを実行して空の HTML ファイルを作成します。

touch health.html

4.    Lightsail ホームページに移動し、[ネットワーク] を選択します。

5.    ロードバランサーを選択します。

6.    [ターゲットインスタンス] タブで、[ヘルスチェックのカスタマイズ] を選択します。

7.    health.html というパスを入力し、[保存] を選択します。

8.    http://ipaddress:80/health.html が HTTP Header Checker を使用して 200OK レスポンスを返すことを確認します。

9.    数分待ってから、ヘルスチェックが通ったことを確認します。

リダイレクトをウェブサーバーのリダイレクトルールを使用して設定する

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

1.    「WordPress アプリケーションプラグインを使用してリダイレクトを設定する」セクションのステップ 1～7 に従います。

2.    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 の Bitnami スタック: /opt/bitnami/apache2/conf/bitnami/bitnami.conf。

3.    ウェブサービスを再起動します。

sudo /opt/bitnami/ctlscript.sh restart

4.    http://ipaddress:80/health.html が、この HTTP Header Checker を使用して 200OK レスポンスを返すことを確認します。

5.    数分待ってから、ヘルスチェックが通ったことを確認します。

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

WordPress のマルチサイトは、デフォルトで URL http://ipaddress:80/healthcheckpath を http://ipaddress.nip.io/healthcheckpath にリダイレクトします。この問題を修正するには、次の操作を実行します。

1.    「WordPress アプリケーションプラグインを使用してリダイレクトを設定する」セクションのステップ 1～7 に従います。

2.    /opt/bitnami/apache2/conf/vhosts/wordpress-vhost.conf ファイルを開き、# BEGIN nip.io リダイレクトのセクションの下に次の行を追加します。

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

3.    ウェブサービスを再起動します。

sudo /opt/bitnami/ctlscript.sh restart

4.    http://ipaddress:80/health.html が、この HTTP Header Checker を使用して 200OK レスポンスを返すことを確認します。

5.    数分待ってから、ヘルスチェックが通ったことを確認します。

---