> 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/es/primeros-pasos/microservices.md). # Microservicios La forma recomendada de desplegar y administrar instancias de Overleaf Server CE y Overleaf Pro es mediante el uso del Toolkit. El Toolkit simplifica la creación de su instancia de Overleaf mediante el uso de algunos scripts personalizados que abstraen la orquestación de los microservicios necesarios. Simplemente ejecute el script de inicialización incluido, proporcione algunas opciones de configuración como las rutas de su almacenamiento persistente, y el Toolkit se encargará de aprovisionar y conectar los microservicios que componen su instancia de Overleaf Server CE o Pro. Esto le permite centrarse en personalizar la experiencia de usuario e implementar las funciones específicas que componen su instancia local. El Toolkit maneja toda la complejidad entre bastidores, permitiendo un despliegue simplificado de su instancia de Overleaf. {% hint style="info" %} Por razones heredadas, el contenedor principal de Overleaf se llama `sharelatex`, y se basa en la `sharelatex/sharelatex` imagen de Docker. Esto se debe a que la tecnología se basa en la base de código de ShareLaTeX, que se fusionó en Overleaf. Consulte [esta entrada del blogarrow-up-right](https://www.overleaf.com/blog/518-exciting-news-sharelatex-is-joining-overleaf) para más detalles. En algún momento en el futuro, se le cambiará el nombre para que coincida con la convención de nombres de Overleaf. {% endhint %} #### Arquitectura Dentro del contenedor de Overleaf, el software se ejecuta como un conjunto de microservicios, gestionados por `runit`. Algunos de los archivos más interesantes dentro del contenedor son: * `/etc/service/`: archivos de inicialización para los microservicios. * `/var/log/overleaf/`: registros de cada microservicio. * `/overleaf/services/`: código de los distintos microservicios. * `/var/lib/overleaf/`: el punto de montaje para los datos persistentes (corresponde al directorio indicado por `OVERLEAF_DATA_PATH` en el host). #### Los contenedores de MongoDB y Redis Overleaf depende de dos bases de datos externas: MongoDB y Redis. De forma predeterminada, el Toolkit aprovisionará un contenedor para cada una de estas bases de datos, además del contenedor de Overleaf, para un total de tres contenedores Docker. {% hint style="info" %} Si prefiere conectarse a una instancia existente de MongoDB o Redis, puede hacerlo configurando los ajustes adecuados en el [overleaf.rc](https://overleaf-pro.ayaka.space/on-premises/es/primeros-pasos/pages/699ab3e0b5674419627d2b1a29b6727b4b67ebca#the-overleaf.rc-file) archivo de configuración. {% endhint %} #### Proceso del editor y de compilación Esta sección proporciona una visión general del manejo de documentos y del proceso de compilación. {% hint style="info" %} Esta página describe el proceso de compilación con compilaciones en sandbox, disponible solo en Overleaf Pro. En Server CE, el proceso de compilación usa subprocesos simples — reemplace los elementos que hacen referencia a un **contenedor** por un único elemento **ejecutar compilación en subproceso**. {% endhint %} Componentes / Actores: * `usuario` — Un usuario de la aplicación * `editor` — La aplicación cliente que se ejecuta en el navegador * `clsi` — El microservicio utilizado para compilar PDFs * `document-updater` — El microservicio utilizado para procesar actualizaciones de documentos * `filestore` — El microservicio que gestiona archivos binarios * `real-time` — El microservicio utilizado para gestionar sockets web * `web` — El (no tan) microservicio utilizado para gestionar solicitudes de API **Caché de Redis** * **usuario**: carga la página del editor * **editor**: abre un socket web * **editor**: envía una solicitud para abrir un documento a través del socket web * **real-time** -> **document-updater**: el documento se carga desde MongoDB en Redis * **editor**: envía una actualización del documento a través del socket web * **real-time** -> **document-updater**: el documento se actualiza en Redis * **editor**: envía más solicitudes de compilación * Después de que hayan transcurrido 5 minutos desde el último vaciado (por documento): * **document-updater**: vacía el documento de Redis a MongoDB * **editor**: envía más actualizaciones * cada 100 actualizaciones (por documento): * **document-updater**: vacía el historial del documento de Redis a MongoDB * **usuario**: abandona el editor/cierra la pestaña del navegador * 5 minutos después * **real-time**: comprueba si hay otros colaboradores; si no los hay: * **real-time** -> **document-updater**: vacía los documentos de Redis a MongoDB **Lectura desde MongoDB hacia Redis** * **document-updater** -> **web** -> **docstore**: leer desde MongoDB **Vaciado de Redis a MongoDB** * **document-updater** -> **web** -> **docstore**: escribir en MongoDB **Compilación — modo de sincronización "full"** * **editor**: envía una solicitud de compilación con el modo de sincronización configurado en "full" * **web** -> **document-updater**: cualquier documento se vacía de Redis a MongoDB * **web** -> **docstore**: todos los documentos se descargan desde MongoDB * **web** -> **clsi**: la solicitud de compilación se envía a `clsi`, incluyendo: * el modo de sincronización * un hash del árbol de archivos -> el "estado del proyecto" * todos los documentos con su contenido -> sujeto al límite de 7 MB del cuerpo de la solicitud * URL de archivos binarios para descarga separada * **clsi**: comprobar el estado en disco con el modo de sincronización y el "estado del proyecto" * esta es una sincronización completa, por lo que se puede ignorar el estado previo en disco * **clsi**: limpiar el directorio de compilación * **clsi**: escribir todos los documentos en el directorio de compilación * **clsi**: escribir todos los archivos binarios en el directorio de compilación * `clsi` copia los archivos desde una caché local por proyecto * si hay un fallo de caché: * **clsi** -> **filestore**: descargar archivos * **clsi**: escribir el "estado del proyecto" * **clsi**: asegurarse de que exista un contenedor Docker con la configuración deseada * construir opciones del contenedor, incluye la versión de texlive * opciones de hash * nombre del contenedor: `project---` * **clsi**: iniciar el contenedor y transmitir stdout/stderr a la memoria -> límite de 2 MB * **clsi**: dejar el contenedor detenido -> se limpia después de 24 h * **clsi**: escribir stdout/stderr en disco * **clsi**: copiar los archivos de salida a un directorio de salida único * build-id compuesto por 8 bytes aleatorios más una marca de tiempo con precisión de ms * eliminar todas las carpetas de compilación excepto las últimas 3 (anónimo) / la última 1 (usuario con sesión iniciada) * **clsi**: la compilación falló/agotó el tiempo * eliminar la caché de compilación — puede tener archivos parciales/caché corrupta * **editor**: descarga output.log y output.pdf **Compilación — modo de sincronización "incremental"** * **editor**: envía una solicitud de compilación con el modo de sincronización configurado en "incremental" * **web** -> **document-updater**: obtener cualquier documento de Redis * el hash del "estado del proyecto" también se almacena en Redis * **web** envía el hash del árbol de archivos a `document-updater` y `document-updater` puede convertir la compilación incremental en una compilación completa si hay discrepancia * vea el proceso de compilación tal como se realiza cuando el editor solicitó una compilación "full" * **web** -> **clsi**: la solicitud de compilación se envía a `clsi`, incluyendo: * el modo de sincronización * un hash del árbol de archivos -> el "estado del proyecto" * todos los documentos de Redis con su contenido -> sujeto al límite de 7 MB del cuerpo de la solicitud * sin archivos binarios * **clsi**: comprobar el estado en disco con el modo de sincronización y el "estado del proyecto" * esta es una sincronización incremental, por lo que el "estado del proyecto" debe coincidir * si hay discrepancia: responder con 409, permitir que la web reintente con sincronización "full" * vea el proceso de compilación tal como se realiza cuando el editor solicitó una compilación "full" * **clsi**: escribir los documentos actualizados en el directorio de compilación * **clsi**: asegurarse de que exista un contenedor Docker con la configuración deseada * construir opciones del contenedor, incluye la versión de texlive * opciones de hash * nombre del contenedor: `project---` * **clsi**: iniciar el contenedor y transmitir stdout/stderr a la memoria -> límite de 2 MB * **clsi**: dejar el contenedor detenido -> se limpia después de 24 h * **clsi**: escribir stdout/stderr en disco * **clsi**: copiar los archivos de salida a un directorio de salida único * build-id compuesto por 8 bytes aleatorios más una marca de tiempo con precisión de ms * eliminar todas las carpetas de compilación excepto las últimas 3 (anónimo) / la última 1 (usuario con sesión iniciada) * **clsi**: la compilación falló/agotó el tiempo * eliminar la caché de compilación — puede tener archivos parciales/caché corrupta * **editor**: descarga output.log y output.pdf **Compilación — cambio entre modos** * **editor**: observa un fallo de compilación, la siguiente compilación es una compilación "full" * **editor**: observa una compilación exitosa, la siguiente compilación es una compilación "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://overleaf-pro.ayaka.space/on-premises/es/primeros-pasos/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.