Utilizzo di Lambda MicroVMS come sandbox per gli agenti Cursor Cloud

Puoi utilizzare AWS Lambda MicroVMS come macchine ospitate autonomamente per i tuoi Cursor Cloud Agent, mantenendo i repository, l'esecuzione degli strumenti e l'accesso alla rete nell'infrastruttura che controlli. Cursor ospita il ciclo e il modello degli agenti; Lambda MicroVM è il luogo in cui il lavoratore raccoglie le richieste del pool ed esegue le chiamate agli strumenti. Con questo schema, controlli l'ambiente di esecuzione: cosa è installato nell'immagine, quale accesso alla rete è disponibile e quali AWS risorse può raggiungere il ruolo IAM del lavoratore.

Ogni MicroVM è una macchina Firecracker-isolated virtuale con avvio basato su istantanee, funziona per un massimo di 8 ore e viene terminata al termine della sessione. Le sessioni non condividono mai lo stato. Ottieni i limiti di sicurezza di una VM con il modello operativo serverless: nessun cluster da gestire, nessuna capacità di pool inattiva a pagamento. Puoi orchestrare MicroVMS con una funzione Lambda con controller pianificato che risponde alle richieste di pool in sospeso. Per maggiori dettagli, consulta il modello di riferimento Run self-hosted machines for Cursor Cloud Agents on Lambda MicroVMS. AWS

Come funziona

Un controller pianificato avvia una microVM per ogni richiesta di pool in sospeso:

1. Si avvia un agente cloud dal cursore. com/agentscontro una macchina ospitata autonomamente. La richiesta rimane in sospeso fino a quando un lavoratore non la richiede.

2. La funzione Lambda del controller viene eseguita agent worker controller --spawn ./spawn.sh per una finestra di sondaggio Server-Sent Events (SSE) di cinque minuti. Quando vede una richiesta corrispondente, viene eseguita. spawn.sh

3. spawn.shchiama RunMicrovm (aws lambda-microvms run-microvm) e ritorna senza attendere. Inoltra l'CURSOR_*ambiente del reclamo all'ospite tramite--run-hook-payload.

4. L'/runhook microVM (hook.py) applica quel payload e si avviaentrypoint.sh, il quale viene eseguito. cursor-agent worker --pool … start Il lavoratore esegue le chiamate agli strumenti nel tuo account.

5. Quando la sessione è inattiva dopo il timeout di rilascio, il worker lo rilascia e la MicroVM termina.

La chiave API dell'account di servizio Cursor è archiviata in Systems Manager Parameter Store come. AWS SecureString Il controller e la microVM la leggono in fase di esecuzionessm:GetParameter; la chiave non viene mai inserita nell'immagine.

Proprietà chiave

Proprietà	Vantaggio
Isolamento con petardi	Hardware-virtualized limite per sessione
Avvio con istantanea	Lambda ripristina l'ospite da un'istantanea Firecracker della tua immagine
IAM tramite il ruolo di esecuzione	L'ospite utilizza credenziali di breve durata da MicroVmExecutionRoleArn
Durata statica	Ogni microVM può funzionare fino a 8 ore () --maximum-duration-in-seconds 28800
Pay-per-session	I costi sono calcolati per il runtime di una microVM, non per la capacità inattiva del pool

Prerequisiti

• Un AWS account con Lambda MicroVMS abilitato, oltre all'autorizzazione per utilizzare Amazon S3, IAM e Systems Manager Parameter Store CloudFormation

• Un account Cursor Enterprise

• Un team Cursor con macchine ospitate autonomamente abilitate

• Una chiave API dell'account di servizio per i lavoratori del pool

• La AWS CLI aggiornata all'ultima versione stabile e Docker (lo script di distribuzione crea l'immagine del controller)

Implementazione dell'implementazione di riferimento

Il repository anysphere/aws -lambda-workers fornisce una distribuzione minima e funzionante. e include:

• Uno CloudFormation stack (cloudformation.yaml): una funzione Lambda del controller pianificato, una EventBridge rate(1 minute) regola, un bucket di artefatti Amazon S3, una coda di lettere morte e i ruoli IAM (,,,) MicroVmExecutionRole BuildRole SpawnRole ControllerRole

• Un'immagine del controller (,) che esegue una finestra di polling SSE per controller/Dockerfile controller/handler.py richiamo

• Un'immagine MicroVM (:,,) microvm-image/ Dockerfile hook.py entrypoint.sh

• Uno spawn hook (spawn.sh) e uno script di distribuzione () deploy.sh

Fasi di distribuzione:

1. Archivia la chiave API dell'account di servizio in SSM.

   aws ssm put-parameter --type SecureString \
     --name /cursor-lambda-workers/cursor-api-key \
     --value "YOUR_SERVICE_ACCOUNT_KEY"

2. Distribuisci lo stack. deploy.shcrea l'immagine del controller ed esegue. aws cloudformation deploy

   POOL_NAMES=default ./deploy.sh
   # POOL_NAMES=gpu,default ./deploy.sh
   # ALL_POOLS=true ./deploy.sh

3. Crea l'immagine MicroVM microvm-image/ utilizzando gli output dello stack. Abilita gli hook ready and validate image e l'hook run MicroVM in modo che vengano catturati nel percorso dell'istantanea.

   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}}'

4. Avvia un agente cloud dal cursore. com/agentscontro il pool (o contro un repository in modalità repo-bound) per la verifica.

Per istruzioni dettagliate, consulta il repository README. https://github.com/anysphere/aws-lambda-workers/blob/main/README.md

Modalità pool e repo

Mantieni lo stack PoolNames e l'immagine POOL_NAME allineati in modo che controller e guest servano lo stesso pool.

• Any-repo mode — Il routing avviene per nome del pool, non per git remote. L'ospite avvia il lavoratore da uno spazio di lavoro senza git remote, quindi il lavoratore repo= omette le etichette. Gli utenti scelgono il gruppo di repository Any e il nome del pool quando avviano un agente.

• Repo-bound modalità: il lavoratore serve uno o più telecomandi git specifici. O inserisce il clone nell'immagine MicroVM o impostalo in CURSOR_REPO_URL modo da entrypoint.sh clonarlo all'avvio. Il lavoratore ricava l'repo=etichetta dal telecomando git. I repository privati richiedono le credenziali git sul lavoratore.

Rete

Il riferimento spawn.sh collega il INTERNET_EGRESS connettore gestito in modo che il lavoratore possa raggiungere il piano di controllo di Cursor e ALL_INGRESS gli hook delle immagini. Outbound-only i lavoratori non ricevono mai HTTPS in entrata dopo l'avvio.

Per accedere a risorse private (ad esempio un database Amazon Aurora o un ElastiCache cluster Amazon) o per applicare le tue restrizioni, collega un connettore di uscita VPC al momento dell'avvio al posto di. INTERNET_EGRESS Consulta Utilizzo dei connettori di rete in uscita.

Monitoraggio

Registri degli ospiti: i log di MicroVM vanno a Logs: CloudWatch

aws logs tail /aws/lambda/microvms/cursor-pool-worker --follow

Log del controller: la funzione Lambda del controller accede a. /aws/lambda/cursor-lambda-workers-controller

MicroVMS in esecuzione: elenca i MicroVMS in esecuzione per l'immagine:

aws lambda-microvms list-microvms --image-identifier cursor-pool-worker

Risoluzione dei problemi

Caratteristiche	Causa
La creazione dell'immagine non riesce (S3 o IAM)	Verifica gli output dello stack ArtifactBucketName eBuildRoleArn; lo zip deve atterrare in quel bucket e il ruolo di compilazione deve essere in grado di leggerlo
Nessun avvio di MicroVM	Il controller non è in esecuzione o non è in grado di chiamareRunMicrovm; conferma che l'cursor-pool-workerimmagine esiste e (per un controller locale) si presume SpawnRoleArn
Il lavoratore esce immediatamente	L'ospite è mancante CURSOR_API_KEY (SSM/cursor-lambda-workers/cursor-api-key) o l'/runhook non è stato avviato cursor-agent worker … start
Exec format error - node	L'immagine ha installato l'architettura CLI sbagliata; ecco le microVM aarch64 () arm64
Service-account chiave segnalata non valida	CURSOR_API_ENDPOINT/CURSOR_API_URLsono stati inoltrati all'ospite; questi devono rimanere non impostati, quindi worker start utilizza l'host di autenticazione predefinito
Immagine creata prima dell'attivazione degli hook	Ricostruisci l'immagine MicroVM in questo modo e gli run hook ready si validate trovino nel percorso dell'istantanea

Risorse correlate

• AWS Lambda MicroVMS

• RunMicrovmRiferimento CLI

• Macchine ospitate autonomamente da Cursor Quickstart

• Modello di riferimento: -lambda-workers anysphere/aws