ONLYOFFICE Docs hinter HAProxy ablegen, ohne die Bearbeitung zu beeinträchtigen

Betreiben Sie ONLYOFFICE Docs hinter HAProxy, indem Sie HTTPS am Proxy terminieren, den ursprünglichen Host und das Schema weiterleiten und dauerhafte WebSocket-Verbindungen zulassen. Beginnen Sie mit einem funktionierenden Dokumentenserver; fügen Sie weitere Backends erst hinzu, wenn Ihre ONLYOFFICE-Bereitstellung für den unterstützten Betrieb mit mehreren Knoten konfiguriert ist, und nicht nur, weil HAProxy Anfragen verteilen kann.

Kann HAProxy den Lastenausgleich für zwei unabhängige Dokumentenserver übernehmen?

HAProxy kann HTTP-Anfragen zwischen Knoten verteilen, aber dadurch werden zwei eigenständige ONLYOFFICE-Installationen nicht zu einem koordinierten Bearbeitungscluster. Eine Bearbeitungssitzung verfügt über persistente Verbindungen und einen persistenten Anwendungsstatus. Das offizielle ONLYOFFICE-Beispiel mit Aktiv-Aktiv-Konfiguration verwendet Backend-Integritätsprüfungen und ein Persistenz-Cookie; dies sind Routing-Mechanismen, kein Ersatz für die gemeinsam genutzten Dienste und die Anwendungsarchitektur, die Ihre Edition erfordert.

Bei einer herkömmlichen Einzelserverinstallation verwenden Sie docs1die unten beschriebene Backend-Konfiguration. Bei zwei Knoten überprüfen Sie bitte zunächst die Clusterarchitektur, die unterstützte Edition, die gemeinsamen Abhängigkeiten, die Versionskompatibilität und die JWT-Konfiguration anhand Ihrer ONLYOFFICE-Bereitstellungsdokumentation oder beim Support Ihres Anbieters. Die Beispieladressen – 10.0.10.21und 10.0.10.22– sind beispielhafte private IP-Adressen und keine ermittelten Hosts.

Was muss funktionieren, bevor Sie HAProxy bearbeiten.

Der öffentliche Name docs.example.commuss auf Ihren HAProxy-Endpunkt verweisen. HAProxy benötigt eingehende TCP-Ports 80 und 443 sowie Zugriff auf jeden Dokumentenserver über ein privates Netzwerk auf Port 80. Ihre Dokumentenverwaltungsanwendung muss die öffentliche Docs-Adresse erreichen können, während ONLYOFFICE Dokumente abrufen und Rückrufe an die Anwendung senden muss. Halten Sie die HTTP-Verbindung im Backend privat; verschlüsseln Sie den Backend-Hop separat, falls er ein nicht vertrauenswürdiges Netzwerk durchläuft.

1. Prüfen Sie jeden Dokumentenserver vom Proxy-Host aus. Führen Sie den Befehl aus curl -i http://10.0.10.21/healthcheckund, falls vorhanden, den Befehl curl -i http://10.0.10.22/healthcheck. Ein funktionsfähiger Integritätsendpunkt gibt normalerweise HTTP 200 mit dem entsprechenden Body zurück true. Untersuchen Sie Routing, Firewalls oder Serverintegrität, bevor Sie den Lastausgleich konfigurieren, falls einer dieser Punkte fehlschlägt.
2. Bestätigen Sie ein festes JWT-Secret. Der Dokumentenserver und sein Konnektor müssen sich auf das Token-Secret einigen. Bei Docker-Installationen dokumentiert ONLYOFFICE die JWT_SECRETUmgebungsvariable. Seit Docs 7.2 kann die Verwendung eines automatisch generierten Secrets nach einer Neuerstellung oder einem Neustart zu Integrationsfehlern führen. In unterstützten Multi-Node-Bereitstellungen müssen die Secrets gemäß der Architektur des Herstellers auf allen Knoten aufeinander abgestimmt sein.

Diese Prüfungen erfolgen gemäß den Installationsanweisungen für Docker und den Konfigurationshinweisen für JWT des Herstellers . Deaktivieren Sie JWT nicht, nur um einen Proxy-Fehler zu umgehen.

Wie konfiguriert man HTTPS und leitet die korrekten Header weiter?

Schritt 1: Bereiten Sie das Zertifikat vor

Besorgen Sie sich ein vertrauenswürdiges Zertifikat docs.example.com. In diesem Linux-Beispiel liest HAProxy eine PEM-Datei, die die Zertifikatskette und den zugehörigen privaten Schlüssel enthält. Falls Zertifikate bereits an anderer Stelle vorhanden sind, ersetzen Sie diese Pfade. Beschränken Sie den Zugriff auf die kombinierte PEM-Datei und veranlassen Sie, dass diese bei der Zertifikatserneuerung neu erstellt wird.

sudo install -d -m 700 /etc/haproxy/certs
sudo sh -c 'umask 077; cat /etc/letsencrypt/live/docs.example.com/fullchain.pem /etc/letsencrypt/live/docs.example.com/privkey.pem > /etc/haproxy/certs/docs.example.com.pem'

Schritt 2: Frontend und Backend hinzufügen

Sichern Sie Ihre bestehenden Einstellungen /etc/haproxy/haproxy.cfgund passen Sie die folgenden Abschnitte an, anstatt die distributionsspezifischen Protokollierungs- oder Diensteinstellungen einfach zu ersetzen. Dies ist eine Beispielkonfiguration für aktuelle HAProxy-Versionen. Sie akzeptiert ausschließlich HTTP für die Umleitung, beendet HTTPS-Anfragen an Port 443, leitet den öffentlichen Host und das Schema weiter und überwacht den Anwendungsstatus-Endpunkt.

global
    log /dev/log local0

defaults
    mode http
    log global
    option httplog
    option forwardfor
    timeout connect 5s
    timeout client 60s
    timeout server 60s
    timeout tunnel 1h

frontend docs_http
    bind :80
    http-request redirect scheme https code 301

frontend docs_https
    bind :443 ssl crt /etc/haproxy/certs/docs.example.com.pem
    http-request set-header X-Forwarded-Proto https
    http-request set-header X-Forwarded-Host %[req.hdr(Host)]
    default_backend docs_nodes

backend docs_nodes
    option http-server-close
    balance roundrobin
    cookie SERVERID insert indirect nocache
    option httpchk GET /healthcheck
    http-check expect string true
    server docs1 10.0.10.21:80 check cookie docs1
    server docs2 10.0.10.22:80 check cookie docs2

Entfernen Sie die docs2Zeile, es sei denn, der zweite Knoten ist tatsächlich bereit. Der Persistenz-Cookie sorgt dafür, dass nachfolgende HTTP-Anfragen zum ausgewählten Knoten zurückgeleitet werden. HAProxy verarbeitet ein HTTP-WebSocket-Upgrade ohne spezielle URL-Umschreibung und timeout tunnel 1hermöglicht es, dass inaktive, aktualisierte Verbindungen länger als normale Anfragen offen bleiben. Die HAProxy-WebSocket-Dokumentation erläutert dieses Verhalten.

X-Forwarded-ProtoDie Einstellung httpsist hier korrekt, da dieses Frontend öffentliche HTTPS-Verbindungen beendet. Vertrauen Sie keinem beliebigen, vom Client bereitgestellten Weiterleitungsschema oder Host an einem Internet-Edge. Die ONLYOFFICE-Proxy-Dokumentation fordert ausdrücklich, dass X-Forwarded-Protoder X-Forwarded-Hostexterne URL-Kontext beibehalten wird.

Wie sollte man den Load Balancer neu laden und testen?

Schritt 3: Validierung vor der Umschaltung des Datenverkehrs

Überprüfen Sie die Syntax vor dem Neuladen. Ein Exit-Status ungleich Null bedeutet, dass Sie den gemeldeten Konfigurations- oder Zertifikatsfehler beheben müssen, bevor Sie fortfahren können:

sudo haproxy -c -f /etc/haproxy/haproxy.cfg
sudo systemctl reload haproxy
curl -i https://docs.example.com/healthcheck

Die öffentliche Health-Check-Antwort sollte HTTP 200 anzeigen, truewenn ein Backend fehlerfrei funktioniert. HAProxy verwendet die Direktiven option httpchk`remove` und `remove` http-check expect, um fehlerhafte Knoten aus der Rotation neuer Anfragen zu entfernen; siehe dazu die Health-Check-Referenz . Ein erfolgreicher Check beweist nicht, dass die Dokumentbearbeitung oder die Callback-Zustellung funktionieren.

Schritt 4: Bearbeitung, WebSockets und Speichern bestätigen.

Öffnen Sie ein Dokument über Ihre integrierte Anwendung, z. B. ein mit ONLYOFFICE Docs verbundenes Dokumentenmanagementsystem. Überprüfen Sie in den Entwicklertools Ihres Browsers im Netzwerk-Panel die WebSocket-Verbindung: Der Upgrade-Handshake sollte erfolgreich sein (HTTP-Statuscode: 0) 101 Switching Protocols. Nehmen Sie eine kleine Änderung vor, schließen Sie den Editor, öffnen Sie das Dokument erneut und prüfen Sie, ob die Änderung gespeichert wurde. Testen Sie bei einer ordnungsgemäß unterstützten Zwei-Knoten-Bereitstellung zusätzlich einen zweiten Mitarbeiter und eine geplante Datenentnahme auf einem einzelnen Knoten während eines Wartungsfensters.

Wenn die öffentliche Integritätsprüfung erfolgreich ist, der Editor aber abstürzt oder die Verbindung getrennt wird, prüfen Sie Warnungen zu gemischten Inhalten, WebSocket-Fehler, JWT-Fehler und ob die Dokumentanwendung die angegebene Docs-URL erreichen kann. Wenn ein Dokument geöffnet, aber nicht gespeichert wird, untersuchen Sie die Erreichbarkeit der Callback-Funktion vom Dokumentenserver zur Quellanwendung, anstatt die Round-Robin-Richtlinie von HAProxy zu ändern. Eine unterbrochene aktive WebSocket-Sitzung kann weiterhin eine erneute Verbindung des Clients erfordern; Backend-Integritätsprüfungen garantieren kein nahtloses Failover beim Bearbeiten.

Abschließende Überprüfung: Sowohl der Test des öffentlichen Gesundheits-Endpunkts als auch ein tatsächlicher Bearbeitungs- und Wiederöffnungstest sollten erfolgreich sein. Verwenden Sie ausschließlich verifizierte, unterstützte Knoten im Rotationsverfahren, stellen Sie sicher, dass die Zertifikatserneuerung das korrekte PEM neu lädt, und überwachen Sie die HAProxy-Protokolle auf wiederholte 502/503-Fehler oder unerwartete WebSocket-Verbindungsabbrüche.