Docker-Sandbox fuer harness.run

Agent-Harnesses in einer Docker-Sandbox ausfuehren.

Dagu kann einen Docker-Container fuer den gesamten DAG run oder nur fuer einen harness.run-Schritt starten. Dateisystem-Mounts, Environment, Netzwerkzugriff und Provider-Binary kommen alle aus der container-Konfiguration.

Docker-Dokumentation lesenCodex in Docker ausfuehren
Gemeinsame Docker-Sandbox
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

Root-level container teilt ein Dateisystem zwischen command- und harness-Schritten.

Step-level container isoliert einen harness-Versuch mit eigenem Image und Mounts.

Docker ist der Standard, wenn DAGU_CONTAINER_RUNTIME nicht gesetzt ist.

Die Alpine-Beispiele pruefen den Containerpfad ohne Modellaufruf.

01

Container-Scope

Nutze root-level container, wenn command- und harness-Schritte Dateien und Tools teilen sollen. Nutze step-level container, wenn nur ein Agent-Versuch ein Runner-Image, Workspace-Mount und Credential erhalten soll.

  • Root-level container gilt fuer geerbte command-Schritte und CLI-basierte harness.run-Schritte.
  • Ein step-level container ueberschreibt den root-level container fuer diesen Schritt.
  • Ein bestehender benannter Container kann angebunden werden; image mode ist fuer reproduzierbare Agent Runner klarer.
02

Netzwerkzugriff des Agents

Codex, Claude Code, OpenCode und aehnliche hosted Agent CLIs brauchen normalerweise ausgehenden Netzwerkzugriff auf Provider-APIs. Dagu setzt den Netzwerkmodus des Containers; Allow/Deny-Egress wird ausserhalb von Dagu mit Docker, Podman, Firewall oder Proxy konfiguriert.

  • Lasse container.network leer fuer das Docker-Default-Netzwerk, oder setze ein Custom Network mit dem benoetigten Egress.
  • Nutze Docker- oder Podman-Netzwerke, Firewall-Regeln oder Proxy-Umgebungsvariablen fuer Allow/Deny Policy.
  • `network: none` ist nur fuer Befehle geeignet, die niemals externe Dienste aufrufen; es ist kein nuetzliches Beispiel fuer hosted Agents.
03

Runtime-Environment

Setze den Container-Runtime auf dem Dagu-Prozess, der den Run ausfuehrt: server, scheduler, worker oder CLI. Docker ist Standard, und Docker-Variablen wie DOCKER_HOST bleiben wirksam.

  • DAGU_CONTAINER_RUNTIME=docker ist nur noetig, wenn die Auswahl explizit sein soll.
  • Wenn Dagu selbst in Docker laeuft, mounte den Docker-Socket nur in vertrauenswuerdige Dagu worker.
  • Der Agent Runner braucht keinen Docker-Socket, sofern der Agent nicht selbst Container verwalten soll.
04

Credentials

Credentials sind nicht implizit. Uebergib sie mit container.env oder mounte das Verzeichnis, das der Provider wirklich liest. Root-level Credentials sind fuer alle geerbten Schritte im gemeinsamen Container lesbar.

Provider-Beispiele

Docker-Sandbox fuer harness.run

Codex in Docker

Baue einen Codex Runner aus dem OpenAI-Base-Image und nutze CODEX_HOME oder CODEX_API_KEY.

Claude Code in Docker

Installiere Claude Code in einem Node-Image und uebergib Anthropic-Credentials an einen Schritt.

OpenCode in Docker

Installiere OpenCode, mounte sein Auth-Verzeichnis und starte es ueber harness.run.

Eigene CLI in Docker

Definiere einen Custom Provider fuer eine interne CLI oder ein Wrapper-Script.

Referenzen

Dagu Docker sandbox documentationDagu harness sandbox overview