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 di container
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:
+ [Usare un'immagine AWS di base per Lambda](#runtimes-images-lp)
[Le immagini di base AWS](#runtimes-images-lp) sono precaricate con un runtime in linguaggio, un client di interfaccia di runtime per gestire l'interazione tra Lambda e il codice della funzione e un emulatore di interfaccia di runtime per i test locali.
+ [Utilizzo di un'immagine di AWS base solo per il sistema operativo](#runtimes-images-provided)
[AWS Le immagini di base solo](https://gallery.ecr.aws/lambda/provided) per il sistema operativo contengono una distribuzione Amazon Linux e l'emulatore [di interfaccia di runtime](https://github.com/aws/aws-lambda-runtime-interface-emulator/). Queste immagini vengono comunemente utilizzate per creare immagini di container per linguaggi compilati, come [Go](go-image.md#go-image-provided) e [Rust](lambda-rust.md), 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](runtimes-custom.md). Per rendere l'immagine compatibile con Lambda, devi includere nell'immagine un [client di interfaccia di runtime](#images-ric) per il tuo linguaggio.
+ [Utilizzo di un'immagine non AWS di base](#images-types)
È possibile utilizzare un'immagine di base alternativa da un altro registro del container, come ad esempio Alpine Linux o Debian. Puoi anche utilizzare un'immagine personalizzata creata dalla tua organizzazione. Per rendere l'immagine compatibile con Lambda, devi includere nell'immagine un [client di interfaccia di runtime](#images-ric) per il tuo linguaggio.
**Suggerimento**
Per ridurre il tempo necessario all'attivazione delle funzioni del container Lambda, consulta [Utilizzo di compilazioni a più fasi](https://docs.docker.com/build/building/multi-stage/) nella documentazione Docker. Per creare immagini di container efficienti, segui le [best practice per scrivere file Docker](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/).
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). Se si utilizza un'immagine container fornita da un venditore [Marketplace AWS](https://docs.aws.amazon.com/marketplace/latest/userguide/container-based-products.html), devi prima clonare l'immagine nel tuo repository Amazon ECR privato. 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](#configuration-images-xaccount-permissions).
**Nota**
Lambda non supporta gli endpoint FIPS di Amazon ECR per le immagini dei container. Se l'URI del repository include `ecr-fips`, stai utilizzando un endpoint FIPS. Esempio: `111122223333.dkr.ecr-fips.us-east-1.amazonaws.com`.
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 implementazione](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-PackageType) (.zip o immagine di container) per una funzione esistente. Ad esempio, non è possibile convertire una funzione di immagine di container esistente per utilizzare un archivio di file .zip. È necessario creare una nuova funzione.
**Topics**
+ [
## Requisiti
](#images-reqs)
+ [
## Usare un'immagine AWS di base per Lambda
](#runtimes-images-lp)
+ [
## Utilizzo di un'immagine di AWS base solo per il sistema operativo
](#runtimes-images-provided)
+ [
## Utilizzo di un'immagine non AWS di base
](#images-types)
+ [
## Client di interfaccia runtime
](#images-ric)
+ [
## Autorizzazioni Amazon ECR
](#gettingstarted-images-permissions)
+ [
## Ciclo di vita delle funzioni
](#images-lifecycle)
## Requisiti
Installa la [AWS CLI versione 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) e la [CLI Docker](https://docs.docker.com/get-docker). Sono inoltre necessari i seguenti requisiti:
+ L'immagine di container deve implementare l'[Utilizzo dell'API di runtime Lambda per runtime personalizzati](runtimes-api.md). I [client dell'interfaccia runtime AWS](#images-ric) 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. Ciò significa che non è necessario specificare un [USER](https://docs.docker.com/reference/dockerfile/#user) nel Dockerfile. 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](https://gallery.ecr.aws/lambda/) 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](https://gallery.ecr.aws/lambda/). Per utilizzare l'immagine di base aggiornata, è necessario ricostruire l'immagine di container e [aggiornare il codice della funzione](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html).
Le immagini di base Node.js 20, Python 3.12, Java 21, .NET 8, Ruby 3.3 e versioni successive si basano sull'[immagine minima del container di Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/minimal-container.html). Le immagini di base precedenti utilizzavano Amazon Linux 2. AL2023 offre diversi vantaggi rispetto ad Amazon Linux 2, tra cui un ingombro di distribuzione ridotto e versioni aggiornate di librerie come`glibc`.
AL2023le immagini basate utilizzano `microdnf` (symlinked as`dnf`) 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 AL2023 basate, consulta le colonne **Minimal Container** in [Comparing packages installed on Amazon Linux 2023 Container Images](https://docs.aws.amazon.com/linux/al2023/ug/al2023-container-image-types.html). Per ulteriori informazioni sulle differenze tra Amazon Linux 2 AL2023 e Amazon Linux 2, consulta [la sezione Introduzione al runtime di Amazon Linux 2023 AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/) sul AWS Compute Blog.
**Nota**
Per eseguire immagini AL2023 basate 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:
+ [Node.js](nodejs-image.md#nodejs-image-instructions)
+ [TypeScript](typescript-image.md#base-image-typescript)(utilizza un'immagine di base Node.js)
+ [Python](python-image.md#python-image-instructions)
+ [Java](java-image.md#java-image-instructions)
+ [Go](go-image.md#go-image-provided)
+ [.NET](csharp-image.md#csharp-image-instructions)
+ [Ruby](ruby-image.md#ruby-image-instructions)
## Utilizzo di un'immagine di AWS base solo per il sistema operativo
[AWS Le immagini di base solo](https://gallery.ecr.aws/lambda/provided) per il sistema operativo contengono una distribuzione Amazon Linux e l'emulatore [di interfaccia di runtime](https://github.com/aws/aws-lambda-runtime-interface-emulator/). Queste immagini vengono comunemente utilizzate per creare immagini di container per linguaggi compilati, come [Go](go-image.md#go-image-provided) e [Rust](lambda-rust.md), 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](runtimes-custom.md). Per rendere l'immagine compatibile con Lambda, devi includere nell'immagine un [client di interfaccia di runtime](#images-ric) per il tuo linguaggio.
| Tag | Runtime | Sistema operativo | Dockerfile | Raggiunta obsolescenza |
| --- | --- | --- | --- | --- |
| al2023 | Runtime solo per il sistema operativo | Amazon Linux 2023 | [Dockerfile per Runtime solo per sistema operativo su GitHub](https://github.com/aws/aws-lambda-base-images/blob/provided.al2023/Dockerfile.provided.al2023) | 30 giugno 2029 |
| al2 | Runtime solo per il sistema operativo | Amazon Linux 2 | [Dockerfile per Runtime solo per sistema operativo su GitHub](https://github.com/aws/aws-lambda-base-images/blob/provided.al2/Dockerfile.provided.al2) | 31 luglio 2026 |
Galleria pubblica di Amazon Elastic Container Registry: [gallery.ecr. aws/lambda/provided](https://gallery.ecr.aws/lambda/provided)
## Utilizzo di un'immagine non AWS di base
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](#images-ric) per il tuo linguaggio.
Per prestazioni ottimali, mantenere la dimensione del manifesto dell'immagine al di sotto di 25.400 byte. Per ridurre le dimensioni del manifesto dell'immagine, ridurre al minimo il numero di livelli nell'immagine e riduci le annotazioni.
## Client di interfaccia runtime
Se utilizzi un'[immagine di base solo per il sistema operativo](#runtimes-images-provided) o un'immagine di base alternativa, devi includere un client dell'interfaccia di runtime nell'immagine. Il client dell'interfaccia di runtime deve estendere[Utilizzo dell'API di runtime Lambda per runtime personalizzati](runtimes-api.md), che gestisce l'interazione tra Lambda e il codice della funzione. AWS fornisce client di interfaccia di runtime open source per le seguenti lingue:
+ [Node.js](nodejs-image.md#nodejs-image-clients)
+ [Python](python-image.md#python-image-clients)
+ [Java](java-image.md#java-image-clients)
+ [.NET](csharp-image.md#csharp-image-clients)
+ [Go](go-image.md#go-image-clients)
+ [Ruby](ruby-image.md#ruby-image-clients)
+ [Ruggine](lambda-rust.md) —
Se utilizzi un linguaggio che non dispone di un AWS client di interfaccia di runtime fornito, devi crearne uno tuo.
## 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 includano`GetRepositoryPolicy`, `SetRepositoryPolicy``BatchGetImage`, e. `GetDownloadUrlForLayer`
Ad esempio, utilizza la console IAM per creare un ruolo con la seguente policy:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"ecr:SetRepositoryPolicy",
"ecr:GetRepositoryPolicy",
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"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](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policies.html) nella *Guida per l'utente di Amazon Elastic Container Registry*.
Se il repository Amazon ECR non include queste autorizzazioni, Lambda tenta di aggiungerle automaticamente. Lambda può aggiungere 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](https://docs.aws.amazon.com/AmazonECR/latest/userguide/set-repository-policy.html) 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](https://docs.aws.amazon.com/AmazonECR/latest/userguide/set-repository-policy.html) richiede le seguenti istruzioni per concedere l'accesso all'account numero 123456789012.
+ **CrossAccountPermission**— Consente all'account 123456789012 di creare e aggiornare funzioni Lambda che utilizzano immagini da questo repository ECR.
+ **Lambda**: ECRImage CrossAccountRetrievalPolicy 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.
**Example - 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"
},
"Resource": "arn:aws:ecr:us-east-1:123456789012:repository/example-lambda-repository"
},
{
"Sid": "LambdaECRImageCrossAccountRetrievalPolicy",
"Effect": "Allow",
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Condition": {
"ArnLike": {
"aws:sourceARN": "arn:aws:lambda:us-east-1:123456789012:function:*"
}
},
"Resource": "arn:aws:ecr:us-east-1:123456789012:repository/example-lambda-repository"
}
]
}
```
Per consentire l'accesso a più account, aggiungi l'account IDs all'elenco Principal nella `CrossAccountPermission` policy e all'elenco di valutazione delle condizioni in. `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 anche delle autorizzazioni `BatchGetImage` 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, quando lo stato passa a `Active`. Non è possibile richiamare la funzione fino a quando non raggiunge lo stato `Active`.
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 di container 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](functions-states.md).