> 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/it/per-iniziare/microservices.md). # Microservizi Il modo consigliato per distribuire e gestire istanze di Overleaf Server CE e Overleaf Pro è tramite l'uso del Toolkit. Il Toolkit semplifica la creazione della tua istanza Overleaf tramite l'uso di alcuni script personalizzati che astraggono l'orchestrazione dei microservizi richiesti. Esegui semplicemente lo script di inizializzazione incluso, fornisci alcune opzioni di configurazione come i percorsi di archiviazione persistente e il Toolkit si occuperà di predisporre e collegare i microservizi che compongono la tua istanza Overleaf Server CE o Pro. Questo ti lascia libero di concentrarti sulla personalizzazione dell'esperienza utente e sull'implementazione delle funzionalità specifiche che compongono la tua istanza on-premise. Il Toolkit gestisce tutta la complessità dietro le quinte, consentendo una distribuzione semplificata della tua istanza Overleaf. {% hint style="info" %} Per ragioni di retrocompatibilità, il contenitore principale di Overleaf si chiama `sharelatex`, ed è basato sull' `sharelatex/sharelatex` immagine Docker. Questo perché la tecnologia si basa sulla code base di ShareLaTeX, che è stata integrata in Overleaf. Vedi [questo post del blogarrow-up-right](https://www.overleaf.com/blog/518-exciting-news-sharelatex-is-joining-overleaf) per maggiori dettagli. A un certo punto in futuro, verrà rinominato per corrispondere allo schema di denominazione di Overleaf. {% endhint %} #### Architettura All'interno del contenitore Overleaf, il software gira come un insieme di microservizi, gestiti da `runit`. Alcuni dei file più interessanti all'interno del contenitore sono: * `/etc/service/`: file di inizializzazione per i microservizi. * `/var/log/overleaf/`: log per ciascun microservizio. * `/overleaf/services/`: codice per i vari microservizi. * `/var/lib/overleaf/`: il punto di mount per i dati persistenti (corrisponde alla directory indicata da `OVERLEAF_DATA_PATH` sull'host). #### I contenitori MongoDB e Redis Overleaf dipende da due database esterni: MongoDB e Redis. Per impostazione predefinita, il Toolkit predisporrà un contenitore per ciascuno di questi database, oltre al contenitore Overleaf, per un totale di tre contenitori Docker. {% hint style="info" %} Se preferisci connetterti a un'istanza MongoDB o Redis esistente, puoi farlo impostando le opzioni appropriate nel [overleaf.rc](https://ayakaleaf-pro.ayaka.space/on-premises/it/per-iniziare/pages/20286f318630c6914afc98559e7bb4b8b02f187e#the-overleaf.rc-file) file di configurazione. {% endhint %} #### Editor e processo di compilazione Questa sezione fornisce una panoramica generale sulla gestione dei documenti e sul processo di compilazione. {% hint style="info" %} Questa pagina descrive il processo di compilazione con Sandboxed Compiles, disponibile solo in Overleaf Pro. In Server CE, il processo di compilazione usa semplici sottoprocessi — sostituisci gli elementi che fanno riferimento a un **container** con un singolo elemento **esegui la compilazione in sottoprocesso**. {% endhint %} Componenti / Attori: * `utente` — Un utente dell'applicazione * `editor` — L'applicazione client in esecuzione nel browser * `clsi` — Il microservizio usato per la compilazione dei PDF * `document-updater` — Il microservizio usato per elaborare gli aggiornamenti dei documenti * `filestore` — Il microservizio che gestisce i file binari * `real-time` — Il microservizio usato per gestire i websocket * `web` — Il (non così) microservizio usato per gestire le richieste API **Caching di Redis** * **utente**: carica la pagina dell'editor * **editor**: apre il websocket * **editor**: invia una richiesta per aprire un documento tramite websocket * **real-time** -> **document-updater**: il documento viene caricato da MongoDB in Redis * **editor**: invia l'aggiornamento del documento tramite websocket * **real-time** -> **document-updater**: il documento viene aggiornato in Redis * **editor**: invia altre richieste di compilazione * Dopo 5 minuti dall'ultimo flush (per documento): * **document-updater**: svuota il documento da Redis in MongoDB * **editor**: invia altri aggiornamenti * ogni 100 aggiornamenti (per documento): * **document-updater**: svuota la cronologia del documento da Redis in MongoDB * **utente**: esce dall'editor/chiude la scheda del browser * 5 minuti dopo * **real-time**: controlla se ci sono altri collaboratori, se non ce ne sono: * **real-time** -> **document-updater**: svuota i documenti da Redis in MongoDB **Lettura da MongoDB in Redis** * **document-updater** -> **web** -> **docstore**: leggi da MongoDB **Svuotamento da Redis in MongoDB** * **document-updater** -> **web** -> **docstore**: scrivi in MongoDB **Compilazione — modalità di sincronizzazione "full"** * **editor**: invia la richiesta di compilazione con la modalità di sincronizzazione impostata su "full" * **web** -> **document-updater**: eventuali documenti vengono svuotati da Redis in MongoDB * **web** -> **docstore**: tutti i documenti vengono scaricati da MongoDB * **web** -> **clsi**: la richiesta di compilazione viene inviata a `clsi`, inclusi: * la modalità di sincronizzazione * un hash dell'albero dei file -> lo "stato del progetto" * tutti i documenti con il loro contenuto -> soggetto al limite di 7 MB per il corpo della richiesta * URL dei file binari per il download separato * **clsi**: controlla lo stato su disco con la modalità di sincronizzazione e lo "stato del progetto" * questa è una sincronizzazione completa, quindi il precedente stato su disco può essere ignorato * **clsi**: pulisci la directory di compilazione * **clsi**: scrivi tutti i documenti nella directory di compilazione * **clsi**: scrivi tutti i file binari nella directory di compilazione * `clsi` copia i file da una cache locale per progetto * in caso di cache miss: * **clsi** -> **filestore**: scarica i file * **clsi**: scrivi lo "stato del progetto" * **clsi**: assicurati che il contenitore Docker esista con la configurazione desiderata * costruisci le opzioni del contenitore, include la versione di texlive * opzioni hash * nome del contenitore: `project---` * **clsi**: avvia il contenitore e trasmette stdout/stderr in memoria -> limite 2 MB * **clsi**: lascia il contenitore fermo dietro di sé -> viene ripulito dopo 24 ore * **clsi**: scrivi stdout/stderr su disco * **clsi**: copia i file di output in una directory di output univoca * build-id composto da 8 byte casuali più timestamp con precisione al millisecondo * elimina tutte le cartelle di build tranne le ultime 3 (anonimo) / l'ultima 1 (utente autenticato) * **clsi**: la compilazione è fallita/è andata in timeout * elimina la cache di compilazione — potrebbe avere file parziali/cache corrotta * **editor**: scarica output.log e output.pdf **Compilazione — modalità di sincronizzazione "incremental"** * **editor**: invia la richiesta di compilazione con la modalità di sincronizzazione impostata su "incremental" * **web** -> **document-updater**: ottieni eventuali documenti da Redis * l'"hash dello stato del progetto" è anch'esso memorizzato in Redis * **web** invia l'hash dell'albero dei file a `document-updater` e `document-updater` può trasformare la compilazione incrementale in una compilazione completa in caso di mancata corrispondenza * vedi il processo di compilazione così come eseguito quando l'editor richiedeva una compilazione "full" * **web** -> **clsi**: la richiesta di compilazione viene inviata a `clsi`, inclusi: * la modalità di sincronizzazione * un hash dell'albero dei file -> lo "stato del progetto" * tutti i documenti da Redis con il loro contenuto -> soggetto al limite di 7 MB per il corpo della richiesta * nessun file binario * **clsi**: controlla lo stato su disco con la modalità di sincronizzazione e lo "stato del progetto" * questa è una sincronizzazione incrementale, quindi lo "stato del progetto" deve corrispondere * in caso di mancata corrispondenza: rispondi con 409, lascia che il web ritenti con sincronizzazione "full" * vedi il processo di compilazione così come eseguito quando l'editor richiedeva una compilazione "full" * **clsi**: scrivi i documenti aggiornati nella directory di compilazione * **clsi**: assicurati che il contenitore Docker esista con la configurazione desiderata * costruisci le opzioni del contenitore, include la versione di texlive * opzioni hash * nome del contenitore: `project---` * **clsi**: avvia il contenitore e trasmette stdout/stderr in memoria -> limite 2 MB * **clsi**: lascia il contenitore fermo dietro di sé -> viene ripulito dopo 24 ore * **clsi**: scrivi stdout/stderr su disco * **clsi**: copia i file di output in una directory di output univoca * build-id composto da 8 byte casuali più timestamp con precisione al millisecondo * elimina tutte le cartelle di build tranne le ultime 3 (anonimo) / l'ultima 1 (utente autenticato) * **clsi**: la compilazione è fallita/è andata in timeout * elimina la cache di compilazione — potrebbe avere file parziali/cache corrotta * **editor**: scarica output.log e output.pdf **Compilazione — cambio tra modalità** * **editor**: osserva un fallimento della compilazione, la prossima compilazione è una compilazione "full" * **editor**: osserva un successo della compilazione, la prossima compilazione è una compilazione "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/it/per-iniziare/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.