> 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/es/configuracion/overleaf-toolkit/sandboxed-compiles.md). # Compilaciones aisladas Overleaf Pro incluye la opción de ejecutar compilaciones en un entorno aislado seguro para seguridad empresarial. Lo hace ejecutando cada proyecto en su propio entorno Docker seguro. ### Seguridad mejorada Las compilaciones aisladas son el enfoque recomendado para Server Pro debido a que muchos documentos LaTeX requieren/tienen la capacidad de ejecutar comandos de shell arbitrarios como parte del proceso de compilación del PDF. Si usa compilaciones aisladas, cada compilación se ejecuta en un contenedor Docker separado con capacidades limitadas que no se comparten con ningún otro usuario o proyecto y no tiene acceso a recursos externos como la red del host. {% hint style="warning" %} Si intenta ejecutar Overleaf Pro **sin** compilaciones aisladas, la compilación se ejecuta junto con otras compilaciones concurrentes dentro del contenedor Docker principal y los usuarios tienen acceso total de lectura y escritura a los `sharelatex` recursos del contenedor (sistema de archivos, red y variables de entorno) al ejecutar compilaciones LaTeX. {% endhint %} ### Gestión de paquetes más sencilla Para evitar instalar paquetes manualmente, recomendamos habilitar las compilaciones aisladas. Esta es una configuración ajustable dentro de Server Pro que proporcionará a sus usuarios acceso al mismo entorno de TeX Live que el de overleaf.com, pero dentro de su propia instalación local. Las imágenes de TeX Live utilizadas por las compilaciones aisladas contienen los paquetes y fuentes más populares probados con nuestras plantillas de galería, lo que garantiza la máxima compatibilidad con proyectos locales. Habilitar las compilaciones aisladas le permite configurar qué versiones de TeX Live pueden elegir los usuarios dentro de su proyecto, además de establecer una versión de imagen de TeX Live predeterminada para los proyectos nuevos. {% hint style="info" %} Si intenta ejecutar Overleaf Pro sin compilaciones aisladas, su instancia usará de forma predeterminada una versión de esquema básico de TeX Live para las compilaciones. Esta versión básica es ligera y solo contiene un subconjunto muy limitado de paquetes LaTeX, lo que probablemente resultará en errores de paquetes faltantes para sus usuarios, especialmente si intentan usar plantillas preconstruidas. {% endhint %} Como Overleaf Pro ha sido diseñado para funcionar sin conexión, no existe una forma automatizada de integrar las plantillas de la galería de overleaf.com en su instalación local; sin embargo, es posible hacerlo manualmente por plantilla. Para obtener más información sobre cómo funciona esto, consulte nuestra guía para transferir plantillas desde overleaf.com: [/pages/7231a90673c6e603d0c6758a51fb647a197c6622#transferring-templates-from-overleaf.com](https://ayakaleaf-pro.ayaka.space/on-premises/es/configuracion/overleaf-toolkit/pages/7231a90673c6e603d0c6758a51fb647a197c6622#transferring-templates-from-overleaf.com "mention"). {% hint style="info" %} Las compilaciones aisladas requieren que el `sharelatex` contenedor tenga acceso al socket de Docker en la máquina host (mediante un montaje enlazado) para que pueda administrar estos contenedores hermanos de compilación. {% endhint %} ## Cómo funciona Cuando las compilaciones aisladas están habilitadas, el socket de Docker se montará desde la máquina host en el `sharelatex` contenedor, de modo que el servicio de compilación dentro del contenedor pueda crear nuevos contenedores Docker en el host. Luego, para cada ejecución del compilador en cada proyecto, el servicio compilador de LaTeX (CLSI) hará lo siguiente: * Escribir los archivos del proyecto en una ubicación dentro de `OVERLEAF_DATA_PATH`. * Usar el socket de Docker montado para crear un nuevo `texlive` contenedor para la ejecución de la compilación. * Hacer que el `texlive` contenedor lea los datos del proyecto desde la ubicación en `OVERLEAF_DATA_PATH`. * Compilar el proyecto dentro del `texlive` contenedor. ### Habilitar compilaciones aisladas #### Para usuarios de Toolkit Para habilitar las compilaciones aisladas (también conocidas como contenedores hermanos), establezca las siguientes opciones de configuración en `overleaf-toolkit/config/overleaf.rc`: {% code title="config/overleaf.rc" %} ```dotenv SERVER_PRO=true SIBLING_CONTAINERS_ENABLED=true ``` {% endcode %} #### Para usuarios de Docker Compose {% hint style="danger" %} A partir de Overleaf CE/Server Pro `5.0.3` las variables de entorno fueron rebautizadas de `SHARELATEX_*` a `OVERLEAF_*`. {% endhint %} Si está usando una `4.x` versión (o anterior), asegúrese de que las variables tengan el prefijo correspondiente (por ejemplo, `SHARELATEX_MONGO_URL` en lugar de `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"
            #...
        #...
### Cambiar la imagen de TexLive {% hint style="info" %} Para usuarios de China continental, puede usar `ghcr.nju.edu.cn` para acelerar la descarga. {% endhint %} Overleaf Pro usa tres variables de entorno para determinar qué imágenes de TeX Live usar para las compilaciones aisladas: * `TEX_LIVE_DOCKER_IMAGE` **(obligatoria),** La imagen de TeX Live predeterminada utilizada para compilar proyectos nuevos. Esta imagen debe incluirse en `ALL_TEX_LIVE_DOCKER_IMAGES`. * `ALL_TEX_LIVE_DOCKER_IMAGE_NAMES` **(obligatoria),** Una lista separada por comas de nombres descriptivos para las imágenes, usada para las opciones del frontend. * `ALL_TEX_LIVE_DOCKER_IMAGES` **(obligatoria),** Una lista separada por comas de imágenes de TeX Live que se usarán. Si se utiliza Overleaf Toolkit para la implementación, estas imágenes se descargarán o actualizarán. Para omitir la descarga, establezca `SIBLING_CONTAINERS_PULL=false` en `config/overleaf.rc`. Al iniciar su instancia de Overleaf Pro usando el `bin/up` comando, Toolkit descargará automáticamente todas las imágenes enumeradas en `ALL_TEX_LIVE_DOCKER_IMAGES`. Aquí hay un ejemplo en el que usamos TeX Live 2025 como predeterminado para los proyectos nuevos y mantenemos 2024 en uso para los proyectos existentes. {% tabs %} {% tab title="instalación común" %} La siguiente configuración instala todas las imágenes completas de Docker de TeX Live desde 2025 hasta 2026. Recomendamos tener al menos 80 GB de almacenamiento disponible antes de usar esta configuración. {% code title="config/variables.env" overflow="wrap" %} ```dotenv ALL_TEX_LIVE_DOCKER_IMAGES=ghcr.io/ayaka-notes/texlive-full:2026.1, ghcr.io/ayaka-notes/texlive-full:2025.1 ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=Texlive 2026, Texlive 2025 TEX_LIVE_DOCKER_IMAGE=ghcr.io/ayaka-notes/texlive-full:2026.1 ``` {% endcode %} {% endtab %} {% tab title="instalación completa" %} La siguiente configuración instala todas las imágenes completas de Docker de TeX Live desde 2020 hasta 2026. Recomendamos tener al menos 256 GB de almacenamiento disponible antes de usar esta configuración. {% code title="config/variables.env" overflow="wrap" %} ```dotenv ALL_TEX_LIVE_DOCKER_IMAGES=ghcr.io/ayaka-notes/texlive-full:2026.1,ghcr.io/ayaka-notes/texlive-full:2025.1,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 ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=Texlive 2026,Texlive 2025,Texlive 2024,Texlive 2023,Texlive 2022,Texlive 2021,Texlive 2020 TEX_LIVE_DOCKER_IMAGE=ghcr.io/ayaka-notes/texlive-full:2026.1 ``` {% endcode %} {% endtab %} {% endtabs %} {% hint style="danger" %} Se recomienda encarecidamente establecer **al menos 2 imágenes texlive-full**. Para una razón detallada, consulte [#known-issues](#known-issues "mention") {% endhint %} ### Imágenes de TeX Live disponibles Estas son una serie de imágenes de TeX Live especialmente optimizadas para Overleaf, también se pueden añadir a `TEX_LIVE_DOCKER_IMAGE` y `ALL_TEX_LIVE_DOCKER_IMAGES`: * `ghcr.io/ayaka-notes/texlive-full:2026.1` (también `latest` etiqueta) * `ghcr.io/ayaka-notes/texlive-full:2025.1` * `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" %} Existe un esquema estricto sobre cómo las imágenes **deben** etiquetarse (se aplica la siguiente expresión regular `^[0-9]+.[0-9]+`, en la que el primer número determina el año de TeX Live y el segundo la versión del parche). {% endhint %} ### ¿Puedo usar otro registro de imágenes? > Algunas personas pueden preguntarse si puedo reemplazar `ghcr.io` por otro sitio espejo, o cambiar texlive por otra imagen de Docker Hub? No, no lo recomendamos porque la configuración es relativamente complicada. Si está descargando desde un sitio espejo, puede cambiar el nombre de su imagen a `ghcr.io/ayaka-notes/texlive-full`. Pero, si realmente quiere usar su propio registro de imágenes, añada: {% code title="config/variables.env" overflow="wrap" %} ```dotenv IMAGE_ROOT=hub.your.com/your-repo ``` {% endcode %} Entonces, debe asegurarse de que todas las imágenes de texlive estén en `your-repo`, como * `hub.your.com/your-repo/texlive-full:2025.1` * `hub.your.com/your-repo/texlive-full:2024.1` Para información detallada, lea el código fuente de abajo para entender cómo analizamos su variable de entorno: {% code title="sandboxed-compiles/index.mjs" overflow="wrap" expandable="true" %} ```mjs if (process.env.SANDBOXED_COMPILES === 'true') { // Establecer la raíz de imagen predeterminada si no se proporciona let imageRootPath = process.env.IMAGE_ROOT || "ghcr.io/ayaka-notes"; // Exportar imageRoot a Settings Settings.imageRoot = imageRootPath // allowedImageNames debería ser: // [ // { 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], })) // Al final, imageName se combinará con imageRoot para formar la ruta completa de la imagen // El nombre completo será como: ghcr.io/ayaka-notes/texlive-2023:latest // Establecer el nombre de imagen predeterminado si no se proporciona if(!process.env.TEX_LIVE_DOCKER_IMAGE) { process.env.TEX_LIVE_DOCKER_IMAGE = imageRootPath + "/" + Settings.allowedImageNames[0].imageName } // Exportar currentImageName a Settings // Este es el nombre de imagen de los proyectos recién creados Settings.currentImageName = process.env.TEX_LIVE_DOCKER_IMAGE } ``` {% endcode %} ### Problemas conocidos Este es un caso real de la comunidad de Overleaf: > Usando `6.0.1-ext-v3.3`, tengo estos ajustes en `variables.env`: > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=texlive/texlive:latest-full > ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texlive:latest-full > ``` > > Esto funciona bien con `texlive/texlive:latest-full`. Sin embargo, descargué otra imagen de texlive `danteev/texlive:2025-10-15` y cambié ambas variables al nuevo nombre de imagen, pero no funciona: > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=danteev/texlive:2025-10-15 > ALL_TEX_LIVE_DOCKER_IMAGES=danteev/texlive:2025-10-15 > ``` > > En los registros, veo lo siguiente: > > {% code overflow="wrap" %} > > ``` > {"name":"clsi","level":50,"err":{"message":"(código HTTP 404) no existe tal contenedor - No existe tal imagen: texlive/texlive:latest-full ","name":"Error","stack":"Error: (código HTTP 404) no existe tal contenedor - No existe tal imagen: texlive/texlive:latest-full ... > ``` > > {% endcode %} > > Parece que los ajustes actualizados en `variables.env` no están surtiendo efecto. La compilación sigue intentando ejecutar la `texlive/texlive:latest-full` imagen, no la nueva imagen. > > Intenté reiniciar, eliminar los contenedores y ejecutar de nuevo, pero sigue siendo el mismo problema. > > ¿Alguna solución? Debido a algunas limitaciones técnicas, si solo configura una única imagen Docker de TeXLive, como `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 ``` Y después de ejecutar su instancia de Overleaf durante un tiempo, podría querer modificar la imagen de TeXLive a `texlive-fullB:latest`. Entonces verá que sus usuarios no pueden compilar todos los proyectos. ``` ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texliveA:latest-full ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=TeXLiveA TEX_LIVE_DOCKER_IMAGE=texlive/texliveA:latest-full ``` Esto se debe a que el nombre de la imagen TeXLive-Full (para compilación en sandbox) de cada proyecto se mantiene en la base de datos. *Solo cuando el usuario cambie la versión de TeXLive de su proyecto, por ejemplo, de 2024 a 2025, se cambiará el nombre de la imagen en la base de datos*. Cuando CLSI compila un proyecto, usa el nombre de la imagen del contenedor encontrado en la base de datos para compilar el proyecto directamente. Si solo proporciona una imagen Docker, los usuarios no podrán modificar la imagen utilizada para compilar el proyecto. En este caso, necesita escribir un script para **modificar manualmente** la imagen de TeXLive para todos los proyectos de los usuarios en mongoDB. ### Depuración Ejecute el siguiente comando para comprobar el registro de clsi desde 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://ayakaleaf-pro.ayaka.space/on-premises/es/configuracion/overleaf-toolkit/sandboxed-compiles.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.