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

# Microservices

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

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

Hierdoor kun je je richten op het aanpassen van de gebruikerservaring en het implementeren van de specifieke functies waaruit je on-premise instantie bestaat. De Toolkit handelt alle complexiteit achter de schermen af, waardoor de implementatie van je 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 gebaseerd is op de ShareLaTeX-codebase, die in Overleaf is samengevoegd. 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 krijgt dit een nieuwe naam om overeen te komen 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 koppelpunt voor persistente gegevens (komt overeen met de map die wordt aangeduid 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, in totaal drie Docker-containers.

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

#### Editor- en compileproces

Deze sectie geeft een algemeen overzicht van de afhandeling van documenten en het compileproces.

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

Componenten / 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 verwerkt
* `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-verzoeken

**Redis-caching**

* **gebruiker**: laadt de editorpagina
* **editor**: opent een 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 bijgewerkt in Redis
* **editor**: stuurt meer compileverzoeken
  * Nadat er 5 minuten zijn verstreken sinds de laatste flush (per document):
    * **document-updater**: schrijft document van Redis naar MongoDB
* **editor**: stuurt meer updates
  * elke 100 updates (per document):
    * **document-updater**: schrijft documentgeschiedenis van Redis naar MongoDB
* **gebruiker**: verlaat de editor/sluit browsertabblad
  * 5 minuten later
    * **real-time**: controleert op andere samenwerkers, en als er geen zijn:
      * **real-time** -> **document-updater**: schrijft documenten van Redis naar MongoDB

**Lezen van MongoDB naar Redis**

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

**Flushen van Redis naar MongoDB**

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

**Compileren — synchronisatiemodus "full"**

* **editor**: stuurt compileverzoek met sync-modus ingesteld op "full"
* **web** -> **document-updater**: eventuele documenten worden van Redis naar MongoDB geschreven
* **web** -> **docstore**: alle documenten worden gedownload uit MongoDB
* **web** -> **clsi**: compileverzoek wordt verzonden naar `clsi`, waaronder:
  * de sync-modus
  * een hash van de bestandstructuur -> de "projectstatus"
  * alle documenten met hun inhoud -> onderhevig aan een limiet van 7 MB voor de request body
  * URL's van binaire bestanden voor afzonderlijk downloaden
* **clsi**: controleer de schijfstatus met sync-modus en "projectstatus"
  * dit is een volledige synchronisatie, dus de vorige schijfstatus kan worden genegeerd
* **clsi**: opschonen van de compilemap
* **clsi**: schrijf alle documenten in de compilemap
* **clsi**: schrijf alle binaire bestanden in de compilemap
  * `clsi` kopieert de bestanden uit een lokale cache per project
  * bij een cachemiss:
    * **clsi** -> **filestore**: bestanden downloaden
* **clsi**: schrijf de "projectstatus"
* **clsi**: zorg dat de Docker-container bestaat met de gewenste configuratie
  * bouw containeropties op, inclusief Tex Live-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 bestaat uit 8 willekeurige bytes plus een timestamp met ms-precisie
  * verwijder alle buildmappen behalve de laatste 3 (anonieme) / laatste 1 (ingelogde gebruiker)
* **clsi**: compilatie mislukte/timede out
  * verwijder de compilecache — die kan gedeeltelijke bestanden/corruptie bevatten
* **editor**: downloadt output.log en output.pdf

**Compileren — synchronisatiemodus "incremental"**

* **editor**: stuurt compileverzoek met sync-modus ingesteld op "incremental"
* **web** -> **document-updater**: haal eventuele documenten uit Redis
  * de hash van de "projectstatus" wordt ook opgeslagen in Redis
  * **web** stuurt de hash van de bestandstructuur naar `document-updater` en `document-updater` kan de incrementele compilatie bij een mismatch omzetten in een volledige compilatie
    * zie het compileproces zoals uitgevoerd wanneer de editor een "full"-compile aanvroeg
* **web** -> **clsi**: compileverzoek wordt verzonden naar `clsi`, waaronder:
  * de sync-modus
  * een hash van de bestandstructuur -> de "projectstatus"
  * alle documenten uit Redis met hun inhoud -> onderhevig aan een limiet van 7 MB voor de request body
  * geen binaire bestanden
* **clsi**: controleer de schijfstatus met sync-modus en "projectstatus"
  * dit is een incrementele synchronisatie, dus de "projectstatus" moet overeenkomen
  * bij mismatch: reageer met 409, laat de webclient opnieuw proberen met "full"-synchronisatie
    * zie het compileproces zoals uitgevoerd wanneer de editor een "full"-compile aanvroeg
* **clsi**: schrijf bijgewerkte documenten in de compilemap
* **clsi**: zorg dat de Docker-container bestaat met de gewenste configuratie
  * bouw containeropties op, inclusief Tex Live-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 bestaat uit 8 willekeurige bytes plus een timestamp met ms-precisie
  * verwijder alle buildmappen behalve de laatste 3 (anonieme) / laatste 1 (ingelogde gebruiker)
* **clsi**: compilatie mislukte/timede out
  * verwijder de compilecache — die kan gedeeltelijke bestanden/corruptie bevatten
* **editor**: downloadt output.log en output.pdf

**Compileren — schakelen tussen modi**

* **editor**: ziet een compilefout, de volgende compilatie is een "full"-compile
* **editor**: ziet een succesvolle compilatie, de volgende compilatie 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://ayakaleaf-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.
