앱은 여전히 열리는데 컨테이너 상태 확인이 실패하는 이유는 무엇인가요?

컨테이너의 상태 확인이 실패하더라도 컨테이너를 계속 사용할 수 있습니다. 상태 확인 프로브가 브라우저에서 사용하는 경로와 다른 명령, 주소, 사용자 또는 준비 상태를 테스트할 수 있기 때문입니다.

홈 서버에서는 Docker가 컨테이너 내부에서 localhost, 누락된 유틸리티, 잘못된 포트 또는 일시적으로 사용할 수 없는 종속성을 대상으로 상태 확인 명령을 실행하는 동안, 리버스 프록시를 통해 앱이 정상적으로 열릴 수 있습니다. 재시도 횟수를 늘리거나 상태 확인을 비활성화하기 전에, 먼저 컨테이너 내부에서 정확한 프로브를 재현한 다음 실제 사용자 경로와 프로브의 대상 및 예상 결과를 비교하세요.

브라우저가 테스트하는 대상과 상태 확인이 테스트하는 대상 비교

애플리케이션을 정상적으로 여는 URL과 네트워크 경로를 기록하세요. 브라우저가 리버스 프록시, 공개된 호스트 포트, 로컬 IP 또는 컨테이너에 직접 연결하는지 확인합니다.

Docker는 컨테이너 내부에서 구성된 프로브를 실행하므로 브라우저와 다른 엔드포인트를 테스트할 수 있습니다. Docker 커뮤니티의 한 사례에서는 서비스 프로세스 자체는 실행 중이었지만 이미지에 프로브에서 사용하는 curl 명령이 포함되어 있지 않아 상태 확인이 실패했습니다.

브라우저의 정상 경로가 다른 프록시나 포트를 거친다면, 이를 내부 프로브 대상이 올바르다는 증거로 간주하지 마세요. 두 경로를 모두 적고 처음으로 달라지는 구성 요소를 확인하세요.

컨테이너 내부에서 정확한 상태 확인 명령 실행

셸 형식, URL, 플래그, 인증 정보, 환경 변수를 포함해 상태 확인 명령을 정확히 복사하세요. 실행 중인 컨테이너에서 동일한 사용자로 명령을 실행하고 종료 코드와 출력을 기록합니다.

컨테이너가 비정상으로 표시되어도 실행 중인 프로세스가 있을 수 있습니다. 상태는 사용자가 페이지를 불러올 수 있는지가 아니라 프로브 결과를 반영하기 때문입니다. Netdata의 진단 절차는 재시작 동작을 변경하기 전에 프로브 실패와 프로세스 실패를 구분합니다.

명령을 수동으로 실행했을 때 성공한다면 자동 상태 확인에서 사용하는 실행 사용자, 셸, 작업 디렉터리, 환경 및 타이밍을 비교하세요. 수동 실행에서도 실패한다면 다음 상태 확인 주기를 기다리지 않아도 오류를 통해 문제의 다음 계층을 파악할 수 있습니다.

프로브 도구, 셸, PATH 및 사용자 확인

상태 확인 명령에 포함된 모든 실행 파일이 현재 이미지 내부에 존재하고 컨테이너 사용자로 실행 가능한지 확인하세요. 최소 이미지에는 curl, wget, bash, DNS 도구 또는 인증서 저장소가 없을 수 있습니다.

셸 형식 프로브와 실행 형식 프로브는 서로 다르게 동작합니다. 인용 부호, 파이프, 변수 확장 및 복합 명령에는 사용 가능한 셸이 필요하며, 직접 명령을 실행하는 경우 상태 확인 환경의 PATH가 제한되어 있다면 실행 파일의 전체 경로가 필요합니다.

절대 경로와 지정된 서비스 사용자로 명령을 실행하세요. 도구를 대화형으로 설치하지 말고 이미지나 프로브를 수정하세요. 수동으로 변경한 컨테이너의 내용은 다음 빌드 후 사라지기 때문입니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

내부 주소, 포트 및 프로토콜 확인

컨테이너 내부에서 애플리케이션이 수신 대기하는 주소와 포트를 확인하고 프로브 URL과 비교하세요. 8080:80과 같이 호스트 포트를 공개했다고 해서 컨테이너 내부 서비스가 포트 8080에서 수신 대기한다는 의미는 아닙니다.

상태 확인은 컨테이너가 제어하는 애플리케이션 상태를 테스트해야 합니다. Dash0의 실용 가이드에서는 프로브가 HTTP 엔드포인트를 호출하거나 프로세스를 검사할 수 있지만, 해당 엔드포인트는 외부 프록시를 통해서만 사용할 수 있는 경로가 아니라 실제 컨테이너 준비 상태를 반영해야 한다고 설명합니다.

127.0.0.1, 컨테이너의 수신 대기 주소 및 서비스 이름을 각각 적절한 경우에만 테스트하세요. 앱이 Unix 소켓이나 다른 인터페이스에서만 바인딩된다면 프로브를 실제 내부 진입점으로 변경합니다.

느린 시작과 영구적인 실패 구분

올바른 엔드포인트가 응답하기 전까지 애플리케이션 시작, 데이터베이스 마이그레이션, 캐시 준비 또는 모델 로드에 걸리는 시간을 측정하세요. 이 시간을 start_period, interval, timeout 및 retries와 비교합니다.

종속 서비스가 나중에 준비되더라도 아직 비정상으로 표시되어 있으면 Compose가 종속 서비스의 시작을 차단할 수 있습니다. 보고된 Compose 회귀 사례에서는 종속 서비스 실패로 스택이 이미 중지된 후에야 서비스가 정상 상태가 되었으며, 이로 인해 상태 확인 시작 시간이 지나치게 짧았음이 드러났습니다.

로그를 통해 앱이 정상적으로 진행 중이라는 사실이 확인될 때만 타이밍을 늘리세요. 재시도 시간을 늘려 잘못된 포트, 실패한 마이그레이션, 누락된 인증서 또는 연결할 수 없는 데이터베이스를 숨겨서는 안 됩니다.

프로브를 좁게 유지하고 복구 확인

상태 확인이 프로세스 생존 여부, 로컬 애플리케이션 준비 상태 또는 더 깊은 종속성 체인을 나타내야 하는지 결정하세요. 선택 사항인 외부 API를 사용할 수 없다는 이유만으로 로컬 컨테이너를 비정상으로 만들지 마세요.

애플리케이션이 데이터베이스, 캐시 또는 네트워크 서비스 없이는 준비 상태가 될 수 없다면, ZimaSpace의 첫 번째 실패 종속성 찾기 가이드가 다음 단계입니다.

정상 시작 후 정확한 자동 프로브가 성공하고, 종속성이 재시작되는 동안에도 컨테이너가 정상 상태를 유지하며, 실제 앱 작업 흐름을 계속 사용할 수 있으면 문제가 해결된 것입니다. 프로브는 서비스 고장을 감지할 만큼 엄격하게 유지하되, 관련 없는 시스템으로 인한 오탐을 피할 수 있을 만큼 범위를 좁게 설정하세요.