Jitsi Meet Docker 컨테이너 무한 재시작 문제 해결

Jitsi Meet 배포가 잠시 실행된 후 Docker Desktop이나 Dockerfile에서 하나 이상의 서비스가 "다시 시작 중"으로 표시될 수 docker compose ps있습니다. Docker는 일반적으로 프로세스가 종료된 후 구성된 다시 시작 정책을 적용합니다. 근본적인 해결책은 종료되는 서비스를 식별하고, 해당 서비스의 마지막 로그를 확인하고, 시작 오류를 수정하는 것입니다. 전체 스택을 반복적으로 다시 시작하거나 볼륨을 삭제하면 증거가 은폐되거나 영구 데이터가 제거될 수 있습니다.

1. 재시작되는 서비스를 찾으세요

이 설치를 실행할 때 사용했던 Compose 파일이 있는 디렉토리에서 Compose를 실행하십시오 .env. 평소에 추가 Compose 파일, 프로필 등을 사용하는 경우 --env-file, 해당 옵션도 함께 포함하십시오.

docker compose ps -a

각 서비스를 개별적으로 확인하십시오. 핵심 서비스는 web, prosody, jicofo, 및 이며, 또는 jvb와 같은 선택적 서비스가 포함될 수 있습니다. 상태가 또는 인 정확한 서비스를 기록해 두십시오 . 하나의 서비스에 오류가 발생했다고 해서 모든 컨테이너에 동일한 오류가 발생하는 것은 아닙니다.jibrijigasiRestartingExited

타임스탬프를 사용하여 해당 서비스의 로그 테일을 읽으십시오.

docker compose logs --tail=150 --timestamps jicofo

jicofo영향을 받는 서비스로 교체하세요 . -f다른 시작 시도를 감시하도록 추가하세요. Jitsi Docker 가이드에는 서비스에 대한 Compose 로그 문서가 있습니다. Docker에서 로그를 반환할 수 없는 경우 해당 컨테이너에 구성된 로깅 드라이버가 로그 읽기를 지원하는지 확인하세요.

2. 첫 번째 치명적인 메시지를 찾으십시오.

각 시작 주기에서 처음으로 명확하게 오류가 발생한 부분을 찾아 스크롤하십시오. 이후 줄에는 프로세스가 중지되었고 Docker가 다시 시작한다는 내용만 표시될 수 있습니다. 일반적인 근본 원인은 다음과 같습니다.

필수 암호 누락: Jitsi는 내부 서비스 계정의 기본 암호를 제거했으며, 암호가 필요한 서비스는 암호가 설정될 때까지 시작되지 않습니다. 표준 배포 디렉터리에서 제공된 ./gen-passwords.sh스크립트를 실행하여 필요한 값을 파일에 입력하십시오 .env. 해당 파일을 보호하고 지원 요청 시 암호 내용을 절대 게시하지 마십시오.
구성이 잘못되었거나 읽을 수 없습니다. 오류 메시지에 명시된 파일 경로와 구문을 확인하십시오. 사용자 지정 Prosody, Jicofo 또는 JVB 구성으로 인해 해당 서비스가 시작되지 않을 수 있습니다.
마운트된 디렉터리가 없거나 쓰기 권한이 없습니다. 오류 메시지에 표시된 정확한 호스트 경로를 확인하고 서비스의 볼륨 매핑과 비교하십시오. 전체 구성 트리의 권한을 변경하지 마십시오.
이미지 또는 진입점 오류: 배포 디렉터리, Compose 파일 및 이미지 태그가 호환되는 릴리스에 속하는지 확인하십시오. 특히 업데이트 후에 오류가 발생한 경우 더욱 중요합니다.
메모리 부족: 컨테이너 상태와 호스트 메모리를 점검하십시오. 메모리 부족으로 인한 종료는 구성 오류로 인한 종료와는 다른 해결 방법을 필요로 합니다.

Docker 재시작 정책은 프로세스가 종료된 후 다시 시작되는 이유를 설명하지만, 프로세스가 종료된 이유는 설명하지 않습니다. 종료 Restarting원인은 증상으로, 서비스 로그는 증거로 간주하십시오.

3. 환경을 검증하고 파일을 구성합니다.

Compose가 실제로 로드하는 파일을 편집하고 있는지 확인하십시오. 흔히 발생하는 실수는 .envCompose가 다른 디렉터리 또는 명시적으로 제공된 경로에서 파일을 읽는 동안 해당 파일을 변경하는 것입니다 --env-file. 컨테이너를 다시 생성하기 전에 구성을 검증하십시오.

docker compose config --quiet

Compose에서 오류가 발생하면 YAML, 변수 치환, 참조 파일 누락 또는 오류가 가리키는 옵션을 수정하십시오. docker compose config오류 없이 실행하면 --quiet해결된 모델을 검사하는 데 도움이 될 수 있지만, 암호가 보간되어 출력될 수 있습니다. 수정되지 않은 출력은 공유하지 마십시오.

표준 Jitsi 설치의 경우, 동일 릴리스의 .env구성과 비교 env.example하여 필요한 내부 암호가 있는지 확인하십시오. 사용자 지정 Compose 파일을 사용하는 경우, 필요한 변수가 올바른 서비스에 전달되는지 확인하십시오. 빈 자리 표시자 대신 포함된 암호 스크립트를 사용하십시오. 암호를 변경하는 경우, 해당 구성 요소의 설정도 일관되게 유지하십시오.

Jitsi 프로젝트는 일반 릴리스 파일과 개발 코드 및 불안정한 이미지를 구분합니다. 문제 해결 시 이전 Compose 디렉터리, 임의의 이미지 태그 및 다른 릴리스의 파일을 함께 사용하지 마십시오.

4. 구성 마운트 및 권한을 확인합니다.

서비스의 볼륨 항목과 실제 호스트 경로를 비교하십시오. 오타, 예상치 못한 CONFIG값 또는 다른 Compose 작업 디렉터리로 인해 배포에서 다른 구성 디렉터리가 사용될 수 있습니다.

권한은 Jitsi 버전에 따라 다릅니다. 설명서에 따르면 stable-11146, 버전부터 컨테이너는 읽기 전용 컨테이너 파일 시스템을 사용하는 비특권 사용자 권한으로 실행됩니다. 구성 디렉터리는 입력 디렉터리이며, 쓰기 가능한 데이터는 storage및 tmp디렉터리로 분리되어 저장되며, UID/GID 1000 이상의 사용자가 쓰기 권한을 가져야 합니다. 이전 버전에서는 다른 레이아웃을 사용합니다. 다른 버전의 권한 설정 방법을 재사용하지 말고, 현재 사용 중인 버전의 설명서를 따르십시오.

chmod -R 777로그에 누락되었거나 쓰기 불가능한 디렉터리가 확인되면 해당 경로를 정확하게 복구하십시오. Jitsi 구성 디렉터리 전체에 대해 포괄적인 명령을 적용하지 마십시오 . 마운트된 경로를 수정하지 않고 이러한 명령을 실행하면 보안이 약화될 수 있습니다.

5. 종료 상태 및 최근 변경 사항을 확인합니다.

Docker는 컨테이너의 종료 코드, 메모리 부족 상태, 재시작 횟수 및 데몬 오류를 보고할 수 있습니다. 먼저 오류가 발생한 서비스의 컨테이너 ID를 확인하세요.

docker compose ps -q jicofo

그런 다음 반환된 ID를 대입합니다.

docker inspect --format '{{.State.Status}} exit={{.State.ExitCode}} oom={{.State.OOMKilled}} restarts={{.RestartCount}} error={{.State.Error}}' CONTAINER_ID

재시작 횟수가 증가하는 것은 반복적인 시도가 있었음을 나타냅니다. 이 경우 oom=true호스트 또는 컨테이너의 메모리 제한 및 시스템 로그를 확인하십시오. 0이 아닌 종료 코드만으로는 진단이 불가능하며, 서비스 로그와 비교해야 합니다.

업데이트 후 루프가 발생했다면 변경 사항(릴리스 파일, 이미지 태그, 암호, 바인드 마운트 또는 사용자 지정 구성)을 기록해 두십시오. 버전을 변경하기 전에 구성 및 영구 데이터를 백업하십시오. 호환되는 Compose 파일 및 이미지 세트를 복원하거나 Jitsi의 업그레이드 지침을 따르십시오. 네트워크 및 방화벽 문제로 인해 참여자가 연결하지 못할 수 있지만, 일반적으로 서비스 프로세스가 반복적으로 종료되는 이유는 설명하지 못합니다. 부팅 실패와 미디어 연결 문제를 구분하십시오.

6. 원인을 해결한 후 서비스를 다시 생성하세요.

환경 변수 값 또는 Compose 정의를 변경한 후에는 영향을 받는 서비스를 다시 생성하여 새 구성을 적용하십시오.

docker compose up -d --force-recreate jicofo

서비스 이름을 바꿔주세요. 공유 구성 변경 사항이 여러 구성 요소에 영향을 미치는 경우 관련 서비스를 함께 다시 생성하세요. 그런 다음 상태와 로그를 다시 검토하세요. 단순히 재시작하는 것만으로는 모든 Compose 또는 환경 변경 사항이 적용되지 않으며, 전체 스택을 다시 생성하면 진행 중인 회의가 중단될 수 있습니다.

docker compose down -v일반적인 재시작 루프 해결 방법으로 사용하지 마십시오 . 이 -v옵션은 Compose에서 관리하는 볼륨을 제거하며, 보존하려던 데이터가 삭제될 수 있습니다. 컨테이너 또는 데이터를 제거하기 전에 로그를 저장하고 마운트 상태를 확인하십시오.

수정 사항을 확인하세요

상태를 확인하고, 정상적인 시작 과정이 몇 차례 진행된 후 다시 확인하십시오.

docker compose ps
docker compose logs --tail=100 --timestamps jicofo

해당 서비스는 계속 실행되어야 하며, 재시작 횟수 증가가 멈추고, 로그에 동일한 오류 메시지가 더 이상 반복되지 않아야 합니다. 웹 페이지가 정상적으로 로드되는지 확인하고 두 명의 클라이언트와 회의를 진행해 보세요. 서비스는 계속 실행되지만 참가자들이 오디오 또는 비디오를 주고받을 수 없는 경우, 네트워킹, 방화벽 규칙 및 Jitsi 설명서에 명시된 JVB 주소를 조사하십시오.

참고 자료로는 Jitsi Meet Docker 자체 호스팅 가이드 , 프로젝트 환경 변수 예제 , Docker 재시작 정책 문서 , Compose 로그 참조 및 컨테이너 검사 참조를 활용하세요 .