Collabora Online mit Docker installieren und sicher an Nextcloud anbinden

Mit Collabora Online lassen sich Textdokumente, Tabellen und Präsentationen direkt in Nextcloud bearbeiten. Der Browser lädt die Bedienoberfläche und die WebSocket-Verbindung unmittelbar vom Collabora Server. Deshalb muss die Office Domain für die Benutzer erreichbar sein. Die Absicherung erfolgt nicht durch eine pauschale Sperre aller öffentlichen Zugriffe, sondern durch TLS, erlaubte WOPI Hosts und eine WOPI Allowlist in Nextcloud.

Diese Anleitung installiert die Collabora Online Development Edition, kurz CODE, als Docker Container. Nginx Proxy Manager übernimmt das TLS Zertifikat und leitet die Anfragen intern über HTTP an den Container weiter. Anschließend werden zwei Nextcloud Instanzen als Beispiele angebunden.

Wichtig: Alle Domains, IP Adressen, Benutzer und Kennwörter in dieser Anleitung sind Beispieldaten. Ersetzen Sie diese Werte vor der Ausführung durch die Daten Ihrer eigenen Umgebung.

1. Architektur und Datenfluss verstehen

Bei der Integration sind drei getrennte Verbindungen beteiligt:

Der Editor läuft in einem iframe im Browser. Eine Firewall Regel, die an der Office Domain ausschließlich die IP Adresse des Nextcloud Servers zulässt, blockiert deshalb auch die Endanwender. Typisches Ergebnis ist ein leerer oder grauer Editorbereich.

Für die eigentliche Absicherung werden zwei Richtungen getrennt betrachtet:

1. Collabora akzeptiert nur festgelegte WOPI Hosts: Die Variablen aliasgroup1, aliasgroup2 und weitere Gruppen begrenzen, von welchen Nextcloud Domains Dokumente geöffnet werden dürfen.
2. Nextcloud akzeptiert WOPI Anfragen nur vom Collabora Server: Die Einstellung wopi_allowlist enthält die Quelladresse, die Nextcloud bei den WOPI Anfragen tatsächlich sieht. Nextcloud empfiehlt ausdrücklich, WOPI Anfragen auf die erwarteten Collabora Server zu begrenzen.[3]

2. Voraussetzungen

1. Ein Linux Server mit Docker Engine und dem Docker Compose Plugin. Fehlt Docker noch, hilft die S-EDV Anleitung zur Docker Installation.
2. Eine eigene Subdomain für Collabora, im Beispiel office.example.net.
3. Ein DNS A Record, der auf die öffentliche IPv4 Adresse des Collabora Servers zeigt.
4. Nginx Proxy Manager auf demselben Docker Host oder ein anderer korrekt konfigurierter Reverse Proxy.
5. Ein gemeinsames externes Docker Netzwerk, im Beispiel npm_network.
6. Mindestens eine erreichbare Nextcloud Instanz mit gültigem TLS Zertifikat.
7. SSH Zugriff auf den Docker Host und auf die Nextcloud Systeme.
8. Ausreichend Arbeitsspeicher und CPU Reserven. Der tatsächliche Bedarf hängt von Dokumentgröße, Dateityp, Funktionen und gleichzeitiger Nutzung ab. Vor einem produktiven Einsatz sollte die Auslastung mit realistischen Testdokumenten gemessen werden.

Beispielwerte vorab prüfen

3. DNS und Docker Netzwerk prüfen

Die Office Domain muss auf den Reverse Proxy zeigen. Die folgenden Befehle werden auf einem Administrationsrechner oder auf dem Docker Host ausgeführt:

dig +short office.example.net A
curl -4 -s https://ifconfig.me
printf '\n'

Beide Ausgaben sollten zur vorgesehenen öffentlichen Adresse passen. Bei NAT oder vorgeschalteten Proxys kann die ausgehende Adresse von der eingehenden Adresse abweichen.

Nun wird geprüft, ob das Docker Netzwerk von Nginx Proxy Manager vorhanden ist:

docker network inspect npm_network

Falls der Name abweicht, lässt er sich über die Netzwerke des Proxy Containers ermitteln:

docker ps --format '{{.Names}}\t{{.Image}}'
docker inspect NPM_CONTAINER --format '{{range $name, $config := .NetworkSettings.Networks}}{{$name}}{{"\n"}}{{end}}'

NPM_CONTAINER wird durch den tatsächlichen Containernamen ersetzt.

4. Collabora Online mit Docker Compose installieren

4.1 Arbeitsverzeichnis anlegen

sudo mkdir -p /opt/docker/collabora
sudo chown "$USER":"$USER" /opt/docker/collabora
cd /opt/docker/collabora

4.2 Kennwort für die Administrationskonsole erzeugen

Ein hexadezimales Kennwort vermeidet Sonderzeichen, die Docker Compose als Variablen interpretieren könnte:

openssl rand -hex 24

Das Kennwort wird an einer sicheren Stelle gespeichert. Es gehört nicht in eine öffentlich erreichbare Dokumentation oder ein Git Repository.

4.3 Compose Datei erstellen

Die folgende Datei wird als /opt/docker/collabora/docker-compose.yml gespeichert. Die Domains, das Kennwort und bei Bedarf die Ressourcengrenzen müssen angepasst werden.

services:
  collabora:
    image: collabora/code:latest
    container_name: collabora
    restart: unless-stopped

    cap_add:
      - MKNOD

    mem_limit: 3g
    memswap_limit: 3g
    cpus: 2.0
    pids_limit: 512

    ulimits:
      nofile:
        soft: 65536
        hard: 65536

    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

    environment:
      aliasgroup1: 'https://cloud1\.example\.net:443'
      aliasgroup2: 'https://cloud2\.example\.net:443'
      server_name: 'office.example.net'
      dictionaries: 'de_DE en_US'
      username: 'admin'
      password: 'HIER_DAS_ERZEUGTE_KENNWORT_EINTRAGEN'
      extra_params: >-
        --o:ssl.enable=false
        --o:ssl.termination=true
        --o:net.proto=IPv4
        --o:logging.level=warning
        --o:num_prespawn_children=4

    networks:
      - npm_network

networks:
  npm_network:
    external: true

Das offizielle Container Image heißt collabora/code. Collabora beschreibt CODE als schnell nutzbares Image für die Integration mit einer Speicherplattform wie Nextcloud.[1]

Die Punkte in den Nextcloud Domains sind mit einem Backslash maskiert, weil die Aliasgruppe als regulärer Ausdruck ausgewertet wird.

Hinweis zu latest: Für ein Testsystem ist das Tag bequem. In einer kontrollierten Produktivumgebung sollte nach erfolgreichem Test ein konkretes Image Tag oder ein Digest festgelegt werden. So lässt sich ein Rollback reproduzierbar durchführen.

4.4 Konfiguration validieren

cd /opt/docker/collabora
docker compose config

Die gerenderte Konfiguration muss die vollständigen Aliasgruppen, den richtigen Servernamen und das erwartete Kennwort enthalten. Das Kennwort darf nicht unbemerkt durch eine Compose Variable verändert worden sein.

4.5 Container starten

docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 collabora

Der Container soll den Status Up erreichen. Im Log wird anschließend nach den erlaubten WOPI Hosts und der Bereitschaft auf Port 9980 gesucht:

docker compose logs collabora | grep -E 'trusted WOPI|Ready to accept connections|port 9980'

Logtexte ändern sich zwischen Versionen. Entscheidend sind ein laufender Container, keine fortlaufenden Neustarts und ein erfolgreicher Abruf des Discovery Endpunkts.

5. Internen Zugriff aus Nginx Proxy Manager testen

Zuerst wird der tatsächliche Name des Proxy Containers ermittelt:

docker ps --format '{{.Names}}\t{{.Image}}' | grep -Ei 'nginx|proxy|npm'

Danach wird der Discovery Endpunkt aus diesem Container abgerufen:

docker exec NPM_CONTAINER \
  curl -sS -o /dev/null -w '%{http_code}\n' \
  http://collabora:9980/hosting/discovery

Erwartet wird der HTTP Status 200. Schlägt der Test fehl, befinden sich die Container meist nicht im selben Docker Netzwerk oder der Containername collabora kann nicht aufgelöst werden.

6. Nginx Proxy Manager konfigurieren

In Nginx Proxy Manager wird unter Hosts und Proxy Hosts ein neuer Eintrag erstellt.

6.1 Details

Das interne Schema ist bewusst http. TLS endet am Reverse Proxy. Wird hier versehentlich https gewählt, trifft TLS Datenverkehr auf den unverschlüsselten Port 9980.

6.2 TLS Zertifikat

1. Ein neues Let's Encrypt Zertifikat anfordern oder ein vorhandenes Zertifikat auswählen.
2. Force SSL aktivieren.
3. HTTP/2 Support aktivieren.
4. Die Nutzungsbedingungen bestätigen.

6.3 Erweiterte Proxy Einstellungen

proxy_read_timeout 36000s;
proxy_send_timeout 36000s;
client_max_body_size 0;
proxy_buffering off;
proxy_set_header Host $host;

Die langen Zeitüberschreitungen verhindern, dass länger geöffnete Bearbeitungssitzungen vom Proxy vorzeitig beendet werden. Collabora dokumentiert für Reverse Proxys eigene Weiterleitungen für Discovery, Capabilities, Browser Ressourcen und WebSocket Verbindungen.[2] Nginx Proxy Manager erzeugt diese Weiterleitungen weitgehend über den Proxy Host und die aktivierte WebSocket Unterstützung.

7. Öffentliche Endpunkte testen

curl -fsS https://office.example.net/hosting/discovery | head -n 3
curl -fsS https://office.example.net/hosting/capabilities

Der Discovery Endpunkt muss XML liefern. Im XML sollte für eine extern per HTTPS erreichbare Installation die Zone external-https erscheinen:

curl -fsS https://office.example.net/hosting/discovery \
  | grep -o 'net-zone name="[^"]*"' \
  | sort -u

Erscheint ausschließlich external-http, werden ssl.termination, der Host Header und die Proxy Konfiguration geprüft.

8. Nextcloud anbinden

Die App richdocuments verbindet Nextcloud mit dem externen Collabora Server. Die separat gebündelte CODE App richdocumentscode wird für diesen Aufbau nicht benötigt.

8.1 Tatsächliche WOPI Quelladresse ermitteln

Die Beispieladresse 203.0.113.10/32 darf nicht ungeprüft übernommen werden. In die Allowlist gehört die Adresse, die Nextcloud als Quelle der WOPI Anfrage sieht. Bei NAT, Reverse Proxy oder internem Routing kann das eine andere Adresse sein.

Als erster Anhaltspunkt dient die ausgehende IPv4 Adresse des Collabora Hosts:

curl -4 -s https://ifconfig.me
printf '\n'

Nach dem ersten Öffnungsversuch wird die Adresse zusätzlich in den Webserver Logs und in nextcloud.log geprüft. Erst dann wird die Allowlist endgültig gesetzt.

8.2 Erste Nextcloud Instanz

Im Beispiel liegt Nextcloud unter /var/www/cloud1.example.net und gehört dem Systembenutzer nextcloud1. Pfad, Benutzer und PHP Befehl müssen zur eigenen Umgebung passen.

cd /var/www/cloud1.example.net

sudo -u nextcloud1 php occ status
sudo -u nextcloud1 php occ app:install richdocuments
sudo -u nextcloud1 php occ app:enable richdocuments

sudo -u nextcloud1 php occ config:app:set richdocuments wopi_url \
  --value='https://office.example.net'
sudo -u nextcloud1 php occ config:app:set richdocuments public_wopi_url \
  --value='https://office.example.net'
sudo -u nextcloud1 php occ config:app:set richdocuments wopi_allowlist \
  --value='203.0.113.10/32'

sudo -u nextcloud1 php occ richdocuments:activate-config

Falls bereits die eingebaute CODE App verwendet wurde, wird sie nach Prüfung der eigenen Umgebung deaktiviert und entfernt:

sudo -u nextcloud1 php occ app:disable richdocumentscode
sudo -u nextcloud1 php occ app:remove richdocumentscode

8.3 Zweite Nextcloud Instanz

cd /var/www/cloud2.example.net

sudo -u nextcloud2 php occ status
sudo -u nextcloud2 php occ app:install richdocuments
sudo -u nextcloud2 php occ app:enable richdocuments

sudo -u nextcloud2 php occ config:app:set richdocuments wopi_url \
  --value='https://office.example.net'
sudo -u nextcloud2 php occ config:app:set richdocuments public_wopi_url \
  --value='https://office.example.net'
sudo -u nextcloud2 php occ config:app:set richdocuments wopi_allowlist \
  --value='203.0.113.10/32'

sudo -u nextcloud2 php occ richdocuments:activate-config

Wichtig: occ wird als der Benutzer ausgeführt, dem die jeweilige Nextcloud Installation gehört. Eine Ausführung als root kann falsche Eigentümer bei neu angelegten Dateien verursachen.

Auf Hosting Systemen mit mehreren PHP Versionen wird statt php der passende Befehl verwendet, beispielsweise php8.3 oder php8.4. occ status muss mit derselben PHP Hauptversion funktionieren, die auch der Webserver für die Instanz nutzt.

9. Integration vollständig verifizieren

9.1 Gespeicherte Nextcloud Einstellungen prüfen

sudo -u nextcloud1 php occ config:app:get richdocuments wopi_url
sudo -u nextcloud1 php occ config:app:get richdocuments public_wopi_url
sudo -u nextcloud1 php occ config:app:get richdocuments wopi_allowlist

9.2 Funktionstest im Browser

1. In Nextcloud anmelden.
2. Ein kleines ODT Dokument anlegen.
3. Das Dokument öffnen und auf einen vollständig geladenen Editor warten.
4. Text eingeben.
5. Dokument schließen.
6. Dokument erneut öffnen und prüfen, ob die Änderung gespeichert wurde.
7. Den Test mit einem zweiten Benutzer wiederholen, wenn gemeinsames Bearbeiten eingesetzt werden soll.

9.3 Browser Prüfung bei Fehlern

Die Entwicklertools des Browsers zeigen unter Network, ob Anfragen an office.example.net fehlschlagen. Besonders wichtig sind WebSocket Verbindungen mit dem Schema wss://. Fehlerhafte ws:// Verbindungen auf einer HTTPS Seite sprechen für eine unpassende TLS Terminierung oder falsche externe URLs.

10. Eine weitere Nextcloud Instanz hinzufügen

Für eine neue Instanz wird zuerst eine weitere Aliasgruppe ergänzt:

aliasgroup3: 'https://cloud3\.example\.net:443'

Anschließend wird die Konfiguration geprüft und der Container neu erstellt:

cd /opt/docker/collabora
docker compose config
docker compose up -d --force-recreate
docker compose logs --tail=100 collabora

Das Neuerstellen trennt bestehende Bearbeitungssitzungen. Die Änderung gehört deshalb in ein angekündigtes Wartungsfenster.

Danach wird auf der neuen Nextcloud Instanz der passende Block aus Abschnitt 8 ausgeführt. Abschließend folgen der Konfigurationsabruf und ein echter Öffnungs- und Speichertest.

11. Betrieb und Monitoring

11.1 Administrationskonsole

Die Administrationskonsole liegt üblicherweise unter:

https://office.example.net/browser/dist/admin/admin.html

Der Pfad ist über die öffentliche Office Domain erreichbar und wird durch die konfigurierten Anmeldedaten geschützt. Zusätzlich kann der Zugriff am Reverse Proxy auf vertrauenswürdige Verwaltungsadressen begrenzt werden. Vor einer IP Sperre muss eine feste Verwaltungsadresse oder ein VPN vorhanden sein, sonst sperrt sich der Administrator leicht selbst aus.

Wer die Konsole nicht benötigt, ergänzt in extra_params:

--o:admin_console.enable=false

11.2 HTTP Monitoring

Ein einfacher Monitor kann den Capabilities Endpunkt prüfen:

1. URL: https://office.example.net/hosting/capabilities
2. Erwarteter HTTP Status: 200
3. Optionales Suchwort: productName

Eine vollständige Anleitung zum Aufbau des Monitors bietet Uptime Kuma mit Docker und Nginx Proxy Manager installieren.

11.3 Logs

cd /opt/docker/collabora
docker compose logs -f --tail=100 collabora

Der Nextcloud Logpfad hängt von der Installation ab. Der konfigurierte Pfad lässt sich mit occ auslesen:

sudo -u nextcloud1 php occ config:system:get logfile

11.4 Updates kontrolliert durchführen

Automatische Container Updates können alle geöffneten Dokumente trennen. Für einen Office Dienst ist ein kontrolliertes Wartungsfenster meist sicherer.

cd /opt/docker/collabora
docker compose pull
docker compose up -d
docker compose ps
curl -fsS https://office.example.net/hosting/capabilities

Vor dem Update werden das bisherige Image Tag oder der Digest sowie die aktuelle Compose Datei dokumentiert. Schlägt die neue Version fehl, kann gezielt auf das vorherige Image zurückgegangen werden.

12. Sicherheitshinweise

1. Die Office Domain benötigt ein gültiges TLS Zertifikat.
2. Jede Nextcloud Domain wird als eigene Aliasgruppe eingetragen.
3. Die WOPI Allowlist in Nextcloud enthält nur die tatsächlich sichtbaren Quelladressen der Collabora Server.
4. Die Administrationskonsole erhält ein starkes, einzigartiges Kennwort oder wird deaktiviert.
5. Port 9980 wird nicht direkt am Host veröffentlicht, wenn Nginx Proxy Manager denselben Docker Host und dasselbe Netzwerk nutzt.
6. Konfigurationsdateien mit Kennwörtern erhalten restriktive Dateirechte.
7. Container Updates erfolgen getestet und nachvollziehbar.
8. Backups der Nextcloud Daten und Datenbanken werden regelmäßig durch einen Wiederherstellungstest geprüft. Collabora ersetzt kein Nextcloud Backup.

chmod 600 /opt/docker/collabora/docker-compose.yml

Härtungen wie ein schreibgeschütztes Dateisystem oder no-new-privileges dürfen nicht ungeprüft übernommen werden. Collabora erzeugt Laufzeitverzeichnisse und verwendet Hilfsprozesse für die Dokumentisolation. Jede zusätzliche Härtung muss mit Öffnen, Bearbeiten, Speichern, Exportieren und gemeinsamem Arbeiten getestet werden.

13. Troubleshooting

Kompakter Diagnoseblock

cd /opt/docker/collabora

docker compose ps
docker compose logs --tail=100 collabora
docker network inspect npm_network
curl -fsS https://office.example.net/hosting/discovery | head -n 3
curl -fsS https://office.example.net/hosting/capabilities

14. Kapazität und Lizenz vor dem Kundeneinsatz prüfen

CODE ist die Entwicklungsedition von Collabora Online und richtet sich laut Produktbeschreibung besonders an kleine Installationen, Tests und den privaten Einsatz.[1] Vor einem geschäftlichen Rollout auf mehrere unabhängige Kundeninstanzen müssen die aktuell geltenden Nutzungsbedingungen, Kapazitätsgrenzen und Supportoptionen direkt beim Hersteller geprüft werden.

Alle Nextcloud Instanzen, die denselben Collabora Server verwenden, teilen dessen CPU, Arbeitsspeicher und gleichzeitige Sitzungen. Für größere oder voneinander getrennte Umgebungen kommen eine lizenzierte Collabora Online Ausgabe oder getrennte Office Instanzen infrage.

15. Schnellreferenz

# Status und Logs
cd /opt/docker/collabora
docker compose ps
docker compose logs --tail=100 collabora

# Neustart ohne Konfigurationsänderung
docker compose restart collabora

# Geänderte Konfiguration übernehmen
docker compose config
docker compose up -d --force-recreate

# Öffentliche Endpunkte prüfen
curl -fsS https://office.example.net/hosting/discovery | head -n 3
curl -fsS https://office.example.net/hosting/capabilities

# Nextcloud Konfiguration auslesen
sudo -u nextcloud1 php occ config:app:get richdocuments wopi_url
sudo -u nextcloud1 php occ config:app:get richdocuments public_wopi_url
sudo -u nextcloud1 php occ config:app:get richdocuments wopi_allowlist

Passende Anleitungen auf S-EDV

1. Docker installieren: Grundlage für den Betrieb von Collabora als Container.
2. Uptime Kuma mit Docker und Nginx Proxy Manager installieren: Den öffentlichen Collabora Endpunkt überwachen.

Quellen

1. [1] Collabora Online SDK: CODE Docker Image
2. [2] Collabora Online SDK: Proxy settings
3. [3] Nextcloud Administration Manual: Office configuration
4. [4] Docker Docs: Compose interpolation