> 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/konfiguraciya/overleaf-toolkit/izolovanikh-kompilyacii.md). # Ізольованих компіляцій Overleaf Pro має можливість запускати компіляції в захищеному пісочному середовищі для корпоративної безпеки. Це робиться шляхом запуску кожного проєкту у власному захищеному середовищі Docker. ### Підвищена безпека Ізольовані компіляції є рекомендованим підходом для Server Pro, оскільки багато документів LaTeX потребують/мають можливість виконувати довільні команди shell як частину процесу компіляції PDF. Якщо ви використовуєте ізольовані компіляції, кожна компіляція виконується в окремому контейнері Docker з обмеженими можливостями, які не спільні з жодним іншим користувачем чи проєктом, і не має доступу до зовнішніх ресурсів, таких як мережа хоста. {% hint style="warning" %} Якщо ви спробуєте запустити Overleaf Pro **без** ізольованих компіляцій, компіляція виконуватиметься поряд з іншими одночасними компіляціями всередині основного контейнера Docker, і користувачі матимуть повний доступ на читання та запис до `sharelatex` ресурсів контейнера (файлова система, мережа та змінні середовища) під час запуску компіляцій LaTeX. {% endhint %} ### Простіше керування пакетами Щоб уникнути ручного встановлення пакетів, ми рекомендуємо увімкнути ізольовані компіляції. Це налаштовуваний параметр у Server Pro, який надасть вашим користувачам доступ до того ж середовища TeX Live, що й на overleaf.com, але всередині вашої власної локальної інсталяції. Образи TeX Live, що використовуються ізольованими компіляціями, містять найпопулярніші пакети та шрифти, протестовані з нашими шаблонами галереї, що забезпечує максимальну сумісність із локальними проєктами. Увімкнення ізольованих компіляцій дає змогу налаштувати, з яких версій TeX Live користувачі можуть вибирати у своєму проєкті, а також задати версію образу TeX Live за замовчуванням для нових проєктів. {% hint style="info" %} Якщо ви спробуєте запустити Overleaf Pro без ізольованих компіляцій, ваша інсталяція за замовчуванням використовуватиме базову схему TeX Live для компіляцій. Ця базова версія є легкою і містить лише дуже обмежений набір пакетів LaTeX, що, найімовірніше, призведе до помилок про відсутні пакети у ваших користувачів, особливо якщо вони спробують використовувати готові шаблони. {% endhint %} Оскільки Overleaf Pro спроєктовано для роботи офлайн, не існує автоматизованого способу інтегрувати шаблони галереї overleaf.com у вашу локальну інсталяцію; однак це можливо зробити вручну для кожного шаблону окремо. Докладніше про те, як це працює, дивіться наш посібник з перенесення шаблонів із overleaf.com: [/pages/0da4c6a3906dd38224e377f81822ad623f327059#transferring-templates-from-overleaf.com](https://overleaf-pro.ayaka.space/on-premises/uk/konfiguraciya/overleaf-toolkit/pages/0da4c6a3906dd38224e377f81822ad623f327059#transferring-templates-from-overleaf.com "mention"). {% hint style="info" %} Ізольовані компіляції потребують, щоб `sharelatex` контейнер мав доступ до сокета Docker на машині хоста (через монтування bind) для керування цими суміжними контейнерами компіляції. {% endhint %} ## Як це працює Коли ізольовані компіляції увімкнено, сокет Docker буде змонтовано з машини хоста до `sharelatex` контейнера, щоб сервіс компілятора в контейнері міг створювати нові контейнери Docker на хості. Далі для кожного запуску компілятора в кожному проєкті сервіс компілятора LaTeX (CLSI) виконуватиме таке: * Записувати файли проєкту в розташування всередині `OVERLEAF_DATA_PATH`. * Використовувати змонтований сокет Docker для створення нового `texlive` контейнера для запуску компіляції. * Нехай `texlive` контейнер читає дані проєкту з розташування під `OVERLEAF_DATA_PATH`. * Компілювати проєкт усередині `texlive` контейнера. ### Увімкнення ізольованих компіляцій #### Для користувача Toolkit Щоб увімкнути ізольовані компіляції (також відомі як суміжні контейнери), встановіть такі параметри конфігурації в `overleaf-toolkit/config/overleaf.rc`: {% code title="config/overleaf.rc" %} ```dotenv SERVER_PRO=true SIBLING_CONTAINERS_ENABLED=true ``` {% endcode %} #### Для користувача Docker Compose {% hint style="danger" %} Починаючи з Overleaf CE/Server Pro `5.0.3` змінні середовища були перейменовані з `SHARELATEX_*` до `OVERLEAF_*`. {% endhint %} Якщо ви використовуєте `4.x` версії (або ранішої), переконайтеся, що перед змінними відповідно вказано префікс (наприклад, `SHARELATEX_MONGO_URL` замість `OVERLEAF_MONGO_URL`). 
version: '2'
services:
    sharelatex:
        #...
        volumes:
            - /data/overleaf_data:/var/lib/overleaf
            - /var/run/docker.sock:/var/run/docker.sock
        environment:
            #...
            DOCKER_RUNNER: "true"
            SANDBOXED_COMPILES: "true"
            SANDBOXED_COMPILES_HOST_DIR: "/data/overleaf_data/data/compiles"
            #...
        #...
### Зміна образу TeX Live {% hint style="info" %} Для користувачів материкового Китаю ви можете використовувати `ghcr.nju.edu.cn` щоб прискорити завантаження. {% endhint %} Overleaf Pro використовує три змінні середовища, щоб визначити, які образи TeX Live використовувати для ізольованих компіляцій: * `TEX_LIVE_DOCKER_IMAGE` **(обов'язково),** Образ TeX Live за замовчуванням, що використовується для компіляції нових проєктів. Цей образ має бути включений до `ALL_TEX_LIVE_DOCKER_IMAGES`. * `ALL_TEX_LIVE_DOCKER_IMAGE_NAMES` **(обов'язково),** Список дружніх назв образів, розділених комами, використовується для параметрів інтерфейсу. * `ALL_TEX_LIVE_DOCKER_IMAGES` **(обов'язково),** Список образів TeX Live, розділених комами, які слід використовувати. Якщо для розгортання використовується Overleaf Toolkit, ці образи будуть завантажені або оновлені. Щоб пропустити завантаження, встановіть `SIBLING_CONTAINERS_PULL=false` у `config/overleaf.rc`. Під час запуску вашого екземпляра Overleaf Pro за допомогою `bin/up` команди Toolkit автоматично підтягне всі образи, перелічені в `ALL_TEX_LIVE_DOCKER_IMAGES`. Ось приклад, де за замовчуванням для нових проєктів використовується TeX Live 2025, а для наявних проєктів залишається TeX Live 2024. {% code title="config/variables.env" overflow="wrap" %} ```dotenv ALL_TEX_LIVE_DOCKER_IMAGES=ghcr.io/ayaka-notes/texlive-full:2025.1, ghcr.io/ayaka-notes/texlive-full:2024.1 ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=Texlive 2025, Texlive 2024 TEX_LIVE_DOCKER_IMAGE=ghcr.io/ayaka-notes/texlive-full:2025.1 ``` {% endcode %} {% hint style="danger" %} Настійно рекомендується встановити **щонайменше 2 образи texlive-full**. Для докладної причини див. [#known-issues](#known-issues "mention") {% endhint %} ### Доступні образи TeX Live Це серія образів TeX Live, спеціально оптимізованих для Overleaf, їх також можна додати до `TEX_LIVE_DOCKER_IMAGE` та `ALL_TEX_LIVE_DOCKER_IMAGES`: * `ghcr.io/ayaka-notes/texlive-full:2025.1` (також `latest` тег) * `ghcr.io/ayaka-notes/texlive-full:2024.1` * `ghcr.io/ayaka-notes/texlive-full:2023.1` * `ghcr.io/ayaka-notes/texlive-full:2022.1` * `ghcr.io/ayaka-notes/texlive-full:2021.1` * `ghcr.io/ayaka-notes/texlive-full:2020.1` {% hint style="warning" %} Існує сувора схема щодо того, як образи **мають** бути позначені тегом (застосовується такий regex `^[0-9]+.[0-9]+`, для якого перше число визначає рік TeX Live, а друге — версію виправлення). {% endhint %} ### Чи можу я використовувати інший реєстр образів > Дехто може замислюватися, чи можу я замінити `ghcr.io` на інший сайт-дзеркало або переключити texlive на інший образ із Docker Hub? Ні, ми не рекомендуємо цього, оскільки конфігурація є відносно складною. Якщо ви завантажуєте з сайту-дзеркала, ви можете перейменувати свій образ на `ghcr.io/ayaka-notes/texlive-full`. Але якщо ви дійсно хочете використовувати власний реєстр образів, додайте: {% code title="config/variables.env" overflow="wrap" %} ```dotenv IMAGE_ROOT=hub.your.com/your-repo ``` {% endcode %} Тоді вам потрібно переконатися, що всі образи texlive знаходяться в `your-repo`, як-от * `hub.your.com/your-repo/texlive-full:2025.1` * `hub.your.com/your-repo/texlive-full:2024.1` Для докладнішої інформації прочитайте вихідний код нижче, щоб зрозуміти, як ми парсимо вашу змінну середовища: {% code title="sandboxed-compiles/index.mjs" overflow="wrap" expandable="true" %} ```mjs if (process.env.SANDBOXED_COMPILES === 'true') { // Встановити кореневий образ за замовчуванням, якщо не вказано let imageRootPath = process.env.IMAGE_ROOT || "ghcr.io/ayaka-notes"; // Експортувати imageRoot до Settings Settings.imageRoot = imageRootPath // allowedImageNames має виглядати так: // [ // { imageName: "texlive-2023:latest", imageDesc: "TeX Live 2023" }, // { imageName: "texlive-2022:latest", imageDesc: "TeX Live 2022" }, // ] Settings.allowedImageNames = parseTextExtensions(process.env.ALL_TEX_LIVE_DOCKER_IMAGES) .map((texImage, index) => ({ imageName: texImage.split("/")[texImage.split("/").length - 1], imageDesc: parseTextExtensions(process.env.ALL_TEX_LIVE_DOCKER_IMAGE_NAMES)[index] || texImage.split(':')[1], })) // Зрештою imageName буде об'єднано з imageRoot, щоб утворити повний шлях до образу // Повна назва матиме вигляд: ghcr.io/ayaka-notes/texlive-2023:latest // Встановити назву образу за замовчуванням, якщо не вказано if(!process.env.TEX_LIVE_DOCKER_IMAGE) { process.env.TEX_LIVE_DOCKER_IMAGE = imageRootPath + "/" + Settings.allowedImageNames[0].imageName } // Експортувати currentImageName до Settings // Це назва образу для щойно створених проєктів Settings.currentImageName = process.env.TEX_LIVE_DOCKER_IMAGE } ``` {% endcode %} ### Відомі проблеми > Використання `6.0.1-ext-v3.3`, у мене є такі налаштування в `variables.env`: > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=texlive/texlive:latest-full > ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texlive:latest-full > ``` > > Це чудово працює з `texlive/texlive:latest-full`. Однак я підтягнув інший образ texlive `danteev/texlive:2025-10-15` і змінив обидві ці змінні на нову назву образу, але це не працює: > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=danteev/texlive:2025-10-15 > ALL_TEX_LIVE_DOCKER_IMAGES=danteev/texlive:2025-10-15 > ``` > > У журналах я бачу таке: > > {% code overflow="wrap" %} > > ``` > {"name":"clsi","level":50,"err":{"message":"(Код HTTP 404) такого контейнера не існує - немає такого образу: texlive/texlive:latest-full ","name":"Error","stack":"Error: (Код HTTP 404) такого контейнера не існує - немає такого образу: texlive/texlive:latest-full ..."}} > ``` > > {% endcode %} > > Схоже, оновлені налаштування в `variables.env` не набувають чинності. Компіляція все ще намагається запускати `texlive/texlive:latest-full` образ, а не новий образ. > > Я спробував перезавантажити, видалити контейнери та запустити знову, але проблема все та сама. > > Якісь рішення? Через деякі технічні обмеження, якщо ви налаштуєте лише один образ Docker TeXLive, наприклад `texlive-fullA:latest` ``` ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texliveA:latest-full ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=TeXLiveA TEX_LIVE_DOCKER_IMAGE=texlive/texliveA:latest-full ``` А після того, як ваш екземпляр overleaf працюватиме певний час, ви можете захотіти змінити образ TeXLive на `texlive-fullB:latest`. Тоді ви побачите, що ваші користувачі не можуть скомпілювати всі проєкти. ``` ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texliveA:latest-full ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=TeXLiveA TEX_LIVE_DOCKER_IMAGE=texlive/texliveA:latest-full ``` Це тому, що назва образу TeXLive-Full (для sandbox compile) у кожному проєкті зберігається в базі даних. *Лише коли користувач перемикає версію TeXLive свого проєкту, наприклад з 2024 на 2025, назва образу зміниться в базі даних*. Коли CLSI компілює проєкт, він використовує назву контейнерного образу, знайдену в базі даних, щоб безпосередньо компілювати проєкт. Якщо ви надаєте лише один образ Docker, користувачі не зможуть змінити образ, що використовується для компіляції проєкту. У такому разі вам потрібно написати скрипт, щоб **вручну змінити** образ TeXLive для всіх проєктів користувачів у mongoDB. ### Налагодження Запустіть таку команду, щоб перевірити журнал clsi з toolkit: {% code overflow="wrap" %} ```bash bin/logs clsi ``` {% endcode %} --- # 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/konfiguraciya/overleaf-toolkit/izolovanikh-kompilyacii.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.