สำหรับการใช้งาน Collabora Online แบบหลายโหนด ให้ใช้ Helm chart ของ Collabora บน Kubernetes โดยอยู่เบื้องหลัง ingress หรือ reverse proxy ที่จะรักษาการร้องขอเอกสารเดียวกันทั้งหมดไว้ใน pod เดียวกันของ Collabora ความสัมพันธ์ของเซสชันนี้มีความสำคัญอย่างยิ่ง: การกระจายโหลดแบบ round-robin ทั่วไปอาจส่งคำขอแก้ไขและคัดลอกข้อมูลของผู้ใช้ไปยัง pod ต่างๆ และขัดขวางการแก้ไขร่วมกัน ตัวอย่างด้านล่างใช้ replicas สามตัว, NGINX Ingress และจำนวน replicas คงที่ แทนที่ชื่อโฮสต์และ TLS secret ในตัวอย่างด้วยชื่อและรหัสลับ TLS ของคุณเอง
คำสั่งในเทอร์มินัลจะเพิ่มที่เก็บ Helm chart อย่างเป็นทางการของ Collabora ก่อนการปรับใช้
คุณต้องเตรียมอะไรบ้างก่อนที่จะเพิ่มสำเนาข้อมูล?
คุณต้องมีคลัสเตอร์ Kubernetes ที่ทำงานอยู่ โดยมีโหนดผู้ปฏิบัติงานอย่างน้อยสองโหนด, Helm, ตัวควบคุม Ingress ที่รองรับกฎ Affinity ที่จำเป็น, ชื่อ DNS เช่นoffice.example.comและใบรับรอง TLS สำหรับชื่อนั้น แต่ละ Pod ของ Collabora ต้องสามารถเข้าถึง Nextcloud ได้ที่ต้นทาง WOPI สาธารณะ เช่นhttps://cloud.example.comCODE และ Nextcloud เป็นบริการที่แยกจากกัน คู่มือนี้จะกำหนดค่าระดับ Collabora จากนั้นเชื่อมต่อ URL สาธารณะกับ Nextcloud Office
ควรใช้การตั้งค่าแบบหลายสำเนา (multi-replica) ตามที่ระบุไว้ในเอกสารของ Collabora chart แทนการวางคอนเทนเนอร์ Docker อิสระหลายตัวไว้ด้านหลัง load balancer ทั่วไป load balancer ที่กระจายคำขอแต่ละรายการโดยไม่คำนึงถึงแหล่งที่มาของ WOPI ในเอกสาร อาจทำให้เซสชันล้มเหลวได้ คู่มือนี้เป็นไปตามคำแนะนำอย่างเป็นทางการของ Collabora Helm chart ที่เผยแพร่เมื่อวันที่ 10 ตุลาคม 2026 ค่าของ chart อาจมีการเปลี่ยนแปลง ดังนั้นโปรดตรวจสอบค่าสำหรับ chart เวอร์ชันที่คุณวางแผนจะติดตั้ง
1. กำหนดค่าสำเนาข้อมูล ความสัมพันธ์ขาเข้า และโฮสต์ WOPI
เพิ่มแหล่งเก็บข้อมูลแผนภูมิ อัปเดตดัชนี และตรวจสอบค่าเริ่มต้นปัจจุบันของแผนภูมิก่อนที่จะเขียนไฟล์กำหนดค่าเพิ่มเติมของคุณ:
helm repo add collabora https://collaboraonline.github.io/online/
helm repo update
helm show values collabora/collabora-online
สร้างmy_values.yamlโดยใช้การตั้งค่าหลักด้านล่าง ตัวอย่างนี้ใช้คำอธิบายประกอบ NGINX Ingress ที่แสดงใน README ของแผนภูมิ Collabora ซึ่งจะทำการแฮชเพื่อWOPISrcให้คำขอที่ผูกกับเอกสารเดียวกันไปถึงพอดเดียวกัน นอกจากนี้ยังยุติ TLS สาธารณะที่ ingress ด้วย การตั้งค่าเซิร์ฟเวอร์ Collabora ที่แสดงไว้เป็นไปตามรูปแบบ TLS ที่ยุติผ่านพร็อกซี
ไฟล์ค่าจะกำหนดจำนวนสำเนาคงที่และกำหนดเส้นทางการร้องขอของแต่ละเอกสารผ่าน WOPISrc
replicaCount: 3
autoscaling:
enabled: false
ingress:
enabled: true
className: nginx
annotations:
nginx.ingress.kubernetes.io/upstream-hash-by: "$arg_WOPISrc"
nginx.ingress.kubernetes.io/proxy-body-size: "0"
nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "600"
hosts:
- host: office.example.com
paths:
- path: /
pathType: ImplementationSpecific
tls:
- secretName: office-example-tls
hosts:
- office.example.com
collabora:
aliasgroups:
- host: "https://cloud.example.com:443"
extra_params: --o:ssl.enable=false --o:ssl.termination=true
ข้อมูลaliasgroupsที่ใช้คือโฮสต์ Nextcloud WOPI ไม่ใช่ชื่อโฮสต์ของ Collabora ให้ใช้ชื่อที่แคบและตรงตามรูปแบบ ชื่อโฮสต์ และพอร์ตที่ Nextcloud ระบุไว้ รหัสลับ TLS ของ ingress ต้องมีอยู่ใน namespace ของ ingress และต้องมีใบรับรองที่ถูกต้อง หาก TLS สิ้นสุดที่อื่น ให้ทำตามรูปแบบพร็อกซีที่ตรงกันในเอกสาร chart แทนที่จะคัด ลอกแฟล็กoffice.example.comทั้งสองโดยไม่ ตรวจสอบextra_params
มีข้อควรระวังเกี่ยวกับการปรับขนาดอัตโนมัติที่ขึ้นอยู่กับเวอร์ชัน: ตัวอย่างในไฟล์ README ของแผนภูมิจะปิดใช้งานการปรับขนาดอัตโนมัติและเตือนว่าการปรับขนาดอาจรบกวนการแก้ไขร่วมกันและการคัดลอก/วาง ในขณะที่ไฟล์ค่าที่เผยแพร่ในปัจจุบันมีการเปิดใช้งานการปรับขนาดอัตโนมัติโดยค่าเริ่มต้น เพื่อให้ได้คลัสเตอร์เริ่มต้นที่คาดการณ์ได้ ให้ปิดใช้งานการปรับขนาดอัตโนมัติอย่างชัดเจนและเลือกจำนวนสำเนาคงที่ พิจารณาการปรับขนาดอัตโนมัติอีกครั้งหลังจากตรวจสอบคำแนะนำในเวอร์ชันแผนภูมิที่แน่นอนและทดสอบการขยายขนาดและการลดขนาดด้วยเซสชันการแก้ไขจริงแล้ว
2. ติดตั้งแผนภูมิและตรวจสอบตำแหน่งของพ็อด
ติดตั้งชาร์ตลงในเนมสเปซที่กำหนดไว้ เอกสารเกี่ยวกับรูปแบบคำสั่งนี้อยู่ในคลังชาร์ตอย่างเป็นทางการ:
helm install --create-namespace \
--namespace collabora \
collabora-online collabora/collabora-online \
-f my_values.yaml
จากนั้นตรวจสอบว่าการปรับใช้ถึงจำนวนสำเนาที่ต้องการแล้ว และดูว่าโหนดผู้ปฏิบัติงานใดเป็นโฮสต์ของพอด:
ใช้รายการพ็อดแบบละเอียดเพื่อตรวจสอบความพร้อมใช้งานและโหนดที่กำหนดให้กับแต่ละสำเนา
kubectl get pods -n collabora -o wide
kubectl get ingress -n collabora
helm status collabora-online -n collabora
ตรวจสอบให้แน่ใจว่าพอดทั้งสามพร้อมใช้งาน (Ready) แล้ว อินเกรส (Ingress) มีโฮสต์ที่คาดหวังไว้ และมีการกระจายสำเนา (Replicas) ไปยังโหนดผู้ปฏิบัติงาน (Worker Node) หากต้องการความยืดหยุ่นในระดับโหนด การนับจำนวนสำเนาเพียงอย่างเดียวไม่ได้รับประกันว่า Kubernetes จะวางพอดไว้บนโหนดที่แยกจากกัน เทมเพลตชาร์ตอย่างเป็นทางการแสดงตัวเลือกโหนด (Node Selector) ความสัมพันธ์ (Affinity) และการตั้งค่าความทนทาน (Toleration) กำหนดค่ากฎการจัดกำหนดการที่เหมาะสมสำหรับคลัสเตอร์ของคุณและตรวจสอบความถูกต้องของชาร์ตที่แสดงผลก่อนที่จะนำไปใช้ หากชาร์ตเวอร์ชันของคุณไม่แสดงนโยบายที่คุณต้องการ ให้ใช้ส่วนขยายชาร์ตที่รองรับหรือการปรับแต่งการปรับใช้ Kubernetes แทนที่จะสันนิษฐานว่าพอดกระจายอยู่ทั่วไป
3. เชื่อมต่อ Nextcloud และตรวจสอบความสัมพันธ์ของเอกสาร
ใน Nextcloud ให้ติดตั้งหรือเปิดใช้งาน แอป Nextcloud Officeจากนั้นเปิดการตั้งค่าการดูแลระบบ → Officeเลือกเซิร์ฟเวอร์ Collabora ภายนอกและป้อนhttps://office.example.comURL ของเซิร์ฟเวอร์ URL นี้คือปลายทาง TLS สาธารณะที่ทั้งเซิร์ฟเวอร์ Nextcloud และเบราว์เซอร์ของผู้ใช้สามารถเข้าถึงได้ อย่าป้อน IP ของ pod หรือที่อยู่บริการภายใน
เปิดไฟล์ DOCX หรือ ODT สำหรับทดสอบจาก Nextcloud แก้ไขไฟล์นั้นจากสองเซสชันผู้ใช้ที่แตกต่างกัน และยืนยันว่าผู้ใช้ทั้งสองเห็นการเปลี่ยนแปลง ตรวจสอบเครื่องมือสำหรับนักพัฒนาเบราว์เซอร์หรือบันทึก Ingress สำหรับข้อผิดพลาด WebSocket ด้วย Ingress ต้องรักษาการเชื่อมต่อกับตัวแก้ไขให้เปิดอยู่ตลอดเวลา หากคำขอของไฟล์หนึ่งกระจายอยู่ทั่ว Pods ให้ตรวจสอบว่าWOPISrcมีพารามิเตอร์การค้นหาอยู่ในตำแหน่งที่ Ingress ใช้กฎแฮช และตัวควบคุม Ingress ที่ติดตั้งไว้เคารพคำอธิบายประกอบนั้น
เอกสารแบบเปิดช่วยให้ผู้ใช้ตรวจสอบได้หลังจากที่ Nextcloud ชี้ไปยัง URL ของคลัสเตอร์ Collabora แล้ว
กลุ่มที่มีสุขภาพดีพิสูจน์อะไร?
การทดสอบที่ประสบความสำเร็จยืนยันว่า Nextcloud สามารถเข้าถึงปลายทาง Collabora ได้ และสามารถแก้ไขเอกสารผ่าน ingress ที่กำหนดค่าไว้ได้ แต่ไม่ได้พิสูจน์ว่าทุกเซสชันที่ใช้งานอยู่จะยังคงทำงานได้แม้ว่า pod หรือ node จะล้มเหลว สถานะการแก้ไขจะถูกจัดการโดย pod ที่ให้บริการเอกสารนั้น ดังนั้นความล้มเหลวอาจทำให้ผู้ใช้ต้องเชื่อมต่อใหม่หรือเปิดไฟล์ใหม่แม้ว่าสำเนาอื่นๆ ยังคงใช้งานได้ ควรทดสอบสถานการณ์การบำรุงรักษาและความล้มเหลวด้วยเอกสารที่ไม่สำคัญ และวางแผนการอัปเกรดเพื่อให้จัดการกับเซสชัน WebSocket ที่ใช้งานเป็นเวลานานอย่างรอบคอบ
สำหรับไวยากรณ์และข้อควรระวังในปัจจุบัน โปรดศึกษาเอกสารREADME และค่าต่างๆ ของ Helm chart สำหรับ Kubernetes อย่างเป็นทางการ ของ Collabora ไฟล์ค่า chart ที่เผยแพร่และคู่มือการกำหนดค่า Office ของ Nextcloud ตรวจสอบการตั้งค่ากับเวอร์ชัน chart ที่คุณติดตั้ง เนื่องจากตัวอย่างและค่าเริ่มต้นใน repository อาจไม่เหมือนกันทุกประการ