> For the complete documentation index, see [llms.txt](https://overleaf-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://overleaf-pro.ayaka.space/on-premises/de/erste-schritte/microservices.md). # Microservices Die empfohlene Art, Overleaf Server CE- und Overleaf Pro-Instanzen bereitzustellen und zu verwalten, ist die Verwendung des Toolkits. Das Toolkit vereinfacht die Erstellung Ihrer Overleaf-Instanz durch die Verwendung einiger benutzerdefinierter Skripte, die die Orchestrierung der erforderlichen Microservices abstrahieren. Führen Sie einfach das mitgelieferte Initialisierungsskript aus, geben Sie einige Konfigurationsoptionen wie Ihre persistenten Speicherpfade 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 heißt der Haupt-Container von Overleaf `sharelatex`, und basiert auf dem `sharelatex/sharelatex` Docker-Image. Das liegt daran, dass die Technologie auf der ShareLaTeX-Codebasis 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 Innerhalb des Overleaf-Containers 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 `OVERLEAF_DATA_PATH` Host angegeben ist). #### Die MongoDB- und Redis-Container Overleaf hängt von zwei externen Datenbanken ab: MongoDB und Redis. Standardmäßig stellt das Toolkit zusätzlich zum Overleaf-Container jeweils einen Container für diese Datenbanken bereit, also insgesamt drei Docker-Container. {% hint style="info" %} Wenn Sie es vorziehen, eine vorhandene MongoDB- oder Redis-Instanz zu verbinden, können Sie dies tun, indem Sie die entsprechenden Einstellungen in der [overleaf.rc](https://overleaf-pro.ayaka.space/on-premises/de/erste-schritte/pages/ebffc4db90c8424b56a0fb8eda6f213a842f7da3#the-overleaf.rc-file) Konfigurationsdatei. {% endhint %} #### Editor und Kompilierungsprozess Dieser Abschnitt gibt einen allgemeinen Überblick über die Behandlung von Dokumenten und den Kompilierungsprozess. {% hint style="info" %} Diese Seite beschreibt den Kompilierungsprozess mit Sandbox-Kompilierungen, wie er nur in Overleaf Pro verfügbar ist. In Server CE verwendet der Kompilierungsprozess einfache Unterprozesse — ersetzen Sie die Elemente, die auf einen **Containers** durch ein einzelnes Element **Kompilierung in Unterprozess ausführen**. {% endhint %} Komponenten / Akteure: * `Benutzer` — Ein Benutzer der Anwendung * `Editor` — Die Client-Anwendung, die im Browser läuft * `clsi` — Der Mikroservice, der zum Kompilieren von PDFs verwendet wird * `document-updater` — Der Mikroservice, der zur Verarbeitung von Dokumentaktualisierungen verwendet wird * `filestore` — Der Mikroservice, der binäre Dateien verarbeitet * `real-time` — Der Mikroservice, der WebSockets verarbeitet * `web` — Der (nicht ganz so) Mikroservice, der zum Verarbeiten von API-Anfragen verwendet wird **Redis-Caching** * **Benutzer**: lädt die Editorseite * **Editor**: öffnet WebSocket * **Editor**: sendet eine Anfrage, um ein Dokument über WebSocket zu öffnen * **real-time** -> **document-updater**: Dokument wird von 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**: Dokument von Redis nach MongoDB flushen * **Editor**: sendet weitere Aktualisierungen * alle 100 Aktualisierungen (pro Dokument): * **document-updater**: Dokumenthistorie von Redis nach MongoDB flushen * **Benutzer**: verlässt den Editor/schließt Browser-Tab * 5 Minuten später * **real-time**: prüft auf andere Mitwirkende, wenn es keine gibt: * **real-time** -> **document-updater**: flusht Dokumente von Redis nach MongoDB **Lesen von MongoDB nach Redis** * **document-updater** -> **web** -> **docstore**: aus MongoDB lesen **Flushen von Redis nach MongoDB** * **document-updater** -> **web** -> **docstore**: nach MongoDB schreiben **Kompilierung — "voller" Synchronisationsmodus** * **Editor**: sendet Kompilierungsanfrage mit auf "voll" gesetztem Synchronisationsmodus * **web** -> **document-updater**: beliebige Dokumente werden von Redis nach MongoDB geflusht * **web** -> **docstore**: alle Dokumente werden aus MongoDB heruntergeladen * **web** -> **clsi**: Kompilierungsanfrage wird an `clsi`, einschließlich: * den Synchronisationsmodus * ein Hash des Dateibaums -> der "Projektstatus" * alle Dokumente mit ihrem Inhalt -> unterliegt der 7-MB-Beschränkung für den Anforderungstext * URLs für Binärdateien zum separaten Herunterladen * **clsi**: prüft den Zustand auf der Festplatte anhand des Synchronisationsmodus und des "Projektstatus" * dies ist eine vollständige Synchronisation, daher kann der vorherige Zustand auf der Festplatte ignoriert werden * **clsi**: Kompilierungsverzeichnis aufräumen * **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 "Projektstatus" schreiben * **clsi**: stellt sicher, dass der Docker-Container mit der gewünschten Konfiguration existiert * Containeroptionen erstellen, umfasst TeX Live-Version * Optionen hashen * Containername: `project---` * **clsi**: startet Container und streamt stdout/stderr in den Speicher -> Begrenzung 2 MB * **clsi**: lässt gestoppten Container zurück -> 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 Millisekundenauflösung * lösche alle bis auf die letzten 3 (anonym) / letzten 1 (angemeldeter Benutzer) Build-Ordner * **clsi**: Kompilierung ist fehlgeschlagen/Timeout * Kompilierungs-Cache löschen — er kann teilweise Dateien/einen beschädigten Cache enthalten * **Editor**: lädt output.log und output.pdf herunter **Kompilierung — "inkrementeller" Synchronisationsmodus** * **Editor**: sendet Kompilierungsanfrage mit auf "inkrementell" gesetztem Synchronisationsmodus * **web** -> **document-updater**: holt beliebige Dokumente aus Redis * der "Projektstatus"-Hash wird ebenfalls in Redis gespeichert * **web** sendet den Hash des Dateibaums an `document-updater` und `document-updater` kann die inkrementelle Kompilierung bei Nichtübereinstimmung in eine vollständige Kompilierung umwandeln * siehe Kompilierungsprozess, wie er ausgeführt wird, wenn der Editor "volle" Kompilierung angefordert hat * **web** -> **clsi**: Kompilierungsanfrage wird an `clsi`, einschließlich: * den Synchronisationsmodus * ein Hash des Dateibaums -> der "Projektstatus" * alle Dokumente aus Redis mit ihrem Inhalt -> unterliegt der 7-MB-Beschränkung für den Anforderungstext * keine Binärdateien * **clsi**: prüft den Zustand auf der Festplatte anhand des Synchronisationsmodus und des "Projektstatus" * dies ist eine inkrementelle Synchronisation, daher muss der "Projektstatus" übereinstimmen * bei Nichtübereinstimmung: mit 409 antworten, Web die Wiederholung mit "voller" Synchronisation durchführen lassen * siehe Kompilierungsprozess, wie er ausgeführt wird, wenn der Editor "volle" Kompilierung angefordert hat * **clsi**: schreibt aktualisierte Dokumente in das Kompilierungsverzeichnis * **clsi**: stellt sicher, dass der Docker-Container mit der gewünschten Konfiguration existiert * Containeroptionen erstellen, umfasst TeX Live-Version * Optionen hashen * Containername: `project---` * **clsi**: startet Container und streamt stdout/stderr in den Speicher -> Begrenzung 2 MB * **clsi**: lässt gestoppten Container zurück -> 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 Millisekundenauflösung * lösche alle bis auf die letzten 3 (anonym) / letzten 1 (angemeldeter Benutzer) Build-Ordner * **clsi**: Kompilierung ist fehlgeschlagen/Timeout * Kompilierungs-Cache löschen — er kann teilweise Dateien/einen beschädigten Cache enthalten * **Editor**: lädt output.log und output.pdf herunter **Kompilierung — Wechsel zwischen Modi** * **Editor**: beobachtet einen Kompilierungsfehler, die nächste Kompilierung ist eine "volle" Kompilierung * **Editor**: beobachtet einen erfolgreichen Kompilierungsvorgang, die nächste Kompilierung ist eine "inkrementelle" Kompilierung --- # 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://overleaf-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.