웹 사이트가 올바르게 실행되고 있음에도 Lightsail 로드 밸런서가 상태 확인에 실패하는 이유는 무엇인가요?

4분 분량
0

Bitnami 스택을 사용하는 Amazon Lightsail 인스턴스에 Amazon Lightsail 로드 밸런서를 사용하고 있습니다. 웹 사이트가 올바르게 실행되고 있음에도 로드 밸런서 상태 확인이 실패하는 이유는 무엇인가요? 로드 밸런서 상태 확인이 실패하지 않도록 하려면 어떻게 해야 하나요?

간략한 설명

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

WordPress Multisite 인스턴스에서도 동일한 문제가 발생할 수 있습니다. 이러한 인스턴스는 기본적으로 http://ipaddress:80/healthcheckpath URL을 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 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 파일을 업로드하거나 다음 명령을 실행하여 빈 HTML 파일을 만듭니다.

touch health.html

4.    Lightsail 홈페이지로 이동한 다음 **네트워킹(Networking)**을 선택합니다.

5.    로드 밸런서를 선택합니다.

6.    대상 인스턴스(Target instances) 탭에서 **상태 확인 사용자 지정(Customize health checking)**을 선택합니다.

7.    health.html 경로를 입력한 다음 **저장(Save)**을 선택합니다.

8.    http://ipaddress:80/health.html이 HTTP 헤더 검사기를 사용하여 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 헤더 검사기를 사용하여 200OK 응답을 반환하는지 확인합니다.

5.    몇 분 정도 기다린 다음 상태 확인이 통과되었는지 확인합니다.

WordPress Multisite 스택 인스턴스를 사용 중인 경우

WordPress Multisite에서는 기본적으로 http://ipaddress:80/healthcheckpath URL을 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.    웹 서비스를 다시 시작합니다.

sudo /opt/bitnami/ctlscript.sh restart

4.    http://ipaddress:80/health.html이 HTTP 헤더 검사기를 사용하여 200OK 응답을 반환하는지 확인합니다.

5.    몇 분 정도 기다린 다음 상태 확인이 통과되었는지 확인합니다.


AWS 공식
AWS 공식업데이트됨 3년 전