> 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/fr/premiers-pas/microservices.md). # Microservices La manière recommandée de déployer et de gérer les instances Overleaf Server CE et Overleaf Pro consiste à utiliser le Toolkit. Le Toolkit simplifie la création de votre instance Overleaf grâce à l’utilisation de quelques scripts personnalisés qui abstraient l’orchestration des microservices requis. Il suffit d’exécuter le script d’initialisation inclus, de fournir quelques options de configuration comme vos chemins de stockage persistant, et le Toolkit se chargera de provisionner et de connecter les microservices qui composent votre instance Overleaf Server CE ou Pro. Cela vous laisse libre de vous concentrer sur la personnalisation de l’expérience utilisateur et sur l’implémentation des fonctionnalités spécifiques qui composent votre instance sur site. Le Toolkit gère toute la complexité en coulisses, permettant un déploiement simplifié de votre instance Overleaf. {% hint style="info" %} Pour des raisons historiques, le conteneur principal Overleaf s’appelle `conteneur sharelatex.`, et est basé sur l’ `sharelatex/sharelatex` image Docker. Cela tient au fait que la technologie est basée sur la base de code ShareLaTeX, qui a été fusionnée dans Overleaf. Voir [cet article de blogarrow-up-right](https://www.overleaf.com/blog/518-exciting-news-sharelatex-is-joining-overleaf) pour plus de détails. À l’avenir, il sera renommé pour correspondre à la convention de nommage d’Overleaf. {% endhint %} #### Architecture À l’intérieur du conteneur Overleaf, le logiciel s’exécute sous forme d’un ensemble de microservices, gérés par `runit`. Certains des fichiers les plus intéressants à l’intérieur du conteneur sont : * `/etc/service/`: fichiers d’initialisation pour les microservices. * `/var/log/overleaf/`: journaux de chaque microservice. * `/overleaf/services/`: code des différents microservices. * `/var/lib/overleaf/`: le point de montage pour les données persistantes (correspond au répertoire indiqué par `OVERLEAF_DATA_PATH` sur l’hôte). #### Les conteneurs MongoDB et Redis Overleaf dépend de deux bases de données externes : MongoDB et Redis. Par défaut, le Toolkit provisionnera un conteneur pour chacune de ces bases de données, en plus du conteneur Overleaf, pour un total de trois conteneurs Docker. {% hint style="info" %} Si vous préférez vous connecter à une instance MongoDB ou Redis existante, vous pouvez le faire en définissant les paramètres appropriés dans le [overleaf.rc](https://overleaf-pro.ayaka.space/on-premises/fr/premiers-pas/pages/9db05254786ae56bfedbc0e1de94e80cf8171aa4#the-overleaf.rc-file) fichier de configuration. {% endhint %} #### Éditeur et processus de compilation Cette section fournit une vue d’ensemble générale du traitement des documents et du processus de compilation. {% hint style="info" %} Cette page décrit le processus de compilation avec les compilations en bac à sable, disponibles uniquement dans Overleaf Pro. Dans Server CE, le processus de compilation utilise de simples sous-processus — remplacez les éléments faisant référence à un **conteneur** par un seul élément **exécuter la compilation dans un sous-processus**. {% endhint %} Composants / Acteurs : * `utilisateur` — Un utilisateur de l’application * `éditeur` — L’application cliente exécutée dans le navigateur * `clsi` — Le microservice utilisé pour compiler les PDF * `document-updater` — Le microservice utilisé pour traiter les mises à jour de documents * `filestore` — Le microservice qui gère les fichiers binaires * `real-time` — Le microservice utilisé pour gérer les sockets Web * `web` — Le (pas si) microservice utilisé pour gérer les requêtes API **Mise en cache Redis** * **utilisateur**: charge la page de l’éditeur * **éditeur**: ouvre le socket Web * **éditeur**: envoie une requête pour ouvrir un document via le socket Web * **real-time** -> **document-updater**: le document est chargé de MongoDB vers Redis * **éditeur**: envoie la mise à jour du document via le socket Web * **real-time** -> **document-updater**: le document est mis à jour dans Redis * **éditeur**: envoie d’autres requêtes de compilation * Après 5 minutes écoulées depuis le dernier flush (par document) : * **document-updater**: vide le document de Redis vers MongoDB * **éditeur**: envoie d’autres mises à jour * toutes les 100 mises à jour (par document) : * **document-updater**: vide l’historique du document de Redis vers MongoDB * **utilisateur**: quitte l’éditeur/ferme l’onglet du navigateur * 5 minutes plus tard * **real-time**: vérifie s’il y a d’autres collaborateurs, s’il n’y en a pas : * **real-time** -> **document-updater**: vide les documents de Redis vers MongoDB **Lecture de MongoDB vers Redis** * **document-updater** -> **web** -> **docstore**: lecture depuis MongoDB **Vidage de Redis vers MongoDB** * **document-updater** -> **web** -> **docstore**: écriture dans MongoDB **Compilation — mode de synchronisation « full »** * **éditeur**: envoie une requête de compilation avec le mode de synchronisation défini sur « full » * **web** -> **document-updater**: tous les documents sont vidés de Redis vers MongoDB * **web** -> **docstore**: tous les documents sont téléchargés depuis MongoDB * **web** -> **clsi**: la requête de compilation est envoyée à `clsi`, y compris : * le mode de synchronisation * un hachage de l’arborescence des fichiers -> l’« état du projet » * tous les documents avec leur contenu -> soumis à la limite de 7 Mo pour le corps de la requête * URL des fichiers binaires pour téléchargement séparé * **clsi**: vérifie l’état sur disque avec le mode de synchronisation et l’« état du projet » * c’est une synchronisation complète, donc l’état précédent sur disque peut être ignoré * **clsi**: nettoie le répertoire de compilation * **clsi**: écrit tous les documents dans le répertoire de compilation * **clsi**: écrit tous les fichiers binaires dans le répertoire de compilation * `clsi` copie les fichiers depuis un cache local propre à chaque projet * en cas d’échec du cache : * **clsi** -> **filestore**: télécharge les fichiers * **clsi**: écrit l’« état du projet » * **clsi**: s’assure que le conteneur Docker existe avec la configuration souhaitée * construit les options du conteneur, inclut la version de texlive * options de hachage * nom du conteneur : `project---` * **clsi**: démarre le conteneur et diffuse stdout/stderr en mémoire -> limite de 2 Mo * **clsi**: laisse un conteneur arrêté en place -> nettoyé après 24 h * **clsi**: écrit stdout/stderr sur le disque * **clsi**: copie les fichiers de sortie dans un répertoire de sortie unique * build-id composé de 8 octets aléatoires plus un horodatage à la précision de la ms * supprime tout sauf les 3 derniers dossiers de build (anonymes) / le dernier dossier de build (utilisateur connecté) * **clsi**: la compilation a échoué / a expiré * supprime le cache de compilation — il peut contenir des fichiers partiels / un cache corrompu * **éditeur**: télécharge output.log et output.pdf **Compilation — mode de synchronisation « incremental »** * **éditeur**: envoie une requête de compilation avec le mode de synchronisation défini sur « incremental » * **web** -> **document-updater**: récupère tous les documents depuis Redis * le hachage de l’« état du projet » est également stocké dans Redis * **web** envoie le hachage de l’arborescence des fichiers à `document-updater` et `document-updater` peut transformer la compilation incrémentale en compilation complète en cas de divergence * voir le processus de compilation tel qu’effectué lorsque l’éditeur a demandé une compilation « full » * **web** -> **clsi**: la requête de compilation est envoyée à `clsi`, y compris : * le mode de synchronisation * un hachage de l’arborescence des fichiers -> l’« état du projet » * tous les documents depuis Redis avec leur contenu -> soumis à la limite de 7 Mo pour le corps de la requête * aucun fichier binaire * **clsi**: vérifie l’état sur disque avec le mode de synchronisation et l’« état du projet » * c’est une synchronisation incrémentale, donc l’« état du projet » doit correspondre * en cas de divergence : répondre avec 409, laisser le web réessayer avec une synchronisation « full » * voir le processus de compilation tel qu’effectué lorsque l’éditeur a demandé une compilation « full » * **clsi**: écrit les documents mis à jour dans le répertoire de compilation * **clsi**: s’assure que le conteneur Docker existe avec la configuration souhaitée * construit les options du conteneur, inclut la version de texlive * options de hachage * nom du conteneur : `project---` * **clsi**: démarre le conteneur et diffuse stdout/stderr en mémoire -> limite de 2 Mo * **clsi**: laisse un conteneur arrêté en place -> nettoyé après 24 h * **clsi**: écrit stdout/stderr sur le disque * **clsi**: copie les fichiers de sortie dans un répertoire de sortie unique * build-id composé de 8 octets aléatoires plus un horodatage à la précision de la ms * supprime tout sauf les 3 derniers dossiers de build (anonymes) / le dernier dossier de build (utilisateur connecté) * **clsi**: la compilation a échoué / a expiré * supprime le cache de compilation — il peut contenir des fichiers partiels / un cache corrompu * **éditeur**: télécharge output.log et output.pdf **Compilation — basculement entre les modes** * **éditeur**: observe un échec de compilation, la prochaine compilation est une compilation « full » * **éditeur**: observe une compilation réussie, la prochaine compilation est une compilation « 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/fr/premiers-pas/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.