Collabora online auf Kubernetes-Knoten ausführen

Für eine Collabora Online-Bereitstellung mit mehreren Knoten verwenden Sie das Collabora Kubernetes Helm-Chart hinter einem Ingress- oder Reverse-Proxy, der sicherstellt, dass alle Anfragen für dasselbe Dokument im selben Collabora-Pod bleiben. Diese Sitzungsaffinität ist unerlässlich: Herkömmliches Round-Robin-Balancing kann dazu führen, dass Bearbeitungs- und Zwischenablage-Anfragen eines Benutzers an verschiedene Pods gesendet werden und die gemeinsame Bearbeitung beeinträchtigt wird. Das folgende Beispiel verwendet drei Replikate, NGINX Ingress und eine feste Anzahl an Replikaten; ersetzen Sie die Beispiel-Hostnamen und das TLS-Geheimnis durch Ihre eigenen.

Eine Terminal-Eingabeaufforderung mit dem Befehl zum Hinzufügen des offiziellen Collabora Helm-Repositorys
Der Terminalbefehl fügt vor der Bereitstellung das offizielle Helm-Chart-Repository von Collabora hinzu.

Was benötigen Sie, bevor Sie Replikate hinzufügen?

Sie benötigen einen laufenden Kubernetes-Cluster mit mindestens zwei Worker-Knoten, Helm, einen Ingress-Controller, der die erforderliche Affinitätsregel unterstützt, einen DNS-Namen (z. B. `<collabora-name>.com`) office.example.comund ein TLS-Zertifikat für diesen Namen. Nextcloud muss von jedem Collabora-Pod über seinen öffentlichen WOPI-Ursprung (z. B. `<collabora-name>.com`) erreichbar sein https://cloud.example.com. CODE und Nextcloud sind separate Dienste; diese Anleitung konfiguriert die Collabora-Ebene und verbindet anschließend deren öffentliche URL mit Nextcloud Office.

Verwenden Sie die im Collabora-Chart dokumentierte Multi-Replica-Konfiguration, anstatt mehrere unabhängige Docker-Container hinter einem generischen Load Balancer zu platzieren. Ein Load Balancer, der Anfragen unabhängig von der WOPI-Quelle verteilt, kann Sitzungen unterbrechen. Diese Anleitung orientiert sich an den offiziellen Anweisungen für das Collabora Helm-Chart vom 10. Oktober 2026. Da sich die Werte im Chart ändern können, überprüfen Sie bitte die Werte für die von Ihnen geplante Chart-Version.

1. Replikate, Ingress-Affinität und den WOPI-Host konfigurieren

Fügen Sie das Chart-Repository hinzu, aktualisieren Sie dessen Index und überprüfen Sie die aktuellen Standardeinstellungen des Charts, bevor Sie Ihre Überschreibungsdatei schreiben:

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

Erstellen Sie die Anwendung my_values.yamlmit den unten stehenden Kerneinstellungen. Das Beispiel verwendet die in der README-Datei des Collabora-Diagramms dargestellte NGINX-Ingress-Annotation. Es verwendet Hashing, WOPISrcsodass Anfragen, die zu einem Dokument gehören, denselben Pod erreichen. Außerdem wird öffentliches TLS am Ingress beendet; die angezeigten Collabora-Servereinstellungen beziehen sich auf dieses Proxy-terminierte TLS-Muster.

Ein YAML-Editor zeigt drei Collabora-Replikate, deaktiviertes Autoscaling und NGINX-Ingress-Hashing durch WOPISrc an.
Die Wertedatei legt eine feste Anzahl von Replikaten fest und leitet die Anfragen jedes Dokuments über WOPISrc weiter.
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

Der aliasgroupsEintrag ist der Nextcloud-WOPI-Host, nicht der Collabora-Hostname. Halten Sie ihn kurz und verwenden Sie genau das Schema, den Hostnamen und den Port, die Nextcloud angibt. Das Ingress-TLS-Secret muss im Ingress-Namespace vorhanden sein und ein gültiges Zertifikat enthalten office.example.com. Falls TLS an anderer Stelle terminiert, verwenden Sie das entsprechende Proxy-Muster in der Chart-Dokumentation, anstatt die beiden extra_paramsFlags einfach zu kopieren.

Es gibt eine versionsabhängige Einschränkung bezüglich der automatischen Skalierung: Im Beispiel der Chart-README ist die automatische Skalierung deaktiviert, und es wird davor gewarnt, dass die Skalierung die gemeinsame Bearbeitung und das Kopieren/Einfügen beeinträchtigen kann. In der aktuell veröffentlichten Wertedatei ist die automatische Skalierung jedoch standardmäßig aktiviert. Um einen vorhersehbaren initialen Cluster zu erhalten, deaktivieren Sie die automatische Skalierung explizit und wählen Sie eine feste Anzahl von Replikaten. Überprüfen Sie die Hinweise zur jeweiligen Chart-Version und testen Sie das Hoch- und Herunterskalieren in realen Bearbeitungssitzungen erneut, bevor Sie die automatische Skalierung erneut in Betracht ziehen.

2. Installieren Sie das Chart und überprüfen Sie die Pod-Platzierung.

Installieren Sie das Chart in einem dedizierten Namespace. Das offizielle Chart-Repository dokumentiert dieses Befehlsmuster:

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

Überprüfen Sie anschließend, ob die Bereitstellung die gewünschte Anzahl an Replikaten erreicht hat, und sehen Sie nach, welche Worker-Knoten die Pods hosten:

Eine Terminaleingabeaufforderung mit dem Befehl `kubectl get pods -n collabora -o wide` zeigt die Pod-Platzierung an.
Nutzen Sie die Übersicht der Pods, um die Bereitschaft und den Knoten, der jeder Replik zugewiesen ist, zu überprüfen.
kubectl get pods -n collabora -o wide
kubectl get ingress -n collabora
helm status collabora-online -n collabora

Stellen Sie sicher, dass alle drei Pods bereit sind, der Ingress den erwarteten Host verwendet und Replikate auf die Worker-Knoten verteilt sind, falls Ausfallsicherheit auf Knotenebene erforderlich ist. Die Anzahl der Replikate allein garantiert nicht, dass Kubernetes Pods auf separaten Knoten platziert. Die offizielle Chart-Vorlage stellt Einstellungen für Knotenselektor, Affinität und Toleranz bereit. Konfigurieren Sie geeignete Scheduling-Regeln für Ihren Cluster und überprüfen Sie das gerenderte Chart, bevor Sie sich darauf verlassen. Falls Ihre Chart-Version die benötigte Richtlinie nicht bereitstellt, verwenden Sie eine unterstützte Chart-Erweiterung oder eine Anpassung der Kubernetes-Bereitstellung, anstatt von einer Verteilung der Pods auszugehen.

3. Nextcloud verbinden und Dokumentenaffinität überprüfen.

Installieren oder aktivieren Sie in Nextcloud die Nextcloud Office- App und öffnen Sie anschließend die Administrationseinstellungen → Office . Wählen Sie den externen Collabora-Server aus und geben Sie die Server-URL ein https://office.example.com. Die Server-URL ist der öffentliche TLS-Endpunkt, der sowohl vom Nextcloud-Server als auch von den Browsern der Benutzer erreicht werden kann. Geben Sie keine Pod-IP-Adresse oder interne Dienstadresse ein.

Öffnen Sie eine Test-DOCX- oder ODT-Datei in Nextcloud. Bearbeiten Sie diese in zwei separaten Benutzersitzungen und prüfen Sie, ob beide Benutzer die Änderungen sehen. Überprüfen Sie außerdem die Entwicklertools Ihres Browsers oder die Ingress-Logs auf WebSocket-Fehler; der Ingress muss die dauerhafte Editorverbindung aufrechterhalten. Falls die Anfragen für eine Datei auf mehrere Pods verteilt sind, stellen Sie sicher, dass der WOPISrcAbfrageparameter an der Stelle vorhanden ist, an der der Ingress die Hash-Regel anwendet, und dass der installierte Ingress-Controller die Annotation berücksichtigt.

Ein Collabora Online-Dokumenteditor, der eine Checkliste für die Cluster-Einführung mit einer Formatierungsleiste anzeigt.
Ein offenes Dokument bietet dem Benutzer eine Überprüfung, nachdem Nextcloud auf die geclusterte Collabora-URL verwiesen hat.

Was beweist ein gesunder Cluster?

Ein erfolgreicher Test bestätigt, dass Nextcloud den Collabora-Endpunkt erreichen und ein Dokument über den konfigurierten Ingress bearbeitet werden kann. Er beweist jedoch nicht, dass jede aktive Sitzung einen Pod- oder Knotenausfall übersteht. Der Bearbeitungsstatus wird vom Pod verwaltet, der das jeweilige Dokument bereitstellt. Daher kann ein Ausfall dazu führen, dass Benutzer die Verbindung wiederherstellen oder eine Datei erneut öffnen müssen, selbst wenn andere Replikate verfügbar sind. Testen Sie Wartungs- und Ausfallszenarien mit unkritischen Dokumenten und planen Sie Upgrades so, dass langlebige WebSocket-Sitzungen gezielt behandelt werden.

Die aktuelle Syntax und mögliche Einschränkungen finden Sie in der offiziellen README-Datei und den Wertedateien des Collabora Kubernetes Helm Charts , der veröffentlichten Wertedatei des Charts sowie im Konfigurationshandbuch für Nextcloud Office . Überprüfen Sie die Einstellungen anhand der installierten Chart-Version, da die Beispiele und Standardwerte des Repositorys möglicherweise nicht identisch sind.

Einen Kommentar hinterlassen

Collabora CODE-Einstellungen wiederherstellen, ohne Bereitstellungsänderungen zu verlieren

Collabora CODE-Einstellungen wiederherstellen, ohne Bereitstellungsänderungen zu verlieren

Sichern Sie die Datei coolwsd.xml und ihre Bereitstellungsquellen, stellen Sie sie sicher wieder her und überprüfen Sie den CODE, bevor die Benutzer die Bearbeitung wieder aufnehmen.

Beheben Sie den WOPI-Host-Check von CODE, indem Sie den Hostursprung abgleichen.

Beheben Sie den WOPI-Host-Check von CODE, indem Sie den Hostursprung abgleichen.

Erlauben Sie den genauen Ursprung von Nextcloud oder einer anderen WOPI-Instanz im CODE, überprüfen Sie dann die aktive Host-Zulassungsliste und unterscheiden Sie diese von der Quell-IP-Beschränkung von Nextcloud.

Beheben Sie den Fehler „Nun, das ist peinlich“ in Collabora.

Beheben Sie den Fehler „Nun, das ist peinlich“ in Collabora.

Analysieren Sie die Browser-, WOPI- und WebSocket-Verbindungen von Collabora, um herauszufinden, warum sich ein Dokument nicht öffnen lässt, und wenden Sie dann die Lösung an, die zu Ihrer Nextcloud-Konfiguration passt.

Collabora online auf Kubernetes-Knoten ausführen

Collabora online auf Kubernetes-Knoten ausführen

Mit Helm können Collabora CODE-Replikate bereitgestellt werden, wobei jedes Dokument über WOPI-Affinität auf einem Pod verbleibt, und Ingress, Knotenplatzierung und Nextcloud-Bearbeitung können überprüft werden.

Die WebSocket-Verbindung von Collabora über den Proxy wiederherstellen

Die WebSocket-Verbindung von Collabora über den Proxy wiederherstellen

Verfolgen Sie einen fehlgeschlagenen Socket-Handshake vom Browser zu coolwsd und gleichen Sie dann die Reverse-Proxy-Route mit Ihrer Collabora-Version ab, einschließlich der Apache-Änderung CODE 26.04.

Beheben Sie WOPI-Nachweisfehler durch Überprüfung von Schlüsseln, Erkennung und URLs

Beheben Sie WOPI-Nachweisfehler durch Überprüfung von Schlüsseln, Erkennung und URLs

Verfolgen Sie Collabora WOPI-Beweisfehler auf nicht übereinstimmende Schlüssel, veraltete Erkennungsdaten, Zeitabweichungen oder Änderungen der Proxy-URL – ohne die Validierung zu schwächen.

Fehlerhafte Darstellung des Schriftgrößen-Dropdowns in Collabora Online beheben

Fehlerhafte Darstellung des Schriftgrößen-Dropdowns in Collabora Online beheben

Browserzoom zurücksetzen, eine saubere Sitzung testen und feststellen, wann ein fehlerhaftes Größenmenü ein Collabora-Server-Update erfordert.

Verbinden Sie Nextcloud mit einem selbstgehosteten Collabora CODE-Container

Verbinden Sie Nextcloud mit einem selbstgehosteten Collabora CODE-Container

Setzen Sie Collabora CODE mit Docker ein, verbinden Sie es sicher mit Nextcloud Office und überprüfen Sie die Dokumentbearbeitung mit praktischen WOPI- und Proxy-Prüfungen.

Collabora-Verbindungsfehler mit coolwsd-Protokollen verfolgen

Collabora-Verbindungsfehler mit coolwsd-Protokollen verfolgen

Aktivieren Sie vorübergehend coolwsd für den Debug-Modus, erfassen Sie einen fehlgeschlagenen Öffnungsvorgang und verwenden Sie die Protokollsequenz, um WebSocket-, WOPI-, Proxy- und Containerprobleme zu unterscheiden.

Legen Sie ein sicheres Passwort für die Collabora-Administrationskonsole fest.

Legen Sie ein sicheres Passwort für die Collabora-Administrationskonsole fest.

Konfigurieren Sie den Collabora Online-Admin-Login für Docker oder Linux, starten Sie den richtigen Dienst neu und überprüfen Sie das neue Passwort, ohne es preiszugeben.