كيفية إعداد مجموعة Collabora Online متعددة العقد

لا يقتصر نظام Collabora Online على مجرد عدة coolwsdخوادم سليمة خلف موازن تحميل بالتناوب. يعتمد التحرير التعاوني على إرسال طلبات نفس المستند إلى نفس عقدة Collabora. WOPISrcولهذا السبب، يوثق مخطط Kubernetes الخاص بـ Collabora التوجيه باستخدام مُعرّف مستند WOPI. يستخدم هذا الدليل مخطط Helm الخاص بـ Collabora على Kubernetes كإعداد عملي متعدد العقد، ويشير إلى التغييرات اللازمة لاستخدام وحدة تحكم دخول مختلفة أو نشر غير قائم على Kubernetes.

تم التحقق: يدعم مخطط Collabora نسخًا متعددة ويصف تقارب كل مستند باستخدام WOPISrc. يعتمد ذلك على النشر: تعليقات الدخول، وإنهاء TLS، وطلبات الموارد، ومدى ملاءمة وحدة تحكم الجلسة. لا يُنصح بالافتراض بأن أي موازن تحميل أو كل إعداد "جلسة ثابتة" سيحافظ على تقارب المستند. تأكد من سلوك وحدة التحكم واختبره قبل نقل المستخدمين إلى المجموعة.

ما يفعله هذا التجمع - وما لا يفعله

في بيئة نشر قياسية متعددة النسخ، يمكن لكل عقدة من عقد Collabora خدمة المستندات، بينما يقوم خادم وسيط بإرسال طلبات كل مستند إلى عقدة واحدة. هذا يوزع المستندات المنفصلة على مجموعة النسخ. لا يعني هذا أن كل عقدة تشترك في نفس عملية التحرير المباشر، أو أن المستند قيد التشغيل يمكن نقله بسلاسة دائمًا في حال توقف عقدته.

توثق Collabora أيضًا وحدة تحكم COOL لـ Kubernetes تُضيف منهجًا مختلفًا لإدارة الجلسات. يختلف توجيهها وتكوينها عن مجموعة النسخ المتماثلة المستقلة. تُهيئ هذه المقالة نموذج تقارب مصدر WOPI الأبسط؛ لا تجمعه مع إعدادات رمز التوجيه الخاصة بوحدة التحكم إلا إذا كنت قد نشرت وحدة التحكم وهيئتها لإصدارك.

الإجراء: حدد ما إذا كنت بحاجة إلى خدمة Collabora أساسية مُكررة لتوفير السعة وتكرار العقد، أو إعداد مُدار بواسطة وحدة تحكم مع سلوك مُدرك للجلسات. يحتوي الخيار الأخير على مكونات إضافية وتكوين خاص بكل إصدار. راجع نظرة عامة على وحدة تحكم Collabora Online إذا كنت تُقيّم هذا الخيار.

قبل النشر

• مجموعة Kubernetes عاملة، و Helm، و DNS لاسم مضيف Collabora عام، وخادم دخول أو وكيل عكسي قادر على استخدام TLS.
• تكامل WOPI مثل Nextcloud، تم تكوينه لاستخدام اسم مضيف Collabora العام الواحد بدلاً من عناوين pod الفردية.
• مضيف أو مضيفي WOPI الذين يُسمح لـ Collabora بقبولهم، والذين تم إدخالهم في تكوين المخطط collabora.aliasgroups.
• وحدة معالجة مركزية وذاكرة كافية لأعباء العمل المتعلقة بالمستندات، بالإضافة إلى طريقة لفحص حالة البود وسجلات الدخول واستخدام الموارد.
• نافذة صيانة للنشر الأولي ومستند اختبار مع حسابي مستخدمين منفصلين.

تختلف خدمة Collabora Online المخصصة عن خادم CODE المدمج في Nextcloud. يصف Nextcloud خياره المدمج بأنه مُصمم للاستخدام الشخصي أو للفرق الصغيرة، ويفتقر إلى ميزات قابلية التوسع المتقدمة التي يوفرها الخادم المخصص. الإجراء: إذا كنت بحاجة إلى مجموعة Collabora متعددة العُقد، فخطط للخدمة المخصصة وتأكد من نموذج الترخيص والدعم المناسب لبيئة عملك. راجع دليل تثبيت Nextcloud Office .

الخطوة 1: اختر نموذج التوجيه

يُحدد نموذج التجزئة المستقل الموثق WOPISrcالمستند في طلبات WOPI. يجب أن تصل طلبات المستند الواحد إلى نفس وحدة المعالجة (pod)، بينما يمكن توزيع طلبات المستندات المختلفة على وحدات معالجة متعددة. ولا تفي قاعدة التوزيع الدوري العامة بهذا الشرط.

الإجراء: استخدم تطبيق دخول مدعومًا من وثائق المخطط، مثل أمثلة دخول NGINX أو HAProxy الموثقة، أو استخدم وكيلًا عكسيًا داخل مساحة الاسم الخاصة بالمخطط في حال عدم سماح المجموعة بوحدة تحكم دخول مناسبة. في حال استخدام وكيل آخر، تأكد من قدرته على توجيه الطلبات باستمرار عبر مصدر WOPI لكل من طلبات HTTP العادية واتصالات WebSocket طويلة الأمد.

الخطوة الثانية: افحص المخطط واختر إصدارًا

يتغير المخطط وقيمه بمرور الوقت. قبل التثبيت، يُرجى مراجعة ملف README الرسمي الحالي للمخطط وقيمه بدلاً من نسخ إعدادات مُخصصة لإصدار أقدم. تتبع الأمثلة أدناه وثائق مخطط Collabora المُحدّثة بتاريخ 6 أكتوبر 2026؛ لذا يُرجى اعتبار ملاحظات الإصدار الحالية وقيمه في المستودع هي المرجع المعتمد في يوم التثبيت.

helm repo add collabora https://collaboraonline.github.io/online/
helm repo update
helm search repo collabora/collabora-online --versions
helm show values collabora/collabora-online

الإجراء: اختر إصدارًا من المخطط يتوافق مع سياسة إدارة التغييرات لديك، وسجّل إصدار صورة Collabora الذي يتم نشره. ثبّت إصدار المخطط لضمان إمكانية الترقية المتكررة؛ وتجنّب الاعتماد على إصدار غير مُراجع في بيئة الإنتاج. دليل إعداد المخطط موجود في ملف README الخاص بـ Collabora Online for Kubernetes .

الخطوة 3: تجهيز القيم لثلاث نسخ متماثلة

يفترض هذا المثال وجود وحدة تحكم NGINX Ingress، وإنهاء TLS عند نقطة الدخول، ومضيف WOPI خارجي على العنوان التالي cloud.example.com. استبدل كلا اسمي المضيفين باسمك. إذا كان إنهاء TLS يتم في مكان آخر أو كنت تستخدم HAProxy، فاستخدم التكوين الموثق الخاص بوحدة التحكم هذه.

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

collabora:
  aliasgroups:
    - host: "https://cloud.example.com:443"
  extra_params: --o:ssl.enable=false --o:ssl.termination=true

تظهر قيم التجزئة والمهلة الزمنية المذكورة أعلاه في مثال NGINX الخاص بالمخطط. هذا extra_paramsالسطر مناسب فقط عندما يقوم الخادم الوكيل العكسي بإنهاء بروتوكول TLS والاتصال بـ Collabora عبر HTTP. لا تقم بتطبيقه دون تغيير إذا كانت بنية TLS لديك مختلفة. قم بتكوين سر TLS الوارد والمضيف وفقًا لمدير الشهادات وقيم المخطط المحلي لديك؛ لا يتضمن هذا المقتطف تلك الإعدادات الخاصة بمزود الخدمة.

الإجراء: احفظ هذا باسم my_values.yaml، وأضف إعدادات TLS المطلوبة لبوابة الدخول الخاصة بك، وقارن كل مفتاح مع إصدار المخطط المحدد values.yaml. حافظ على اتساق اسم المضيف العام لـ Collabora عبر نظام أسماء النطاقات (DNS) وTLS وعنوان URL الخاص بتكامل Collabora وتوجيه الوكيل.

الخطوة الرابعة: تثبيت إصدار Collabora

قم بالتثبيت في مساحة اسم مخصصة. استبدل <chart-version>بالإصدار المحدد في الخطوة 2؛ الأقواس الزاوية هنا هي عناصر نائبة توضيحية ولا يجب كتابتها حرفيًا.

helm install --create-namespace   --namespace collabora   collabora-online collabora/collabora-online   --version <chart-version>   -f my_values.yaml

بالنسبة للإصدارات الحالية، استخدم ترقية Helm المخططة بعد مراجعة ملاحظات الترحيل والتغييرات المعروضة. تجنب نشر تحديث رئيسي للصورة أو المخطط في نفس وقت أول تغيير في المقياس؛ فتغيير متغير واحد في كل مرة يُسهّل تحديد الأخطاء.

الإجراء: افحص الإصدار وانتظر حتى تصبح جميع النسخ جاهزة:

helm status collabora-online -n collabora
kubectl get pods,svc,ingress -n collabora
kubectl get events -n collabora --sort-by=.lastTimestamp

لا يُعدّ وجود ثلاث نسخ متماثلة مطلوبة دليلاً على أن ثلاث عقد سليمة تُعالج حركة البيانات. تحقق من الجاهزية، وعمليات إعادة التشغيل الأخيرة، والجدولة، ونقاط نهاية الدخول. إذا بقيت الحاويات معلقة، فافحص سعة المجموعة المتاحة وطلبات الموارد وحدودها في قيم المخطط.

الخطوة 5: ربط تطبيق WOPI

في إعدادات تكامل المكتب لمنصة الملفات، عيّن عنوان URL لخادم Collabora إلى نقطة النهاية العامة، على سبيل المثال https://office.example.com. لا تُوجّه التطبيق إلى عنوان IP خاص بوحدة pod أو اسم خدمة خاص بـ Kubernetes فقط إلا إذا كان التكامل نفسه يعمل داخل المجموعة وكان تصميمك يدعم التوجيه الخاص بشكل صريح.

يجب أن يُعرّف اسم المضيف في ملف .org aliasgroupsاسم مضيف WOPI الذي يخزن المستندات ويقدمها؛ وليس اسم مضيف Collabora. قد يؤدي عدم التطابق إلى فشل التحقق من صحة مضيف WOPI حتى عندما تكون وحدات Collabora وبوابة الدخول سليمة.

الإجراء: أدخل عنوان URL العام نفسه لـ Collabora في إعدادات التكامل، واحفظه، وتأكد من نجاح عملية الاتصال أو اكتشاف البيانات. في حال فشلها، تحقق من قائمة السماح الخاصة بتطبيق WOPI، ومجموعات الأسماء المستعارة لـ Collabora، وDNS، وTLS، وعناوين الوكيل قبل تغيير عدد النسخ المتماثلة.

الخطوة 6: اختبار تقارب المستندات والتعاون

افتح مستندًا تجريبيًا وافحص سجلات الدخول أو سجلات الخادم الوكيل للتأكد من الخادم الخلفي الذي يُقدّمه. ثم افتح نفس المستند من جلسة مستخدم ثانية وتحقق من قدرة كلا المستخدمين على التعديل ورؤية تغييرات بعضهما البعض. افتح مستندًا مختلفًا وتأكد من قدرة موازن الأحمال على إرساله إلى وحدة أخرى سليمة. يركز الاختبار على التوجيه والتعاون، وليس فقط على ما إذا كانت الصفحة المقصودة تُعيد استجابة HTTP 200.

الإجراء: تحقق من وجود تجزئة مصدر WOPI وتطبيقها بشكل متسق على الطلبات المُنشأة لنفس المستند، بما في ذلك ترقية WebSocket. إذا لم يرَ المستخدمون تعديلات بعضهم البعض، قارن اختيار الواجهة الخلفية لنفس المستند قبل التحقق من مُضيف WOPI أو ذاكرة التخزين المؤقت للمتصفح.

الخطوة 7: اختبار معالجة الحالة الصحية وفقدان العقدة

يجب أن تمنع فحوصات الجاهزية أي وحدة غير سليمة أو قيد التشغيل من العمل. يتضمن المخطط إعدادات بدء التشغيل والجاهزية وفحص النشاط، ولكن يعتمد السلوك والتوقيت الدقيقان على إصدار المخطط والمجموعة المُختارين. قد يؤدي تعطل وحدة إلى انقطاع المستندات قيد التشغيل عليها؛ ولا ينبغي وصف مجموعة التقارب الأساسية بأنها نسخ متماثل للجلسة المباشرة.

الإجراء: في بيئة اختبار، قم بإزالة وحدة واحدة من الخدمة أثناء جلسة تحرير نشطة، وراقب سلوك العميل وتوجيه الوكيل، ثم أعد فتح المستند وتأكد من وصوله إلى وحدة سليمة. لا تُجرِ هذا الاختبار على مستندات الإنتاج النشطة دون خطة صيانة معتمدة. لضمان استمرارية الجلسة بشكل أدق، قيّم وحدة تحكم COOL وإعداد رمز التوجيه الخاص بها والمُخصّص لكل إصدار.

الخطوة الثامنة: المراقبة والضبط والتحديث بشكل مدروس

تتبّع عمليات إعادة تشغيل الحاويات، واستخدام وحدة المعالجة المركزية والذاكرة، وأخطاء الطلبات وWebSocket، وزمن استجابة الدخول، وتقارير المستخدمين حول تحميل المستندات أو إعادة الاتصال. تتضمن وثائق مخطط Collabora إرشادات لمراقبة Kubernetes. حدّد الموارد بناءً على عبء العمل المُلاحَظ بدلاً من نسخ أرقام الأمثلة: يؤثر حجم المستند، والجلسات المتزامنة، والخطوط، وأنماط التحرير جميعها على السعة.

توصي Collabora بتشغيل نفس الإصدار على جميع العُقد المُوزّعة الأحمال لضمان حصول العملاء على موارد ويب متسقة ومُخصصة لكل إصدار. أثناء التحديثات، استخدم استراتيجية النشر المُعتمدة في المخطط، وراقب جاهزية النظام وسجلاته، واختبر مستندًا مفتوحًا من عدة مستخدمين قبل إعلان اكتمال التغيير.

الإجراء: احتفظ بنسخة المخطط، ونسخة الصورة، وملف القيم، ونتائج الاختبار معًا في سجل التغييرات. جدوِل الترقيات، وتأكد من توافق جميع النسخ المتماثلة مع النسخة المطلوبة، واحتفظ بخطة تراجع متوافقة مع سلوك التراجع المدعوم في المخطط.

مفاهيم خاطئة شائعة يجب التحقق منها

• تُنشئ ثلاث نسخ متماثلة تلقائيًا مجموعة عاملة. لا تُهيئ النسخ المتماثلة وحدها تقارب المستندات. تأكد من أن تجزئات الدخول على مصدر WOPI أو أن وحدة التحكم الخاصة بك توفر توجيه الجلسة المقصود.
• "جلسات ثابتة تعتمد على عنوان IP الخاص بالمستخدم كافية." هذا ليس ما توضحه مخططات Collabora لمجموعة Kubernetes المستقلة. يجب على المستخدمين المتعاونين على مستند واحد الاتصال بنفس العقدة حتى لو وصلوا من أجهزة أو شبكات مختلفة. قم بتكوين تقارب المستند واختبره مع مستخدمين اثنين.
• "صفحة رئيسية سليمة تُثبت جاهزية المجموعة." هذا يُثبت فقط نجاح استجابة طلب HTTP واحد. اختبر فتح مستند وتحريره بشكل تعاوني، وترقيات WebSocket، والسلوك عند تعطل وحدة pod.
• تضمن إضافة عقدة استمرار الجلسات النشطة حتى في حال فقدان عقدة. يقوم مجمع تقارب مصادر WOPI الأساسي بتوجيه المستند إلى عقدة، ولكنه لا يضمن تكرار عملية التحرير في الذاكرة. تأكد من سلوك الاسترداد المتوقع في اختبار مُحكم، أو قيّم ميزات إدارة الجلسات المنفصلة في وحدة التحكم.

بالنسبة للتركيبات التي لا تستخدم Kubernetes، يظل مبدأ البنية كما هو، ولكن أوامر مخطط Kubernetes وتعليقات الدخول لا تنطبق. استخدم إعدادات الوكيل الخاصة بإصدار Collabora وموازن الأحمال لديك، وتأكد من دعم اتصالات WebSocket طويلة الأمد، ونفّذ توجيهًا لكل مستند باستخدام مصدر WOPI. يشرح دليل Collabora Online SDK موازنة الأحمال ومتطلبات WOPISrcالتقارب؛ راجع القسم المكافئ في الدليل الخاص بالإصدار الذي تستخدمه.