為什麼即便網站正常執行,我的 Lightsail 負載平衡器也未能通過運作狀態檢查?

上次更新日期:2021 年 10 月 18 日

我將 Amazon Lightsail 負載平衡器用於具有 Bitnami 堆疊的 Amazon Lightsail 執行個體。為什麼即便網站正常執行,負載平衡器運作狀態檢查仍會失敗? 如何防止負載平衡器運作狀態檢查失敗?

簡短描述

Lightsail 負載平衡器透過檢查 URL http://ipaddress:80/healthcheckpath 的回應來執行運作狀態檢查。如果回應狀態代碼為 200 OK,則可通過運作狀態檢查。此回應檢查在 Lightsail 負載平衡器中不可自訂。如果您的執行個體強制執行 HTTPS 重新引導,則 http://ipaddress:80/healthcheckpath 將返回 301 或 302 回應狀態代碼,而不是 200 OK。這會導致運作狀態檢查失敗。

WordPress Multisite 執行個體可能會出現同樣的問題,因為這些執行個體預設會將 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."

用於解決此問題的步驟因以下各項而異:

  • 使用 WordPress 應用程式外掛程式設定重新引導,例如使用 Really Simple SSL。
  • 使用 Web 伺服器重新引導規則設定重新引導。
  • 您正在使用 WordPress Multisite 堆疊執行個體。

使用 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 主頁,然後選擇 Networking (聯網)。

5.    選擇負載平衡器。

6.    在 Target instances (目標執行個體) 標籤中,選擇 Customize health checking (自訂運作狀態檢查)。

7.    輸入路徑 health.html,然後選擇 Save (儲存)。

8.    使用 HTTP 標頭檢查程式確保 http://ipaddress:80/health.html 返回 200OK 回應。

9.    等待幾分鐘,然後驗證運作狀態檢查是否通過。

使用 Web 伺服器重新引導規則設定重新引導

在 Web 伺服器重新引導規則中新增運作狀態檢查檔案的例外規則,只重新引導原始網站檔案,而不重新引導運作狀態檢查檔案。

1.    按照使用 WordPress 應用程式外掛程式設定重新引導部分中的步驟 1 到 7 操作。

2.    開啟您要新增 HTTPS 重新引導規則的 Web 伺服器檔案,然後在以 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.    重新啟動 Web 服務。

sudo /opt/bitnami/ctlscript.sh restart

4.    使用 HTTP 標頭檢查程式確保 http://ipaddress:80/health.html 返回 200OK 回應。

5.    等待幾分鐘,然後驗證運作狀態檢查是否通過。

您正在使用 WordPress Multisite 堆疊執行個體

WordPress Multisite 預設會將 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 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

3.    重新啟動 Web 服務。

sudo /opt/bitnami/ctlscript.sh restart

4.    使用 HTTP 標頭檢查程式確保 http://ipaddress:80/health.html 返回 200OK 回應。

5.    等待幾分鐘,然後驗證運作狀態檢查是否通過。


此文章是否有幫助?


您是否需要帳單或技術支援?