> 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/on-premises-cs/zaciname/microservices.md).

# Mikroslužby

Doporučený způsob nasazení a správy instancí Overleaf Server CE a Overleaf Pro je pomocí Toolkitu.

Toolkit zjednodušuje vytvoření vaší instance Overleaf pomocí několika vlastních skriptů, které abstrahují orchestraci požadovaných mikroslužeb. Stačí spustit přiložený inicializační skript, zadat několik konfiguračních možností, jako jsou cesty k perzistentnímu úložišti, a Toolkit se postará o zprovoznění a propojení mikroslužeb, které tvoří vaši instanci Overleaf Server CE nebo Pro.

Tím se můžete soustředit na přizpůsobení uživatelského prostředí a implementaci konkrétních funkcí, které tvoří vaši lokální instanci. Toolkit zajišťuje veškerou složitost v pozadí a umožňuje zjednodušené nasazení vaší instance Overleaf.

{% hint style="info" %}
Z historických důvodů se hlavní kontejner Overleaf nazývá `sharelatex`, a je založen na `sharelatex/sharelatex` obrazu Dockeru. Je to proto, že tato technologie je založena na kódové základně ShareLaTeX, která byla sloučena do Overleafu. Viz [tento blogový příspěvekarrow-up-right](https://www.overleaf.com/blog/518-exciting-news-sharelatex-is-joining-overleaf) pro více podrobností. V budoucnu to bude v určitém okamžiku přejmenováno tak, aby to odpovídalo pojmenovacímu schématu Overleafu.
{% endhint %}

#### Architektura

Uvnitř kontejneru Overleaf běží software jako sada mikroslužeb, spravovaných pomocí `runit`. Mezi zajímavější soubory uvnitř kontejneru patří:

* `/etc/service/`: iniciační soubory pro mikroslužby.
* `/var/log/overleaf/`: logy pro každou mikroslužbu.
* `/overleaf/services/`: kód pro různé mikroslužby.
* `/var/lib/overleaf/`: přípojný bod pro perzistentní data (odpovídá adresáři uvedenému `v` na hostiteli).

#### Kontejnery MongoDB a Redis

Overleaf závisí na dvou externích databázích: MongoDB a Redis. Ve výchozím nastavení Toolkit zřídí kontejner pro každou z těchto databází, navíc ke kontejneru Overleaf, celkem tedy tři kontejnery Dockeru.

{% hint style="info" %}
Pokud byste se raději připojili k existující instanci MongoDB nebo Redis, můžete to provést nastavením příslušných voleb v [overleaf.rc](https://overleaf-pro.ayaka.space/on-premises/on-premises-cs/zaciname/pages/21ca43688c5d85b1e3c259e5f0a2d3ff07651168#the-overleaf.rc-file) konfiguračním souboru.
{% endhint %}

#### Editor a proces kompilace

Tato sekce poskytuje široký přehled o zpracování dokumentů a procesu kompilace.

{% hint style="info" %}
Tato stránka popisuje proces kompilace s Sandboxed Compiles, jak je k dispozici pouze v Overleaf Pro. V Server CE proces kompilace používá jednoduché podprocesy — nahraďte položky odkazující na **kontejneru** s jednou položkou **spustit kompilaci v podprocesu**.
{% endhint %}

Komponenty / aktéři:

* `uživatel` — Uživatel aplikace
* `editor` — Klientská aplikace běžící v prohlížeči
* `clsi` — Mikroslužba používaná pro kompilaci PDF
* `document-updater` — Mikroslužba používaná pro zpracování aktualizací dokumentů
* `filestore` — Mikroslužba zpracovávající binární soubory
* `real-time` — Mikroslužba používaná pro zpracování webových socketů
* `web` — (ne tak) mikroslužba používaná pro zpracování požadavků API

**Ukládání do mezipaměti Redis**

* **uživatel**: načte stránku editoru
* **editor**: otevře webový socket
* **editor**: odešle požadavek na otevření dokumentu prostřednictvím webového socketu
  * **real-time** -> **document-updater**: dokument se načte z MongoDB do Redisu
* **editor**: odešle aktualizaci dokumentu prostřednictvím webového socketu
  * **real-time** -> **document-updater**: dokument se aktualizuje v Redisu
* **editor**: odešle další požadavky na kompilaci
  * Po uplynutí 5 minut od posledního vyprázdnění (na dokument):
    * **document-updater**: vyprázdní dokument z Redisu do MongoDB
* **editor**: odešle další aktualizace
  * každých 100 aktualizací (na dokument):
    * **document-updater**: vyprázdní historii dokumentu z Redisu do MongoDB
* **uživatel**: opustí editor / zavře kartu prohlížeče
  * O 5 minut později
    * **real-time**: zkontroluje další spolupracovníky, pokud žádní nejsou:
      * **real-time** -> **document-updater**: vyprázdní dokumenty z Redisu do MongoDB

**Čtení z MongoDB do Redisu**

* **document-updater** -> **web** -> **docstore**: přečte z MongoDB

**Vyprázdnění z Redisu do MongoDB**

* **document-updater** -> **web** -> **docstore**: zapíše do MongoDB

**Kompilace — režim synchronizace „full“**

* **editor**: odešle požadavek na kompilaci s režimem synchronizace nastaveným na „full“
* **web** -> **document-updater**: všechny dokumenty jsou vyprázdněny z Redisu do MongoDB
* **web** -> **docstore**: všechny dokumenty jsou staženy z MongoDB
* **web** -> **clsi**: požadavek na kompilaci je odeslán do `clsi`, včetně:
  * režimu synchronizace
  * hashe stromu souborů -> „stav projektu“
  * všechny dokumenty s jejich obsahem -> podléhá limitu 7 MB na tělo požadavku
  * URL binárních souborů pro samostatné stahování
* **clsi**: zkontroluje stav na disku pomocí režimu synchronizace a „stavu projektu“
  * toto je plná synchronizace, takže předchozí stav na disku lze ignorovat
* **clsi**: vyčistí adresář kompilace
* **clsi**: zapíše všechny dokumenty do adresáře kompilace
* **clsi**: zapíše všechny binární soubory do adresáře kompilace
  * `clsi` kopíruje soubory z lokální mezipaměti pro daný projekt
  * při chybě v mezipaměti:
    * **clsi** -> **filestore**: stáhne soubory
* **clsi**: zapíše „stav projektu“
* **clsi**: zajistí, že kontejner Dockeru existuje s požadovanou konfigurací
  * sestaví volby kontejneru, včetně verze texlive
  * hash volby
  * název kontejneru: `project-<project-id>-<user-id>-<hash>`
* **clsi**: spustí kontejner a streamuje stdout/stderr do paměti -> limit 2 MB
* **clsi**: ponechá zastavený kontejner stranou -> vyčištěn po 24 h
* **clsi**: zapíše stdout/stderr na disk
* **clsi**: zkopíruje výstupní soubory do jedinečného výstupního adresáře
  * build-id složené z 8 náhodných bajtů plus časového razítka s přesností na milisekundy
  * smaže všechny kromě posledních 3 (anonymní) / posledního 1 (přihlášený uživatel) adresářů sestavení
* **clsi**: kompilace selhala / vypršel časový limit
  * smaže mezipaměť kompilace — může obsahovat částečné soubory / poškozenou mezipaměť
* **editor**: stáhne output.log a output.pdf

**Kompilace — režim synchronizace „incremental“**

* **editor**: odešle požadavek na kompilaci s režimem synchronizace nastaveným na „incremental“
* **web** -> **document-updater**: získá jakékoli dokumenty z Redisu
  * hash „stavu projektu“ je také uložen v Redisu
  * **web** odešle hash stromu souborů do `document-updater` a `document-updater` může při neshodě změnit inkrementální kompilaci na plnou kompilaci
    * viz proces kompilace tak, jak probíhá, když editor požádal o „full“ kompilaci
* **web** -> **clsi**: požadavek na kompilaci je odeslán do `clsi`, včetně:
  * režimu synchronizace
  * hashe stromu souborů -> „stav projektu“
  * všechny dokumenty z Redisu s jejich obsahem -> podléhá limitu 7 MB na tělo požadavku
  * žádné binární soubory
* **clsi**: zkontroluje stav na disku pomocí režimu synchronizace a „stavu projektu“
  * toto je inkrementální synchronizace, takže „stav projektu“ musí souhlasit
  * při neshodě: odpovědět 409, nechat web zopakovat s „full“ synchronizací
    * viz proces kompilace tak, jak probíhá, když editor požádal o „full“ kompilaci
* **clsi**: zapíše aktualizované dokumenty do adresáře kompilace
* **clsi**: zajistí, že kontejner Dockeru existuje s požadovanou konfigurací
  * sestaví volby kontejneru, včetně verze texlive
  * hash volby
  * název kontejneru: `project-<project-id>-<user-id>-<hash>`
* **clsi**: spustí kontejner a streamuje stdout/stderr do paměti -> limit 2 MB
* **clsi**: ponechá zastavený kontejner stranou -> vyčištěn po 24 h
* **clsi**: zapíše stdout/stderr na disk
* **clsi**: zkopíruje výstupní soubory do jedinečného výstupního adresáře
  * build-id složené z 8 náhodných bajtů plus časového razítka s přesností na milisekundy
  * smaže všechny kromě posledních 3 (anonymní) / posledního 1 (přihlášený uživatel) adresářů sestavení
* **clsi**: kompilace selhala / vypršel časový limit
  * smaže mezipaměť kompilace — může obsahovat částečné soubory / poškozenou mezipaměť
* **editor**: stáhne output.log a output.pdf

**Kompilace — přepínání mezi režimy**

* **editor**: zaznamená selhání kompilace, další kompilace je „full“ kompilace
* **editor**: zaznamená úspěch kompilace, další kompilace je „incremental“ kompilace


---

# 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/on-premises-cs/zaciname/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.
