Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # 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](https://github.com/anysphere/aws-lambda-workers) ## Come funziona Un controller pianificato avvia una microVM per ogni richiesta di pool in sospeso: 1. Si avvia un agente cloud dal cursore. [ com/agents](https://cursor.com/agents)contro una macchina ospitata autonomamente. La richiesta rimane in sospeso fino a quando un lavoratore non la richiede. 1. 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` 1. `spawn.sh`chiama `RunMicrovm` (`aws lambda-microvms run-microvm`) e ritorna senza attendere. Inoltra l'`CURSOR_*`ambiente del reclamo all'ospite tramite`--run-hook-payload`. 1. L'`/run`hook microVM (`hook.py`) applica quel payload e si avvia`entrypoint.sh`, il quale viene eseguito. `cursor-agent worker --pool … start` Il lavoratore esegue le chiamate agli strumenti nel tuo account. 1. 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 esecuzione`ssm: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 ](https://cursor.com/docs/account/enterprise/service-accounts) per i lavoratori del pool + La [AWS CLI ](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) aggiornata all'ultima versione stabile e Docker (lo script di distribuzione crea l'immagine del controller) ## Implementazione dell'implementazione di riferimento ![Diagramma di architettura che mostra le Self-hosted macchine Cursor su Lambda MicroVMS](https://docs.aws.amazon.com/it_it/lambda/latest/dg/images/microvms-cursor-cloud-agents-architecture.png) Il repository [ anysphere/aws -lambda-workers ](https://github.com/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" ``` 1. **Distribuisci lo stack. **`deploy.sh`crea 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 ``` 1. **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}}' ``` 1. **Avvia un agente cloud dal cursore. ** [ com/agents](https://cursor.com/agents)contro 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](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](microvms-networking.md#microvms-networking-connectors). ## 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 ](https://docs.aws.amazon.com/lambda/latest/dg/lambda-microvms-guide.html) + [RunMicrovmRiferimento CLI ](https://docs.aws.amazon.com/cli/latest/reference/lambda-microvms/run-microvm.html) + [Macchine ospitate autonomamente da Cursor Quickstart ](https://cursor.com/docs/cloud-agent/bring-your-own-machine) + Modello di riferimento: -lambda-workers [ anysphere/aws ](https://github.com/anysphere/aws-lambda-workers)