Jitsi Meet 用の Jibri 録画およびストリーミングサーバーの設定方法

Jitsiの最新のDockerハンドブックには、重要なデプロイメント変更が記載されています。リリース以降stable-11146、コンテナは非特権のUID/GID 1000として実行され、永続データディレクトリはコンテナユーザーが書き込み可能である必要があります。Jibriサービスも、もはや書き込みSYS_ADMIN権限を必要としません。特権コンテナや広範な権限を推奨する古いガイドは、777リリース固有の手順を確認せずに現在のデプロイメントにコピーしないでください。

このチュートリアルでは、既存のセルフホスト型 Jitsi Meet インストール環境で Docker Compose を使用する方法を説明します。これは明らかに架空の例です。Riverview Team は既に Jitsi を で実行しておりmeet.example.net、設定を に保存しています/opt/jitsi-meet-cfg。また、モデレーターが会議をローカルに録画し、必要に応じて RTMP 宛先にストリーミングしたいと考えています。これは設定例であり、実際のインストールやテストのレポートではありません。

図の説明：以下の画面表示は概略図であり、実際のサーバーからのキャプチャではありません。表示されているコマンド出力と会議の状態は例示です。

Jibriの機能と必要なもの

Jibriは、Jitsiが提供する会議の録画やライブストリーミングのためのブロードキャストインフラストラクチャです。ブラウザセッションを通じて会議に参加し、音声と映像をキャプチャした後、出力をエンコードします。そのため、Jibriが正常に動作するには、Jitsiウェブサービス、Prosody XMPPサーバー、およびJicofoが、内部レコーダーアカウントと、利用可能なインスタンスが自身を通知するJibriの「ブリューイング」ルームについて合意している必要があります。

管理権限を持つ完全な Jitsi Meet インストール環境を使用してください。Jibri を、あたかも独自のサーバーであるかのように、公開されている meet.jit.si サービスに接続することはできません。Jibri のアップストリームプロジェクトでは、ディスプレイやオーディオ デバイスを使用する無関係なワークロードがない、別のマシンまたは仮想マシン上で実行することを推奨しています。公式の Docker Compose デプロイメントでは、Jibri を追加サービスとしてパッケージ化しています。小規模なインストールであれば、Compose ホスト上の別のコンテナとして実行できます。継続的に使用する場合は、専用の CPU、メモリ、ディスク容量を割り当てるか、適切なリソースを備えたホストに配置してください。

Jibriインスタンス1つにつき、一度に処理できる録音またはストリーミングセッションは1つだけです。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 スタックが既に実行中の場合は、安易にすべてのパスワードを再生成しないでください。実行中のコンポーネントはすべて、計画的な再起動時に一致する更新された認証情報を受け取る必要があります。

Riverview の例では、ENABLE_RECORDING=1は必須のスイッチです。リリースの環境テンプレートには、XMPP ユーザー、レコーダー ユーザー、brewery MUC、ストレージ パス、その他のオプションの名前とデフォルト値が用意されています。公開の課題、ターミナルのスクリーンショット、共有ミーティングのチャットにパスワードを貼り付けないでください。

ステップ2：書き込み可能な永続ストレージを作成する

録画データはコンテナの置き換え後も保持される必要があるため、JitsiのCompose設定ではJibri用の永続的なホストストレージをマウントします。この例ではCONFIG=/opt/jitsi-meet-cfg、ホストディレクトリは です/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 ストレージディレクトリの下にマウントされたものJIBRI_RECORDING_DIRです/storage/recordings。変更する前に、リリースの環境テンプレートを確認してください。ホストに十分な空きディスク容量と保持プランがあることを確認してください。レコーダーが正常に動作している場合、時間の経過とともに小さなボリュームがいっぱいになることがあります。

ステップ3：対応するComposeファイルを使用して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ホストに対して認証を行い、想定される内部醸造所MUCに参加する必要があります。ログに認証失敗が表示されている場合は、環境ファイルと生成されたサービス構成ファイル全体で、XMPPドメイン、内部MUC、Jibriアカウント、レコーダーアカウント、およびパスワードを比較してください。これらの値は一致している必要があります。いずれかのコンポーネントのパスワードのみを変更すると、ハンドシェイクが失敗します。

ステップ4：録画とRTMPストリームをテストする

モデレーターアカウントを使用してテストミーティングに参加しますmeet.example.net。ミーティングの「その他の操作」メニューで、録画とライブストリーミングの操作が利用可能であることを確認します。まず短い録画を開始し、セッションが終了するまで待ってから、出力先の構成済みホストストレージパスを確認します。録画はコンテナの書き込み可能レイヤーだけでなく、マウントされたホストボリュームにも保存されるため、Jibriコンテナが再作成された後も録画は残ります。

ライブストリームの場合は、宛先サービスから提供される RTMP インジェスト URL とストリームキーを使用します。Jitsi のライブストリームワークフローに現在のプロバイダー値を入力し、宛先のプレビューまたは受信ステータスを確認します。プロバイダーのダッシュボードとラベルは変更される可能性があるため、宛先の最新の RTMP 指示を使用してください。ストリームキーはパスワードのように扱い、会議のチャットや記事のスクリーンショットに公開しないでください。ローカルストレージへの録画とライブストリームの RTMP サービスへの送信は、関連する Jibri 機能ですが、宛先とチェックが異なります。

故障箇所を特定してトラブルシューティングを行う

• 録画やストリームのアクションが表示されない場合：アクティブな環境ファイルに が存在し、変更後に一致する Compose スタックが再作成されたことを確認ENABLE_RECORDING=1してください。実行中のコンテナ内のファイルを編集するのではなく、生成された Web、Prosody、および Jicofo の設定を確認してください。Docker はホストの入力からサービス設定を再生成します。
• アクションは表示されますが、Jibriが参加できません。JibriとJicofoのログを調べて、XMPP認証またはMUCエラーがないか確認してください。内部ホスト、レコーダードメイン、醸​​造所名、および両方の内部パスワードが、同じComposeリリースに対して正しく設定されていることを確認してください。
• コンテナが終了または再起動した場合：ログを確認し、ストレージパスが欠落しているか書き込み不可になっているかを確認してください。最新のルートレスイメージでは、マウントされたディレクトリがUID/GID 1000で書き込み可能であることを確認してください。また、ホストメモリと、公式のJibri Composeファイルで提供される共有メモリ構成も確認してください。
• セッションは開始されるが、録画ファイルが表示されない場合：設定された録画ディレクトリがホストボリュームに正しくマッピングされていること、およびセッションが正常に停止／終了されたことを確認してください。ディスクの空き容量とファイル権限を確認してください。
• 録画は正常に動作するがストリーミングが失敗する： RTMP取り込みURLとストリームキー、送信先の現在の要件、およびホストの送信ネットワークパスを再確認してください。証拠もなく余分な受信ポートを開くのではなく、Jibriログでストリーミング失敗の原因を確認してください。

会議はうまくいったものの、同時録音数を増やす必要がある場合は、意図的に容量を増やしてください。Jibriはインスタンスごとに1セッションに制限されているため、同時実行ジョブにはより多くのインスタンスが必要になります。また、Dockerハンドブックでは、複数のインスタンスに対してそれぞれ異なるオーディオループバックインターフェースを選択することを推奨しています。プールを拡張する前に、追加のインスタンスを1つテストし、各インスタンスが個別の録音を作成できることを確認してください。

これらの公式資料を使用してください

関連性のない Jibri バージョンの設定をコピーするのではなく、デプロイメントに合った手順に従ってください。Jitsi Docker ハンドブックには、Compose ワークフロー、記録変数、ストレージパス、ルートレスコンテナの権限、および最新の Jibri ノートが記載されています。Jibriプロジェクトの README には、Jibri の役割、シングルセッションの制限、および構成モデルについて説明されています。リリース固有の変数名とマウントについては、公式の Jibri Compose サービス定義と環境テンプレートを参照してください。