Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Verwenden von Lambda MicroVMS als Sandbox für Cursor Cloud Agents Sie können AWS Lambda MicroVMs als selbst gehostete Maschinen für Ihre Cursor Cloud Agents verwenden, sodass die Repositorys, die Ausführung der Tools und der Netzwerkzugriff in der von Ihnen kontrollierten Infrastruktur verbleiben. Der Cursor hostet den Agenten-Loop und das Modell. Auf der Lambda-MicroVM beansprucht der Worker Poolanforderungen und führt Tool-Aufrufe aus. Mit diesem Muster steuern Sie die Ausführungsumgebung — was auf dem Image installiert ist, welcher Netzwerkzugriff verfügbar ist und welche AWS Ressourcen die IAM-Rolle des Workers erreichen kann. Jede MicroVM ist eine Firecracker-isolated virtuelle Maschine mit einem Snapshot-basierten Start. Sie läuft bis zu 8 Stunden und wird beendet, wenn die Sitzung endet. Sitzungen haben niemals denselben Status. Mit dem serverlosen Betriebsmodell erhalten Sie die Sicherheitsgrenzen einer virtuellen Maschine — Sie müssen keine Cluster verwalten, keine ungenutzten Poolkapazitäten, für die Sie bezahlen müssen. Sie orchestrieren MicroVMs mit einer geplanten Controller-Lambda-Funktion, die auf ausstehende Poolanfragen reagiert. Weitere Informationen finden Sie in der [ Referenzvorlage „Self-hosted machines for Cursor Cloud Agents on AWS Lambda ](https://github.com/anysphere/aws-lambda-workers) microVMS ausführen“. ## Funktionsweise Ein geplanter Controller startet eine MicroVM pro ausstehender Pool-Anfrage: 1. Sie starten einen Cloud-Agenten am [ Cursor. com/agents](https://cursor.com/agents)gegen einen selbst gehosteten Computer. Die Anfrage bleibt ausstehend, bis sie von einem Mitarbeiter angefordert wird. 1. Die Lambda-Funktion des Controllers wird `agent worker controller --spawn ./spawn.sh` für ein fünfminütiges Abfragefenster für Server-Sent Ereignisse (SSE) ausgeführt. Wenn es eine passende Anfrage sieht, wird es ausgeführt. `spawn.sh` 1. `spawn.sh`ruft `RunMicrovm` (`aws lambda-microvms run-microvm`) auf und kehrt zurück, ohne zu warten. Es leitet die `CURSOR_*` Umgebung des Claims an den Gast weiter. `--run-hook-payload` 1. Der `/run` MicroVM-Hook (`hook.py`) wendet diese Nutzlast an und startet`entrypoint.sh`, was ausgeführt wird. `cursor-agent worker --pool … start` Der Worker führt Tool-Aufrufe in Ihrem Konto aus. 1. Wenn die Sitzung nach Ablauf des Release-Timeouts inaktiv ist, wird der Worker freigegeben und die MicroVM wird beendet. Ihr API-Schlüssel für das Cursor-Dienstkonto wird im AWS Systems Manager Parameter Store als gespeichert. `SecureString` Der Controller und die MicroVM lesen ihn zur Laufzeit durch`ssm:GetParameter`; der Schlüssel wird nie in das Image integriert. ## Die wichtigsten Eigenschaften | Eigenschaft | Vorteil | | --- | --- | | Isolierung von Feuerwerkskörpern | Hardware-virtualized Grenze pro Sitzung | | Snapshot-Start | Lambda stellt den Gast aus einem Firecracker-Snapshot Ihres Images wieder her | | IAM über die Ausführungsrolle | Der Gast verwendet kurzlebige Anmeldeinformationen von MicroVmExecutionRoleArn | | Dauer des Zustands | Jede MicroVM kann bis zu 8 Stunden () laufen --maximum-duration-in-seconds 28800 | | Pay-per-session | Sie zahlen für die Laufzeit einer MicroVM, nicht für ungenutzte Poolkapazität | ## Voraussetzungen + Ein AWS Konto mit aktivierten Lambda-MicroVMs sowie die Erlaubnis, Amazon S3, IAM und Systems Manager Parameter Store CloudFormation zu verwenden + Ein Cursor Enterprise-Konto + Ein Cursor-Team mit aktivierten selbst gehosteten Computern + Ein [ Dienstkonto-API-Schlüssel ](https://cursor.com/docs/account/enterprise/service-accounts) für Pool-Mitarbeiter + Die [AWS CLI ](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) wurde auf die neueste stabile Version aktualisiert, und Docker (das Bereitstellungsskript erstellt das Controller-Image) ## Bereitstellung der Referenzimplementierung ![Architekturdiagramm, das Self-hosted Cursor-Maschinen auf Lambda-MicroVMs zeigt](https://docs.aws.amazon.com/de_de/lambda/latest/dg/images/microvms-cursor-cloud-agents-architecture.png) Das [ anysphere/aws ](https://github.com/anysphere/aws-lambda-workers) -lambda-workers-Repository bietet eine minimale, funktionierende Bereitstellung. Sie umfasst: + Ein CloudFormation Stack (`cloudformation.yaml`): eine geplante Controller-Lambda-Funktion, eine EventBridge `rate(1 minute)` Regel, ein Amazon S3-Artefakt-Bucket, eine Warteschlange mit toten Buchstaben und die IAM-Rollen (,,) `MicroVmExecutionRole` `BuildRole` `SpawnRole` `ControllerRole` + Ein Controller-Image (`controller/Dockerfile`,`controller/handler.py`), das pro Aufruf ein SSE-Abfragefenster ausführt + Ein MicroVM-Image (`microvm-image/`:`Dockerfile`,,`hook.py`) `entrypoint.sh` + Ein Spawn-Hook (`spawn.sh`) und ein Deploy-Skript () `deploy.sh` Schritte zur Bereitstellung: 1. **Speichern Sie den API-Schlüssel für das Dienstkonto in SSM. ** ``` aws ssm put-parameter --type SecureString \ --name /cursor-lambda-workers/cursor-api-key \ --value "YOUR_SERVICE_ACCOUNT_KEY" ``` 1. **Stellen Sie den Stack bereit. **`deploy.sh`erstellt das Controller-Image und wird ausgeführt`aws cloudformation deploy`. ``` POOL_NAMES=default ./deploy.sh # POOL_NAMES=gpu,default ./deploy.sh # ALL_POOLS=true ./deploy.sh ``` 1. **Erstellen Sie das MicroVM-Image `microvm-image/` mithilfe ** der Stack-Ausgaben. Aktivieren Sie die `ready` und `validate` Image-Hooks und den `run` MicroVM-Hook, damit sie im Snapshot-Pfad erfasst werden. ``` BUCKET=$(aws cloudformation describe-stacks --stack-name cursor-lambda-workers \ --query "Stacks[0].Outputs[?OutputKey=='ArtifactBucketName'].OutputValue" --output text) BUILD_ROLE=$(aws cloudformation describe-stacks --stack-name cursor-lambda-workers \ --query "Stacks[0].Outputs[?OutputKey=='BuildRoleArn'].OutputValue" --output text) BASE=$(aws lambda-microvms list-managed-microvm-images --query "items[0].imageArn" --output text) ( cd microvm-image && zip -r /tmp/app.zip . ) aws s3 cp /tmp/app.zip "s3://${BUCKET}/app.zip" aws lambda-microvms create-microvm-image \ --code-artifact "uri=s3://${BUCKET}/app.zip" \ --name cursor-pool-worker \ --base-image-arn "${BASE}" \ --build-role-arn "${BUILD_ROLE}" \ --environment-variables "POOL_NAME=default,CURSOR_API_KEY_PARAM_NAME=/cursor-lambda-workers/cursor-api-key" \ --hooks '{"port":9000,"microvmImageHooks":{"ready":"ENABLED","readyTimeoutInSeconds":60,"validate":"ENABLED","validateTimeoutInSeconds":60},"microvmHooks":{"run":"ENABLED","runTimeoutInSeconds":60}}' ``` 1. **Starten Sie einen Cloud-Agenten ** vom [ Cursor aus. com/agents](https://cursor.com/agents)zur Überprüfung gegen den Pool (oder gegen ein Repository im repogebundenen Modus). Eine ausführliche Anleitung finden Sie in der Readme-Datei des Repositorys[. ](https://github.com/anysphere/aws-lambda-workers/blob/main/README.md) ## Pool- und Repo-Modi Achten Sie darauf, dass die Stacks `PoolNames` und die Images so `POOL_NAME` ausgerichtet sind, dass der Controller und der Gast denselben Pool bedienen. + **Any-repo Modus ** — Das Routing erfolgt nach Poolnamen, nicht nach Git Remote. Der Gast startet den Worker von einem Workspace ohne Git Remote aus, sodass der Worker `repo=` Labels weglässt. Benutzer wählen beim Starten ** eines Agenten die ** Gruppe und den Poolnamen Any Repo. + **Repo-bound Modus ** — Der Worker bedient eine oder mehrere bestimmte Git-Remotes. Entweder backen Sie den Klon in das MicroVM-Image ein oder legen Sie fest, `CURSOR_REPO_URL` dass er zu Beginn `entrypoint.sh` geklont wird. Der Worker leitet das `repo=` Label von Git Remote ab. Private Repositorys erfordern Git-Anmeldeinformationen für den Worker. ## Netzwerk Die Referenz verbindet `spawn.sh` den verwalteten `INTERNET_EGRESS` Connector, sodass der Worker die Steuerungsebene des Cursors erreichen kann, sowie `ALL_INGRESS` für die Image-Hooks. Outbound-only Worker erhalten nach dem Start niemals eingehendes HTTPS. Um private Ressourcen (z. B. eine Amazon Aurora-Datenbank oder einen ElastiCache Amazon-Cluster) zu erreichen oder Ihre eigenen Einschränkungen anzuwenden, fügen Sie beim Start anstelle von einen VPC-Connector für ausgehenden Datenverkehr hinzu. `INTERNET_EGRESS` Siehe [Arbeiten mit Netzwerkanschlüssen für ausgehenden Datenverkehr](microvms-networking.md#microvms-networking-connectors). ## Überwachen **Gastprotokolle ** — Die MicroVM-Protokolle gehen zu den Protokollen: CloudWatch ``` aws logs tail /aws/lambda/microvms/cursor-pool-worker --follow ``` **Controller-Protokolle ** — Die Controller-Lambda-Funktion protokolliert sich in. `/aws/lambda/cursor-lambda-workers-controller` **MicroVMS ausführen ** — Listet die laufenden MicroVMs für das Image auf: ``` aws lambda-microvms list-microvms --image-identifier cursor-pool-worker ``` ## Fehlerbehebung | Symptom | Ursache | | --- | --- | | Die Image-Erstellung schlägt fehl (S3 oder IAM) | Überprüfen Sie die Stack-Ausgaben ArtifactBucketName undBuildRoleArn; die Zip-Datei muss in diesem Bucket landen und die Build-Rolle muss sie lesen können | | MicroVM wird nicht gestartet | Der Controller läuft nicht oder kann nicht aufgerufen werdenRunMicrovm. Stellen Sie sicher, dass das cursor-pool-worker Image existiert und (bei einem lokalen Controller) davon ausgegangen SpawnRoleArn wird | | Worker beendet das Programm sofort | Der Gast fehlt CURSOR\_API\_KEY (SSM/cursor-lambda-workers/cursor-api-key), oder der /run Hook wurde nicht gestartet cursor-agent worker … start | | Exec format error auf node | Das Image hat die falsche CLI-Architektur installiert; MicroVMs hier sind aarch64 () arm64 | | Service-account Der Schlüssel wurde als ungültig gemeldet | CURSOR\_API\_ENDPOINT/CURSOR\_API\_URLwurden an den Gast weitergeleitet; diese müssen nicht konfiguriert sein und worker start verwendet daher den Standard-Auth-Host | | Das Image wurde erstellt, bevor Hooks aktiviert wurden | Erstellen Sie das MicroVM-Image neu readyvalidate, sodass sich die run Hooks im Snapshot-Pfad befinden | ## Zugehörige Ressourcen + [AWS Lambda-MicroVMs ](https://docs.aws.amazon.com/lambda/latest/dg/lambda-microvms-guide.html) + [RunMicrovmCLI-Referenz ](https://docs.aws.amazon.com/cli/latest/reference/lambda-microvms/run-microvm.html) + [Schnellstart für selbst gehostete Cursor-Maschinen ](https://cursor.com/docs/cloud-agent/bring-your-own-machine) + Referenzvorlage: -lambda-workers [ anysphere/aws ](https://github.com/anysphere/aws-lambda-workers)