> 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/nl/aan-de-slag/microservices.md).

# Microservices

De aanbevolen manier om Overleaf Server CE- en Overleaf Pro-instanties te implementeren en beheren is via de Toolkit.

De Toolkit vereenvoudigt het aanmaken van uw Overleaf-instantie door middel van enkele aangepaste scripts die de orkestratie van vereiste microservices abstraheren. Voer eenvoudig het meegeleverde initialisatiescript uit, geef een paar configuratieopties op zoals uw paden voor persistente opslag, en de Toolkit zorgt voor het provisioneren en verbinden van de microservices waaruit uw Overleaf Server CE- of Pro-instantie bestaat.

Hierdoor kunt u zich richten op het aanpassen van de gebruikerservaring en het implementeren van de specifieke functies waaruit uw on-premises instantie bestaat. De Toolkit regelt alle complexiteit achter de schermen, waardoor de implementatie van uw Overleaf-instantie wordt vereenvoudigd.

{% hint style="info" %}
Om historische redenen heet de hoofdcontainer van Overleaf `sharelatex`, en is gebaseerd op de `sharelatex/sharelatex` Docker-image. Dit komt doordat de technologie is gebaseerd op de ShareLaTeX-codebase, die is samengevoegd met Overleaf. Zie [deze blogpostarrow-up-right](https://www.overleaf.com/blog/518-exciting-news-sharelatex-is-joining-overleaf) voor meer details. Op een gegeven moment in de toekomst zal dit worden hernoemd zodat het overeenkomt met het naamgevingsschema van Overleaf.
{% endhint %}

#### Architectuur

Binnen de Overleaf-container draait de software als een set microservices, beheerd door `runit`. Enkele van de interessantere bestanden in de container zijn:

* `/etc/service/`: initialisatiebestanden voor de microservices.
* `/var/log/overleaf/`: logbestanden voor elke microservice.
* `/overleaf/services/`: code voor de verschillende microservices.
* `/var/lib/overleaf/`: het mountpunt voor persistente gegevens (komt overeen met de map die op de host wordt aangegeven door `OVERLEAF_DATA_PATH` op de host).

#### De MongoDB- en Redis-containers

Overleaf is afhankelijk van twee externe databases: MongoDB en Redis. Standaard zal de Toolkit voor elk van deze databases een container provisioneren, naast de Overleaf-container, voor een totaal van drie Docker-containers.

{% hint style="info" %}
Als u liever verbinding maakt met een bestaande MongoDB- of Redis-instantie, kunt u dit doen door de juiste instellingen in het [overleaf.rc](https://overleaf-pro.ayaka.space/on-premises/nl/aan-de-slag/pages/cf22a5337a7da6933c7863f22dd3f7de77f7ac91#the-overleaf.rc-file) configuratiebestand.
{% endhint %}

#### Editor- en compileerproces

Deze sectie geeft een globaal overzicht van de afhandeling van documenten en het compileerproces.

{% hint style="info" %}
Deze pagina beschrijft het compileerproces met Sandboxed Compiles zoals alleen beschikbaar in Overleaf Pro. In Server CE gebruikt het compileerproces eenvoudige subprocessen — vervang de items die verwijzen naar een **container** door één item **compile uitvoeren in subproces**.
{% endhint %}

Onderdelen / Actoren:

* `gebruiker` — Een gebruiker van de applicatie
* `editor` — De clientapplicatie die in de browser draait
* `clsi` — De microservice die wordt gebruikt voor het compileren van pdf's
* `document-updater` — De microservice die wordt gebruikt voor het verwerken van documentupdates
* `filestore` — De microservice die binaire bestanden afhandelt
* `real-time` — De microservice die wordt gebruikt voor het afhandelen van websockets
* `web` — De (niet zo) microservice die wordt gebruikt voor het afhandelen van API-aanvragen

**Redis-caching**

* **gebruiker**: laadt de editorpagina
* **editor**: opent websocket
* **editor**: stuurt een verzoek om een document te openen via websocket
  * **real-time** -> **document-updater**: document wordt vanuit MongoDB in Redis geladen
* **editor**: stuurt documentupdate via websocket
  * **real-time** -> **document-updater**: document wordt in Redis bijgewerkt
* **editor**: stuurt meer compileerverzoeken
  * Nadat 5 minuten zijn verstreken sinds de laatste flush (per document):
    * **document-updater**: schrijft document van Redis naar MongoDB weg
* **editor**: stuurt meer updates
  * elke 100 updates (per document):
    * **document-updater**: schrijft documentgeschiedenis van Redis naar MongoDB weg
* **gebruiker**: verlaat de editor/sluit browsertabblad
  * 5 minuten later
    * **real-time**: controleert op andere samenwerkenden, als er geen zijn:
      * **real-time** -> **document-updater**: schrijft documenten van Redis naar MongoDB weg

**Lezen van MongoDB naar Redis**

* **document-updater** -> **web** -> **docstore**: lezen uit MongoDB

**Wegschrijven van Redis naar MongoDB**

* **document-updater** -> **web** -> **docstore**: schrijven naar MongoDB

**Compile — "full" synchronisatiemodus**

* **editor**: stuurt compileerverzoek met synchronisatiemodus ingesteld op "full"
* **web** -> **document-updater**: eventuele documenten worden van Redis naar MongoDB weggeschreven
* **web** -> **docstore**: alle documenten worden gedownload uit MongoDB
* **web** -> **clsi**: compileerverzoek wordt gestuurd naar `clsi`, inclusief:
  * de synchronisatiemodus
  * een hash van de bestandstree -> de "projectstatus"
  * alle documenten met hun inhoud -> onderhevig aan een limiet van 7 MB voor de aanvraagbody
  * URL's van binaire bestanden voor afzonderlijk downloaden
* **clsi**: controle op schijfstatus met synchronisatiemodus en "projectstatus"
  * dit is een volledige synchronisatie, dus de vorige status op schijf kan worden genegeerd
* **clsi**: compileermap opschonen
* **clsi**: schrijf alle documenten naar de compileermap
* **clsi**: schrijf alle binaire bestanden naar de compileermap
  * `clsi` kopieert de bestanden vanuit een lokale cache per project
  * bij cache-miss:
    * **clsi** -> **filestore**: bestanden downloaden
* **clsi**: schrijf de "projectstatus"
* **clsi**: zorg dat de Docker-container bestaat met de gewenste configuratie
  * bouw containeropties, inclusief texlive-versie
  * opties hashen
  * containernaam: `project-<project-id>-<user-id>-<hash>`
* **clsi**: start de container en stream stdout/stderr naar het geheugen -> limiet 2 MB
* **clsi**: laat de gestopte container achter -> wordt na 24 uur opgeruimd
* **clsi**: schrijf stdout/stderr naar schijf
* **clsi**: kopieer uitvoerbestanden naar een unieke uitvoermap
  * build-id samengesteld uit 8 willekeurige bytes plus tijdstempel met precisie in ms
  * verwijder alle buildmappen behalve de laatste 3 (anoniem) / laatste 1 (ingelogde gebruiker)
* **clsi**: compileer was mislukt/time-out
  * verwijder compileercache — deze kan gedeeltelijke bestanden/corrupte cache bevatten
* **editor**: downloadt output.log en output.pdf

**Compile — "incremental" synchronisatiemodus**

* **editor**: stuurt compileerverzoek met synchronisatiemodus ingesteld op "incremental"
* **web** -> **document-updater**: haal eventuele documenten op uit Redis
  * de hash van de "projectstatus" wordt ook in Redis opgeslagen
  * **web** stuurt de hash van de bestandstree naar `document-updater` en `document-updater` kan de incrementele compile omzetten in een volledige compile bij mismatch
    * zie compileerproces zoals uitgevoerd wanneer de editor "full" compile had aangevraagd
* **web** -> **clsi**: compileerverzoek wordt gestuurd naar `clsi`, inclusief:
  * de synchronisatiemodus
  * een hash van de bestandstree -> de "projectstatus"
  * alle documenten uit Redis met hun inhoud -> onderhevig aan een limiet van 7 MB voor de aanvraagbody
  * geen binaire bestanden
* **clsi**: controle op schijfstatus met synchronisatiemodus en "projectstatus"
  * dit is een incrementele synchronisatie, dus de "projectstatus" moet overeenkomen
  * bij mismatch: antwoord met 409, laat web opnieuw proberen met "full" synchronisatie
    * zie compileerproces zoals uitgevoerd wanneer de editor "full" compile had aangevraagd
* **clsi**: schrijf bijgewerkte documenten naar de compileermap
* **clsi**: zorg dat de Docker-container bestaat met de gewenste configuratie
  * bouw containeropties, inclusief texlive-versie
  * opties hashen
  * containernaam: `project-<project-id>-<user-id>-<hash>`
* **clsi**: start de container en stream stdout/stderr naar het geheugen -> limiet 2 MB
* **clsi**: laat de gestopte container achter -> wordt na 24 uur opgeruimd
* **clsi**: schrijf stdout/stderr naar schijf
* **clsi**: kopieer uitvoerbestanden naar een unieke uitvoermap
  * build-id samengesteld uit 8 willekeurige bytes plus tijdstempel met precisie in ms
  * verwijder alle buildmappen behalve de laatste 3 (anoniem) / laatste 1 (ingelogde gebruiker)
* **clsi**: compileer was mislukt/time-out
  * verwijder compileercache — deze kan gedeeltelijke bestanden/corrupte cache bevatten
* **editor**: downloadt output.log en output.pdf

**Compile — schakelen tussen modi**

* **editor**: constateert een compileerfout, de volgende compile is een "full" compile
* **editor**: constateert een succesvolle compile, de volgende compile is een "incremental" compile


---

# 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/nl/aan-de-slag/microservices.md?ask=<question>&goal=<endgoal>
```

`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.
