Zum Hauptinhalt springen
Ein Orchestrator überwacht die Outposts-API auf Sitzungen, die auf einem Outpost warten, stellt für jede davon eine VM oder einen Container bereit und startet darin den Worker. Auf dieser Seite wird die Orchestrierungsschleife beschrieben: die Warteschlange abfragen, 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 der Kurzanleitung — ein Orchestrator ist nicht erforderlich. Wenn Sie eine unterstützte Plattform verwenden, implementiert möglicherweise bereits eine Integration diese Schleife für Sie. Die vollständige API- und CLI-Referenz finden Sie in der Referenz.
Sie möchten Kubernetes verwenden? devin-outpost-k8s ist ein Open-Source-Operator, der diese Schleife für Sie implementiert: Er überwacht die Warteschlange, beansprucht ausstehende Sitzungen und führt jede davon als Worker-Pod auf einem zertifizierten Cluster (GKE, EKS, …) aus. Installieren Sie ihn mit dem zugehörigen Helm-Chart, anstatt Ihren eigenen Orchestrator zu entwickeln.

​
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 ihn mit devin worker outpost create:
Nach der Registrierung erscheint der Outpost in Devin Cloud beim Starten einer Sitzung als Maschinenoption (neben Ubuntu, Windows usw.). Sitzungen, die für ihn vorgesehen 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 von all seinen Organisationen genutzt). Siehe die Outposts-Endpunkte.

​
2. fleet API auf wartende Sitzungen überwachen

Ihr Orchestrator listet ausstehende Sitzungen für die von ihm bedienten Outposts auf:
Dann hält sie ihre Ansicht mit einem Server-Sent-Events-(SSE)-Watch aktuell und setzt am letzten Cursor der Liste fort:
Dies ist das List-then-Watch-Standardmuster im Kubernetes-Stil: Gehen Sie die Liste mit dem Response-Cursor seitenweise durch und starten Sie dann die Überwachung dort, wo die Liste endet. Speichern Sie den Cursor jedes Events, damit Sie die Verbindung wiederherstellen können, ohne Änderungen zu verpassen. Die Zustellung erfolgt mindestens einmal. Führen Sie Upserts daher anhand von metadata.session_id aus und tolerieren Sie Duplikate. Unter Sitzungen in der Warteschlange auflisten und Änderungen beobachten finden Sie Abfrageparameter, Antwortformate und die vollständige Semantik der Paginierung.

​
3. Vor der Bereitstellung beanspruchen

Bevor Sie eine Maschine für eine Sitzung starten, beanspruchen Sie sie atomisch, damit kein anderer Worker sie übernimmt. Übergeben Sie eine acceptor_id — eine selbst angegebene Identität für Ihren Worker:
Claims erfolgen atomar: Wenn ein anderer Worker die Sitzung zuerst beansprucht hat, erhalten Sie einen 409. Das Beanspruchen bedeutet, dass ein Worker innerhalb der vom Server zugewiesenen Claim-Frist (status.claim_deadline) bereit ist; abgelaufene Claims werden automatisch in die Warteschlange zurückgestellt. Wenn die Bereitstellung fehlschlägt, geben Sie den Claim frei, damit die Sitzung sofort in die Warteschlange zurückkehrt.

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

Stellen Sie für jede beanspruchte Sitzung eine VM oder einen Container aus Ihrem Image 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 beim Beanspruchen per API verwendet haben, und übergeben Sie das Token per --token oder DEVIN_OUTPOSTS_TOKEN (siehe die vollständige Flag-Liste). 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 das Fortsetzen unterstützt, 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 für status.session_status pending, running, suspended oder terminated an.

​
Planung ohne zentrale Koordination

Wenn Sie planen, mehr als ~16 Koordinatoren zu betreiben (Worker oder Orchestratoren, die ein Outpost überwachen und daraus Sitzungen beanspruchen), wenden Sie sich zuerst an Ihr Account-Team — größere Flotten erhöhen die Konkurrenz beim Beanspruchen und die Leselast der Warteschlange, und wir möchten sicherstellen, dass das Outpost dafür entsprechend ausgelegt ist.
Sie benötigen keinen zentralen Scheduler, um eine Flotte zu betreiben. Die Queue-API ist so ausgelegt, dass viele unabhängige Worker dasselbe Outpost bedienen können, ohne miteinander kommunizieren zu müssen:
  • Beanspruchungen sind der einzige Koordinationsmechanismus. Jeder Worker überwacht die Warteschlange unabhängig und versucht, ausstehende Sitzungen zu beanspruchen. Die Beanspruchung ist ein atomares Compare-and-Swap auf dem Server: Genau ein Worker gewinnt, und jeder Verlierer erhält einen 409 und macht einfach mit der nächsten ausstehenden Sitzung weiter. Ein Rennen um eine Beanspruchung zu verlieren, ist normal und kein Fehler.
  • Jeder Worker hat eine eigene Identität. Die acceptor_id beschränkt die Beanspruchungen, Verlängerungen und die Wiederherstellung nach Neustarts eines Workers ausschließlich auf diesen Worker. devin worker start erzeugt und speichert automatisch eine pro Maschine, sodass eine Flotte keine Identitätskonfiguration benötigt. Teilen Sie niemals eine Acceptor-ID (oder ein kopiertes Worker-Datenverzeichnis) zwischen Maschinen — kollidierende Worker stehlen sich gegenseitig ihre Beanspruchungen.
  • Fehler beheben sich selbst. Wenn ein Worker nach dem Beanspruchen ausfällt, läuft seine Beanspruchung mit Ablauf der Claim-Deadline ab und die Sitzung kehrt in die Warteschlange zurück, damit ein anderer Worker sie übernehmen kann. Es ist keine Zustandsverfolgung auf Flottenebene erforderlich.
Das bedeutet: Zum horizontalen Skalieren führen Sie den Worker einfach auf mehr Maschinen aus, die auf dasselbe Outpost verweisen: N Maschinen bedienen N gleichzeitige Sitzungen, und der Rest wartet als ausstehend.

​
Einen benutzerdefinierten Orchestrator erstellen

Alles, was devin worker start ausführt, 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 Devins statischer Distribution herunter und starten Sie sie selbst mit der dokumentierten Umgebung. Siehe Distribution der Remote-Binärdatei und die Spawn-Spezifikation in der Referenz.