> 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/uk/pochatok-roboti/microservices.md). # Мікросервіси Рекомендований спосіб розгортання й керування екземплярами Overleaf Server CE та Overleaf Pro — це використання Toolkit. Toolkit спрощує створення вашого екземпляра Overleaf завдяки використанню спеціальних сценаріїв, які абстрагують оркестрацію необхідних мікросервісів. Просто запустіть включений сценарій ініціалізації, вкажіть кілька параметрів конфігурації, як-от шляхи до постійного сховища, і Toolkit подбає про підготовку та підключення мікросервісів, з яких складається ваш екземпляр Overleaf Server CE або Pro. Це дає вам змогу зосередитися на налаштуванні користувацького досвіду та впровадженні конкретних функцій, з яких складається ваш локальний екземпляр. Toolkit обробляє всю складність за лаштунками, забезпечуючи спрощене розгортання вашого екземпляра Overleaf. {% hint style="info" %} З історичних причин основний контейнер Overleaf називається `контейнера sharelatex`, і базується на `sharelatex/sharelatex` образі Docker. Це тому, що технологія базується на кодовій базі ShareLaTeX, яка була об'єднана з Overleaf. Див. [цей допис у блозіarrow-up-right](https://www.overleaf.com/blog/518-exciting-news-sharelatex-is-joining-overleaf) для отримання додаткових відомостей. У майбутньому це буде перейменовано, щоб відповідати схемі найменування Overleaf. {% endhint %} #### Архітектура Усередині контейнера Overleaf програмне забезпечення працює як набір мікросервісів, якими керує `runit`. Деякі з найцікавіших файлів усередині контейнера такі: * `/etc/service/`: файли ініціалізації мікросервісів. * `/var/log/overleaf/`: журнали кожного мікросервісу. * `/overleaf/services/`: код різних мікросервісів. * `/var/lib/overleaf/`: точка монтування для постійних даних (відповідає каталогу, зазначеному `OVERLEAF_DATA_PATH` на хості). #### Контейнери MongoDB та Redis Overleaf залежить від двох зовнішніх баз даних: MongoDB і Redis. За замовчуванням Toolkit створить по контейнеру для кожної з цих баз даних, на додаток до контейнера Overleaf, усього три контейнери Docker. {% hint style="info" %} Якщо ви віддаєте перевагу підключенню до наявного екземпляра MongoDB або Redis, це можна зробити, встановивши відповідні параметри у [overleaf.rc](https://ayakaleaf-pro.ayaka.space/on-premises/uk/pochatok-roboti/pages/66f7b06d13e882f3d6090b14708d3bcbc6615bbc#the-overleaf.rc-file) файлі конфігурації. {% endhint %} #### Редактор і процес компіляції Цей розділ дає загальний огляд обробки документів і процесу компіляції. {% hint style="info" %} На цій сторінці описано процес компіляції із Sandboxed Compiles, який доступний лише в Overleaf Pro. У Server CE процес компіляції використовує прості підпроцеси — замініть елементи, що посилаються на **контейнера** на один елемент **запустити компіляцію в підпроцесі**. {% endhint %} Компоненти / Актори: * `користувач` — Користувач застосунку * `редактор` — Клієнтський застосунок, що працює в браузері * `clsi` — Мікросервіс, який використовується для компіляції PDF * `document-updater` — Мікросервіс, який використовується для обробки оновлень документа * `filestore` — Мікросервіс для обробки бінарних файлів * `real-time` — Мікросервіс, який використовується для обробки вебсокетів * `web` — (не такий уже й) мікросервіс, який використовується для обробки API-запитів **Кешування Redis** * **користувач**: завантажує сторінку редактора * **редактор**: відкриває вебсокет * **редактор**: надсилає запит на відкриття документа через вебсокет * **real-time** -> **document-updater**: документ завантажується з MongoDB до Redis * **редактор**: надсилає оновлення документа через вебсокет * **real-time** -> **document-updater**: документ оновлюється в Redis * **редактор**: надсилає додаткові запити на компіляцію * Після того як минуло 5 хвилин від останнього скидання (для кожного документа): * **document-updater**: скидає документ з Redis до MongoDB * **редактор**: надсилає додаткові оновлення * кожні 100 оновлень (для кожного документа): * **document-updater**: скидає історію документа з Redis до MongoDB * **користувач**: залишає редактор / закриває вкладку браузера * Через 5 хвилин * **real-time**: перевіряє наявність інших співавторів, якщо їх немає: * **real-time** -> **document-updater**: скидає документи з Redis до MongoDB **Читання з MongoDB до Redis** * **document-updater** -> **web** -> **docstore**: читання з MongoDB **Скидання з Redis до MongoDB** * **document-updater** -> **web** -> **docstore**: запис у MongoDB **Компіляція — режим синхронізації «full»** * **редактор**: надсилає запит на компіляцію з режимом синхронізації, встановленим на «full» * **web** -> **document-updater**: будь-які документи скидаються з Redis до MongoDB * **web** -> **docstore**: усі документи завантажуються з MongoDB * **web** -> **clsi**: запит на компіляцію надсилається до `clsi`, включно з: * режимом синхронізації * хешем дерева файлів -> «станом проєкту» * усі документи з їхнім вмістом -> з урахуванням обмеження 7 МБ для тіла запиту * URL-адресами бінарних файлів для окремого завантаження * **clsi**: перевіряє стан на диску за допомогою режиму синхронізації та «стану проєкту» * це повна синхронізація, тому попередній стан на диску можна ігнорувати * **clsi**: очищає каталог компіляції * **clsi**: записує всі документи до каталогу компіляції * **clsi**: записує всі бінарні файли до каталогу компіляції * `clsi` копіює файли з локального кешу для кожного проєкту * у разі промаху кешу: * **clsi** -> **filestore**: завантажує файли * **clsi**: записує «стан проєкту» * **clsi**: переконується, що контейнер Docker існує з бажаною конфігурацією * формує параметри контейнера, включно з версією TeX Live * хешує параметри * назва контейнера: `project---` * **clsi**: запускає контейнер і передає stdout/stderr у пам’ять -> обмеження 2 МБ * **clsi**: залишає зупинений контейнер -> очищається через 24 години * **clsi**: записує stdout/stderr на диск * **clsi**: копіює вихідні файли до унікального каталогу виводу * build-id складається з 8 випадкових байтів плюс мітки часу з точністю до мілісекунд * видаляє всі папки збірок, крім останніх 3 (анонімний користувач) / останньої 1 (авторизований користувач) * **clsi**: компіляція завершилася помилкою / тайм-аутом * видаляє кеш компіляції — у ньому можуть бути часткові файли / пошкоджений кеш * **редактор**: завантажує output.log і output.pdf **Компіляція — режим синхронізації «incremental»** * **редактор**: надсилає запит на компіляцію з режимом синхронізації, встановленим на «incremental» * **web** -> **document-updater**: отримує будь-які документи з Redis * хеш «стану проєкту» також зберігається в Redis * **web** надсилає хеш дерева файлів до `document-updater` та `document-updater` може перетворити інкрементальну компіляцію на повну компіляцію в разі невідповідності * див. процес компіляції, як він виконується, коли редактор запитав «full» компіляцію * **web** -> **clsi**: запит на компіляцію надсилається до `clsi`, включно з: * режимом синхронізації * хешем дерева файлів -> «станом проєкту» * усі документи з Redis із їхнім вмістом -> з урахуванням обмеження 7 МБ для тіла запиту * без бінарних файлів * **clsi**: перевіряє стан на диску за допомогою режиму синхронізації та «стану проєкту» * це інкрементальна синхронізація, тому «стан проєкту» має збігатися * у разі невідповідності: відповісти 409, дозволити вебу повторити спробу з «full» синхронізацією * див. процес компіляції, як він виконується, коли редактор запитав «full» компіляцію * **clsi**: записує оновлені документи до каталогу компіляції * **clsi**: переконується, що контейнер Docker існує з бажаною конфігурацією * формує параметри контейнера, включно з версією TeX Live * хешує параметри * назва контейнера: `project---` * **clsi**: запускає контейнер і передає stdout/stderr у пам’ять -> обмеження 2 МБ * **clsi**: залишає зупинений контейнер -> очищається через 24 години * **clsi**: записує stdout/stderr на диск * **clsi**: копіює вихідні файли до унікального каталогу виводу * build-id складається з 8 випадкових байтів плюс мітки часу з точністю до мілісекунд * видаляє всі папки збірок, крім останніх 3 (анонімний користувач) / останньої 1 (авторизований користувач) * **clsi**: компіляція завершилася помилкою / тайм-аутом * видаляє кеш компіляції — у ньому можуть бути часткові файли / пошкоджений кеш * **редактор**: завантажує output.log і output.pdf **Компіляція — перемикання між режимами** * **редактор**: виявляє збій компіляції, наступна компіляція — «full» компіляція * **редактор**: виявляє успішну компіляцію, наступна компіляція — «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/uk/pochatok-roboti/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.