Creare una funzione Lambda utilizzando un'immagine del contenitore - AWS Lambda

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à.

Creare una funzione Lambda utilizzando un'immagine del contenitore

Il codice della AWS Lambda funzione è costituito da script o programmi compilati e dalle relative dipendenze. Utilizza un pacchetto di implementazione per distribuire il codice della funzione a Lambda. Lambda supporta due tipi di pacchetti di implementazione: immagini di container e archivi di file .zip.

Esistono tre modi per creare un'immagine di container per una funzione Lambda:

Suggerimento

Per ridurre il tempo necessario all'attivazione delle funzioni del container Lambda, consulta Utilizzo di compilazioni a più fasi nella documentazione Docker. Per creare immagini di container efficienti, segui le best practice per scrivere file Docker.

Per creare una funzione Lambda da un'immagine di un container, crea l'immagine localmente e caricala in un repository Amazon Elastic Container Registry (Amazon ECR). Quindi, specifica l'URI del repository al momento della creazione della funzione. Il repository Amazon ECR deve corrispondere alla funzione Lambda. Regione AWS È possibile creare una funzione utilizzando un'immagine in un AWS account diverso, purché l'immagine si trovi nella stessa regione della funzione Lambda. Per ulteriori informazioni, consulta Autorizzazioni multiaccount Amazon ECR.

Questa pagina spiega i tipi di immagini di base e i requisiti per la creazione di immagini di container compatibili con Lambda.

Nota

Non è possibile modificare il tipo di pacchetto di distribuzione (.zip o immagine del contenitore) per una funzione esistente. Ad esempio, non è possibile convertire una funzione di immagine del contenitore per utilizzare un archivio di file.zip. È necessario creare una nuova funzione.

Requisiti

Installa l'AWS Command Line Interface (AWS CLI) versione 2 e la CLI Docker. Sono inoltre necessari i seguenti requisiti:

  • L'immagine di container deve implementare l'API di runtime Lambda. I client dell'interfaccia runtime AWS open-source implementano l'API. È possibile aggiungere un client di interfaccia di runtime all'immagine di base preferita per renderla compatibile con Lambda.

  • L'immagine di container deve essere in grado di funzionare su un filesystem di sola lettura. Il codice della funzione può accedere a una directory /tmp scrivibile con spazio di storage compreso tra 512 MB e 10.240 MB con incrementi di 1 MB.

  • L'utente Lambda predefinito deve essere in grado di leggere tutti i file necessari per eseguire il codice della funzione. Lambda segue le best practice di sicurezza tramite la definizione di un utente Linux predefinito con autorizzazioni meno privilegiate. Verifica che il codice dell'applicazione non si basi su file che altri utenti Linux non possono eseguire.

  • Lambda supporta solo le immagini di container basate su Linux.

  • Lambda fornisce immagini di base multi-architettura. Tuttavia, l'immagine creata per la tua funzione deve essere destinata a una sola delle architetture. Lambda non supporta funzioni che utilizzano immagini container multi-architettura.

Usare un'immagine AWS di base per Lambda

È possibile utilizzare una delle immagini di base AWS per Lambda per creare l'immagine di container per il codice della funzione. Le immagini di base sono precaricate con un runtime di lingua e altri componenti necessari per eseguire un'immagine container su Lambda. Aggiungere il codice funzione e le dipendenze all'immagine di base e quindi impacchettarlo come immagine container.

AWS fornisce periodicamente aggiornamenti alle immagini di AWS base per Lambda. Se il Dockerfile include il nome dell'immagine nella proprietà FROM, il client Docker estrae l'ultima versione dell'immagine dal repository Amazon ECR. Per utilizzare l'immagine di base aggiornata, è necessario ricostruire l'immagine di container e aggiornare il codice della funzione.

Le immagini di base Node.js 20, Python 3.12, Java 21, AL2023 e versioni successive si basano sull'immagine minima del contenitore Amazon Linux 2023. Le immagini di base precedenti utilizzavano Amazon Linux 2. AL2023 offre diversi vantaggi rispetto ad Amazon Linux 2, tra cui un'impronta di implementazione ridotta e versioni aggiornate di librerie come glibc.

Le immagini basate su AL2023 utilizzano microdnf (symlinked asdnf) come gestore di pacchetti anzichéyum, che è il gestore di pacchetti predefinito in Amazon Linux 2. microdnfè un'implementazione autonoma di. dnf Per un elenco dei pacchetti inclusi nelle immagini basate su AL2023, consulta le colonne Minimal Container in Confronto dei pacchetti installati su Amazon Linux 2023 Container Images. Per ulteriori informazioni sulle differenze tra AL2023 e Amazon Linux 2, consulta la sezione Introduzione al runtime di Amazon Linux 2023 per AWS Lambda sul AWS Compute Blog.

Nota

Per eseguire immagini basate su AL2023 localmente, incluso with AWS Serverless Application Model (AWS SAM), devi usare la versione Docker 20.10.10 o successiva.

Per creare un'immagine del contenitore utilizzando un'immagine di AWS base, scegli le istruzioni per la tua lingua preferita:

Utilizzo di un'immagine di AWS base solo per il sistema operativo

AWS Le immagini di base solo per il sistema operativo contengono una distribuzione Amazon Linux e l'emulatore di interfaccia di runtime. Queste immagini vengono comunemente utilizzate per creare immagini di container per linguaggi compilati, come Go e Rust, e per un linguaggio o una versione di linguaggio per cui Lambda non fornisce un'immagine di base, come Node.js 19. Puoi anche utilizzare immagini di base solo per il sistema operativo per implementare un runtime personalizzato. Per rendere l'immagine compatibile con Lambda, devi includere nell'immagine un client di interfaccia di runtime per il tuo linguaggio.

Tag Runtime Sistema operativo Dockerfile Definizione come obsoleto

al2023

Runtime solo per il sistema operativo Amazon Linux 2023 Dockerfile per Runtime solo per sistema operativo su GitHub

al2

Runtime solo per il sistema operativo Amazon Linux 2 Dockerfile per Runtime solo per sistema operativo attivo GitHub

Galleria pubblica di Amazon Elastic Container Registry: gallery.ecr.aws/lambda/provided

Utilizzo di un'immagine non di base AWS

Lambda supporta qualsiasi immagine conforme a uno dei seguenti formati manifest per le immagini:

  • Docker Image Manifest V2 Schema 2 (utilizzato con Docker versione 1.10 e successive)

  • Open Container Initiative (OCI) Specifications (v1.0.0 e successive)

Lambda supporta una dimensione massima dell'immagine non compressa pari a 10 GB, inclusi tutti i livelli.

Nota

Per rendere l'immagine compatibile con Lambda, devi includere nell'immagine un client di interfaccia di runtime per il tuo linguaggio.

Client di interfaccia runtime

Se utilizzi un'immagine di base solo per il sistema operativo o un'immagine di base alternativa, devi includere un client dell'interfaccia di runtime nell'immagine. Il client dell'interfaccia di runtime deve estendereAPI di runtime Lambda, che gestisce l'interazione tra Lambda e il codice della funzione. AWS fornisce client di interfaccia di runtime open source per le seguenti lingue:

Se utilizzi un linguaggio che non dispone di un AWS client di interfaccia di runtime fornito, devi crearne uno personalizzato.

Autorizzazioni Amazon ECR

Prima di creare la funzione Lambda da un'immagine di container, è necessario creare un'immagine del container in locale e caricarla in un repository Amazon ECR. Quando crei la funzione, specifica l'URI del repository Amazon ECR.

Assicurati che le autorizzazioni per l'utente o il ruolo che crea la funzione GetRepositoryPolicy includano e. SetRepositoryPolicy

Ad esempio, utilizza la console IAM per creare un ruolo con la seguente policy:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "ecr:SetRepositoryPolicy", "ecr:GetRepositoryPolicy" ], "Resource": "arn:aws:ecr:us-east-1:111122223333:repository/hello-world" } ] }

Policy del repository Amazon ECR

Per una funzione nello stesso account dell'immagine di container in Amazon ECR, puoi aggiungere le autorizzazioni ecr:BatchGetImage e ecr:GetDownloadUrlForLayer alla policy del tuo repository Amazon ECR. L'esempio seguente mostra il valore minimo della policy.

{ "Sid": "LambdaECRImageRetrievalPolicy", "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": [ "ecr:BatchGetImage", "ecr:GetDownloadUrlForLayer" ] }

Per ulteriori informazioni sulle autorizzazioni per il repository Amazon ECR, consulta la pagina Policy dei repository privati nella Guida per l'utente di Amazon Elastic Container Registry.

Se il repository Amazon ECR non include queste autorizzazioni, Lambda aggiunge ecr:BatchGetImage e ecr:GetDownloadUrlForLayer alle autorizzazioni del repository di immagini di container. Lambda può aggiungere queste autorizzazioni solo se l'entità principale che chiama Lambda dispone delle autorizzazioni ecr:getRepositoryPolicy e ecr:setRepositoryPolicy.

Per visualizzare o modificare le autorizzazioni del repository Amazon ECR, segui le istruzioni riportate nella pagina Impostazione di un'istruzione di policy per i repository privati della Guida per l'utente di Amazon Elastic Container Registry.

Autorizzazioni multiaccount Amazon ECR

Un account diverso nella stessa Regione può creare una funzione che utilizza un'immagine container di proprietà del tuo account. Nell'esempio seguente, la policy delle autorizzazioni del repository Amazon ECR richiede le seguenti istruzioni per concedere l'accesso all'account numero 123456789012.

  • CrossAccountAutorizzazione: consente all'account 123456789012 di creare e aggiornare funzioni Lambda che utilizzano immagini da questo repository ECR.

  • Politica LambdaECR ImageCrossAccountRetrieval: Lambda alla fine imposterà lo stato di una funzione su inattivo se non viene richiamata per un periodo prolungato. Questa istruzione è necessaria affinché Lambda possa recuperare l'immagine del container per l'ottimizzazione e la memorizzazione nella cache per conto della funzione di proprietà di 123456789012.

Esempio - Aggiunta di autorizzazioni multi-account al repository
{ "Version": "2012-10-17", "Statement": [ { "Sid": "CrossAccountPermission", "Effect": "Allow", "Action": [ "ecr:BatchGetImage", "ecr:GetDownloadUrlForLayer" ], "Principal": { "AWS": "arn:aws:iam::123456789012:root" } }, { "Sid": "LambdaECRImageCrossAccountRetrievalPolicy", "Effect": "Allow", "Action": [ "ecr:BatchGetImage", "ecr:GetDownloadUrlForLayer" ], "Principal": { "Service": "lambda.amazonaws.com" }, "Condition": { "StringLike": { "aws:sourceARN": "arn:aws:lambda:us-east-1:123456789012:function:*" } } } ] }

Per consentire l'accesso a più account, aggiungi gli ID account all'elenco Principal nella CrossAccountPermission policy e alla lista di valutazione delle condizioni nel LambdaECRImageCrossAccountRetrievalPolicy.

Se lavori con più account in un' AWS organizzazione, ti consigliamo di enumerare ogni ID account nella politica di autorizzazione ECR. Questo approccio è in linea con le migliori pratiche di AWS sicurezza che prevedono l'impostazione di autorizzazioni ristrette nelle policy IAM.

Oltre alle autorizzazioni Lambda, l'utente o il ruolo che crea la funzione deve disporre BatchGetImage anche delle autorizzazioni e. GetDownloadUrlForLayer

Ciclo di vita delle funzioni

Dopo aver caricato un'immagine container nuova o aggiornata, Lambda ottimizza l'immagine prima che la funzione possa elaborare le chiamate. Il processo di ottimizzazione può richiedere alcuni secondi. La funzione rimane nello stato Pending fino al completamento del processo. La funzione passa quindi allo stato Active. Mentre lo stato è Pending, è possibile richiamare la funzione, ma non è possibile completare altre operazioni. Le chiamate che si verificano durante l'aggiornamento dell'immagine eseguono il codice dell'immagine precedente.

Se una funzione non viene richiamata per più settimane, Lambda recupera la sua versione ottimizzata e la funzione passa allo stato Inactive. Per riattivare la funzione, è necessario invocarla. Lambda rifiuta la prima invocazione e la funzione entra nello stato Pending finché Lambda non riottimizza l'immagine. La funzione ritorna quindi allo stato Active.

Lambda recupera periodicamente l'immagine del contenitore associata dal repository Amazon ECR. Se l'immagine di container corrispondente non esiste più in Amazon ECR o le autorizzazioni sono state revocate, la funzione entra nello stato Failed e Lambda restituisce un errore per qualsiasi chiamata della funzione.

È possibile utilizzare l'API Lambda per ottenere informazioni sullo stato di una funzione. Per ulteriori informazioni, consulta Stati funzione Lambda.