> 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/it/per-iniziare/microservices.md). # Microservizi Il modo consigliato per distribuire e gestire le istanze di Overleaf Server CE e Overleaf Pro è tramite l'uso del Toolkit. Il Toolkit semplifica la creazione della tua istanza Overleaf attraverso l'uso di alcuni script personalizzati che astraono l'orchestrazione dei microservizi richiesti. Basta eseguire lo script di inizializzazione incluso, fornire alcune opzioni di configurazione come i percorsi di archiviazione persistente e il Toolkit si occuperà del provisioning e della connessione dei 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 motivi di compatibilità con versioni precedenti, il container principale di Overleaf si chiama `sharelatex`, ed è basato sulla `sharelatex/sharelatex` Docker image. Questo perché la tecnologia è basata sul codice sorgente di ShareLaTeX, che è stato integrato in Overleaf. Vedi [questo post del blogarrow-up-right](https://www.overleaf.com/blog/518-exciting-news-sharelatex-is-joining-overleaf) per maggiori dettagli. In futuro, questo verrà rinominato per allinearlo alla convenzione di denominazione di Overleaf. {% endhint %} #### Architettura All'interno del container Overleaf, il software viene eseguito come un insieme di microservizi, gestiti da `runit`. Alcuni dei file più interessanti all'interno del container 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 container MongoDB e Redis Overleaf dipende da due database esterni: MongoDB e Redis. Per impostazione predefinita, il Toolkit predisporrà un container per ciascuno di questi database, oltre al container Overleaf, per un totale di tre container Docker. {% hint style="info" %} Se preferisci collegarti a un'istanza MongoDB o Redis esistente, puoi farlo impostando le configurazioni appropriate nel [overleaf.rc](https://overleaf-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 utilizza semplici sotto-processi — sostituisci gli elementi che fanno riferimento a un **contenitore** con un singolo elemento **esegui la compilazione in un sotto-processo**. {% endhint %} Componenti / Attori: * `utente` — Un utente dell'applicazione * `editor` — L'applicazione client in esecuzione nel browser * `clsi` — Il microservizio utilizzato per la compilazione dei PDF * `document-updater` — Il microservizio utilizzato per elaborare gli aggiornamenti dei documenti * `filestore` — Il microservizio che gestisce i file binari * `real-time` — Il microservizio utilizzato per gestire i web socket * `web` — Il microservizio (non proprio micro) utilizzato per gestire le richieste API **Caching Redis** * **utente**: carica la pagina dell'editor * **editor**: apre il web socket * **editor**: invia una richiesta per aprire un documento tramite web socket * **real-time** -> **document-updater**: il documento viene caricato da MongoDB in Redis * **editor**: invia l'aggiornamento del documento tramite web socket * **real-time** -> **document-updater**: il documento viene aggiornato in Redis * **editor**: invia altre richieste di compilazione * Dopo che sono trascorsi 5 minuti dall'ultimo flush (per documento): * **document-updater**: svuota il documento da Redis a MongoDB * **editor**: invia altri aggiornamenti * ogni 100 aggiornamenti (per documento): * **document-updater**: svuota la cronologia del documento da Redis a MongoDB * **utente**: esce dall'editor/chiude la scheda del browser * 5 minuti dopo * **real-time**: verifica la presenza di altri collaboratori, se non ce ne sono: * **real-time** -> **document-updater**: svuota i documenti da Redis a MongoDB **Lettura da MongoDB in Redis** * **document-updater** -> **web** -> **docstore**: leggi da MongoDB **Flush da Redis a 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 -> soggetti 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 lo stato precedente 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 container Docker esista con la configurazione desiderata * opzioni del container di build, include la versione di texlive * opzioni hash * nome del container: `project---` * **clsi**: avvia il container e streamma stdout/stderr in memoria -> limite 2 MB * **clsi**: lascia il container fermo -> viene pulito 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 in millisecondi * elimina tutte le cartelle di build tranne le ultime 3 (utente anonimo) / l'ultima 1 (utente autenticato) * **clsi**: la compilazione è fallita/in timeout * elimina la cache di compilazione — potrebbe contenere 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 * anche l'hash dello "stato del progetto" è 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 come eseguito quando l'editor ha richiesto 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 -> soggetti 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 riprovi con sincronizzazione "full" * vedi il processo di compilazione come eseguito quando l'editor ha richiesto una compilazione "full" * **clsi**: scrivi i documenti aggiornati nella directory di compilazione * **clsi**: assicurati che il container Docker esista con la configurazione desiderata * opzioni del container di build, include la versione di texlive * opzioni hash * nome del container: `project---` * **clsi**: avvia il container e streamma stdout/stderr in memoria -> limite 2 MB * **clsi**: lascia il container fermo -> viene pulito 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 in millisecondi * elimina tutte le cartelle di build tranne le ultime 3 (utente anonimo) / l'ultima 1 (utente autenticato) * **clsi**: la compilazione è fallita/in timeout * elimina la cache di compilazione — potrebbe contenere file parziali/cache corrotta * **editor**: scarica output.log e output.pdf **Compilazione — cambio tra modalità** * **editor**: rileva un errore di compilazione, la prossima compilazione è una compilazione "full" * **editor**: rileva una compilazione riuscita, 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://overleaf-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.