Cum se configurează un cluster Collabora Online cu mai multe noduri

Un cluster Collabora Online nu este format doar din mai multe coolwsdservere sănătoase în spatele unui echilibrator de încărcare round-robin. Editarea colaborativă depinde de trimiterea de cereri pentru același document către același nod Collabora. WOPISrcDin acest motiv, diagrama Kubernetes din Collabora documentează rutarea documentelor după identificatorul de document WOPI, . Acest ghid utilizează diagrama Collabora Helm întreținută pe Kubernetes ca o configurație concretă cu mai multe noduri și notează ce trebuie să se schimbe pentru un controler de intrare diferit sau o implementare non-Kubernetes.

Verificat: Diagrama Collabora acceptă mai multe replici și descrie afinitatea per document folosind WOPISrc. Depinzând de implementare: adnotări de intrare, terminare TLS, solicitări de resurse și dacă un controler de sesiune este adecvat. Nu este sigur să presupunem: că orice echilibrator de încărcare sau fiecare setare de „sesiune persistentă” va păstra afinitatea documentului. Confirmați comportamentul specific controlerului și testați-l înainte de a muta utilizatorii în cluster.

Ce face clusterul - și ce nu face

Într-o implementare standard cu mai multe replici, fiecare nod Collabora poate servi documente, în timp ce un proxy trimite solicitările fiecărui document către un singur nod. Aceasta distribuie documente separate în întregul pool. Nu înseamnă că fiecare nod are același proces de editare live sau că un document care rulează se poate mișca întotdeauna fără probleme dacă nodul său se oprește.

Collabora documentează, de asemenea, un controller COOL pentru Kubernetes care adaugă o abordare diferită de gestionare a sesiunilor. Rutarea și configurarea sa diferă de cele ale unui pool de replici independent. Acest articol configurează modelul mai simplu de afinitate WOPI-source; nu-l combinați cu setări de token de rută specifice controllerului decât dacă ați implementat și configurat controllerul pentru versiunea dvs.

Acțiune: decideți dacă aveți nevoie de un serviciu Collabora replicat de bază pentru capacitate și redundanță a nodurilor sau de o configurație gestionată de controler cu comportament în funcție de sesiune. Aceasta din urmă are componente suplimentare și configurație specifică versiunii. Consultați prezentarea generală a controlerului online Collabora dacă evaluați acea cale.

Înainte de implementare

• Un cluster Kubernetes funcțional, Helm, DNS pentru un nume de gazdă public Collabora și un proxy de intrare sau invers compatibil cu TLS.
• O integrare WOPI, cum ar fi Nextcloud, configurată să utilizeze numele de gazdă public unic Collabora, în loc de adrese individuale de pod.
• Gazda sau gazdele WOPI pe care Collabora are permisiunea să le accepte, introduse în configurația graficului collabora.aliasgroups.
• Suficient CPU și memorie pentru volumul de lucru al documentelor, plus o modalitate de a inspecta starea de funcționare a pod-urilor, jurnalele de intrare și utilizarea resurselor.
• O fereastră de întreținere pentru implementarea inițială și un document de testare cu două conturi de utilizator separate.

Un serviciu Collabora Online dedicat este diferit de serverul CODE încorporat al Nextcloud. Nextcloud descrie opțiunea sa încorporată ca fiind destinată utilizării personale sau echipelor mici și fără funcțiile avansate de scalabilitate ale unui server dedicat. Acțiune: dacă aveți nevoie de un pool Collabora cu mai multe noduri, planificați serviciul dedicat și confirmați modelul de licențiere și asistență potrivit pentru implementarea dvs. Consultați ghidul de instalare Nextcloud Office .

Pasul 1: Alegeți modelul de rutare

Modelul independent documentat folosește hash pe WOPISrc, care identifică documentul în cererile WOPI. Cererile pentru un document trebuie să ajungă la același pod; cererile pentru documente diferite pot fi distribuite între pod-uri. O regulă generică round-robin nu îndeplinește această cerință.

Acțiune: utilizați o implementare de ingress acceptată de documentația diagramei, cum ar fi exemplele documentate de ingress NGINX sau HAProxy sau utilizați proxy-ul invers în spațiul de nume al diagramei acolo unde clusterul nu permite un controler de ingress adecvat. Dacă utilizați un alt proxy, verificați dacă acesta poate direcționa în mod constant solicitările prin sursa WOPI atât pentru solicitările HTTP obișnuite, cât și pentru conexiunile WebSocket de lungă durată.

Pasul 2: Inspectați graficul și selectați o versiune

Diagrama și valorile sale se modifică în timp. Înainte de instalare, verificați fișierul README și valorile oficiale curente ale diagramei, în loc să copiați o configurație scrisă pentru o versiune mai veche. Exemplele de mai jos respectă documentația întreținută a diagramei Collabora, revizuită la 6 octombrie 2026; considerați notele și valorile actuale ale versiunii depozitului ca fiind autoritative pentru ziua instalării.

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

Acțiune: alegeți o versiune de diagramă care corespunde politicii dvs. de control al modificărilor și înregistrați versiunea imaginii Collabora pe care o implementează. Fixați versiunea de diagramă pentru actualizări repetabile; evitați să vă bazați pe o versiune flotantă neravizuită în producție. Ghidul de configurare propriu al diagramei este fișierul README Collabora Online pentru Kubernetes .

Pasul 3: Pregătiți valorile pentru trei replici

Acest exemplu presupune controlerul de intrare NGINX, terminarea TLS la intrare și o gazdă WOPI externă la cloud.example.com. Înlocuiți ambele nume de gazdă cu ale dvs. Dacă TLS se termină în altă parte sau utilizați HAProxy, utilizați în schimb configurația documentată corespunzătoare a controlerului respectiv.

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

Valorile adnotării hash și ale timeout-ului de mai sus sunt afișate în exemplul NGINX al graficului. Linia extra_paramseste potrivită numai atunci când proxy-ul invers termină TLS și se conectează la Collabora prin HTTP. Nu o aplicați neschimbată dacă topologia TLS diferă. Configurați secretul TLS de intrare și gazda în funcție de managerul de certificate și de valorile graficului local; extrasul omite aceste setări specifice furnizorului.

Acțiune: salvați fișierul ca my_values.yaml, adăugați configurația TLS necesară pentru intrare și comparați fiecare cheie cu cea a versiunii selectate a graficului values.yaml. Mențineți consecvența numelui de gazdă public Collabora între DNS, TLS, adresa URL Collabora a integrării și rutarea proxy.

Pasul 4: Instalați versiunea Collabora

Instalați într-un spațiu de nume dedicat. Înlocuiți <chart-version>cu versiunea selectată în Pasul 2; parantezele unghiulare de aici sunt substituenți explicativi și nu ar trebui tastate literal.

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

Pentru o versiune existentă, utilizați o actualizare Helm planificată după verificarea notelor de migrare ale versiunii și a modificărilor redate. Evitați implementarea unei actualizări majore de imagine sau diagramă în același timp cu prima modificare de scalare; modificarea unei variabile pe rând facilitează izolarea erorilor.

Acțiune: inspectați versiunea și așteptați ca toate replicile să fie gata:

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

Trei replici dorite nu sunt o dovadă că trei noduri sănătoase deservesc trafic. Verificați disponibilitatea, repornirile recente, programarea și punctele finale de intrare. Dacă pod-urile rămân în așteptare, verificați capacitatea disponibilă a clusterului și solicitările și limitele de resurse din valorile diagramei.

Pasul 5: Conectați aplicația WOPI

În setările de integrare Office ale platformei de fișiere, setați adresa URL a serverului Collabora către endpoint-ul public, de exemplu https://office.example.com. Nu direcționați aplicația către o adresă IP de pod sau către un nume de serviciu exclusiv Kubernetes, cu excepția cazului în care integrarea în sine rulează în interiorul clusterului și dacă rutarea privată este acceptată explicit de designul dvs.

Numele de gazdă din [numele de gazdă] aliasgroupstrebuie să identifice gazda WOPI care stochează și servește documente; nu este numele de gazdă Collabora. O nepotrivire poate cauza erori de validare a gazdei WOPI chiar și atunci când pod-urile și ingress-ul Collabora sunt sănătoase.

Acțiune: introduceți aceeași adresă URL publică Collabora în configurația integrării, salvați-o și verificați dacă verificarea conectivității sau a descoperirii a reușit. Dacă eșuează, verificați lista de permisiuni WOPI a aplicației, grupurile de aliasuri Collabora, anteturile DNS, TLS și proxy înainte de a modifica numărul de replici.

Pasul 6: Testați afinitatea și colaborarea documentelor

Deschideți un document de test și inspectați jurnalele de intrare sau proxy pentru a confirma ce backend îl deservește. Apoi, deschideți același document dintr-o a doua sesiune de utilizator și verificați dacă ambii utilizatori pot edita și vedea modificările celuilalt. Deschideți un alt document și confirmați dacă echilibratorul de încărcare îl poate trimite către un alt pod sănătos. Testul se referă la rutare și colaborare, nu doar dacă pagina de destinație returnează HTTP 200.

Acțiune: verificați dacă hash-ul sursă WOPI este prezent și aplicat în mod consecvent cererilor generate pentru același document, inclusiv actualizarea WebSocket. Dacă utilizatorii nu văd editările celuilalt, comparați selecția backend pentru același document înainte de a investiga gazda WOPI sau memoria cache a browserului.

Pasul 7: Testați gestionarea stării de funcționare și pierderea nodurilor

Verificările de pregătire ar trebui să mențină un pod nesănătos sau aflat la început de drum scos din funcțiune. Diagrama include setările de pornire, pregătire și sondă de funcționare, dar comportamentul și sincronizarea exacte depind de versiunea și clusterul selectate ale diagramei. Un pod care devine indisponibil poate întrerupe documentele care rulează în prezent pe acel pod; un pool de afinitate de bază nu ar trebui descris ca replicare a sesiunii în direct.

Acțiune: într-un mediu de testare, eliminați un pod din serviciu în timpul unei sesiuni de editare active, observați comportamentul clientului și rutarea proxy, apoi redeschideți documentul și confirmați că acesta ajunge la un pod sănătos. Nu efectuați acest test pe documente de producție active fără un plan de întreținere aprobat. Pentru o continuitate mai strictă a sesiunii, evaluați COOL Controller și configurația sa specifică versiunii pentru token-ul de rutare.

Pasul 8: Monitorizați, reglați și actualizați în mod deliberat

Repornirile podurilor de urmărire, utilizarea CPU și a memoriei, erorile de solicitare și WebSocket, latența de intrare și rapoartele utilizatorilor despre încărcarea sau reconectarea documentelor. Documentația grafică Collabora include îndrumări de monitorizare Kubernetes. Setați resursele din sarcina de lucru observată, mai degrabă decât să copiați numerele de exemplu: dimensiunea documentului, sesiunile simultane, fonturile și modelele de editare afectează capacitatea.

Collabora recomandă rularea aceleiași versiuni pe toate nodurile cu sarcină echilibrată, astfel încât clienții să primească resurse web consistente, specifice versiunii. În timpul actualizărilor, utilizați strategia de implementare acceptată a graficului, urmăriți disponibilitatea și jurnalele și testați un document deschis de la mai mulți utilizatori înainte de a declara modificarea finalizată.

Acțiune: păstrați versiunea graficului, versiunea imaginii, fișierul cu valori și rezultatele testelor împreună în înregistrarea modificărilor. Programați actualizările, confirmați că toate replicile converg către versiunea dorită și păstrați un plan de revenire compatibil cu comportamentul de revenire acceptat de grafic.

Concepții greșite comune de verificat

• „Trei replici creează automat un cluster funcțional.” Replicile singure nu configurează afinitatea documentelor. Confirmați că hash-urile de intrare de pe sursa WOPI sau că controlerul dvs. furnizează rutarea sesiunii dorită.
• „Sesiunile fixe bazate pe adresa IP a unui utilizator sunt suficiente.” Aceasta nu este regula descrisă de graficul Collabora pentru pool-ul său Kubernetes independent. Utilizatorii care colaborează la un document trebuie să convergă pe același nod chiar și atunci când sosesc de pe dispozitive sau rețele diferite. Configurați afinitatea bazată pe documente și testați cu doi utilizatori.
• „O pagină principală sănătoasă dovedește că clusterul este pregătit.” Dovedește doar că o singură cerere HTTP a fost returnată cu succes. Testează deschiderea și editarea colaborativă a unui document, actualizările WebSocket și comportamentul atunci când un pod devine indisponibil.
• „Adăugarea unui nod garantează că sesiunile active supraviețuiesc pierderii nodului.” Un pool de bază WOPI-source-affinity direcționează un document către un nod; nu stabilește că procesul său de editare în memorie este reprodus. Confirmați comportamentul de recuperare așteptat într-un test controlat sau evaluați caracteristicile separate de gestionare a sesiunilor ale Controlerului.

Pentru instalările non-Kubernetes, principiul arhitecturii este același, dar comenzile diagramei Kubernetes și adnotările de intrare nu se aplică. Folosește configurația proxy pentru versiunea Collabora și echilibratorul de încărcare, asigură-te că sunt acceptate conexiunile WebSocket de lungă durată și implementează rutarea per document folosind sursa WOPI. Manualul SDK-ului Collabora Online descrie echilibrarea încărcării și WOPISrccerința de afinitate; verifică secțiunea echivalentă din manual pentru versiunea pe care o utilizezi.