Rulați Collabora Online pe noduri Kubernetes

Pentru o implementare Collabora Online cu mai multe noduri, utilizați diagrama Kubernetes Helm din Collabora în spatele unui ingress sau a unui proxy invers care păstrează fiecare solicitare pentru același document pe același pod Collabora. Această afinitate de sesiune este esențială: echilibrarea obișnuită round-robin poate trimite solicitările de editare și clipboard ale unui utilizator către diferite pod-uri și poate perturba editarea colaborativă. Exemplul de mai jos utilizează trei replici, NGINX Ingress și un număr fix de replici; înlocuiți numele de gazdă și secretul TLS din exemplu cu ale dvs.

De ce aveți nevoie înainte de a adăuga replici?

Aveți nevoie de un cluster Kubernetes care rulează cu cel puțin două noduri worker, Helm, un controler de intrare care acceptă regula de afinitate necesară, un nume DNS, cum ar fi office.example.com, și un certificat TLS pentru acel nume. Nextcloud trebuie să fie accesibil de către fiecare pod Collabora la originea sa WOPI publică, de exemplu https://cloud.example.com. CODE și Nextcloud sunt servicii separate; acest ghid configurează nivelul Collabora și apoi conectează adresa URL publică a acestuia la Nextcloud Office.

Folosește configurația multi-replică documentată a diagramei Collabora, în loc să plasezi mai multe containere Docker independente în spatele unui echilibrator de sarcină generic. Un echilibrator de sarcină care distribuie fiecare solicitare fără a ține cont de sursa WOPI a documentului poate întrerupe sesiunile. Acest ghid urmează instrucțiunile oficiale ale diagramei Collabora Helm, disponibile pe 10 octombrie 2026. Valorile diagramei se pot modifica, așadar verifică valorile pentru versiunea exactă a diagramei pe care intenționezi să o instalezi.

1. Configurați replicile, afinitatea de intrare și gazda WOPI

Adăugați depozitul de diagrame, actualizați-i indexul și verificați valorile implicite curente ale diagramei înainte de a scrie fișierul de suprascriere:

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

Creați my_values.yamlcu setările de bază de mai jos. Exemplul folosește adnotarea NGINX Ingress afișată în diagrama README a Collabora. Se execută hashing-ul WOPISrcastfel încât cererile legate de un document să ajungă la același pod. De asemenea, termină TLS public la intrare; setările serverului Collabora afișate sunt pentru acel model TLS terminat prin proxy.

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

Intrarea aliasgroupseste gazda WOPI Nextcloud, nu numele de gazdă Collabora. Mențineți o limită restrânsă și utilizați schema exactă, numele de gazdă și portul prezentate de Nextcloud. Secretul TLS de intrare trebuie să existe în spațiul de nume de intrare și să conțină un certificat valid pentru office.example.com. Dacă TLS se termină în altă parte, urmați modelul proxy corespunzător din documentația diagramei în loc să copiați extra_paramsorbește cele două steaguri.

Există o avertizare privind scalarea automată, dependentă de versiune: exemplul fișierului README al diagramei dezactivează scalarea automată și avertizează că scalarea poate perturba editarea colaborativă și copierea/lipirea, în timp ce fișierul cu valori publicat în prezent are scalarea automată activată în mod implicit. Pentru un cluster inițial previzibil, dezactivați-l explicit și alegeți un număr fix de replici. Revizuiți scalarea automată numai după ce verificați instrucțiunile exacte ale versiunii diagramei și testați creșterea și reducerea scalării cu sesiuni de editare reale.

2. Instalați diagrama și verificați amplasarea podului

Instalați diagrama într-un spațiu de nume dedicat. Depozitul oficial de diagrame documentează acest model de comandă:

helm install --create-namespace \
  --namespace collabora \
  collabora-online collabora/collabora-online \
  -f my_values.yaml

Apoi verificați dacă implementarea a atins numărul de replici dorit și vedeți ce noduri worker găzduiesc pod-urile:

kubectl get pods -n collabora -o wide
kubectl get ingress -n collabora
helm status collabora-online -n collabora

Confirmați că toate cele trei pod-uri sunt Ready (Pregătite), că intrarea are gazda așteptată și că replicile sunt distribuite între nodurile worker dacă este necesară reziliența la nivel de nod. Numărul de replici în sine nu garantează că Kubernetes va plasa pod-uri pe noduri separate. Șablonul oficial de diagramă expune selectorul de noduri, afinitatea și setările de toleranță; configurați reguli de programare adecvate pentru clusterul dvs. și validați diagrama redată înainte de a vă baza pe acestea. Dacă versiunea diagramei dvs. nu expune politica de care aveți nevoie, utilizați o extensie de diagramă acceptată sau personalizarea implementării Kubernetes, în loc să presupuneți că pod-urile sunt răspândite.

3. Conectați Nextcloud și verificați afinitatea documentului

În Nextcloud, instalați sau activați aplicația Nextcloud Office , apoi deschideți Setări de administrare → Office . Selectați serverul extern Collabora și introduceți https://office.example.com. Adresa URL a serverului este punctul final TLS public pe care îl pot accesa atât serverul Nextcloud, cât și browserele utilizatorilor; nu introduceți o adresă IP de pod sau o adresă de serviciu internă.

Deschideți un fișier DOCX sau ODT de test din Nextcloud. Editați-l din două sesiuni separate de utilizator și confirmați că ambii utilizatori văd modificările. De asemenea, verificați instrumentele de dezvoltare ale browserului sau jurnalele de intrare pentru erori WebSocket; Ingress trebuie să mențină deschisă conexiunea editorului de lungă durată. Dacă solicitările unui fișier sunt răspândite în mai multe pod-uri, verificați dacă WOPISrcparametrul de interogare este prezent acolo unde ingress aplică regula hash și dacă controlerul de intrare instalat onorează adnotarea.

Ce dovedește un cluster sănătos?

Un test reușit confirmă faptul că Nextcloud poate ajunge la punctul final Collabora și că un document poate fi editat prin intermediul ingress-ului configurat. Nu dovedește că fiecare sesiune activă supraviețuiește unei erori a unui pod sau a unui nod. Starea de editare este gestionată de pod-ul care deservește documentul respectiv, astfel încât o eroare poate necesita reconectarea sau redeschiderea unui fișier de către utilizatori chiar dacă alte replici rămân disponibile. Testați scenariile de întreținere și de eroare cu documente necritice și planificați actualizările astfel încât sesiunile WebSocket cu durată lungă de viață să fie gestionate în mod deliberat.

Pentru sintaxa și avertismentele actuale, consultați fișierul oficial README și valorile graficelor Kubernetes Helm de la Collabora , fișierul cu valorile graficelor publicate și manualul de configurare Office de la Nextcloud . Verificați setările în raport cu versiunea grafică pe care o instalați, deoarece exemplele și valorile implicite ale depozitului pot fi diferite.