> ## Documentation Index > Fetch the complete documentation index at: https://docs.devin.ai/llms.txt > Use this file to discover all available pages before exploring further. # Orchestrierung > Maschinen bereitstellen und Worker automatisch starten, wenn Sitzungen in die Warteschlange kommen 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](/de/cloud/outposts/quickstart) — ein Orchestrator ist nicht erforderlich. Wenn Sie eine unterstützte Plattform verwenden, implementiert möglicherweise bereits eine [Integration](/de/cloud/outposts/overview#integrations) diese Schleife für Sie. Die vollständige API- und CLI-Referenz finden Sie in der [Referenz](/de/cloud/outposts/reference). Sie möchten Kubernetes verwenden? [devin-outpost-k8s](https://github.com/CognitionAI/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`: ```bash theme={null} devin worker outpost create --platform --description "..." ``` 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](/de/cloud/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" ``` Dann hält sie ihre Ansicht mit einem Server-Sent-Events-(SSE)-Watch aktuell und setzt am letzten Cursor der Liste fort: ```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 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](/de/cloud/outposts/reference#list-queued-sessions) und [Änderungen beobachten](/de/cloud/outposts/reference#watch-for-changes) 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: ```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" ``` 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](/de/cloud/outposts/reference#release-a-claim), 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: ```bash theme={null} cd /path/to/repos devin worker start --session= --outpost= --acceptor-id= ``` Ü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](/de/cloud/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 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: ```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 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](/de/cloud/outposts/reference#remote-binary-distribution) und die [Spawn-Spezifikation](/de/cloud/outposts/reference#spawn-contract) in der Referenz.