Zum Hauptinhalt springen
Ein Orchestrator überwacht die Outposts-API auf Sitzungen, die auf einem Outpost warten, stellt für jede eine VM oder einen Container bereit und startet darin den Worker. Diese Seite beschreibt den Orchestrierungsablauf: die Warteschlange pollen, Sitzungen beanspruchen, Worker ausführen und Maschinen wieder herunterfahren. Wenn Sie Sitzungen nur von einer Maschine aus bedienen möchten, die Sie bereits haben, beginnen Sie mit dem Schnellstart — ein Orchestrator ist nicht erforderlich. Wenn Sie eine unterstützte Plattform verwenden, implementiert möglicherweise bereits eine Integration diesen Ablauf für Sie. Die vollständige API- und CLI-Referenz finden Sie in der Referenz.
Verwenden Sie Kubernetes? devin-outpost-k8s ist ein Open-Source-Operator, der diesen Ablauf für Sie implementiert: Er überwacht die Warteschlange, beansprucht ausstehende Sitzungen und führt jede davon als Worker-Pod auf einem beliebigen zertifizierten Cluster (GKE, EKS, …) aus. Installieren Sie ihn über das Helm-Chart, anstatt einen eigenen Orchestrator zu erstellen.

​
Der grundlegende Ablauf

​
1. Einen outpost registrieren

Ein outpost ist eine benannte Warteschlange für Sitzungen, die von vielen Workern auf Ihrer Infrastruktur bedient wird (zum Beispiel rhel, gpu-h200 oder my-outpost). Erstellen Sie einen mit devin worker outpost create:
Sobald er registriert ist, erscheint der Outpost beim Starten einer Sitzung in Devin Cloud als Maschinenoption (neben Ubuntu, Windows usw.). Sitzungen, die für ihn bestimmt sind, warten in seiner Warteschlange, bis ein Worker sie beansprucht.
In der fleet API werden Outposts als outposts-Ressourcen dargestellt, die auf Ihr Konto beschränkt sind (gemeinsam für alle zugehörigen Organisationen). Siehe die Outposts-Endpunkte.

​
2. Fleet API auf wartende Sitzungen überwachen

Ihr Orchestrator listet ausstehende Sitzungen für die von ihm bedienten Outposts auf:
Anschließend hält es seine Ansicht über eine Server-Sent-Events-(SSE)-Überwachung aktuell und nimmt die Überwachung ab dem letzten Cursor der Liste wieder auf:
Dies ist das Kubernetes-übliche List-then-watch-Muster: Blättern Sie die Liste mit dem Cursor aus der Antwort durch und starten Sie dann dort eine Überwachung, wo die Liste aufgehört hat. Speichern Sie dabei den Cursor jedes Ereignisses, damit Sie die Verbindung wiederherstellen können, ohne Änderungen zu verpassen. Die Zustellung erfolgt mindestens einmal, führen Sie daher Upserts anhand von metadata.session_id aus und tolerieren Sie Duplikate. Siehe Wartende Sitzungen auflisten und Änderungen überwachen für Abfrageparameter, Antwortformate und die vollständige Paginierungssemantik.

​
3. Vor der Bereitstellung beanspruchen

Bevor Sie eine Maschine für eine Sitzung starten, beanspruchen Sie sie atomar, damit kein anderer Worker sie übernimmt. Übergeben Sie eine acceptor_id — eine von Ihrem Worker selbst gemeldete Identität:
Das Beanspruchen erfolgt atomar: Wenn ein anderer Worker die Sitzung bereits beansprucht hat, erhältst du einen 409. Das Beanspruchen stellt sicher, dass innerhalb der vom Server zugewiesenen Claim-Frist (status.claim_deadline) ein Worker bereit ist; abgelaufene Beanspruchungen kehren automatisch in die Warteschlange zurück. Wenn die Bereitstellung fehlschlägt, gib die Beanspruchung frei, damit die Sitzung sofort in die Warteschlange zurückkehrt.

​
4. Eine Maschine bereitstellen und den Worker ausführen

Stellen Sie für jede reservierte Sitzung aus Ihrem Image eine VM oder einen Container bereit. Führen Sie darin den Worker aus dem Verzeichnis aus, in dem die Repositories der Sitzung bereits ausgecheckt wurden:
Übergeben Sie dieselbe --acceptor-id, die Sie für das Beanspruchen per API verwendet haben, und geben Sie das Token über --token oder DEVIN_OUTPOSTS_TOKEN an (siehe die vollständige Liste der Flags). Der Worker verbindet sich mit Devins Cloud, markiert die Sitzung als bereit und beginnt mit der Ausführung von Tool-Aufrufen.

​
5. Beenden Sie die Maschine, wenn der Worker beendet ist

Wenn devin worker start beendet ist, ist die Sitzung vorbei (oder wurde angehalten). Beenden Sie die VM oder den Container. Wenn Ihr Outpost fortsetzbar ist, erstellen Sie vor dem Beenden einen Snapshot der Maschine, damit Sie sie wiederherstellen können, falls die Sitzung fortgesetzt wird. Ihr Orchestrator kann seine beanspruchten Sitzungen und deren Zustände verfolgen:
Jeder Eintrag gibt einen status.session_status von pending, running, suspended oder terminated an.

​
Planung ohne zentrale Koordination

Wenn Sie planen, mehr als ~16 Koordinatoren (Worker oder Orchestratoren, die einen Outpost überwachen und daraus Sitzungen beanspruchen) zu betreiben, wenden Sie sich zuerst an Ihr Account-Team — größere Flotten verstärken die Konkurrenz um Beanspruchungen und die Leselast der Warteschlange. Wir möchten sicherstellen, dass der Outpost dafür passend bereitgestellt ist.
Sie brauchen keinen zentralen Scheduler, um eine Flotte zu betreiben. Die Queue-API ist so ausgelegt, dass viele unabhängige Worker denselben Outpost bedienen können, ohne miteinander zu kommunizieren:
  • Beanspruchungen sind der einzige Koordinationsmechanismus. Jeder Worker überwacht die Warteschlange unabhängig und versucht, ausstehende Sitzungen zu beanspruchen. Eine Beanspruchung ist ein atomares Compare-and-Swap auf dem Server: Genau ein Worker gewinnt, und alle anderen erhalten einen 409 und wechseln einfach zur nächsten ausstehenden Sitzung. Einen Wettlauf beim Beanspruchen zu verlieren, ist normal und kein Fehler.
  • Jeder Worker hat seine eigene Identität. Die acceptor_id begrenzt die Beanspruchungen, Verlängerungen und die Wiederherstellung nach einem Neustart auf genau diesen Worker. devin worker start erzeugt und speichert automatisch eine pro Maschine, sodass für eine Flotte keine Identitätskonfiguration erforderlich ist. Verwenden Sie niemals dieselbe Acceptor-ID (oder ein kopiertes Worker-Datenverzeichnis) auf mehreren Maschinen — kollidierende Worker stehlen sich gegenseitig die Beanspruchungen.
  • Fehler heilen sich selbst. Wenn ein Worker nach dem Beanspruchen ausfällt, läuft seine Beanspruchung mit Ablauf der Claim-Frist ab und die Sitzung kehrt in die Warteschlange zurück, damit ein anderer Worker sie übernehmen kann. Es ist kein fleetweites Health-Tracking erforderlich.
Das bedeutet: Horizontal zu skalieren ist so einfach, wie den Worker auf mehr Maschinen auszuführen, die auf denselben Outpost verweisen: N Maschinen bedienen N gleichzeitige Sitzungen, und der Rest wartet ausstehend in der Warteschlange.

​
Einen benutzerdefinierten Orchestrator erstellen

Alles, was devin worker start macht, ist direkt über die fleet API verfügbar, sodass Sie die CLI vollständig ersetzen können: Laden Sie die devin-remote-Binärdatei aus der statischen Distribution von Devin herunter und starten Sie sie selbst mit den dokumentierten Umgebungsvariablen. Weitere Informationen finden Sie unter Verteilung der Remote-Binärdatei und im Spawn-Contract in der Referenz.