> 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/pl/pierwsze-kroki/microservices.md). # Mikrousługi Zalecanym sposobem wdrażania i zarządzania instancjami Overleaf Server CE i Overleaf Pro jest korzystanie z Toolkit. Toolkit upraszcza tworzenie instancji Overleaf dzięki użyciu kilku niestandardowych skryptów, które abstrahują od orkiestracji wymaganych mikrousług. Wystarczy uruchomić dołączony skrypt inicjalizacyjny, podać kilka opcji konfiguracji, takich jak ścieżki do trwałej pamięci masowej, a Toolkit zajmie się przygotowaniem i połączeniem mikrousług tworzących Twoją instancję Overleaf Server CE lub Pro. Dzięki temu możesz skupić się na dostosowywaniu doświadczenia użytkownika i wdrażaniu konkretnych funkcji, które składają się na Twoją instancję lokalną. Toolkit obsługuje całą złożoność w tle, umożliwiając uproszczone wdrożenie instancji Overleaf. {% hint style="info" %} Z przyczyn historycznych główny kontener Overleaf nazywa się `sharelatex`, i jest oparty na `sharelatex/sharelatex` obrazie Dockera. Wynika to z tego, że technologia opiera się na bazie kodu ShareLaTeX, która została scalona z Overleaf. Zobacz [ten wpis na bloguarrow-up-right](https://www.overleaf.com/blog/518-exciting-news-sharelatex-is-joining-overleaf) aby uzyskać więcej szczegółów. W przyszłości zostanie to przemianowane tak, aby odpowiadało schematowi nazewnictwa Overleaf. {% endhint %} #### Architektura Wewnątrz kontenera Overleaf oprogramowanie działa jako zestaw mikrousług zarządzanych przez `runit`. Niektóre z ciekawszych plików wewnątrz kontenera to: * `/etc/service/`: pliki inicjalizacyjne mikrousług. * `/var/log/overleaf/`: logi każdej mikrousługi. * `/overleaf/services/`: kod dla poszczególnych mikrousług. * `/var/lib/overleaf/`: punkt montowania trwałych danych (odpowiada katalogowi wskazanemu przez `OVERLEAF_DATA_PATH` na hoście). #### Kontenery MongoDB i Redis Overleaf zależy od dwóch zewnętrznych baz danych: MongoDB i Redis. Domyślnie Toolkit utworzy kontener dla każdej z tych baz danych, oprócz kontenera Overleaf, co daje łącznie trzy kontenery Docker. {% hint style="info" %} Jeśli wolisz połączyć się z istniejącą instancją MongoDB lub Redis, możesz to zrobić, ustawiając odpowiednie opcje w [overleaf.rc](https://ayakaleaf-pro.ayaka.space/on-premises/pl/pierwsze-kroki/pages/3e3d313bdaeec6821aa864f7240ab22fcd5049d3#the-overleaf.rc-file) pliku konfiguracyjnym. {% endhint %} #### Edytor i proces kompilacji Ta sekcja przedstawia ogólny przegląd obsługi dokumentów i procesu kompilacji. {% hint style="info" %} Ta strona opisuje proces kompilacji z użyciem Sandboxed Compiles, dostępny wyłącznie w Overleaf Pro. W Server CE proces kompilacji używa prostych podprocesów — zamień elementy odnoszące się do a **kontenera** na jeden element **uruchom kompilację w podprocesie**. {% endhint %} Komponenty / Aktorzy: * `użytkownik` — Użytkownik aplikacji * `edytor` — Aplikacja kliencka działająca w przeglądarce * `clsi` — Mikrousługa używana do kompilowania plików PDF * `document-updater` — Mikrousługa używana do przetwarzania aktualizacji dokumentów * `filestore` — Mikrousługa obsługująca pliki binarne * `real-time` — Mikrousługa używana do obsługi gniazd WebSocket * `web` — (nie tak) mikrousługa używana do obsługi żądań API **Buforowanie Redis** * **użytkownik**: ładuje stronę edytora * **edytor**: otwiera gniazdo WebSocket * **edytor**: wysyła żądanie otwarcia dokumentu przez gniazdo WebSocket * **real-time** -> **document-updater**: dokument jest wczytywany z MongoDB do Redis * **edytor**: wysyła aktualizację dokumentu przez gniazdo WebSocket * **real-time** -> **document-updater**: dokument jest aktualizowany w Redis * **edytor**: wysyła kolejne żądania kompilacji * Po upływie 5 minut od ostatniego opróżnienia (dla każdego dokumentu): * **document-updater**: opróżnij dokument z Redis do MongoDB * **edytor**: wysyła kolejne aktualizacje * co 100 aktualizacji (dla każdego dokumentu): * **document-updater**: opróżnij historię dokumentu z Redis do MongoDB * **użytkownik**: opuszcza edytor/zamyka kartę przeglądarki * 5 minut później * **real-time**: sprawdza, czy są inni współpracownicy; jeśli nie ma żadnych: * **real-time** -> **document-updater**: opróżnia dokumenty z Redis do MongoDB **Odczyt z MongoDB do Redis** * **document-updater** -> **web** -> **docstore**: odczyt z MongoDB **Opróżnianie z Redis do MongoDB** * **document-updater** -> **web** -> **docstore**: zapis do MongoDB **Kompilacja — tryb synchronizacji „full”** * **edytor**: wysyła żądanie kompilacji z trybem synchronizacji ustawionym na „full” * **web** -> **document-updater**: wszelkie dokumenty są opróżniane z Redis do MongoDB * **web** -> **docstore**: wszystkie dokumenty są pobierane z MongoDB * **web** -> **clsi**: żądanie kompilacji jest wysyłane do `clsi`, w tym: * tryb synchronizacji * skrót drzewa plików -> „stan projektu” * wszystkie dokumenty z ich treścią -> z zastrzeżeniem limitu 7 MB dla treści żądania * adresy URL plików binarnych do osobnego pobierania * **clsi**: sprawdź stan na dysku względem trybu synchronizacji i „stanu projektu” * to pełna synchronizacja, więc poprzedni stan na dysku można zignorować * **clsi**: wyczyść katalog kompilacji * **clsi**: zapisz wszystkie dokumenty do katalogu kompilacji * **clsi**: zapisz wszystkie pliki binarne do katalogu kompilacji * `clsi` kopiuje pliki z lokalnej pamięci podręcznej dla danego projektu * w przypadku braku w pamięci podręcznej: * **clsi** -> **filestore**: pobierz pliki * **clsi**: zapisz „stan projektu” * **clsi**: upewnij się, że kontener Docker istnieje z żądaną konfiguracją * utwórz opcje kontenera, w tym wersję texlive * opcje skrótu * nazwa kontenera: `project---` * **clsi**: uruchom kontener i strumieniuj stdout/stderr do pamięci -> limit 2 MB * **clsi**: pozostaw zatrzymany kontener -> zostanie uprzątnięty po 24 h * **clsi**: zapisz stdout/stderr na dysku * **clsi**: skopiuj pliki wyjściowe do unikalnego katalogu wyjściowego * build-id składa się z 8 losowych bajtów plus znacznika czasu z dokładnością do ms * usuń wszystkie foldery kompilacji oprócz ostatnich 3 (anonimowych) / ostatniego 1 (zalogowanego użytkownika) * **clsi**: kompilacja zakończyła się niepowodzeniem/przekroczeniem czasu * usuń pamięć podręczną kompilacji — może zawierać częściowe pliki/uszkodzoną pamięć podręczną * **edytor**: pobiera output.log i output.pdf **Kompilacja — tryb synchronizacji „incremental”** * **edytor**: wysyła żądanie kompilacji z trybem synchronizacji ustawionym na „incremental” * **web** -> **document-updater**: pobierz dowolne dokumenty z Redis * skrót „stanu projektu” jest również przechowywany w Redis * **web** wysyła skrót drzewa plików do `document-updater` i `document-updater` może zamienić kompilację inkrementalną na pełną w przypadku niezgodności * zobacz proces kompilacji wykonywany, gdy edytor zażądał kompilacji „full” * **web** -> **clsi**: żądanie kompilacji jest wysyłane do `clsi`, w tym: * tryb synchronizacji * skrót drzewa plików -> „stan projektu” * wszystkie dokumenty z Redis wraz z treścią -> z zastrzeżeniem limitu 7 MB dla treści żądania * bez plików binarnych * **clsi**: sprawdź stan na dysku względem trybu synchronizacji i „stanu projektu” * to synchronizacja inkrementalna, więc „stan projektu” musi się zgadzać * w przypadku niezgodności: odpowiedz 409, pozwól sieci spróbować ponownie z synchronizacją „full” * zobacz proces kompilacji wykonywany, gdy edytor zażądał kompilacji „full” * **clsi**: zapisz zaktualizowane dokumenty do katalogu kompilacji * **clsi**: upewnij się, że kontener Docker istnieje z żądaną konfiguracją * utwórz opcje kontenera, w tym wersję texlive * opcje skrótu * nazwa kontenera: `project---` * **clsi**: uruchom kontener i strumieniuj stdout/stderr do pamięci -> limit 2 MB * **clsi**: pozostaw zatrzymany kontener -> zostanie uprzątnięty po 24 h * **clsi**: zapisz stdout/stderr na dysku * **clsi**: skopiuj pliki wyjściowe do unikalnego katalogu wyjściowego * build-id składa się z 8 losowych bajtów plus znacznika czasu z dokładnością do ms * usuń wszystkie foldery kompilacji oprócz ostatnich 3 (anonimowych) / ostatniego 1 (zalogowanego użytkownika) * **clsi**: kompilacja zakończyła się niepowodzeniem/przekroczeniem czasu * usuń pamięć podręczną kompilacji — może zawierać częściowe pliki/uszkodzoną pamięć podręczną * **edytor**: pobiera output.log i output.pdf **Kompilacja — przełączanie między trybami** * **edytor**: obserwuje nieudaną kompilację, następna kompilacja jest kompilacją „full” * **edytor**: obserwuje pomyślną kompilację, następna kompilacja jest kompilacją „incremental” --- # 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/pl/pierwsze-kroki/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.