컨테이너 종속성 중 어떤 항목이 재시작 루프를 일으키는지 확인하는 방법

앱이 종료되기 전에 사용할 수 없게 된 첫 번째 종속성을 식별하세요. 재시작되는 모든 컨테이너를 근본 원인으로 간주해서는 안 됩니다.

Docker Compose 스택에서는 데이터베이스가 아직 시작 중이거나, Redis에 연결할 수 없거나, DNS가 잘못된 서비스를 반환하거나, 바인드 마운트가 누락되었거나, 시크릿이 변경되었거나, 마이그레이션에 실패했거나, 메모리 부족으로 앱이 종료되면서 겉으로 보이는 애플리케이션이 반복 실행될 수 있습니다. 가장 빠른 진단 방법은 최초 종료와 종속성 오류를 기록하고, 자동 재시작을 일시 중지한 다음, 문제가 발생한 컨테이너가 사용하는 것과 동일한 네트워크와 인증 정보로 각 필수 서비스를 테스트하는 것입니다.

가장 요란한 컨테이너가 아니라 최초로 실패한 컨테이너를 찾으세요

스택의 모든 서비스에 대해 재시작 횟수, 현재 상태, 상태 점검 상태, 마지막 종료 코드, 시작 시간을 확인하세요. 타임라인을 정렬하여 보조 컨테이너가 다시 연결하거나 재시작하기 전에 발생한 최초의 실패가 먼저 표시되도록 하세요.

Netdata의 재시작 루프 가이드는 종료 코드와 상태를 통해 OOM 종료, 세그멘테이션 오류, 정상 종료, 상태 점검 관련 중지를 구분하는 방법을 보여줍니다. OOMKilled 또는 종료 코드 신호를 확인하면 실제로는 앱의 메모리가 부족하거나 내부적으로 충돌한 경우 종속성 문제를 조사하지 않아도 됩니다.

한 종속성이 먼저 실패했다면 애플리케이션보다 해당 종속성을 먼저 조사하세요. 앱이 연결 거부, 시간 초과, 인증 또는 파일 누락 오류와 함께 먼저 종료된다면, 해당 메시지를 앱이 사용하려던 정확한 종속성에 연결하세요.

재시작 폭풍을 멈추고 깔끔한 실패 한 번을 기록하세요

영향을 받은 서비스의 재시작 정책을 일시적으로 비활성화하거나 재정의한 다음, 포그라운드에서 한 번 실행하거나 한 번의 시작 시도에서 생성된 전체 로그를 확인하세요. Docker 데몬과 모든 종속성의 타임스탬프를 보존하세요.

반복되는 자동 재시작은 최초의 중요한 오류를 이후의 연결 실패로 덮어쓸 수 있습니다. 몇 초마다 재시작되는 컨테이너는 데이터베이스, DNS 확인자 또는 로그 볼륨에 과부하를 일으켜 2차 증상을 만들 수도 있습니다.

이 기록 과정에서 컨테이너, 볼륨 또는 데이터베이스를 삭제하지 마세요. 재시작 폭풍만 멈추고, 한 번 재현한 다음, 설정을 변경하기 전에 환경, 마운트, 네트워크 연결, 명령, 종료 상태를 저장하세요.

컨테이너가 준비 상태가 되기 위해 필요한 모든 종속성을 매핑하세요

앱에 필요한 데이터베이스, 캐시, 메시지 큐, 오브젝트 스토리지, DNS 확인자, ID 공급자, 마운트된 파일, 시크릿 및 외부 API를 기록하세요. 예상 서비스 이름, 포트, 프로토콜, 사용자 이름, 데이터베이스 및 경로도 포함하세요.

Dash0는 Compose의 시작 순서가 종속성 내부의 프로세스가 준비되었다는 의미는 아니라고 설명합니다. Postgres가 아직 초기화 중인 동안 앱이 시작될 수 있습니다. 해결 방법은 단순히 실행 중인 상태가 아니라 종속성의 정상 상태가 될 때까지 기다리는 것입니다.

종속성을 필수와 선택 항목으로 구분하세요. 선택적인 메트릭 서비스가 없다고 해서 메인 앱이 재시작되어서는 안 되지만, 데이터베이스를 사용할 수 없다면 제어된 대기, 재시도 또는 중지가 필요할 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

문제가 발생한 컨테이너의 네트워크에서 각 종속성을 테스트하세요

동일한 네트워크에 연결된 임시 진단 컨테이너를 사용하거나 앱이 종료되기 전에 지원되는 셸을 실행하세요. 서비스 이름 DNS, TCP 포트, TLS, 인증, 데이터베이스 쿼리, 필수 경로 순서로 테스트하세요.

Last9의 Compose 상태 점검 가이드에 따르면 준비 상태 점검은 핵심 구성 요소가 실제로 응답할 수 있을 때까지 종속 서비스가 시작되지 않도록 합니다. 유용한 점검은 단순히 프로세스가 존재하는지 확인하는 것이 아니라 클라이언트에 필요한 서비스 작업을 검증합니다.

DNS가 실패하면 네트워크 소속과 별칭을 확인하세요. TCP 연결은 열리지만 인증에 실패한다면 시크릿과 사용자를 비교하세요. 로그인이 되지만 예상한 스키마, 버킷, 큐 또는 디렉터리가 없다면 네트워크가 아니라 초기화를 수정하세요.

마운트, 시크릿 및 마이그레이션을 종속성으로 확인하세요

현재의 바인드 마운트, 이름 있는 볼륨, 권한, 소유권, 환경 파일, 시크릿 파일 및 애플리케이션 버전을 마지막으로 정상 작동한 배포와 비교하세요. 컨테이너가 데이터베이스에 연결할 수 있어도 설정 파일이 읽기 전용이거나 마이그레이션에 쓰기 권한이 없어 재시작될 수 있습니다.

한 컨테이너 시작 사례 연구에서는 상태 기반 종속성 순서를 사용하면 데이터베이스가 준비되기 전에 애플리케이션이 충돌하는 것을 방지할 수 있음을 보여줍니다. 조건부 시작 순서는 최초 부팅과 마이그레이션 중에 특히 중요합니다.

로그가 표시되는 상태에서 마이그레이션을 한 번 실행하고, 파괴적인 단계를 다시 시도하기 전에 데이터베이스를 백업하세요. 앱 버전이 변경되었다면 종속성 버전과 스키마 업그레이드 경로가 지원되는지 확인하세요.

종속성 순서대로 서비스를 다시 활성화하고 안정성을 검증하세요

가장 낮은 수준의 종속성을 먼저 시작하고, 실제 상태 점검이 정상 상태가 될 때까지 기다린 다음, 다음 계층을 시작하고 마지막으로 애플리케이션을 시작하세요. 여러 점검 간격 동안 재시작 횟수와 상태 전환을 기록하세요.

ZimaSpace의 컨테이너 측 DNS 실패 가이드는 앱 환경 내부에서만 나타날 수 있는 한 가지 종속성 경로를 다룹니다.

애플리케이션이 한 번 정상적으로 시작되고, 모든 필수 종속성이 계속 정상 상태를 유지하며, 마이그레이션이 완료되고, 종속성을 의도적으로 재시작했을 때 또 다른 루프가 아니라 제어된 재시도 또는 복구가 발생해야 문제가 해결된 것입니다. 근본적인 실패를 확인할 수 있고 범위가 제한된 후에만 재시작 정책을 복원하세요.