Forum Linux.général Environnement de travail isolé mais persistant pour expériences et projets

Posté par  . Licence CC By‑SA.
Étiquettes :
4
25
oct.
2026

Comme beaucoup d'entre vous j'imagine, j'installe régulièrement de nouveaux outils pour les évaluer. Je travaille aussi sur différents projets qui nécessitent différents outils et qui n'ont pas besoin d'avoir accès aux données de mon environment principal. Le problème devient encore plus important avec les agents IA, qui potentiellement peuvent installer des outils, changer des réglages…
Je cherche une solution qui me permette d'isoler ces expériences et projets dans différents environnement et qui permette de:
1. les créer, démarrer, supprimer rapidement et de manière intuitive
2. partager facilement des dossiers entre l'hôte et l'invité
3. autoriser l'exécution d'applications graphiques (qui s'affichent idéalement dans l'environnement graphique de l'hôte)
4. ne pas avoir à installer l'OS (ou maintenir une image de référence)
5. dans l'idéal, enregistrer et restaurer leur état (snapshots)

Les machines virtuelles sont trop lourdes pour les points 1 et 4. Docker et Podman sont plutôt conçus pour des environnements éphémères. J'ai trouvé Bubbles, qui correspond plus à ce que je cherche, mais je n'ai pas encore trouvé comment réaliser le point 2.
Bubbles se compare à distroboxes et devcontainers, je vais jeter un œil aussi dessus, mais avant de passer plus de temps là-dessus, je serais ravi d'avoir votre conseils.

Ah, et un peu hors-sujet, mais je cherche aussi une solution sous Windows…

  • # qubes OS

    Posté par  . Évalué à 1 (+1/-1).

    Ça m'a fait penser à Qubes OS, je ne suis pas sûr que ça coche toutes les cases mais ça peut t'intéresser.

  • # mon avis de vieux

    Posté par  . Évalué à 8 (+5/-0).

    1. les créer, démarrer, supprimer rapidement et de manière intuitive
    2. partager facilement des dossiers entre l'hôte et l'invité
    3. autoriser l'exécution d'applications graphiques (qui s'affichent idéalement dans l'environnement graphique de l'hôte)
    4. ne pas avoir à installer l'OS (ou maintenir une image de référence)
    5. dans l'idéal, enregistrer et restaurer leur état (snapshots)

    les VMs ca reste le mieux, tu as tes 10 VMs pour ton environnement, avec une VM template voir linked clone (pour ne refaire que le master)

    tu fais un snapshot de tes VMs à un instant T, tu reviens en arriere quand tu as besoin

    et tu peux avoir une VM 'client' sur lequel tu installes le client graphique que tu vas tester

    Docker semble correspondre à une grande partie de la problematique (upgrade du logiciel sans toucher aux données/bases de données, etc) mais pas à la partie graphique

    un environnement mixte ?

    • tes serveurs à base de docker, avec un gros docker compose qui te regroupe tout ton environnement, un autre docker compose pour un autre evenironnement, docker down fichier.yaml, docker up autrefichier.yaml et tu as changé d'environnement

    • ton client en VM pour avoir l'interface graphique, des snapshots si besoin

  • # Incus + distrobox, et un conteneur dédié pour les agents

    Posté par  . Évalué à 4 (+4/-1).

    Bonjour,

    Pour ton cahier des charges, je regarderais du côté d'Incus (le fork communautaire de LXD) en complément de distrobox :

    • Création/suppression en quelques secondes : incus launch images:debian/12 test, et incus delete -f test. Pas d'OS à installer, les images sont téléchargées et mises en cache. On peut aussi lancer de vraies VM avec --vm si l'isolation d'un conteneur ne suffit pas.
    • Partage de dossiers : incus config device add test projets disk source=/home/toi/projets path=/projets. Attention aux UID/GID (shift=true ou un raw.idmap), c'est le point qui coince le plus souvent.
    • Snapshots : incus snapshot create test avant-install puis incus snapshot restore test avant-install. Instantané si ton stockage est en btrfs ou ZFS.
    • Applications graphiques : possible via un profil qui passe le socket Wayland/X11 de l'hôte et le GPU (la doc d'Incus et celle de LXD décrivent des profils « gui » prêts à l'emploi). C'est la partie la moins « clé en main ».

    Distrobox est plus simple pour le graphique (ça partage ton $HOME et ton affichage par défaut), mais l'isolation est faible : le conteneur voit tes données. Si tu veux justement que l'environnement n'ait pas accès à ton home, mieux vaut ne pas l'utiliser tel quel, ou lui donner un HOME séparé (--home).

    Sur ce que tu dis des agents IA : c'est précisément le cas où je ne leur laisserais pas ton environnement principal. Un conteneur ou une VM dédiée, avec un seul dossier de projet monté, pas de clés SSH ni de jetons de l'hôte, et un snapshot avant chaque session : si l'agent casse quelque chose, tu restaures.

    Sous Windows, l'équivalent le plus proche est WSL2 avec plusieurs distributions (wsl --import pour en créer à partir d'une archive, wsl --export pour sauvegarder), ou Windows Sandbox pour du jetable.

    Je suis curieux de savoir ce que tu retiens.

    • [^] # Re: Incus + distrobox, et un conteneur dédié pour les agents

      Posté par  . Évalué à 2 (+1/-0).

      Ah oui, ça correspond pas mal à ce que je cherche, merci! Pour les applications, je n'ai rien trouvé dans la doc, mais j'ai trouvé ça:
      https://discuss.linuxcontainers.org/t/incus-lxd-profile-for-gui-apps-wayland-x11-and-pulseaudio/18295/38

      Il faut bricoler un peu effectivement. Je me demande aussi les implications en terme de sécurité si les applications dans le système invité ont accès au socket Wayland. Mais j'imagine qu'on ne peut pas tout avoir.

      • [^] # Re: Incus + distrobox, et un conteneur dédié pour les agents

        Posté par  . Évalué à 1 (+0/-0).

        Bonne question : la sécurité est justement le point faible de ce montage. Voici ce que j'en sais, à vérifier selon ton compositeur :

        • Avec X11, c'est le pire cas : n'importe quel client connecté au socket peut lire les frappes clavier et capturer les autres fenêtres. Donner le socket X11 de l'hôte à un conteneur qui exécute un agent IA revient à lui donner un keylogger.
        • Avec Wayland, les clients sont isolés les uns des autres par conception (pas d'espionnage des fenêtres voisines comme sous X11). Mais le socket expose aussi les protocoles « étendus » de ton compositeur (capture d'écran, clavier virtuel, presse-papiers…) selon ce qu'il autorise sans demander. Ça dépend donc beaucoup du compositeur. Le protocole security-context (celui qu'utilise Flatpak) sert justement à restreindre ça pour un client sandboxé ; regarde s'il est géré chez toi.
        • Passer le GPU (/dev/dri) élargit aussi la surface d'attaque : le conteneur parle directement au pilote de l'hôte. Pour du jetable c'est acceptable, pour un agent qui exécute du code non relu, moins.

        Une piste intermédiaire : waypipe. L'application tourne dans le conteneur ou la VM et seul le flux Wayland est relayé jusqu'à l'hôte, sans que l'invité ait accès au socket lui-même. C'est un peu plus de bricolage, mais ça isole mieux. Et pour les agents IA : je les ferais tourner dans l'invité sans interface graphique tant que possible (ligne de commande + dossier de projet monté), l'interface graphique n'étant utile que pour les outils que tu évalues toi-même.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.