Sandbox Docker pour harness.run

Executer les harness d'agents dans une sandbox Docker.

Dagu peut demarrer un conteneur Docker pour tout le DAG run ou seulement pour une etape harness.run. Les montages, variables d'environnement, acces reseau et binaires provider viennent tous de la configuration container.

Lire la doc DockerExecuter Codex dans Docker
Sandbox Docker partagee
type: graph

container:
  image: alpine:3.20
  pull_policy: missing
  working_dir: /workspace
  volumes:
    - .:/workspace
  env:
    - SMOKE_TOKEN=container-env-ok

harnesses:
  shell:
    binary: sh
    prefix_args:
      - -c
    prompt_mode: arg

steps:
  - id: write_file
    run: echo "from command step" > shared.txt

  - id: read_file
    action: harness.run
    with:
      provider: shell
      prompt: |
        set -eu
        cat shared.txt
        echo "SMOKE_TOKEN=$SMOKE_TOKEN"
        cat /etc/alpine-release

Le container racine partage un systeme de fichiers entre etapes command et harness.

Le container d'etape isole une tentative harness avec son image et ses montages.

Docker est le runtime par defaut quand DAGU_CONTAINER_RUNTIME n'est pas defini.

Les exemples Alpine verifient le chemin conteneur sans appeler de modele.

01

Portee du conteneur

Utilisez un container racine quand les etapes command et harness doivent partager fichiers et outils. Utilisez un container d'etape quand une seule tentative agent doit recevoir une image runner, un workspace et un credential.

  • Le container racine s'applique aux etapes command heritees et aux harness.run bases sur une CLI.
  • Un container d'etape remplace le container racine pour cette etape.
  • Un conteneur nomme existant peut etre attache, mais le mode image est plus reproductible pour les runners d'agents.
02

Acces reseau de l'agent

Codex, Claude Code, OpenCode et les CLI d'agents heberges similaires ont generalement besoin d'un acces reseau sortant vers les API provider. Dagu configure le mode reseau du conteneur; les regles d'egress se configurent hors de Dagu avec Docker, Podman, firewall ou proxy.

  • Laissez container.network vide pour le reseau Docker par defaut, ou indiquez un reseau custom qui a l'egress requis.
  • Utilisez les reseaux Docker ou Podman, les regles firewall ou les variables de proxy pour la politique allow/deny.
  • `network: none` sert seulement aux commandes qui n'appellent aucun service externe; ce n'est pas un exemple utile pour un agent heberge.
03

Environnement runtime

Configurez le runtime conteneur sur le processus Dagu qui execute le run: server, scheduler, worker ou CLI. Docker est choisi par defaut, et les variables Docker standard comme DOCKER_HOST restent valables.

  • DAGU_CONTAINER_RUNTIME=docker sert seulement a rendre le choix explicite.
  • Si Dagu tourne lui-meme dans Docker, ne montez le socket Docker que dans des workers Dagu de confiance.
  • Le runner de l'agent n'a pas besoin du socket Docker sauf si l'agent doit gerer des conteneurs.
04

Credentials

Les credentials ne sont pas implicites. Ajoutez-les avec container.env ou montez le repertoire lu par le provider. Les credentials au niveau racine sont lisibles par toutes les etapes heritees dans le conteneur partage.

Exemples provider

Sandbox Docker pour harness.run

Codex dans Docker

Construire un runner Codex depuis l'image OpenAI et reutiliser CODEX_HOME ou CODEX_API_KEY.

Claude Code dans Docker

Installer Claude Code dans une image Node et passer les credentials Anthropic a une seule etape.

OpenCode dans Docker

Installer OpenCode, monter son repertoire d'auth et l'executer via harness.run.

CLI personnalisee dans Docker

Definir un provider personnalise pour une CLI interne ou un script wrapper.

References

Dagu Docker sandbox documentationDagu harness sandbox overview