> For the complete documentation index, see [llms.txt](https://ayakaleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ayakaleaf-pro.ayaka.space/on-premises/de/erste-schritte/microservices.md). # Mikroservices Der empfohlene Weg, Overleaf Server CE- und Overleaf Pro-Instanzen bereitzustellen und zu verwalten, ist die Verwendung des Toolkits. Das Toolkit vereinfacht das Erstellen Ihrer Overleaf-Instanz durch den Einsatz einiger benutzerdefinierter Skripte, die die Orchestrierung der erforderlichen Microservices abstrahieren. Führen Sie einfach das mitgelieferte Initialisierungsskript aus, geben Sie einige Konfigurationsoptionen wie Ihre Pfade für den persistenten Speicher an, und das Toolkit kümmert sich um die Bereitstellung und Verbindung der Microservices, aus denen Ihre Overleaf Server CE- oder Pro-Instanz besteht. Dadurch können Sie sich ganz auf die Anpassung der Benutzererfahrung und die Implementierung der spezifischen Funktionen konzentrieren, aus denen Ihre On-Premise-Instanz besteht. Das Toolkit übernimmt die gesamte Komplexität im Hintergrund und ermöglicht so eine vereinfachte Bereitstellung Ihrer Overleaf-Instanz. {% hint style="info" %} Aus historischen Gründen wird der Hauptcontainer von Overleaf genannt `sharelatex`, und basiert auf dem `sharelatex/sharelatex` Docker-Image. Das liegt daran, dass die Technologie auf der Codebasis von ShareLaTeX basiert, die in Overleaf zusammengeführt wurde. Siehe [diesen Blogbeitragarrow-up-right](https://www.overleaf.com/blog/518-exciting-news-sharelatex-is-joining-overleaf) für weitere Details. Irgendwann in der Zukunft wird dies umbenannt, um dem Overleaf-Namensschema zu entsprechen. {% endhint %} #### Architektur Im Overleaf-Container läuft die Software als eine Reihe von Microservices, verwaltet von `runit`. Einige der interessanteren Dateien im Container sind: * `/etc/service/`: Initialisierungsdateien für die Microservices. * `/var/log/overleaf/`: Protokolle für jeden Microservice. * `/overleaf/services/`: Code für die verschiedenen Microservices. * `/var/lib/overleaf/`: der Mount-Punkt für persistente Daten (entspricht dem Verzeichnis, das auf dem Host durch `OVERLEAF_DATA_PATH` angegeben ist). #### Die MongoDB- und Redis-Container Overleaf ist von zwei externen Datenbanken abhängig: MongoDB und Redis. Standardmäßig stellt das Toolkit zusätzlich zum Overleaf-Container jeweils einen Container für diese Datenbanken bereit, insgesamt also drei Docker-Container. {% hint style="info" %} Wenn Sie sich lieber mit einer vorhandenen MongoDB- oder Redis-Instanz verbinden möchten, können Sie dies tun, indem Sie die entsprechenden Einstellungen in der [overleaf.rc](https://ayakaleaf-pro.ayaka.space/on-premises/de/erste-schritte/pages/ebffc4db90c8424b56a0fb8eda6f213a842f7da3#the-overleaf.rc-file) Konfigurationsdatei. {% endhint %} #### Editor- und Kompilierungsprozess Dieser Abschnitt bietet einen groben Überblick über die Behandlung von Dokumenten und den Kompilierungsprozess. {% hint style="info" %} Diese Seite beschreibt den Kompilierungsprozess mit Sandboxed Compiles, wie er nur in Overleaf Pro verfügbar ist. In Server CE verwendet der Kompilierungsprozess einfache Unterprozesse — ersetzen Sie die Elemente, die auf a verweisen **Container** mit einem einzelnen Element **Kompilierung im Unterprozess ausführen**. {% endhint %} Komponenten / Akteure: * `Benutzer` — Ein Benutzer der Anwendung * `Editor` — Die im Browser laufende Client-Anwendung * `clsi` — Der Microservice, der zum Kompilieren von PDFs verwendet wird * `document-updater` — Der Microservice, der zur Verarbeitung von Dokumentaktualisierungen verwendet wird * `filestore` — Der Microservice, der Binärdateien verarbeitet * `real-time` — Der Microservice, der WebSockets verarbeitet * `web` — Der (nicht ganz so) Microservice, der für die Verarbeitung von API-Anfragen verwendet wird **Redis-Caching** * **Benutzer**: lädt die Editor-Seite * **Editor**: öffnet WebSocket * **Editor**: sendet eine Anfrage, ein Dokument über WebSocket zu öffnen * **real-time** -> **document-updater**: Dokument wird aus MongoDB in Redis geladen * **Editor**: sendet Dokumentaktualisierung über WebSocket * **real-time** -> **document-updater**: Dokument wird in Redis aktualisiert * **Editor**: sendet weitere Kompilierungsanfragen * Nachdem seit dem letzten Flush 5 Minuten vergangen sind (pro Dokument): * **document-updater**: spült Dokument von Redis nach MongoDB * **Editor**: sendet weitere Aktualisierungen * alle 100 Aktualisierungen (pro Dokument): * **document-updater**: spült die Dokumenthistorie von Redis nach MongoDB * **Benutzer**: verlässt den Editor/schließt Browser-Tab * 5 Minuten später * **real-time**: prüft, ob es andere Mitwirkende gibt; wenn keine vorhanden sind: * **real-time** -> **document-updater**: spült Dokumente von Redis nach MongoDB **Lesen von MongoDB in Redis** * **document-updater** -> **web** -> **docstore**: aus MongoDB lesen **Spülen von Redis nach MongoDB** * **document-updater** -> **web** -> **docstore**: in MongoDB schreiben **Kompilieren — „vollständiger“ Sync-Modus** * **Editor**: sendet Kompilierungsanfrage mit auf „vollständig“ gesetztem Sync-Modus * **web** -> **document-updater**: beliebige Dokumente werden von Redis nach MongoDB gespült * **web** -> **docstore**: alle Dokumente werden aus MongoDB heruntergeladen * **web** -> **clsi**: Kompilierungsanfrage wird gesendet an `clsi`, einschließlich: * dem Sync-Modus * einem Hash des Dateibaums -> der „Projektzustand“ * allen Dokumenten mit ihrem Inhalt -> unterliegt dem 7-MB-Limit für den Request-Body * URLs von Binärdateien zum separaten Herunterladen * **clsi**: prüft den Zustand auf der Festplatte mit Sync-Modus und „Projektzustand“ * dies ist ein vollständiger Sync, daher kann der vorherige Zustand auf der Festplatte ignoriert werden * **clsi**: Kompilierungsverzeichnis bereinigen * **clsi**: alle Dokumente in das Kompilierungsverzeichnis schreiben * **clsi**: alle Binärdateien in das Kompilierungsverzeichnis schreiben * `clsi` kopiert die Dateien aus einem lokalen Cache pro Projekt * bei Cache-Miss: * **clsi** -> **filestore**: Dateien herunterladen * **clsi**: den „Projektzustand“ schreiben * **clsi**: sicherstellen, dass der Docker-Container mit der gewünschten Konfiguration existiert * Container-Optionen erstellen, einschließlich TeX-Live-Version * Optionen hashen * Containername: `projekt---` * **clsi**: startet Container und streamt stdout/stderr in den Speicher -> Limit 2 MB * **clsi**: zurückgelassenen gestoppten Container -> wird nach 24 Stunden bereinigt * **clsi**: schreibt stdout/stderr auf die Festplatte * **clsi**: kopiert Ausgabedateien in ein eindeutiges Ausgabeverzeichnis * build-id besteht aus 8 zufälligen Bytes plus Zeitstempel mit ms-Präzision * löscht alle Build-Ordner außer den letzten 3 (anonym) / den letzten 1 (angemeldeter Benutzer) * **clsi**: Kompilierung war fehlgeschlagen/abgelaufen * Kompilierungs-Cache löschen — er könnte teilweise Dateien/beschädigten Cache enthalten * **Editor**: lädt output.log und output.pdf herunter **Kompilieren — „inkrementeller“ Sync-Modus** * **Editor**: sendet Kompilierungsanfrage mit auf „inkrementell“ gesetztem Sync-Modus * **web** -> **document-updater**: alle Dokumente aus Redis abrufen * der Hash des Dateibaums wird ebenfalls in Redis gespeichert * **web** sendet den Hash des Dateibaums an `document-updater` und `document-updater` kann den inkrementellen Kompilierungslauf bei einer Abweichung in einen vollständigen Kompilierungslauf umwandeln * siehe Kompilierungsprozess wie ausgeführt, wenn der Editor „vollständige“ Kompilierung anforderte * **web** -> **clsi**: Kompilierungsanfrage wird gesendet an `clsi`, einschließlich: * dem Sync-Modus * einem Hash des Dateibaums -> der „Projektzustand“ * alle Dokumente aus Redis mit ihrem Inhalt -> unterliegt dem 7-MB-Limit für den Request-Body * keine Binärdateien * **clsi**: prüft den Zustand auf der Festplatte mit Sync-Modus und „Projektzustand“ * dies ist ein inkrementeller Sync, daher muss der „Projektzustand“ übereinstimmen * bei Abweichung: mit 409 antworten, das Web erneut mit „vollständigem“ Sync versuchen lassen * siehe Kompilierungsprozess wie ausgeführt, wenn der Editor „vollständige“ Kompilierung anforderte * **clsi**: aktualisierte Dokumente in das Kompilierungsverzeichnis schreiben * **clsi**: sicherstellen, dass der Docker-Container mit der gewünschten Konfiguration existiert * Container-Optionen erstellen, einschließlich TeX-Live-Version * Optionen hashen * Containername: `projekt---` * **clsi**: startet Container und streamt stdout/stderr in den Speicher -> Limit 2 MB * **clsi**: zurückgelassenen gestoppten Container -> wird nach 24 Stunden bereinigt * **clsi**: schreibt stdout/stderr auf die Festplatte * **clsi**: kopiert Ausgabedateien in ein eindeutiges Ausgabeverzeichnis * build-id besteht aus 8 zufälligen Bytes plus Zeitstempel mit ms-Präzision * löscht alle Build-Ordner außer den letzten 3 (anonym) / den letzten 1 (angemeldeter Benutzer) * **clsi**: Kompilierung war fehlgeschlagen/abgelaufen * Kompilierungs-Cache löschen — er könnte teilweise Dateien/beschädigten Cache enthalten * **Editor**: lädt output.log und output.pdf herunter **Kompilieren — Wechsel zwischen Modi** * **Editor**: beobachtet einen Kompilierungsfehler, der nächste Kompilierungslauf ist ein „vollständiger“ Kompilierungslauf * **Editor**: beobachtet einen Kompilierungserfolg, der nächste Kompilierungslauf ist ein „inkrementeller“ Kompilierungslauf --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://ayakaleaf-pro.ayaka.space/on-premises/de/erste-schritte/microservices.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.