> 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/pl/pierwsze-kroki/microservices.md). # Mikroserwisy Zalecanym sposobem wdrażania i zarządzania instancjami Overleaf Server CE i Overleaf Pro jest użycie Toolkit. Toolkit upraszcza tworzenie instancji Overleaf dzięki użyciu kilku niestandardowych skryptów, które abstrahują orkiestrację wymaganych mikrousług. Wystarczy uruchomić dołączony skrypt inicjalizacyjny, podać kilka opcji konfiguracji, takich jak ścieżki trwałej pamięci masowej, a Toolkit zajmie się udostępnieniem 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ą lokalną instancję. Toolkit obsługuje całą złożoność w tle, umożliwiając uproszczone wdrożenie instancji Overleaf. {% hint style="info" %} Ze względów historycznych główny kontener Overleaf nazywa się `sharelatex`, i jest oparty na `sharelatex/sharelatex` obrazie Docker. Dzieje się tak, ponieważ 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 informacji. W pewnym momencie w przyszłości zostanie to zmienione tak, aby pasowało do schematu 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 dla mikrousług. * `/var/log/overleaf/`: logi dla każdej mikrousługi. * `/overleaf/services/`: kod różnych mikrousług. * `/var/lib/overleaf/`: punkt montowania dla 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 przygotuje 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://overleaf-pro.ayaka.space/on-premises/pl/pierwsze-kroki/pages/3e3d313bdaeec6821aa864f7240ab22fcd5049d3#the-overleaf.rc-file) pliku konfiguracji. {% 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 Sandboxed Compiles, dostępny wyłącznie w Overleaf Pro. W Server CE proces kompilacji używa prostych podprocesów — zamień elementy odwołujące się do **kontenera** na pojedynczy element **uruchom kompilację w podprocesie**. {% endhint %} Składniki / 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 * `magazyn plików` — mikrousługa obsługująca pliki binarne * `real-time` — mikrousługa używana do obsługi gniazd WebSocket * `web` — (nie do końca) mikrousługa używana do obsługi żądań API **Buforowanie Redis** * **użytkownik**: ładuje stronę edytora * **edytor**: otwiera WebSocket * **edytor**: wysyła żądanie otwarcia dokumentu przez WebSocket * **real-time** -> **document-updater**: dokument jest ładowany z MongoDB do Redis * **edytor**: wysyła aktualizację dokumentu przez WebSocket * **real-time** -> **document-updater**: dokument jest aktualizowany w Redis * **edytor**: wysyła więcej żądań kompilacji * Po upływie 5 minut od ostatniego opróżnienia (na dokument): * **document-updater**: przenosi dokument z Redis do MongoDB * **edytor**: wysyła więcej aktualizacji * co 100 aktualizacji (na dokument): * **document-updater**: przenosi 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: * **real-time** -> **document-updater**: przenosi 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 „pełny”** * **edytor**: wysyła żądanie kompilacji z ustawionym trybem synchronizacji na „pełny” * **web** -> **document-updater**: wszystkie dokumenty są przenoszone 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 wraz z treścią -> z zastrzeżeniem limitu 7 MB dla treści żądania * adresy URL plików binarnych do osobnego pobierania * **clsi**: sprawdza stan na dysku względem trybu synchronizacji i „stanu projektu” * to pełna synchronizacja, więc poprzedni stan na dysku można zignorować * **clsi**: czyści katalog kompilacji * **clsi**: zapisuje wszystkie dokumenty do katalogu kompilacji * **clsi**: zapisuje 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** -> **magazyn plików**: pobiera pliki * **clsi**: zapisuje „stan projektu” * **clsi**: upewnia się, że kontener Docker istnieje z żądaną konfiguracją * tworzy opcje kontenera, w tym wersję TeX Live * opcje skrótu * nazwa kontenera: `project---` * **clsi**: uruchamia kontener i strumieniuje stdout/stderr do pamięci -> limit 2 MB * **clsi**: pozostawia zatrzymany kontener -> usuwany po 24 h * **clsi**: zapisuje stdout/stderr na dysk * **clsi**: kopiuje pliki wyjściowe do unikalnego katalogu wyjściowego * build-id złożony z 8 losowych bajtów plus znacznika czasu z dokładnością do ms * usuwa wszystkie foldery kompilacji oprócz ostatnich 3 (anonimowy) / ostatniego 1 (zalogowany użytkownik) * **clsi**: kompilacja zakończyła się niepowodzeniem/przekroczeniem limitu czasu * usuwa pamięć podręczną kompilacji — może zawierać częściowe pliki/uszkodzoną pamięć podręczną * **edytor**: pobiera output.log i output.pdf **Kompilacja — tryb synchronizacji „przyrostowy”** * **edytor**: wysyła żądanie kompilacji z ustawionym trybem synchronizacji na „przyrostowy” * **web** -> **document-updater**: pobiera 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ę przyrostową w pełną w przypadku niezgodności * zobacz proces kompilacji wykonywany, gdy edytor zażądał kompilacji „pełnej” * **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**: sprawdza stan na dysku względem trybu synchronizacji i „stanu projektu” * to synchronizacja przyrostowa, więc „stan projektu” musi się zgadzać * w przypadku niezgodności: odpowiedz 409, pozwól web ponowić próbę z synchronizacją „pełną” * zobacz proces kompilacji wykonywany, gdy edytor zażądał kompilacji „pełnej” * **clsi**: zapisuje zaktualizowane dokumenty do katalogu kompilacji * **clsi**: upewnia się, że kontener Docker istnieje z żądaną konfiguracją * tworzy opcje kontenera, w tym wersję TeX Live * opcje skrótu * nazwa kontenera: `project---` * **clsi**: uruchamia kontener i strumieniuje stdout/stderr do pamięci -> limit 2 MB * **clsi**: pozostawia zatrzymany kontener -> usuwany po 24 h * **clsi**: zapisuje stdout/stderr na dysk * **clsi**: kopiuje pliki wyjściowe do unikalnego katalogu wyjściowego * build-id złożony z 8 losowych bajtów plus znacznika czasu z dokładnością do ms * usuwa wszystkie foldery kompilacji oprócz ostatnich 3 (anonimowy) / ostatniego 1 (zalogowany użytkownik) * **clsi**: kompilacja zakończyła się niepowodzeniem/przekroczeniem limitu czasu * usuwa 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**: wykrywa niepowodzenie kompilacji, następna kompilacja to kompilacja „pełna” * **edytor**: wykrywa powodzenie kompilacji, następna kompilacja to kompilacja „przyrostowa” --- # 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/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.