> ## Documentation Index > Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt > Use this file to discover all available pages before exploring further. # Orchestrierung > Maschinen bereitstellen und Worker automatisch ausführen, sobald Sitzungen in die Warteschlange eingehen 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](/de/onboard-devin/outposts/quickstart) — ein Orchestrator ist nicht erforderlich. Wenn Sie eine unterstützte Plattform verwenden, implementiert möglicherweise bereits eine [Integration](/de/onboard-devin/outposts#integrations) diesen Ablauf für Sie. Die vollständige API- und CLI-Referenz finden Sie in der [Referenz](/de/onboard-devin/outposts/reference). Verwenden Sie Kubernetes? [devin-outpost-k8s](https://github.com/CognitionAI/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`: ```bash theme={null} devin worker outpost create --platform --description "..." ``` 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](/de/onboard-devin/outposts/reference#outposts).
### 2. Fleet API auf wartende Sitzungen überwachen
Ihr Orchestrator listet ausstehende Sitzungen für die von ihm bedienten Outposts auf: ```bash theme={null} curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \ "https://api.devin.ai/opbeta/outposts/devins?outpost=&phase=pending" ``` 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: ```bash theme={null} curl -N -H "Authorization: Bearer $DEVIN_API_TOKEN" \ "https://api.devin.ai/opbeta/outposts/devins?outpost=&watch=true&cursor=" ``` 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](/de/onboard-devin/outposts/reference#list-queued-sessions) und [Änderungen überwachen](/de/onboard-devin/outposts/reference#watch-for-changes) 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: ```bash theme={null} curl -X POST -H "Authorization: Bearer $DEVIN_API_TOKEN" \ -H "Content-Type: application/json" \ -d '{"acceptor_id": "worker-1"}' \ "https://api.devin.ai/opbeta/outposts/devins/{session_id}/claim" ``` 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](/de/onboard-devin/outposts/reference#release-a-claim), 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: ```bash theme={null} cd /path/to/repos devin worker start --session= --outpost= --acceptor-id= ``` Ü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](/de/onboard-devin/outposts/reference#devin-worker-start)). 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: ```bash theme={null} curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \ "https://api.devin.ai/opbeta/outposts/devins?phase=claimed&acceptor_id=worker-1" ``` 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](/de/onboard-devin/outposts/reference#remote-binary-distribution) und im [Spawn-Contract](/de/onboard-devin/outposts/reference#spawn-contract) in der Referenz.