為什麼即便網站正常執行,我的 Lightsail 負載平衡器也未能通過運作狀態檢查?
我將 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. 等待幾分鐘,然後驗證運作狀態檢查是否通過。
相關內容
- 已提問 10 個月前lg...
- 已提問 3 個月前lg...
- 已提問 1 年前lg...
- AWS 官方已更新 3 年前
- AWS 官方已更新 3 個月前
- AWS 官方已更新 1 年前
- AWS 官方已更新 3 年前