如何為 Jitsi Meet 設定 Jibri 錄製和串流媒體伺服器

Jitsi 目前的 Docker 手冊記錄了一項重要的部署變更：自版本發布以來stable-11146，其容器以非特權使用者（UID/GID 1000）運行，且持久化資料目錄必須對該容器使用者俱有寫入權限。 Jibri 服務也不再需要此SYS_ADMIN功能。建議使用特權容器或廣泛權限的舊版指南777不應直接複製到目前部署中，除非已查閱特定版本的說明。

本教學課程使用 Docker Compose 為現有的自架 Jitsi Meet 安裝提供設定。範例基於假設：Riverview 團隊已在本地運行 Jitsi meet.example.net，並將設定檔儲存在 `/etc/jitsi.conf` 目錄下/opt/jitsi-meet-cfg，他們希望主持人能夠本地錄製會議，並偶爾將會議內容串流到 RTMP 目標位置。本教學僅為範例配置，並非實際安裝或測試的報告。

圖示說明：以下螢幕視圖為示意圖範例，並非真實伺服器的截圖；顯示的指令輸出和會議狀態僅供參考。

Jibri 的功能及其需求

Jibri 是 Jitsi 的廣播基礎設施，用於錄製或直播會議。它透過瀏覽器會話加入會議，捕獲音頻和視頻，然後對輸出進行編碼。因此，Jibri 的正常運作取決於 Jitsi Web 服務、Prosody XMPP 伺服器和 Jicofo 是否就內部錄製帳戶以及 Jibri 的「釀造室」（可用實例在此發布自身資訊）達成協議。

請使用您管理的完整 Jitsi Meet 安裝；Jibri 不能像您自己的伺服器一樣連接到公共的 meet.jit.si 服務。 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 配置使用內部 XMPP 帳戶來管理 Jibri 本身和錄製器瀏覽器會話。請為 Jibri 和錄音機設定強密碼，並確保密碼安全。對於全新的 Jitsi 堆疊，專案gen-passwords.sh腳本可以產生內部服務密碼。該腳本會修改環境變數文件，因此請務必先備份該文件。如果 Jitsi 堆疊已在運行，請勿隨意重新產生所有密碼：所有正在運行的元件都必須在計劃重新啟動期間接收匹配的更新憑證。

以 Riverview 為例，ENABLE_RECORDING=1需要使用 `--switch` 參數，而發布環境模板則提供了 XMPP 使用者、錄製器使用者、brewery MUC、儲存路徑和其他選項的名稱和預設值。請勿將密碼貼到公開問題、終端螢幕截圖或分享會議聊天記錄中。

步驟 2：建立可寫入持久性存儲

錄製內容必須在容器替換後仍然存在，因此 Jitsi 的 Compose 配置會為 Jibri 掛載持久主機儲存。例如CONFIG=/opt/jitsi-meet-cfg，主機目錄為 `<host_directory>` /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 儲存目錄下。更改前請檢查您版本的環境範本。確認主機有足夠的可用磁碟空間和保留策略：正在執行的錄製器可能會隨著時間的推移填滿一個小磁碟區。

步驟 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 主機，並加入預期的內部 Brewery MUC。如果日誌顯示驗證失敗，請比較環境檔案和產生的服務配置中的 XMPP 網域、內部 MUC、Jibri 帳戶、錄製器帳戶和密碼。這些值必須完全匹配；僅更改其中一個組件的密碼會導致握手失敗。

步驟 4：測試錄影和 RTMP 串流

使用主持人帳號加入測試會議meet.example.net。在會議的「更多操作」選單中，確認錄音和直播功能可用。先進行一次簡短的錄製，等待會議結束，然後檢查配置的主機儲存路徑以尋找輸出檔案。即使 Jibri 容器重新創建，錄製檔案也應該仍然存在，因為它儲存在已掛載的主機磁碟區上，而不僅僅是容器的可寫入層。

對於直播串流，請使用目標服務提供的 RTMP 接收 URL 和串流金鑰。在 Jitsi 的直播流程工作流程中輸入目前提供者的值，並檢查目標服務的預覽或接收狀態。提供者的控制面板和標籤可能會更改，因此請使用目標服務目前的 RTMP 指令。請像對待密碼一樣對待串流密鑰：不要將其發佈到會議聊天或文章截圖中。錄製到本機儲存和將直播串流傳送到 RTMP 服務是 Jibri 的相關功能，但它們的目標服務和檢查方式不同。

按故障點進行故障排除

• 沒有錄製或串流操作：請確認ENABLE_RECORDING=1活動環境檔案中是否有對應配置，以及變更後是否已重新建立相符的 Compose 堆疊。請檢查產生的 web、Prosody 和 Jicofo 配置，而不是編輯執行容器內的檔案；Docker 會根據主機輸入重新產生服務配置。
• 操作已顯示，但 Jibri 無法加入：請檢查 Jibri 和 Jicofo 日誌，尋找 XMPP 驗證或 MUC 錯誤。請根據 Compose 版本驗證內部主機、錄音機網域、brewery 名稱以及兩個內部密碼。
• 容器退出或重新啟動：檢查其日誌，查看是否有缺失或不可寫入的儲存路徑。對於目前的無根鏡像，請驗證掛載的目錄是否對 UID/GID 1000 可寫入。同時檢查主機記憶體和官方 Jibri Compose 檔案中提供的共享記憶體配置。
• 會話已啟動，但未產生錄製檔案：請確認配置的錄製目錄已對應到主機卷，並且會話已正常停止/結束。請檢查可用磁碟空間和檔案權限。
• 錄音功能正常，但串流播放失敗：請重新檢查 RTMP 接收 URL 和串流金鑰、目標伺服器的目前要求以及主機的出站網路路徑。請查看 Jibri 日誌以查找串流媒體播放失敗的原因，而不是在沒有證據的情況下開啟額外的入站連接埠。

如果會議進行得很順利，但您需要更多並發錄製，請有意識地增加容量。 Jibri 每個實例只能進行一個會話的限制意味著並發任務需要更多實例；Docker 手冊也建議為多個實例選擇不同的音訊回環介面。在擴展實例池之前，請先測試一個額外的實例，並驗證每個實例都能建立獨立的錄製。

請參考以下官方資料

請遵循與您的部署環境相符的說明，而不是從不相關的 Jibri 版本複製設定。 Jitsi Docker 手冊詳細介紹了 Compose 工作流程、記錄變數、儲存路徑、無根容器權限以及目前的 Jibri 注意事項。 Jibri專案 README 檔案解釋了 Jibri 的角色、單一會話限制和設定模型。官方的 Jibri Compose 服務定義和環境範本是特定於版本的變數名稱和掛載點的權威來源。