วิธีตั้งค่าเซิร์ฟเวอร์บันทึกและสตรีมมิ่ง Jibri สำหรับ Jitsi Meet

คู่มือ Docker ฉบับปัจจุบันของ Jitsi ระบุถึงการเปลี่ยนแปลงที่สำคัญในการใช้งาน: ตั้งแต่เวอร์ชันปัจจุบันstable-11146เป็นต้นไป คอนเทนเนอร์จะทำงานโดยใช้ UID/GID 1000 ที่ไม่มีสิทธิ์พิเศษ และไดเร็กทอรีข้อมูลถาวรจะต้องสามารถเขียนได้โดยผู้ใช้คอนเทนเนอร์นั้น บริการ Jibri ก็ไม่จำเป็นต้อง ใช้ SYS_ADMINความสามารถนี้อีกต่อไปแล้ว คู่มือฉบับเก่าที่แนะนำให้ใช้คอนเทนเนอร์ที่มีสิทธิ์พิเศษหรือ777สิทธิ์การเข้าถึงแบบกว้างๆ ไม่ควรนำไปใช้ในระบบปัจจุบันโดยไม่ตรวจสอบคำแนะนำเฉพาะเวอร์ชันก่อน

คู่มือนี้ใช้ Docker Compose สำหรับการติดตั้ง Jitsi Meet บนเซิร์ฟเวอร์ภายในองค์กรที่มีอยู่แล้ว ตัวอย่างที่ใช้เป็นตัวอย่างสมมติอย่างชัดเจน: ทีม Riverview ใช้งาน Jitsi อยู่แล้วที่meet.example.netจัดเก็บการตั้งค่าไว้ที่/opt/jitsi-meet-cfgและต้องการให้ผู้ดูแลบันทึกการประชุมในเครื่องและสตรีมไปยังปลายทาง RTMP เป็นครั้งคราว นี่เป็นเพียงตัวอย่างการตั้งค่า ไม่ใช่รายงานการติดตั้งหรือการทดสอบจริง

หมายเหตุประกอบภาพ:ภาพหน้าจอที่แสดงด้านล่างเป็นเพียงตัวอย่างแผนผัง ไม่ใช่ภาพที่บันทึกจากเซิร์ฟเวอร์จริง ผลลัพธ์คำสั่งและสถานะการประชุมที่แสดงเป็นเพียงภาพประกอบเท่านั้น

Jibri ทำอะไร และต้องการอะไรบ้าง

Jibri คือโครงสร้างพื้นฐานการออกอากาศของ Jitsi สำหรับการบันทึกหรือถ่ายทอดสดการประชุม โดยจะเข้าร่วมการประชุมผ่านเซสชันของเบราว์เซอร์ บันทึกเสียงและวิดีโอ จากนั้นเข้ารหัสเอาต์พุต ดังนั้นการตั้งค่า Jibri ที่ใช้งานได้จึงขึ้นอยู่กับบริการเว็บ Jitsi เซิร์ฟเวอร์ XMPP ของ Prosody และ Jicofo ที่ตกลงกันเกี่ยวกับบัญชีผู้บันทึกภายในและห้อง "brewery" ของ Jibri ซึ่งอินสแตนซ์ที่พร้อมใช้งานจะประกาศตัวเอง

ใช้การติดตั้ง Jitsi Meet แบบเต็มรูปแบบที่คุณเป็นผู้ดูแลระบบ Jibri ไม่สามารถเชื่อมต่อกับบริการสาธารณะ meet.jit.si ได้ราวกับว่าเป็นเซิร์ฟเวอร์ของคุณเอง โครงการ Jibri ต้นทางระบุว่าควรใช้งานบนเครื่องแยกต่างหากหรือเครื่องเสมือน โดยไม่มีภาระงานที่ไม่เกี่ยวข้องใดๆ ที่ใช้จอแสดงผลหรืออุปกรณ์เสียง แพ็กเกจการติดตั้ง Docker Compose อย่างเป็นทางการจะรวม Jibri ไว้เป็นบริการเพิ่มเติม สำหรับการติดตั้งขนาดเล็ก อาจเป็นคอนเทนเนอร์แยกต่างหากบนโฮสต์ Compose สำหรับการใช้งานอย่างต่อเนื่อง ควรจัดสรร CPU หน่วยความจำ และพื้นที่ดิสก์เฉพาะให้ หรือวางไว้บนโฮสต์ที่มีทรัพยากรที่เหมาะสม

Jibri หนึ่งอินสแตนซ์สามารถรองรับการบันทึกหรือสตรีมได้ครั้งละหนึ่งเซสชันเท่านั้น หาก Riverview คาดหวังเซสชันพร้อมกันหลายเซสชัน ควรวางแผนใช้ Jibri pool ที่มีหลายอินสแตนซ์ และคำนึงถึงการกำหนดค่าลูปแบ็กเสียงเพิ่มเติมตามที่อธิบายไว้ในคู่มือของ Jitsi การเพิ่มคอนเทนเนอร์โดยไม่มีอุปกรณ์เสียงเฉพาะไม่ใช่แผนการปรับขนาดที่สมบูรณ์

ขั้นตอนที่ 1: เตรียมสภาพแวดล้อม Docker สำหรับ Jitsi Meet

เริ่มต้นจากเวอร์ชันอย่างเป็นทางการของ Docker Jitsi Meet และไฟล์ Compose ที่ตรงกัน เก็บ.envไฟล์และไฟล์ Compose จากเวอร์ชันเดียวกัน ในไฟล์สภาพแวดล้อม ให้เปิดใช้งานการบันทึก:

ENABLE_RECORDING=1

การตั้งค่า Compose ของ Jitsi ใช้บัญชี XMPP ภายในสำหรับ Jibri เองและสำหรับเซสชันเบราว์เซอร์ของเครื่องบันทึก ตั้งค่ารหัสผ่านที่แข็งแกร่งและแตกต่างกันสำหรับ Jibri และเครื่องบันทึก และเก็บรักษาไว้เป็นความลับ สำหรับสแต็กใหม่เอี่ยมgen-passwords.shสคริปต์ของโครงการสามารถสร้างรหัสผ่านบริการภายในได้ แต่จะเปลี่ยนแปลงไฟล์สภาพแวดล้อม ดังนั้นควรสำรองข้อมูลไว้ก่อน หากสแต็ก Jitsi กำลังทำงานอยู่แล้ว อย่าสร้างรหัสผ่านใหม่ทุกครั้งโดยไม่ระมัดระวัง: ส่วนประกอบที่กำลังทำงานอยู่ทั้งหมดจะต้องได้รับข้อมูลประจำตัวที่อัปเดตแล้วที่ตรงกันในระหว่างการรีสตาร์ทตามแผน

สำหรับตัวอย่างของ Riverview นั้นENABLE_RECORDING=1สวิตช์ที่จำเป็นคือตัวที่กำหนด ในขณะที่เทมเพลตสภาพแวดล้อมของเวอร์ชันนั้นจะระบุชื่อและค่าเริ่มต้นสำหรับผู้ใช้ XMPP ผู้ใช้เครื่องบันทึก MUC ของ Brewery เส้นทางจัดเก็บข้อมูล และตัวเลือกอื่นๆ ห้ามวางรหัสผ่านลงในประเด็นสาธารณะ ภาพหน้าจอเทอร์มินัล หรือแชทการประชุมที่แชร์

ขั้นตอนที่ 2: สร้างพื้นที่จัดเก็บข้อมูลถาวรที่สามารถเขียนได้

ไฟล์บันทึกต้องคงอยู่แม้ว่าจะมีการเปลี่ยนคอนเทนเนอร์ ดังนั้นการตั้งค่า Compose ของ Jitsi จึงทำการเมานต์พื้นที่จัดเก็บข้อมูลถาวรบนโฮสต์สำหรับ 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 ให้คงการตั้งค่า volume-label จากไฟล์ Compose อย่างเป็นทางการที่ตรงกันแทนที่จะลบออก

ไดเร็กทอรีสำหรับบันทึกข้อมูลของคอนเทนเนอร์สามารถกำหนดค่าได้ ตัวอย่างที่ระบุไว้ในคู่มือJIBRI_RECORDING_DIRคือ/storage/recordingsซึ่งติดตั้งอยู่ใต้ไดเร็กทอรีจัดเก็บข้อมูล Jibri ของโฮสต์ ตรวจสอบเทมเพลตสภาพแวดล้อมของเวอร์ชันของคุณก่อนทำการเปลี่ยนแปลง ตรวจสอบให้แน่ใจว่าโฮสต์มีพื้นที่ว่างในดิสก์เพียงพอและมีแผนการเก็บรักษาข้อมูล: เครื่องบันทึกที่ใช้งานได้อาจทำให้พื้นที่จัดเก็บข้อมูลขนาดเล็กเต็มได้เมื่อเวลาผ่านไป

ขั้นตอนที่ 3: เริ่มใช้งาน Jibri โดยใช้ไฟล์ Compose ที่ตรงกัน

จากไดเร็กทอรีที่มีไฟล์ Jitsi Compose อย่างเป็นทางการและไฟล์การกำหนดค่าสภาพแวดล้อม ให้เริ่มสแต็กพื้นฐานโดยใช้การตั้งค่า Jibri override:

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 ภายในของ Brewery ที่คาดไว้ หากบันทึกแสดงข้อผิดพลาดในการตรวจสอบสิทธิ์ ให้เปรียบเทียบโดเมน XMPP, MUC ภายใน, บัญชี Jibri, บัญชีผู้บันทึก และรหัสผ่านในไฟล์สภาพแวดล้อมและการกำหนดค่าบริการที่สร้างขึ้น ค่าต่างๆ ต้องตรงกัน การเปลี่ยนรหัสผ่านของส่วนประกอบเพียงส่วนเดียวจะทำให้การเชื่อมต่อล้มเหลว

ขั้นตอนที่ 4: ทดสอบการบันทึกและการสตรีม RTMP

เข้าร่วมการประชุมทดสอบโดยmeet.example.netใช้บัญชีผู้ดูแล ในเมนู "การดำเนินการเพิ่มเติม" ของการประชุม ตรวจสอบว่ามีการบันทึกและการถ่ายทอดสดให้ใช้งานได้หรือไม่ เริ่มต้นด้วยการบันทึกสั้นๆ รอจนกว่าการประชุมจะสิ้นสุด และตรวจสอบเส้นทางการจัดเก็บข้อมูลโฮสต์ที่กำหนดค่าไว้สำหรับไฟล์บันทึก การบันทึกควรยังคงอยู่หลังจากสร้างคอนเทนเนอร์ Jibri ขึ้นใหม่ เนื่องจากไฟล์บันทึกจะถูกจัดเก็บไว้ในวอลุ่มโฮสต์ที่เชื่อมต่ออยู่ แทนที่จะจัดเก็บไว้ในเลเยอร์ที่เขียนได้ของคอนเทนเนอร์เท่านั้น

สำหรับการถ่ายทอดสด ให้ใช้ URL การนำเข้า RTMP และคีย์สตรีมที่ได้รับจากบริการปลายทาง ป้อนค่าผู้ให้บริการปัจจุบันในเวิร์กโฟลว์การถ่ายทอดสดของ Jitsi และตรวจสอบสถานะการแสดงตัวอย่างหรือสถานะการรับของปลายทาง แดชบอร์ดและป้ายกำกับของผู้ให้บริการอาจเปลี่ยนแปลงได้ ดังนั้นให้ใช้คำแนะนำ RTMP ปัจจุบันของปลายทาง โปรดปฏิบัติต่อคีย์สตรีมเหมือนรหัสผ่าน: อย่าเผยแพร่ในแชทการประชุมหรือภาพหน้าจอบทความ การบันทึกไปยังที่จัดเก็บข้อมูลภายในเครื่องและการส่งการถ่ายทอดสดไปยังบริการ RTMP เป็นฟังก์ชันที่เกี่ยวข้องของ Jibri แต่มีปลายทางและการตรวจสอบที่แตกต่างกัน

แก้ไขปัญหาโดยระบุจุดที่เกิดความล้มเหลว

• ไม่มีการบันทึกหรือการสตรีมปรากฏขึ้น:ตรวจสอบENABLE_RECORDING=1ว่ามีอยู่ในไฟล์สภาพแวดล้อมที่ใช้งานอยู่ และตรวจสอบว่าสแต็ก Compose ที่ตรงกันได้รับการสร้างใหม่หลังจากทำการเปลี่ยนแปลงแล้ว ตรวจสอบการกำหนดค่าเว็บ Prosody และ Jicofo ที่สร้างขึ้นแทนการแก้ไขไฟล์ภายในคอนเทนเนอร์ที่กำลังทำงานอยู่ เนื่องจาก Docker จะสร้างการกำหนดค่าบริการใหม่จากอินพุตของโฮสต์
• การดำเนินการปรากฏขึ้น แต่ Jibri ไม่สามารถเข้าร่วมได้:ตรวจสอบบันทึกของ Jibri และ Jicofo เพื่อหาข้อผิดพลาดในการตรวจสอบสิทธิ์ XMPP หรือ MUC ตรวจสอบโฮสต์ภายใน โดเมนตัวบันทึก ชื่อโรงเบียร์ และรหัสผ่านภายในทั้งสองกับเวอร์ชัน Compose เดียวกัน
• หากคอนเทนเนอร์ปิดตัวลงหรือรีสตาร์ท:ตรวจสอบบันทึกการทำงานเพื่อหาเส้นทางจัดเก็บข้อมูลที่หายไปหรือไม่สามารถเขียนได้ สำหรับอิมเมจแบบ rootless ในปัจจุบัน ให้ตรวจสอบว่าไดเร็กทอรีที่เมานต์นั้นสามารถเขียนได้โดย UID/GID 1000 นอกจากนี้ ให้ตรวจสอบหน่วยความจำของโฮสต์และการกำหนดค่าหน่วยความจำที่ใช้ร่วมกันซึ่งจัดเตรียมไว้ในไฟล์ Jibri Compose อย่างเป็นทางการด้วย
• การบันทึกเริ่มต้นขึ้น แต่ไม่มีไฟล์บันทึกปรากฏขึ้น:โปรดตรวจสอบว่าไดเร็กทอรีการบันทึกที่กำหนดค่าไว้ตรงกับไดรฟ์ของโฮสต์ และการบันทึกหยุด/สิ้นสุดอย่างถูกต้อง ตรวจสอบพื้นที่ว่างในดิสก์และสิทธิ์การเข้าถึงไฟล์
• การบันทึกทำงานได้ แต่การสตรีมล้มเหลว:ตรวจสอบ URL การนำเข้า RTMP และคีย์สตรีม ข้อกำหนดปัจจุบันของปลายทาง และเส้นทางเครือข่ายขาออกของโฮสต์อีกครั้ง ตรวจสอบบันทึกของ Jibri เพื่อหาสาเหตุของการสตรีมล้มเหลว แทนที่จะเปิดพอร์ตขาเข้าเพิ่มเติมโดยไม่มีหลักฐาน

เมื่อการประชุมดำเนินไปได้ แต่คุณต้องการบันทึกพร้อมกันมากขึ้น ให้เพิ่มความจุอย่างรอบคอบ ข้อจำกัดของ Jibri ที่อนุญาตให้บันทึกได้หนึ่งเซสชันต่ออินสแตนซ์ หมายความว่างานที่ทำงานพร้อมกันต้องใช้อินสแตนซ์มากกว่านั้น คู่มือ Docker ยังระบุให้เลือกอินเทอร์เฟซลูปแบ็กเสียงที่แตกต่างกันสำหรับหลายอินสแตนซ์ ทดสอบอินสแตนซ์เพิ่มเติมหนึ่งรายการก่อนที่จะขยายกลุ่ม และตรวจสอบว่าแต่ละอินสแตนซ์สามารถสร้างการบันทึกแยกต่างหากได้

โปรดใช้เอกสารอ้างอิงอย่างเป็นทางการเหล่านี้

ปฏิบัติตามคำแนะนำที่ตรงกับการใช้งานของคุณ แทนที่จะคัดลอกการตั้งค่าจาก Jibri เวอร์ชันอื่นที่ไม่เกี่ยวข้องคู่มือ Jitsi Dockerอธิบายขั้นตอนการทำงานของ Compose การบันทึกตัวแปร เส้นทางจัดเก็บข้อมูล สิทธิ์การเข้าถึงคอนเทนเนอร์แบบ rootless และบันทึกย่อของ Jibri ในปัจจุบันไฟล์ README ของโครงการ Jibriอธิบายบทบาทของ Jibri ข้อจำกัดของเซสชันเดียว และรูปแบบการกำหนดค่าคำจำกัดความบริการ Compose อย่างเป็นทางการของ Jibriและเทมเพลตสภาพแวดล้อมเป็นแหล่งข้อมูลที่ถูกต้องสำหรับชื่อตัวแปรและการเมานต์เฉพาะ รุ่น