> 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/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://overleaf-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 **Компіляція — режим синхронізації «повна»** * **редактор**: надсилає запит на компіляцію з режимом синхронізації, встановленим на «повна» * **web** -> **document-updater**: будь-які документи скидаються з Redis до MongoDB * **web** -> **docstore**: усі документи завантажуються з MongoDB * **web** -> **clsi**: запит на компіляцію надсилається до `clsi`, зокрема: * режим синхронізації * хеш дерева файлів -> «стан проєкту» * усі документи з їхнім вмістом -> підлягає обмеженню тіла запиту в 7 МБ * URL-адреси бінарних файлів для окремого завантаження * **clsi**: перевірка стану на диску за режимом синхронізації та «станом проєкту» * це повна синхронізація, тож попередній стан на диску можна ігнорувати * **clsi**: очищає каталог компіляції * **clsi**: записує всі документи до каталогу компіляції * **clsi**: записує всі бінарні файли до каталогу компіляції * `clsi` копіює файли з локального кешу для кожного проєкту * у разі промаху кешу: * **clsi** -> **filestore**: завантажує файли * **clsi**: записує «стан проєкту» * **clsi**: переконується, що контейнер Docker існує з бажаною конфігурацією * параметри контейнера збірки, включно з версією texlive * параметри хешування * назва контейнера: `project---` * **clsi**: запускає контейнер і передає stdout/stderr у пам'ять -> обмеження 2 МБ * **clsi**: залишає зупинений контейнер -> очищається через 24 год * **clsi**: записує stdout/stderr на диск * **clsi**: копіює вихідні файли до унікального каталогу вихідних даних * build-id, складений з 8 випадкових байтів плюс мітка часу з точністю до мс * видаляє всі папки збірок, крім останніх 3 (анонімний користувач) / останньої 1 (авторизований користувач) * **clsi**: компіляція завершилася помилкою/тайм-аутом * видаляє кеш компіляції — у ньому можуть бути неповні файли/пошкоджений кеш * **редактор**: завантажує output.log і output.pdf **Компіляція — режим синхронізації «інкрементальна»** * **редактор**: надсилає запит на компіляцію з режимом синхронізації, встановленим на «інкрементальна» * **web** -> **document-updater**: отримує будь-які документи з Redis * «стан проєкту» також зберігається в Redis * **web** надсилає хеш дерева файлів до `document-updater` та `document-updater` може перетворити інкрементальну компіляцію на повну у разі невідповідності * див. процес компіляції, як він виконується, коли редактор запитує «повну» компіляцію * **web** -> **clsi**: запит на компіляцію надсилається до `clsi`, зокрема: * режим синхронізації * хеш дерева файлів -> «стан проєкту» * усі документи з Redis разом із їхнім вмістом -> підлягає обмеженню тіла запиту в 7 МБ * без бінарних файлів * **clsi**: перевірка стану на диску за режимом синхронізації та «станом проєкту» * це інкрементальна синхронізація, тож «стан проєкту» має збігатися * у разі невідповідності: відповідає 409, дає вебу повторити з «повною» синхронізацією * див. процес компіляції, як він виконується, коли редактор запитує «повну» компіляцію * **clsi**: записує оновлені документи до каталогу компіляції * **clsi**: переконується, що контейнер Docker існує з бажаною конфігурацією * параметри контейнера збірки, включно з версією texlive * параметри хешування * назва контейнера: `project---` * **clsi**: запускає контейнер і передає stdout/stderr у пам'ять -> обмеження 2 МБ * **clsi**: залишає зупинений контейнер -> очищається через 24 год * **clsi**: записує stdout/stderr на диск * **clsi**: копіює вихідні файли до унікального каталогу вихідних даних * build-id, складений з 8 випадкових байтів плюс мітка часу з точністю до мс * видаляє всі папки збірок, крім останніх 3 (анонімний користувач) / останньої 1 (авторизований користувач) * **clsi**: компіляція завершилася помилкою/тайм-аутом * видаляє кеш компіляції — у ньому можуть бути неповні файли/пошкоджений кеш * **редактор**: завантажує output.log і output.pdf **Компіляція — перемикання між режимами** * **редактор**: виявляє невдалу компіляцію, наступна компіляція є «повною» * **редактор**: виявляє успішну компіляцію, наступна компіляція є «інкрементальною» --- # 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/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.