Jitsi Meet용 Jibri 녹화 및 스트리밍 서버 설정 방법

Jitsi의 최신 Docker 핸드북에는 중요한 배포 변경 사항이 명시되어 있습니다. 해당 릴리스 이후 stable-11146Jitsi 컨테이너는 권한이 없는 UID/GID 1000으로 실행되며, 영구 데이터 디렉터리는 해당 컨테이너 사용자에게 쓰기 권한이 있어야 합니다. Jibri 서비스 또한 더 이상 SYS_ADMIN쓰기 권한이 필요하지 않습니다. 따라서 권한 있는 컨테이너 또는 광범위한 777권한 설정을 권장하는 이전 가이드를 최신 릴리스의 지침을 확인하지 않고 그대로 배포에 적용해서는 안 됩니다.

이 가이드는 기존에 자체 호스팅된 Jitsi Meet 설치 환경에 Docker Compose를 사용하는 방법을 설명합니다. 예시는 가상의 상황을 가정합니다. Riverview 팀은 이미 `/usr/jitsi/mit/jitsi.js`에서 Jitsi를 실행 중이며 meet.example.net, 설정 파일은 `/usr/jitsi.js`에 저장되어 있고 /opt/jitsi-meet-cfg, 진행자는 회의를 로컬에 녹화하고 필요에 따라 RTMP로 스트리밍할 수 있기를 원합니다. 이는 실제 설치 또는 테스트 결과가 아닌, 예시적인 설정입니다.

참고: 아래 화면은 실제 서버 화면이 아닌 개략적인 예시이며, 표시된 명령 출력 및 회의 상태는 설명을 위한 것입니다.

지브리가 하는 일과 지브리가 필요로 하는 것은 무엇인가

Jibri는 Jitsi의 회의 녹화 또는 실시간 스트리밍을 위한 방송 인프라입니다. 브라우저 세션을 통해 회의에 참여하여 오디오와 비디오를 캡처한 후 인코딩하여 출력합니다. 따라서 Jibri를 제대로 사용하려면 Jitsi 웹 서비스, Prosody XMPP 서버, 그리고 Jicofo가 내부 녹화 계정과 사용 가능한 인스턴스가 자신을 알리는 Jibri "brewery" 룸에 대해 합의해야 합니다.

직접 관리하는 Jitsi Meet 정식 설치 환경을 사용하십시오. Jibri는 마치 자체 서버인 것처럼 공용 meet.jit.si 서비스에 연결할 수 없습니다. Jibri 공식 프로젝트에서는 디스플레이 또는 오디오 장치를 사용하는 다른 워크로드가 없는 별도의 머신이나 가상 머신에서 Jibri를 실행할 것을 권장합니다. 공식 Docker Compose 배포 패키지는 Jibri를 추가 서비스로 제공합니다. 소규모 설치의 경우 Compose 호스트에서 별도의 컨테이너로 실행할 수 있지만, 지속적인 사용을 위해서는 전용 CPU, 메모리 및 디스크 용량을 할당하거나 적절한 리소스를 갖춘 호스트에 배치해야 합니다.

Jibri 인스턴스 하나는 한 번에 하나의 녹음 또는 스트리밍 세션만 처리할 수 있습니다. Riverview에서 동시 세션을 예상하는 경우, 여러 인스턴스로 구성된 Jibri 풀을 계획하고 Jitsi 설명서에 설명된 추가 오디오 루프백 구성을 고려해야 합니다. 고유한 오디오 장치가 없는 컨테이너를 추가하는 것은 완전한 확장 계획이 아닙니다.

1단계: Docker Jitsi Meet 환경 준비

공식 Docker Jitsi Meet 릴리스와 해당 Compose 파일에서 시작하세요. .env파일과 Compose 파일은 동일한 릴리스에서 가져오세요. 환경 변수 파일에서 녹화를 활성화하세요.

ENABLE_RECORDING=1

Jitsi의 Compose 구성은 Jibri 자체와 레코더 브라우저 세션에 내부 XMPP 계정을 사용합니다. Jibri 및 레코더 암호는 강력하고 서로 다른 값으로 설정하고 안전하게 보관하십시오. 새 스택을 구축하는 경우 프로젝트 gen-passwords.sh스크립트를 사용하여 내부 서비스 암호를 생성할 수 있습니다. 이 스크립트는 환경 파일을 변경하므로 먼저 백업해 두어야 합니다. Jitsi 스택이 이미 실행 중인 경우 모든 암호를 임의로 다시 생성하지 마십시오. 실행 중인 모든 구성 요소는 계획된 재시작 시 일치하는 업데이트된 자격 증명을 받아야 합니다.

리버뷰의 예시에서 ENABLE_RECORDING=1는 필수 스위치이며, 릴리스 환경 템플릿은 XMPP 사용자, 레코더 사용자, 브루어리 MUC, 스토리지 경로 및 기타 옵션에 대한 이름과 기본값을 제공합니다. 공개 이슈, 터미널 스크린샷 또는 공유 회의 채팅에 암호를 붙여넣지 마십시오.

2단계: 쓰기 ​​가능한 영구 저장소 생성

컨테이너 교체 시에도 녹음 데이터가 유지되어야 하므로 Jitsi의 Compose 설정은 Jibri를 위해 영구 호스트 스토리지를 마운트합니다. 예시에서 CONFIG=/opt/jitsi-meet-cfg호스트 디렉터리는 `/hosts.js`입니다 /opt/jitsi-meet-cfg/storage/jibri. 서비스를 시작하기 전에 해당 디렉터리를 생성하고 컨테이너의 UID/GID 1000으로 쓰기 권한을 부여하십시오.

sudo mkdir -p /opt/jitsi-meet-cfg/storage/jibri
sudo chown 1000:1000 /opt/jitsi-meet-cfg/storage/jibri
sudo chmod 750 /opt/jitsi-meet-cfg/storage/jibri
ls -ldn /opt/jitsi-meet-cfg/storage/jibri

숫자로 표시된 목록에는 소유자와 그룹이 나와야 합니다 1000. 환경 파일의 경로가 다를 경우 실제 CONFIG경로를 사용하십시오. Jitsi 구성 디렉터리 전체의 소유권을 재귀적으로 변경하지 마십시오. 필요한 소유권은 Jibri 저장 경로에 적용하고, 기존 호스트를 조정할 때는 기존 녹음을 보존하십시오. SELinux 시스템에서는 공식 Compose 파일의 볼륨 레이블 설정을 제거하고 그대로 유지하십시오.

컨테이너의 기록 디렉터리는 구성 가능합니다. 설명서에 나와 있는 예시는 JIBRI_RECORDING_DIR호스트 /storage/recordings의 Jibri 스토리지 디렉터리 아래에 마운트된 `/etc/reserve ...

3단계: 해당 작성 파일을 사용하여 Jibri를 시작합니다.

공식 Jitsi Compose 파일과 구성된 환경 파일이 있는 디렉토리에서 Jibri 오버라이드를 사용하여 기본 스택을 시작합니다.

docker compose -f docker-compose.yml -f jibri.yml up -d

공식 핸드북에서는 이 Compose 패턴을 사용하여 Jibri를 Docker 배포에 추가합니다. Jibri 오버라이드는 서비스의 컨테이너 이미지, 구성 및 스토리지 마운트, 공유 메모리 할당을 정의합니다. 선택한 릴리스에 포함된 파일을 사용하십시오. 현재 버전 jibri.yml과 이전 버전 .env또는 Compose 번들을 혼합하여 사용하지 마십시오.

Jibri 서비스가 계속 가동 중인지 확인하고 Jicofo 및 Prosody와 함께 로그를 검토하십시오.

docker compose ps jibri
docker compose logs --tail=100 jibri jicofo prosody

실행 중인 컨테이너는 초기 확인 단계일 뿐, 회의 녹화가 가능하다는 증거는 아닙니다. Jibri는 올바른 XMPP 호스트에 인증하고 예상되는 내부 Brewery MUC에 참여해야 합니다. 로그에 인증 실패가 표시되면 환경 파일과 생성된 서비스 구성에서 XMPP 도메인, 내부 MUC, Jibri 계정, 레코더 계정 및 암호를 비교하십시오. 모든 값이 일치해야 하며, 한 구성 요소의 암호만 변경해도 인증 과정이 중단됩니다.

4단계: 녹화 및 RTMP 스트림을 테스트합니다.

관리자 계정으로 테스트 회의에 참여하세요 meet.example.net. 회의의 '추가 작업' 메뉴에서 녹화 및 라이브 스트리밍 기능이 사용 가능한지 확인합니다. 짧은 녹화를 시작하고 세션이 끝날 때까지 기다린 후 구성된 호스트 저장 경로에서 출력 파일을 확인합니다. 녹화 파일은 컨테이너의 쓰기 가능 영역뿐만 아니라 마운트된 호스트 볼륨에도 저장되므로 Jibri 컨테이너가 다시 생성된 후에도 남아 있어야 합니다.

라이브 스트림의 경우, 대상 서비스에서 제공하는 RTMP 수집 URL과 스트림 키를 사용하세요. Jitsi의 라이브 스트림 워크플로에 현재 공급자 값을 입력하고 대상의 미리 보기 또는 수신 상태를 확인하세요. 공급자 대시보드와 레이블은 변경될 수 있으므로 대상의 최신 RTMP 지침을 따르세요. 스트림 키는 암호처럼 취급해야 합니다. 회의 채팅이나 기사 스크린샷에 공개하지 마세요. 로컬 저장소에 녹화하는 것과 RTMP 서비스로 라이브 스트림을 전송하는 것은 Jibri의 관련 기능이지만, 대상과 확인 절차가 다릅니다.

고장 지점을 기준으로 문제를 해결하세요.

• 녹화 또는 스트리밍 작업이 표시되지 않습니다. 활성 환경 파일에 해당 설정이 ENABLE_RECORDING=1있는지, 그리고 변경 후 일치하는 Compose 스택이 다시 생성되었는지 확인하십시오. 실행 중인 컨테이너 내부의 파일을 편집하는 대신 생성된 웹, Prosody 및 Jicofo 구성을 확인하십시오. Docker는 호스트 입력에서 서비스 구성을 다시 생성합니다.
• 액션은 나타나지만 Jibri가 참여할 수 없습니다. Jibri 및 Jicofo 로그에서 XMPP 인증 또는 MUC 오류를 확인하십시오. 내부 호스트, 레코더 도메인, 양조장 이름 및 두 개의 내부 암호가 동일한 Compose 릴리스와 일치하는지 확인하십시오.
• 컨테이너가 종료되거나 재시작되는 경우, 로그에서 누락되었거나 쓰기 불가능한 스토리지 경로가 있는지 확인하십시오. 현재 루트리스 이미지의 경우, 마운트된 디렉터리에 UID/GID 1000으로 쓰기 권한이 있는지 확인하십시오. 또한 호스트 메모리와 공식 Jibri Compose 파일에서 제공하는 공유 메모리 구성을 확인하십시오.
• 세션이 시작되었지만 녹화 파일이 생성되지 않았습니다. 구성된 녹화 디렉터리가 호스트 볼륨에 매핑되었는지, 그리고 세션이 정상적으로 중지/종료되었는지 확인하십시오. 디스크 여유 공간과 파일 권한을 확인하십시오.
• 녹화는 되지만 스트리밍이 실패하는 경우: RTMP 수집 URL 및 스트림 키, 대상의 현재 요구 사항, 호스트의 아웃바운드 네트워크 경로를 다시 확인하십시오. 증거 없이 추가 인바운드 포트를 열기보다는 Jibri 로그에서 스트리밍 실패 원인을 확인하십시오.

회의는 원활하게 진행되지만 동시 녹화 횟수가 더 필요한 경우, 용량을 의도적으로 추가하세요. Jibri는 인스턴스당 하나의 세션만 허용하므로 동시 작업에는 더 많은 인스턴스가 필요합니다. Docker 핸드북에서도 여러 인스턴스에 대해 서로 다른 오디오 루프백 인터페이스를 선택할 것을 권장합니다. 풀을 확장하기 전에 인스턴스를 하나 추가하여 테스트하고 각 인스턴스가 별도의 녹화를 생성할 수 있는지 확인하세요.

다음 공식 자료를 활용하세요.

다른 Jibri 버전의 설정을 복사하지 말고, 사용 중인 배포 환경에 맞는 지침을 따르세요. Jitsi Docker 핸드북 에는 Compose 워크플로, 기록 변수, 스토리지 경로, 루트리스 컨테이너 권한 및 최신 Jibri 노트에 대한 설명이 있습니다. Jibri 프로젝트 README 파일에는 Jibri의 역할, 단일 세션 제한 사항 및 구성 모델이 설명되어 있습니다. 공식 Jibri Compose 서비스 정의 및 환경 템플릿은 릴리스별 변수 이름과 마운트에 대한 정확한 정보를 제공합니다.