Docker Compose avec sandbox agent

Stib peut lancer chaque session éligible dans un conteneur agent éphémère. Cela sépare le processus agent de la base serveur et des dépôts non montés dans ce conteneur.

C’est un déploiement avancé. L’isolation réduit les accès accidentels mais ne rend pas du code arbitraire sans risque : l’agent écrit dans le projet choisi, utilise les identifiants configurés, joint les réseaux autorisés et rappelle Stib.

Prérequis

Stib Server s’exécute lui-même sous Docker.
Il joint une API Docker via DOCKER_HOST ou /var/run/docker.sock.
STIB_AGENT_IMAGE désigne une image runtime compatible.
Les dossiers projet sont montés dans le serveur au même chemin absolu hôte utilisé pour créer les conteneurs agent.
Les tags des images serveur et agent utilisent la même version de protocole Stib.

Le serveur expose sa capacité dans les paramètres projet. Un serveur natif ou un conteneur sans API Docker ne peut activer le toggle.

Accès plus sûr au socket

Préférez un proxy dédié au montage direct du socket. Il permet encore de créer/supprimer des conteneurs et reste donc un contrôle puissant. Gardez-le sur un réseau privé et ne publiez jamais son port.

yaml

services:
  docker-socket-proxy:
    image: tecnativa/docker-socket-proxy:0.3.0
    restart: unless-stopped
    privileged: true
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      CONTAINERS: 1
      IMAGES: 1
      POST: 1
      DELETE: 1
      ALLOW_START: 1
      ALLOW_STOP: 1
      NETWORKS: 0
      VOLUMES: 0
      EXEC: 0
    networks:
      - stib-control

  stib:
    image: enixion/stib-server:${STIB_VERSION}
    restart: unless-stopped
    depends_on:
      - docker-socket-proxy
    ports:
      - "50505:50505"
    volumes:
      - stib-data:/data
      # Remplacez ce chemin en gardant les deux côtés identiques.
      - /srv/stib-projects:/srv/stib-projects:rw
    environment:
      RUST_LOG: info
      DOCKER_HOST: tcp://docker-socket-proxy:2375
      STIB_AGENT_API_URL: http://host.docker.internal:50505
      STIB_AGENT_IMAGE: enixion/stib-agent-runtime:${STIB_VERSION}
    extra_hosts:
      - "host.docker.internal:host-gateway"
    networks:
      - stib-control
      - default
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:50505/api/health"]
      interval: 30s
      timeout: 5s
      retries: 3

networks:
  stib-control:
    internal: true

volumes:
  stib-data:

Définissez STIB_VERSION dans .env avec une version publiée pour les deux images. Tirez les deux avant mise à jour :

bash

docker compose pull
docker compose up -d

Activer un projet

Démarrez la stack et vérifiez /api/health.
Ouvrez Paramètres du projet → Général → Environnement.
Confirmez que le dépôt est accessible et le toggle Sandbox actif.
Activez-le sur un projet de test.
Lancez une carte inoffensive et inspectez logs serveur et docker ps.

N’activez pas tant que le chemin serveur n’est pas le chemin hôte attendu. Un mauvais montage peut n’exposer aucun fichier — ou les mauvais fichiers.

URL de callback

STIB_AGENT_API_URL sélectionne la route privée utilisée par le runtime agent pour rappeler le serveur. Le processus fournisseur reçoit ensuite cette route sous le nom STIB_API_URL, qui reste le contrat du CLI. L’origine publique configurée du serveur n’est jamais réutilisée implicitement. Sous Linux, host-gateway permet de résoudre host.docker.internal. Avec une autre topologie, choisissez une origine interne joignable des conteneurs agent sans l’exposer inutilement à Internet.

Les tokens de callback restent limités aux réseaux loopback/privés. N’utilisez pas STIB_ALLOW_REMOTE_CALLBACK pour les exposer à un réseau non fiable.

Vérifier l’isolation

Sur un projet jetable, vérifiez :

lecture/écriture limitée aux chemins prévus pour le mode de colonne ;
absence d’un dépôt tiers et du volume serveur /data ;
callback et événements de conversation fonctionnels ;
suppression du conteneur après annulation ;
propriétaire des fichiers utilisable sur l’hôte ;
réconciliation sûre des orphelins après interruption.

L’image agent configurée détermine les exécutables fournisseurs disponibles dans le sandbox. Voir un identifiant dans Stib ne suffit pas si son runtime manque dans l’image.

Précautions d’exploitation

Sauvegardez Stib avant de mettre à jour ensemble serveur et agent.
Épinglez les versions en production ; ne laissez pas une image avancer seule.
Surveillez orphelins et disque sans supprimer les conteneurs d’une autre instance.
Considérez proxy socket, dépôts montés, identifiants et origine de callback comme sensibles.

Suite : Docker Compose et Configuration du serveur.

Docker Compose avec sandbox agent ​

Prérequis ​

Accès plus sûr au socket ​

Activer un projet ​

URL de callback ​

Vérifier l’isolation ​