웹 사이트가 제대로 실행되고 있는데도 Lightsail 로드 밸런서가 상태 확인에 실패하는 이유는 무엇인가요?

3분 분량

Bitnami 스택이 있는 Lightsail 인스턴스에 Amazon Lightsail 로드 밸런서를 사용하고 있습니다. 웹 사이트가 제대로 실행되고 있는데도 로드 밸런서 상태 확인이 실패합니다.

간략한 설명

Lightsail 로드 밸런서는 상태 확인을 수행하기 위해 URL http://ipaddress:80/healthcheckpath의 응답을 확인합니다. 상태 코드가 200 OK이면 상태 확인은 통과한 것입니다. Lightsail 로드 밸런서에서는 이 응답 검사를 사용자 지정할 수 없습니다. 인스턴스에서 HTTPS 리디렉션을 지정하는 경우 http://ipaddress:80/healthcheckpath에서 200 OK 대신 301 또는 302 응답 상태 코드를 반환합니다. 이로 인해 상태 확인이 실패합니다.

WordPress Multisite 인스턴스에서도 동일한 문제가 발생할 수 있습니다. 이러한 인스턴스가 기본적으로 http://ipaddress:80/healthcheckpath에서http://ipaddress.nip.io/healthcheckpath로 리디렉션되기 때문입니다.

해결 방법

참고: 파일 경로는 Bitnami 스택이 네이티브 Linux 시스템 패키지(Approach A)를 사용하는지 아니면 독립형 설치(Approach 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 Multisite 스택 인스턴스를 사용하고 있습니다.

WordPress 애플리케이션 플러그인을 사용하여 리디렉션 설정

웹 사이트의 문서 루트에 HTML 파일을 생성합니다. 그런 다음 HTML 파일을 상태 확인 파일로 추가하도록 로드 밸런서 상태 확인 구성을 수정합니다. 애플리케이션 수준 리디렉션은 원래 애플리케이션에 속한 HTML 파일에만 영향을 미치므로 HMTL 파일을 상태 확인 파일로 추가해야 합니다.

Lightsail 인스턴스에 연결합니다.
웹 사이트 파일을 저장한 웹 사이트의 문서 루트 위치로 이동합니다.
Approach A의 Bitnami 스택에서 문서 루트 위치는 /opt/bitnami/APPNAME/(예: /opt/bitnami/wordpress)입니다.
Approach B의 Bitnami 스택에서 문서 루트 위치는 /opt/bitnami/apps/APPNAME/htdocs(예: /opt/bitnami/apps/wordpress/htdocs)입니다.
LAMP Bitnami 스택에서 문서 루트 위치는 /opt/bitnami/apache2/htdocs입니다.
빈 HTML 파일을 업로드하거나 다음 명령을 실행하여 빈 HTML 파일을 생성합니다.
```
touch health.html
```
Lightsail 콘솔을 엽니다.
네트워킹을 선택합니다.
로드 밸런서를 선택합니다.
Target 인스턴스 탭에서 상태 확인 사용자 지정을 선택합니다.
health.html 경로를 입력한 다음 저장을 선택합니다.
http://ipaddress:80/health.html에서 200 OK 응답을 반환하는지 확인합니다. KeyCDN 웹 사이트에서 HTTP Header Checker를 사용합니다.
몇 분 정도 기다린 다음 상태 확인이 통과되었는지 확인합니다.

웹 서버 리디렉션 규칙을 사용하여 리디렉션 설정

웹 서버 리디렉션 규칙에 예외 규칙을 추가하여 원본 웹 사이트 파일만 리디렉션하고 상태 확인 파일은 리디렉션하지 않게 합니다.

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}

다음 위치의 규칙에 이전 줄을 추가합니다.
Approach A의 Bitnami 스택: /opt/bitnami/apache2/conf/bitnami/bitnami.conf 그리고 /opt/bitnami/apache2/conf/vhosts/ 디렉터리에서 -vhost.conf로 끝나는 모든 파일
Approach B의 Bitnami 스택: /opt/bitnami/apache2/conf/bitnami/bitnami.conf

웹 서비스를 다시 시작합니다.

sudo /opt/bitnami/ctlscript.sh restart

http://ipaddress:80/health.html에서 200 OK 응답을 반환하는지 확인합니다. KeyCDN 웹 사이트에서 이 HTTP Header Checker를 사용합니다.
몇 분 정도 기다린 다음 상태 확인이 통과되었는지 확인합니다.

WordPress Multisite 스택 인스턴스 사용

이 문제를 해결하려면, 다음 단계를 완료하세요.

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

웹 서비스를 다시 시작합니다.