> 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/configuration/overleaf-toolkit/compilations-en-bac-a-sable.md). # Compilations en bac à sable Overleaf Pro inclut l’option d’exécuter les compilations dans un environnement sandbox sécurisé pour la sécurité en entreprise. Il le fait en exécutant chaque projet dans son propre environnement Docker sécurisé. ### Sécurité améliorée Les compilations en sandbox sont l’approche recommandée pour Server Pro, car de nombreux documents LaTeX nécessitent ou ont la capacité d’exécuter des commandes shell arbitraires dans le cadre du processus de compilation PDF. Si vous utilisez les compilations en sandbox, chaque compilation s’exécute dans un conteneur Docker séparé aux capacités limitées, qui n’est partagé avec aucun autre utilisateur ni projet et n’a aucun accès à des ressources externes telles que le réseau hôte. {% hint style="warning" %} Si vous essayez d’exécuter Overleaf Pro **sans** compilations en sandbox, la compilation s’exécute aux côtés d’autres compilations concurrentes à l’intérieur du conteneur Docker principal et les utilisateurs ont un accès complet en lecture et en écriture aux `conteneur sharelatex.` ressources du conteneur (système de fichiers, réseau et variables d’environnement) lors de l’exécution des compilations LaTeX. {% endhint %} ### Gestion des paquets plus simple Pour éviter d’installer manuellement des paquets, nous recommandons d’activer les compilations en sandbox. Il s’agit d’un paramètre configurable dans Server Pro qui donnera à vos utilisateurs accès au même environnement TeX Live que sur overleaf.com, mais au sein de votre propre installation sur site. Les images TeX Live utilisées par les compilations en sandbox contiennent les paquets et polices les plus populaires, testés avec nos modèles de galerie, garantissant une compatibilité maximale avec les projets sur site. L’activation des compilations en sandbox vous permet de configurer quelles versions de TeX Live les utilisateurs peuvent choisir dans leur projet, ainsi que de définir une version d’image TeX Live par défaut pour les nouveaux projets. {% hint style="info" %} Si vous essayez d’exécuter Overleaf Pro sans compilations en sandbox, votre instance utilisera par défaut une version de schéma de base de TeX Live pour les compilations. Cette version de base est légère et ne contient qu’un sous-ensemble très limité de paquets LaTeX, ce qui entraînera très probablement des erreurs de paquets manquants pour vos utilisateurs, en particulier s’ils essaient d’utiliser des modèles prédéfinis. {% endhint %} Comme Overleaf Pro a été conçu pour fonctionner hors ligne, il n’existe pas de moyen automatisé d’intégrer les modèles de galerie d’overleaf.com dans votre installation sur site ; il est toutefois possible de le faire manuellement, modèle par modèle. Pour plus d’informations sur son fonctionnement, veuillez consulter notre guide sur le transfert des modèles depuis overleaf.com : [/pages/9ad9cb3b4e4996ea67502a12de7c15ff7797ccfa#transferring-templates-from-overleaf.com](https://overleaf-pro.ayaka.space/on-premises/fr/configuration/overleaf-toolkit/pages/9ad9cb3b4e4996ea67502a12de7c15ff7797ccfa#transferring-templates-from-overleaf.com "mention"). {% hint style="info" %} Les compilations en sandbox nécessitent que le `conteneur sharelatex.` conteneur ait accès au socket Docker sur la machine hôte (via un montage bind) afin qu’il puisse gérer ces conteneurs de compilation frères. {% endhint %} ## Fonctionnement Lorsque les compilations en sandbox sont activées, le socket Docker sera monté depuis la machine hôte dans le `conteneur sharelatex.` conteneur, afin que le service de compilation dans le conteneur puisse créer de nouveaux conteneurs Docker sur l’hôte. Ensuite, pour chaque exécution du compilateur dans chaque projet, le service de compilation LaTeX (CLSI) fera ce qui suit : * Écrire les fichiers du projet dans un emplacement à l’intérieur du `OVERLEAF_DATA_PATH`. * Utiliser le socket Docker monté pour créer un nouveau `texlive` conteneur pour l’exécution de la compilation. * Faire en sorte que le `texlive` conteneur lise les données du projet depuis l’emplacement sous `OVERLEAF_DATA_PATH`. * Compiler le projet à l’intérieur du `texlive` conteneur. ### Activation des compilations en sandbox #### Pour les utilisateurs du Toolkit Pour activer les compilations en sandbox (également appelées conteneurs frères), définissez les options de configuration suivantes dans `overleaf-toolkit/config/overleaf.rc`: {% code title="config/overleaf.rc" %} ```dotenv SERVER_PRO=true SIBLING_CONTAINERS_ENABLED=true ``` {% endcode %} #### Pour les utilisateurs de Docker Compose {% hint style="danger" %} À partir d’Overleaf CE/Server Pro `5.0.3` les variables d'environnement ont été renommées de `SHARELATEX_*` à `OVERLEAF_*`. {% endhint %} Si vous utilisez une `4.x` version (ou antérieure), veuillez vous assurer que les variables sont préfixées en conséquence (par ex. `SHARELATEX_MONGO_URL` au lieu 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"
            #...
        #...
### Modifier l’image TexLive {% hint style="info" %} Pour les utilisateurs de Chine continentale, vous pouvez utiliser `ghcr.nju.edu.cn` pour accélérer votre téléchargement. {% endhint %} Overleaf Pro utilise trois variables d’environnement pour déterminer quelles images TeX Live utiliser pour les compilations en sandbox : * `TEX_LIVE_DOCKER_IMAGE` **(requis),** L’image TeX Live par défaut utilisée pour compiler les nouveaux projets. Cette image doit être incluse dans `ALL_TEX_LIVE_DOCKER_IMAGES`. * `ALL_TEX_LIVE_DOCKER_IMAGE_NAMES` **(requis),** Une liste séparée par des virgules de noms conviviaux pour les images, utilisée pour les options du frontend. * `ALL_TEX_LIVE_DOCKER_IMAGES` **(requis),** Une liste séparée par des virgules d’images TeX Live à utiliser. Si Overleaf Toolkit est utilisé pour le déploiement, ces images seront téléchargées ou mises à jour. Pour ignorer le téléchargement, définissez `SIBLING_CONTAINERS_PULL=false` dans `config/overleaf.rc`. Lors du démarrage de votre instance Overleaf Pro à l’aide de la `bin/up` commande, le Toolkit récupérera automatiquement toutes les images répertoriées dans `ALL_TEX_LIVE_DOCKER_IMAGES`. Voici un exemple dans lequel nous définissons TeX Live 2025 par défaut pour les nouveaux projets, tout en conservant 2024 pour les projets existants. {% code title="config/variables.env" overflow="wrap" %} ```dotenv ALL_TEX_LIVE_DOCKER_IMAGES=ghcr.io/ayaka-notes/texlive-full:2025.1, ghcr.io/ayaka-notes/texlive-full:2024.1 ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=Texlive 2025, Texlive 2024 TEX_LIVE_DOCKER_IMAGE=ghcr.io/ayaka-notes/texlive-full:2025.1 ``` {% endcode %} {% hint style="danger" %} Il est fortement recommandé de définir **au moins 2 images texlive-full**. Pour une raison détaillée, voir [#known-issues](#known-issues "mention") {% endhint %} ### Images TeX Live disponibles Il s’agit d’une série d’images TeX Live spécialement optimisées pour Overleaf, et qui peuvent aussi être ajoutées à `TEX_LIVE_DOCKER_IMAGE` et `ALL_TEX_LIVE_DOCKER_IMAGES`: * `ghcr.io/ayaka-notes/texlive-full:2025.1` (également `latest` tag) * `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" %} Il existe un schéma strict concernant la manière dont les images **doivent** être étiquetées (l’expression régulière suivante s’applique `^[0-9]+.[0-9]+` , pour laquelle le premier nombre détermine l’année de TeX Live et le second la version du correctif). {% endhint %} ### Puis-je utiliser un autre registre d’images > Certaines personnes peuvent se demander si je peux remplacer `ghcr.io` par un autre site miroir, ou passer à une autre image texlive depuis Docker Hub ? Non, nous ne le recommandons pas, car la configuration est relativement compliquée. Si vous téléchargez depuis un site miroir, vous pouvez renommer votre image en `ghcr.io/ayaka-notes/texlive-full`. Mais, si vous voulez vraiment utiliser votre propre registre d’images, veuillez ajouter : {% code title="config/variables.env" overflow="wrap" %} ```dotenv IMAGE_ROOT=hub.your.com/your-repo ``` {% endcode %} Ensuite, vous devez vous assurer que toutes les images texlive se trouvent dans `your-repo`, comme * `hub.your.com/your-repo/texlive-full:2025.1` * `hub.your.com/your-repo/texlive-full:2024.1` Pour des informations détaillées, lisez le code source ci-dessous afin de comprendre comment nous analysons votre variable d’environnement : {% code title="sandboxed-compiles/index.mjs" overflow="wrap" expandable="true" %} ```mjs if (process.env.SANDBOXED_COMPILES === 'true') { // Définir l’image racine par défaut si elle n’est pas fournie let imageRootPath = process.env.IMAGE_ROOT || "ghcr.io/ayaka-notes"; // Exporter imageRoot vers Settings Settings.imageRoot = imageRootPath // allowedImageNames devrait être : // [ // { 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], })) // À la fin, imageName sera assemblé avec imageRoot pour former le chemin complet de l’image // Le nom complet sera du type : ghcr.io/ayaka-notes/texlive-2023:latest // Définir le nom d’image par défaut s’il n’est pas fourni if(!process.env.TEX_LIVE_DOCKER_IMAGE) { process.env.TEX_LIVE_DOCKER_IMAGE = imageRootPath + "/" + Settings.allowedImageNames[0].imageName } // Exporter currentImageName vers Settings // Il s’agit du nom d’image des projets nouvellement créés Settings.currentImageName = process.env.TEX_LIVE_DOCKER_IMAGE } ``` {% endcode %} ### Problèmes connus > Utilisation `6.0.1-ext-v3.3`, j’ai ces paramètres dans `variables.env`: > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=texlive/texlive:latest-full > ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texlive:latest-full > ``` > > Cela fonctionne correctement avec `texlive/texlive:latest-full`. Cependant, j’ai récupéré une autre image texlive `danteev/texlive:2025-10-15` et j’ai modifié ces deux variables pour utiliser le nouveau nom d’image, mais cela ne fonctionne pas : > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=danteev/texlive:2025-10-15 > ALL_TEX_LIVE_DOCKER_IMAGES=danteev/texlive:2025-10-15 > ``` > > Dans les journaux, je vois ce qui suit : > > {% code overflow="wrap" %} > > ``` > {"name":"clsi","level":50,"err":{"message":"(HTTP code 404) no such container - No such image: texlive/texlive:latest-full ","name":"Error","stack":"Error: (HTTP code 404) no such container - No such image: texlive/texlive:latest-full ... > ``` > > {% endcode %} > > Il semble que les paramètres mis à jour dans `variables.env` ne prennent pas effet. La compilation essaie toujours d’exécuter l’ `texlive/texlive:latest-full` image, et non la nouvelle image. > > J’ai essayé de redémarrer, de supprimer les conteneurs et de relancer, mais le problème reste le même. > > Des solutions ? En raison de certaines limitations techniques, si vous ne configurez qu’une seule image TeXLive Docker, comme `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 ``` Et après avoir fait fonctionner votre instance Overleaf pendant un certain temps, vous pourriez vouloir modifier l’image TeXLive en `texlive-fullB:latest`. Vous constaterez alors que vos utilisateurs ne peuvent plus compiler tous les projets. ``` ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texliveA:latest-full ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=TeXLiveA TEX_LIVE_DOCKER_IMAGE=texlive/texliveA:latest-full ``` Cela est dû au fait que le nom de l’image TeXLive-Full (pour les compilations en sandbox) de chaque projet est conservé dans la base de données. *Ce n’est que lorsque l’utilisateur change la version TeXLive de son projet, par exemple de 2024 à 2025, que le nom de l’image est modifié dans la base de données*. Lorsque CLSI compile un projet, il utilise le nom de l’image conteneur trouvé dans la base de données pour compiler directement le projet. Si vous ne fournissez qu’une seule image Docker, les utilisateurs ne pourront pas modifier l’image utilisée pour compiler le projet. Dans ce cas, vous devez écrire un script pour **modifier manuellement** l’image TeXLive pour tous les projets des utilisateurs dans mongoDB. ### Débogage Exécutez la commande suivante pour vérifier le journal de clsi depuis le 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://overleaf-pro.ayaka.space/on-premises/fr/configuration/overleaf-toolkit/compilations-en-bac-a-sable.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.