แก้ไขปัญหาการรีสตาร์ทวนซ้ำไม่สิ้นสุดของคอนเทนเนอร์ Docker ใน Jitsi Meet

การติดตั้ง Jitsi Meet อาจทำงานได้เพียงชั่วครู่แล้วแสดงสถานะ "กำลังรีสตาร์ท" ใน Docker Desktop หรือในไฟล์docker compose ps.document.js โดยปกติ Docker จะใช้การตั้งค่าการรีสตาร์ทที่กำหนดไว้หลังจากกระบวนการหยุดทำงาน วิธีแก้ไขที่ได้ผลในระยะยาวคือการระบุบริการที่หยุดทำงาน อ่านบันทึกการทำงานล่าสุด และแก้ไขข้อผิดพลาดในการเริ่มต้น การรีสตาร์ททั้งระบบซ้ำๆ หรือการลบวอลุ่มอาจซ่อนหลักฐานหรือลบข้อมูลถาวรได้

1. ค้นหาบริการที่กำลังรีสตาร์ท

เรียกใช้ Compose จากไดเร็กทอรีที่มีไฟล์ Compose เดียวกันกับ.envที่ใช้ในการติดตั้งนี้ หากคุณปกติใช้ไฟล์ Compose เพิ่มเติม โปรไฟล์ หรือ--env-fileตัวเลือกอื่นๆ ให้ใส่ตัวเลือกเหล่านั้นด้วย

docker compose ps -a

ตรวจสอบแต่ละบริการแยกกัน บริการหลักได้แก่web, prosody, jicofo, และjvb; บริการเสริม เช่นjibriหรือjigasiอาจปรากฏขึ้นได้เช่นกัน จดบันทึกบริการที่มีสถานะเป็นRestartingหรือ อย่างแม่นยำ Exitedบริการที่ล้มเหลวหนึ่งบริการไม่ได้หมายความว่าคอนเทนเนอร์ทุกตัวจะมีข้อผิดพลาดเดียวกัน

อ่านบันทึกส่วนท้ายของบริการนั้น โดยใช้การประทับเวลา:

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

แทนที่jicofoด้วยบริการที่ได้รับผลกระทบ เพิ่ม-fเพื่อตรวจสอบความพยายามในการเริ่มต้นระบบอีกครั้ง คู่มือ Jitsi Docker อธิบายวิธีสร้างบันทึก (log) สำหรับบริการต่างๆ หาก Docker ไม่สามารถส่งคืนบันทึกได้ ให้ตรวจสอบว่าไดรเวอร์การบันทึกที่กำหนดค่าไว้ในคอนเทนเนอร์นั้นรองรับการอ่านบันทึกหรือไม่

2. มองหาข้อความแจ้งเตือนอันตรายข้อแรก

เลื่อนไปที่ข้อผิดพลาดที่ชัดเจนแรกในแต่ละรอบการเริ่มต้นระบบ บรรทัดถัดไปอาจรายงานเพียงว่ากระบวนการหยุดทำงานและ Docker กำลังเริ่มต้นใหม่ สาเหตุหลักที่พบบ่อย ได้แก่:

• รหัสผ่านที่จำเป็นหายไป: Jitsi ได้ลบรหัสผ่านเริ่มต้นสำหรับบัญชีบริการภายในออกแล้ว และบริการที่ต้องการรหัสผ่านเหล่านี้จะไม่สามารถเริ่มต้นได้จนกว่าจะมีการตั้งค่ารหัสผ่าน จากไดเร็กทอรีการปรับใช้มาตรฐาน ให้เรียกใช้./gen-passwords.shสคริปต์ที่ให้มาเพื่อกรอกค่าที่จำเป็นลงใน.envไฟล์ .js โปรดปกป้องไฟล์นั้นและอย่าเปิดเผยข้อมูลลับในไฟล์นั้นในคำขอรับการสนับสนุน
• การกำหนดค่าไม่ถูกต้องหรือไม่สามารถอ่านได้:ตรวจสอบเส้นทางไฟล์และไวยากรณ์ที่ระบุในข้อผิดพลาด การกำหนดค่า Prosody, Jicofo หรือ JVB แบบกำหนดเองอาจทำให้บริการนั้นไม่สามารถเริ่มต้นได้
• ไดเร็กทอรีที่เชื่อมต่อหายไปหรือเขียนไม่ได้:ตรวจสอบเส้นทางโฮสต์ที่แน่นอนในข้อผิดพลาดและเปรียบเทียบกับแผนที่การเชื่อมต่อของบริการ หลีกเลี่ยงการเปลี่ยนแปลงสิทธิ์การเข้าถึงในโครงสร้างการกำหนดค่าทั้งหมด
• ความล้มเหลวของรูปภาพหรือจุดเริ่มต้น:ตรวจสอบว่าไดเร็กทอรีการปรับใช้ ไฟล์ Compose และแท็กรูปภาพเป็นของเวอร์ชันที่เข้ากันได้หรือไม่ โดยเฉพาะอย่างยิ่งหากลูปเริ่มต้นหลังจากการอัปเดต
• ปัญหาหน่วยความจำไม่เพียงพอ:ตรวจสอบสถานะของคอนเทนเนอร์และหน่วยความจำของโฮสต์ การปิดระบบเนื่องจากหน่วยความจำไม่เพียงพอต้องใช้วิธีแก้ไขที่แตกต่างจากการตั้งค่าที่ไม่ถูกต้อง

นโยบายการรีสตาร์ทของ Docker อธิบายว่าทำไมกระบวนการจึงกลับมาทำงานอีกครั้งหลังจากหยุดทำงาน แต่ไม่ได้อธิบายว่าทำไมกระบวนการจึงหยุดทำงาน ให้พิจารณาRestartingอาการของปัญหา และตรวจสอบบันทึกการทำงานของบริการเป็นหลักฐาน

3. ตรวจสอบความถูกต้องของสภาพแวดล้อมและสร้างไฟล์

ตรวจสอบให้แน่ใจว่าคุณกำลังแก้ไขไฟล์ที่ Compose โหลดจริง ๆ ข้อผิดพลาดที่พบบ่อยคือการเปลี่ยนแปลงไฟล์หนึ่ง.envในขณะที่ Compose กำลังอ่านไฟล์อื่นจากไดเร็กทอรีอื่นหรือจากไฟล์ที่ระบุไว้อย่างชัดเจน--env-fileตรวจสอบความถูกต้องของการกำหนดค่าก่อนที่จะสร้างคอนเทนเนอร์ใหม่:

docker compose config --quiet

หาก Compose รายงานข้อผิดพลาด ให้แก้ไขไฟล์ YAML การแทนที่ตัวแปร ไฟล์อ้างอิงที่หายไป หรือตัวเลือกที่มันระบุ การเรียกใช้docker compose configโดยไม่แก้ไข--quietอาจช่วยตรวจสอบโมเดลที่แก้ไขแล้วได้ แต่ผลลัพธ์อาจแสดงรหัสผ่านที่แทรกเข้าไป อย่าแชร์ผลลัพธ์ที่ไม่ได้แก้ไข

สำหรับการติดตั้ง Jitsi มาตรฐาน ให้เปรียบเทียบ.envกับไฟล์env.exampleจากเวอร์ชันเดียวกันและยืนยันว่ามีรหัสผ่านภายในที่จำเป็นอยู่ หากคุณใช้ไฟล์ Compose ที่กำหนดเอง ให้ตรวจสอบว่าตัวแปรที่จำเป็นส่งไปยังบริการที่ถูกต้อง ใช้สคริปต์รหัสผ่านที่ให้มาแทนการใช้ช่องว่าง หากคุณเปลี่ยนรหัสผ่าน ให้รักษาการกำหนดค่าส่วนประกอบที่ตรงกันให้สอดคล้องกัน

โปรเจ็กต์ Jitsi แยกไฟล์เวอร์ชันปกติออกจากโค้ดสำหรับการพัฒนาและอิมเมจที่ไม่เสถียร หลีกเลี่ยงการรวมไดเร็กทอรี Compose เก่า แท็กอิมเมจที่ไม่เกี่ยวข้อง และไฟล์จากเวอร์ชันอื่นในระหว่างการแก้ไขปัญหา

4. ตรวจสอบการเชื่อมต่อและการอนุญาตในไฟล์คอนฟิก

เปรียบเทียบรายการปริมาณของบริการกับเส้นทางโฮสต์จริง การพิมพ์ผิดCONFIGค่าที่ไม่คาดคิด หรือไดเร็กทอรีการทำงานของ Compose ที่แตกต่างกัน อาจทำให้การปรับใช้ใช้ไดเร็กทอรีการกำหนดค่าอื่น

สิทธิ์การเข้าถึงขึ้นอยู่กับเวอร์ชันของ Jitsi คู่มือระบุว่าตั้งแต่เวอร์ชัน 1 เป็นต้นไปstable-11146คอนเทนเนอร์จะทำงานในฐานะผู้ใช้ที่ไม่ได้รับสิทธิ์พิเศษ โดยใช้ระบบไฟล์คอนเทนเนอร์แบบอ่านอย่างเดียว ไดเร็กทอรีการกำหนดค่าเป็นอินพุต ข้อมูลที่เขียนได้จะถูกแยกออกเป็น ไดเร็กทอรี `/etc/jitsi` storageและtmp`/etc/jitsi` ซึ่งต้องสามารถเขียนได้โดย UID/GID 1000 เวอร์ชันเก่ากว่าจะใช้โครงสร้างอื่น โปรดปฏิบัติตามคู่มือสำหรับเวอร์ชันที่คุณใช้งาน แทนที่จะนำสูตรการกำหนดสิทธิ์สำหรับเวอร์ชันอื่นมาใช้ซ้ำ

หากบันทึกระบุว่ามีไดเร็กทอรีหายไปหรือไม่สามารถเขียนได้ ให้แก้ไขเส้นทางนั้นโดยเฉพาะ อย่าใช้คำสั่งแบบกว้างๆ เช่นchmod -R 777การแก้ไขไดเร็กทอรีการกำหนดค่า Jitsi ทั้งหมด เพราะอาจทำให้ความปลอดภัยลดลงโดยที่ยังไม่ได้แก้ไขเส้นทางที่เชื่อมต่ออยู่

5. ตรวจสอบสถานะการออกและการเปลี่ยนแปลงล่าสุด

Docker สามารถรายงานรหัสการออกจากคอนเทนเนอร์ สถานะหน่วยความจำไม่เพียงพอ จำนวนการรีสตาร์ท และข้อผิดพลาดของดีมอนได้ ขั้นแรกให้หา ID ของคอนเทนเนอร์สำหรับบริการที่ล้มเหลว:

docker compose ps -q jicofo

จากนั้นแทนที่ด้วยรหัสที่ได้รับ:

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

จำนวนการรีสตาร์ทที่เพิ่มขึ้นยืนยันว่ามีการพยายามซ้ำหลายครั้ง หากเป็นเช่นนั้นoom=trueให้ตรวจสอบขีดจำกัดหน่วยความจำของโฮสต์หรือคอนเทนเนอร์ และบันทึกระบบ รหัสการออกที่ไม่เป็นศูนย์เพียงอย่างเดียวไม่ถือเป็นการวินิจฉัยปัญหา ให้เปรียบเทียบกับบันทึกบริการ

หากลูปเริ่มต้นหลังจากอัปเดต โปรดสังเกตสิ่งที่เปลี่ยนแปลงไป เช่น ไฟล์รุ่น แท็กรูปภาพ รหัสผ่าน การเชื่อมต่อแบบ bind mount หรือการกำหนดค่าแบบกำหนดเอง สำรองข้อมูลการกำหนดค่าและข้อมูลถาวรก่อนเปลี่ยนเวอร์ชัน กู้คืนไฟล์และรูปภาพ 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

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

สำหรับข้อมูลอ้างอิง โปรดดูคู่มือการโฮสต์ด้วยตนเองของ Jitsi Meet Docker , ตัวอย่างตัวแปรสภาพแวดล้อมของโครงการ , เอกสารนโยบายการรีสตาร์ทของ Docker , ข้อมูลอ้างอิงบันทึก Composeและข้อมูลอ้างอิงการตรวจสอบคอนเทนเนอร์