Skip to main content
Die Dropbox-Synchronisierung nutzt drei Teile jedes Ayakaleaf-Pro-Pods, und alle drei starten nur mit DROPBOX_ENABLED: "true":
  • web (das dropbox-Modul): Verknüpfung, der Dropbox-Dialog des Projekts und der Webhook, den Dropbox aufruft.
  • third-party-datastore: ein eigener Dienst innerhalb des Pods, der die Warteschlange der Änderungen abarbeitet, die an Dropbox gesendet oder von Dropbox abgerufen werden sollen.
  • document-updater: Bei aktiviertem Dropbox schreibt er die Änderungen des Editors im Hintergrund in MongoDB, einige Minuten nachdem alle ein Projekt verlassen haben; erst dann gelangen sie zu Dropbox.
Erstellen Sie die Dropbox-App und lesen Sie, wie die Synchronisierung funktioniert, unter Dropbox-Synchronisierung; diese Seite überträgt das auf Kubernetes.

Konfiguration

1

ConfigMap

30-config.yaml (additions)
GIT_BRIDGE_ENABLED: "true" und das git-bridge-StatefulSet aus Git-Integration müssen vorhanden sein: Ohne sie blenden die Kontoeinstellungen den Bereich zur Projektsynchronisierung aus.
2

Secret

DROPBOX_TOKEN_CIPHER_PASSWORD verschlüsselt die Dropbox-Tokens der Benutzer in MongoDB. Jedes Replikat muss denselben Wert verwenden, und eine spätere Änderung zwingt jeden Benutzer, Dropbox erneut zu verknüpfen.
3

Die Datenbankindizes erstellen

Führen Sie die Index-Befehle aus Die Datenbankindizes erstellen einmal auf dem Primary des Replica Sets aus:
4

Anwenden und neu starten

third-party-datastore.log existiert nur, wenn DROPBOX_ENABLED auf "true" steht.
5

Den Webhook für das Internet öffnen

Dropbox muss ${OVERLEAF_SITE_URL}/dropbox/webhook aus dem Internet erreichen. Wenn Ihr Ingress oder Load Balancer von außen nur bestimmte Pfade oder Netzwerke zulässt, erlauben Sie diesen; es ist der einzige Pfad, den Dropbox aufruft. Prüfen Sie ihn von außerhalb des Clusters:
Fügen Sie den Webhook dann in der Dropbox App Console hinzu, wie auf der Toolkit-Seite beschrieben.

Mehrere Replikate

Über das gemeinsame DROPBOX_TOKEN_CIPHER_PASSWORD hinaus nichts weiter:
  • Der Webhook kann bei jedem beliebigen Replikat ankommen. Er stellt die Änderung lediglich in Redis in die Warteschlange.
  • Jedes Replikat führt third-party-datastore aus, und jedes arbeitet an der gemeinsamen Warteschlange. Die Warteschlange eines Benutzers wird mit einer Sperre in Redis übernommen, sodass jeweils nur ein Replikat die Änderungen eines bestimmten Benutzers sendet oder abruft.
  • Der document-updater jedes Replikats schreibt inaktive Projekte im Hintergrund. Jedes Projekt wird aus einer gemeinsamen Liste in Redis entnommen, sodass es nur einmal geschrieben wird.

Getestet auf Kubernetes

Gegen einen Mock der Dropbox-API bestehen auf Kubernetes 1.37 mit drei Replikaten hinter HAProxy unsere End-to-End-Tests für die Dropbox-Synchronisierung (59 Fälle): Verknüpfen und Trennen; Senden von Projekten, Bearbeitungen, Binärdateien, Umbenennungen, Verschiebungen und Löschungen an Dropbox, einschließlich einer Bearbeitung im Editor, die nach dem Schließen des Projekts über das Schreiben im Hintergrund ankommt, ohne Kompilieren oder “sync now”; Übernahme von in Dropbox vorgenommenen Änderungen über den Webhook (Verifizierungs-Challenge und Signaturprüfung), neue Projekte aus neuen Ordnern, gelöschte Projektordner; Projekte mit demselben Namen; der Dropbox-Dialog des Editors und “sync now” mit seiner Ratenbegrenzung; Wiederholungen, Ratenbegrenzungen und Timeouts von Dropbox; getrennte Konten, wenn Dropbox voll ist, das Token ablehnt oder gesperrt ist; gesperrte Overleaf-Konten; sowie die Antwort des Webhooks, wenn third-party-datastore ausgefallen ist.
Zuletzt geändert am 2. November 2026