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à.
# Quando usare i runtime solo per il sistema operativo di Lambda
Lambda fornisce [runtime gestiti](lambda-runtimes.md) per Java, Python, Node.js, .NET e Ruby. Per creare funzioni Lambda in un linguaggio di programmazione non disponibile come runtime gestito, utilizza un runtime solo per il sistema operativo (la famiglia di runtime `provided`). Esistono tre casi d'uso principali per i runtime solo per il sistema operativo:
+ **Compilazione nativa ahead-of-time (AOT)**: linguaggi come Go, Rust, Swift e C\$1\$1 vengono compilati nativamente in un binario eseguibile, che non richiede un runtime linguistico dedicato. Questi linguaggi richiedono solo un ambiente di sistema operativo in cui sia possibile eseguire il file binario compilato. Puoi anche utilizzare i runtime solo per il sistema operativo Lambda per distribuire file binari compilati con.NET Native AOT e Java GraalVM Native Image.
È necessario includere un client dell'interfaccia di runtime nel file binario. Il client dell'interfaccia di runtime chiama [Utilizzo dell'API di runtime Lambda per runtime personalizzati](runtimes-api.md) per recuperare le invocazioni della funzione e quindi esegue la chiamata al gestore della funzione. Lambda fornisce client di interfaccia runtime per [Rust](lambda-rust.md), [Go](golang-package.md#golang-package-mac-linux), [.NET Native AOT](dotnet-native-aot.md), [Swift](https://github.com/awslabs/swift-aws-lambda-runtime) (sperimentale) e [C\$1\$1](https://github.com/awslabs/aws-lambda-cpp) (sperimentale).
Devi compilare il file binario per un ambiente Linux e per la stessa architettura di set di istruzioni che intendi utilizzare per la funzione (x86\$164 o arm64).
+ **Runtime di terze parti**: puoi eseguire funzioni Lambda off-the-shelf utilizzando runtime [come](https://bref.sh/docs/news/01-bref-1.0.html#amazon-linux-2) Bref per PHP.
+ **Runtime personalizzati**: puoi creare il tuo runtime personale per un linguaggio o una versione di linguaggio per cui Lambda non fornisce un runtime gestito, come Node.js 19. Per ulteriori informazioni, consulta [Creazione di un runtime personalizzato per AWS Lambda](runtimes-custom.md). Questo è il caso d'uso meno comune per i runtime solo per il sistema operativo.
Lambda supporta i seguenti runtime solo per il sistema operativo:
| Name | Identificatore | Sistema operativo | Data di ritiro | Blocco creazione funzioni | Blocco aggiornamento funzioni |
| --- | --- | --- | --- | --- | --- |
| Runtime solo per il sistema operativo | `provided.al2023` | Amazon Linux 2023 | 30 giugno 2029 | 31 luglio 2029 | 31 agosto 2029 |
| Runtime solo per il sistema operativo | `provided.al2` | Amazon Linux 2 | 31 luglio 2026 | 31 agosto 2026 | 30 settembre 2026 |
Il runtime Amazon Linux 2023 (`provided.al2023`) offre diversi vantaggi rispetto ad Amazon Linux 2, tra cui un'impronta di implementazione ridotta e versioni aggiornate di librerie come `glibc`.
Il runtime `provided.al2023` utilizza `dnf` come gestore di pacchetti invece di `yum`, che è il gestore di pacchetti predefinito in Amazon Linux 2. Per ulteriori informazioni sulle differenze tra `provided.al2023` e`provided.al2`, consulta [Introducing the Amazon Linux 2023 runtime for AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/) sul AWS Compute Blog.
# Creazione di un runtime personalizzato per AWS Lambda
È possibile implementare un AWS Lambda runtime in qualsiasi linguaggio di programmazione. Il runtime è un programma che esegue un metodo del gestore della funzione Lambda quando la funzione viene richiamata. Puoi includere il runtime nel pacchetto di implementazione della funzione o distribuirlo in un [livello](chapter-layers.md). Quando crei la funzione Lambda, [scegli un runtime solo per il sistema operativo](runtimes-provided.md) (la famiglia di runtime `provided`).
**Nota**
La creazione di un runtime personalizzato è un caso d'uso avanzato. Se stai cercando informazioni sulla compilazione in un file binario nativo o sull'utilizzo di un off-the-shelf runtime di terze parti, consulta[Quando usare i runtime solo per il sistema operativo di Lambda](runtimes-provided.md).
Per una procedura guidata sul processo di implementazione del runtime personalizzato, consulta [Tutorial: Creazione di un runtime personalizzato](runtimes-walkthrough.md).
**Topics**
+ [Requisiti](#runtimes-custom-build)
+ [Implementazione dello streaming delle risposte in un runtime personalizzato](#runtimes-custom-response-streaming)
+ [Creazione di runtime personalizzati per istanze gestite Lambda](#runtimes-custom-managed-instances)
## Requisiti
I runtime personalizzati devono completare determinate attività di inizializzazione ed elaborazione. Il runtime è responsabile dell'esecuzione del codice di configurazione della funzione, della lettura del nome del gestore da una variabile di ambiente e della lettura degli eventi di richiamo dall'API del runtime Lambda. Il runtime passa i dati dell'evento al gestore della funzioni e invia la risposta dal gestore a Lambda.
### Attività di inizializzazione
Le attività di inizializzazione vengono eseguite una volta [per istanza della funzione](lambda-runtime-environment.md) per preparare l'ambiente a gestire le chiamate.
+ **Recupero delle impostazioni** – Leggi le variabili d'ambiente per ottenere dettagli sulla funzione e sull'ambiente.
+ `_HANDLER` – Il percorso del gestore della configurazione della funzione. Il formato standard è `file.method`, dove `file` è il nome del file senza estensione e `method` è il nome di un metodo o una funzione definita nel file.
+ `LAMBDA_TASK_ROOT` – La directory che contiene il codice della funzione.
+ `AWS_LAMBDA_RUNTIME_API` – L'host e la porta dell'API di runtime.
Per l'elenco completo delle variabili disponibili, consulta la pagina [Variabili di ambiente di runtime definite](configuration-envvars.md#configuration-envvars-runtime).
+ **Inizializzazione della funzione** – Carica il file del gestore ed esegui il codice globale o statico che contiene. Le funzioni devono creare le risorse statiche come i client SDK e le connessioni al database e quindi riutilizzarle per più chiamate.
+ **Gestione degli errori** – Se si verifica un errore, viene chiamata l'API [errore di inizializzazione](runtimes-api.md#runtimes-api-initerror) e viene chiusa la funzione.
L'inizializzazione viene calcolata nella fatturazione del runtime e del timeout. Quando un'esecuzione attiva l'inizializzazione di una nuova istanza della funzione, puoi visualizzare il tempo di inizializzazione nei log e nella [traccia AWS X-Ray](services-xray.md).
**Example log**
```
REPORT RequestId: f8ac1208... Init Duration: 48.26 ms Duration: 237.17 ms Billed Duration: 300 ms Memory Size: 128 MB Max Memory Used: 26 MB
```
### Attività di elaborazione
Durante l'esecuzione, un runtime usa l'[interfaccia del runtime Lambda](runtimes-api.md) per gestire gli eventi in entrata e segnalare gli errori. Dopo aver completato le attività di inizializzazione, il runtime elabora gli eventi in entrata in un ciclo. Nel codice di runtime, eseguire le seguenti fasi in ordine.
+ **Recupero di un evento** – Viene invocata l'API [chiamata successiva](runtimes-api.md#runtimes-api-next) per ottenere l'evento seguente. Il corpo della risposta contiene i dati dell'evento. Le intestazioni di risposta contengono l'ID della richiesta e altre informazioni.
+ **Propagazione dell'intestazione di traccia** – Recupera l'intestazione di traccia X-Ray dall'intestazione `Lambda-Runtime-Trace-Id` nella risposta dell'API. Imposta la variabile di ambiente `_X_AMZN_TRACE_ID` locale allo stesso valore. L'SDK X-Ray utilizza questo valore per associare i dati di tracciamento tra i servizi.
+ **Creazione di un oggetto contesto** – Crea un oggetto con informazioni di contesto dalle variabili di ambiente e dalle intestazioni nella risposta dell'API.
+ **Richiamo del gestore della funzione** – Passa l'evento e l'oggetto contesto al gestore.
+ **Gestione della risposta** – Viene [invocata l'API risposta](runtimes-api.md#runtimes-api-response) della chiamata per pubblicare la risposta del gestore.
+ **Gestione degli errori** – Se si verifica un errore, viene chiamata l'API [errore di chiamata](runtimes-api.md#runtimes-api-invokeerror).
+ **Pulizia** – Rilascia le risorse inutilizzate, invia i dati ad altri servizi o esegui attività aggiuntive prima di ottenere il prossimo evento.
### Entrypoint
Il punto di ingresso di un runtime personalizzato è un file eseguibile denominato `bootstrap`. Il file di bootstrap può essere il runtime oppure può richiamare un altro file che crea il runtime. Se la root del pacchetto di implementazione non contiene un file denominato `bootstrap`, Lambda cerca il file nei livelli della funzione. Se il file `bootstrap` non esiste o non è eseguibile, la funzione restituisce un errore `Runtime.InvalidEntrypoint` in caso di invocazione.
Ecco un `bootstrap` file di esempio che utilizza una versione in bundle di Node.js per eseguire un JavaScript runtime in un file separato denominato. `runtime.js`
**Example bootstrap**
```
#!/bin/sh
cd $LAMBDA_TASK_ROOT
./node-v11.1.0-linux-x64/bin/node runtime.js
```
## Implementazione dello streaming delle risposte in un runtime personalizzato
Per le [funzioni di streaming delle risposte](configuration-response-streaming.md), gli endpoint `response` ed `error` manifestano un comportamento leggermente diverso che consente al runtime di trasmettere risposte parziali al client e restituire i payload in blocchi. Per ulteriori informazioni sul comportamento specifico, consulta le seguenti risorse:
+ `/runtime/invocation/AwsRequestId/response`: propaga l'intestazione `Content-Type` dal runtime per inviarla al client. Lambda restituisce il payload di risposta in blocchi tramite codifica di trasferimento in blocchi HTTP/1.1. Per trasmettere la risposta in streaming a Lambda, il runtime deve:
+ Impostare l'intestazione HTTP `Lambda-Runtime-Function-Response-Mode` su `streaming`.
+ Imposta l'intestazione `Transfer-Encoding` su `chunked`.
+ Scrivere la risposta in conformità alla specifica di codifica del trasferimento in blocchi HTTP/1.1.
+ Chiudere la connessione sottostante dopo la corretta scrittura della risposta.
+ `/runtime/invocation/AwsRequestId/error`: il runtime può utilizzare questo endpoint per segnalare errori di funzione o di runtime a Lambda, che accetta anche l'intestazione `Transfer-Encoding`. Questo endpoint può essere chiamato solo prima che il runtime inizi a inviare una risposta alla chiamata.
+ Segnala gli errori intermedi utilizzando i trailer degli errori in `/runtime/invocation/AwsRequestId/response`: per segnalare gli errori che si verificano dopo aver iniziato a scrivere la risposta alla chiamata, il runtime può facoltativamente collegare intestazioni HTTP finali denominate `Lambda-Runtime-Function-Error-Type` e `Lambda-Runtime-Function-Error-Body`. Lambda considera questa come una risposta riuscita e inoltra i metadati degli errori che il runtime fornisce al client.
**Nota**
Per allegare le intestazioni finali, il runtime deve impostare il valore dell'intestazione `Trailer` all'inizio della richiesta HTTP. Si tratta di un requisito della specifica di codifica di trasferimento in blocchi HTTP/1.1.
+ `Lambda-Runtime-Function-Error-Type`: il tipo di errore rilevato dal runtime. L'intestazione è costituita da un valore stringa. Lambda accetta qualsiasi stringa, ma consigliamo un formato di. ** Ad esempio, `Runtime.APIKeyNotFound`.
+ `Lambda-Runtime-Function-Error-Body`: informazioni sull'errore nella codifica base64.
## Creazione di runtime personalizzati per istanze gestite Lambda
Le istanze gestite Lambda utilizzano la stessa API di runtime delle funzioni Lambda (predefinite). Tuttavia, esistono differenze fondamentali nel modo in cui devono essere implementati i runtime personalizzati per supportare il modello di esecuzione simultanea delle istanze gestite.
### Gestione simultanea delle richieste
La differenza principale nella creazione di runtime personalizzati per le istanze gestite è il supporto per le chiamate simultanee. A differenza delle funzioni Lambda (predefinite) in cui il runtime elabora una chiamata alla volta, le istanze gestite possono elaborare più chiamate contemporaneamente all'interno di un unico ambiente di esecuzione.
Il runtime personalizzato deve:
+ **Supporta `/next` richieste simultanee**: il runtime può effettuare più chiamate simultanee all'API di [chiamata successiva](runtimes-api.md#runtimes-api-next), fino al limite specificato dalla variabile di ambiente. `AWS_LAMBDA_MAX_CONCURRENCY`
+ **Gestisci `/response` le richieste simultanee**[: più chiamate possono chiamare contemporaneamente l'API di risposta alle chiamate.](runtimes-api.md#runtimes-api-response)
+ **Implementa la gestione delle richieste thread-safe**: assicurati che le chiamate simultanee non interferiscano tra loro gestendo correttamente le risorse e lo stato condivisi.
+ **Usa una richiesta univoca IDs**: traccia ogni chiamata separatamente utilizzando l'`Lambda-Runtime-Aws-Request-Id`intestazione per abbinare le risposte alle richieste corrispondenti.
### Modello di implementazione
Un tipico modello di implementazione per i runtime delle istanze gestite prevede la creazione di thread o processi di lavoro per gestire le chiamate simultanee:
1. **Leggi il limite di concorrenza**: al momento dell'inizializzazione, leggi la variabile di `AWS_LAMBDA_MAX_CONCURRENCY` ambiente per determinare quante chiamate simultanee supportare.
1. **Crea un pool di lavoratori**: inizializza un pool di lavoratori (thread, processi o attività asincrone) pari al limite di concorrenza.
1. **Ciclo di elaborazione dei lavoratori**: ogni lavoratore in modo indipendente:
+ Chiamate `/runtime/invocation/next` per ottenere un evento di invocazione
+ Richiama il gestore della funzione con i dati dell'evento
+ Invia la risposta a `/runtime/invocation/AwsRequestId/response`
+ Ripete il ciclo
### Ulteriori considerazioni
+ **Formato di registrazione**: le istanze gestite supportano solo il formato di registro JSON. Assicurati che il runtime rispetti la variabile di `AWS_LAMBDA_LOG_FORMAT` ambiente e utilizzi solo il formato JSON. Per ulteriori informazioni, consulta [Configurazione dei formati di log JSON e testo normale](monitoring-cloudwatchlogs-logformat.md).
+ **Risorse condivise**: fai attenzione quando utilizzi risorse condivise come la `/tmp` directory con chiamate simultanee. Implementa meccanismi di blocco adeguati per prevenire condizioni di gara.
Per ulteriori informazioni sugli ambienti di esecuzione di Lambda Managed Instances, vedere. [Comprendere l'ambiente di esecuzione di Lambda Managed Instances](lambda-managed-instances-execution-environment.md)
# Tutorial: Creazione di un runtime personalizzato
In questo tutorial crei una funzione Lambda con un runtime personalizzato. Si inizia includendo il runtime nel pacchetto di distribuzione della funzione. Quindi lo trasferisci in un livello che gestisci in modo indipendente dalla funzione. Infine, condividi il livello del runtime con tutti aggiornando la policy delle autorizzazioni basate sulle risorse.
## Prerequisiti
Questo tutorial presuppone una certa conoscenza delle operazioni di base di Lambda e della console relativa. Se non lo si è già fatto, seguire le istruzioni riportate in [Creare una funzione Lambda con la console](getting-started.md#getting-started-create-function) per creare la prima funzione Lambda.
Per completare i passaggi seguenti, è necessaria la [AWS CLI versione 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). I comandi e l'output previsto sono elencati in blocchi separati:
```
aws --version
```
Verrà visualizzato l'output seguente:
```
aws-cli/2.13.27 Python/3.11.6 Linux/4.14.328-248.540.amzn2.x86_64 exe/x86_64.amzn.2
```
Per i comandi lunghi viene utilizzato un carattere di escape (`\`) per dividere un comando su più righe.
In Linux e macOS utilizzare la propria shell e il proprio programma di gestione dei pacchetti preferiti.
**Nota**
Su Windows, alcuni comandi della CLI Bash utilizzati comunemente con Lambda (ad esempio, `zip`) non sono supportati dai terminali integrati del sistema operativo. Per ottenere una versione integrata su Windows di Ubuntu e Bash, [installa il sottosistema Windows per Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10). I comandi della CLI di esempio in questa guida utilizzano la formattazione Linux. Se si utilizza la CLI di Windows, i comandi che includono documenti JSON in linea dovranno essere riformattati.
È necessario un ruolo IAM per creare una funzione Lambda. Il ruolo richiede l'autorizzazione per inviare i log a CloudWatch Logs e accedere ai Servizi AWS utilizzati dalla tua funzione. Se non hai un ruolo per lo sviluppo di funzioni, creane uno ora.
**Per creare un ruolo di esecuzione**
1. Apri la pagina [Ruoli](https://console.aws.amazon.com/iam/home#/roles) nella console IAM.
1. Scegliere **Crea ruolo**.
1. Creare un ruolo con le seguenti proprietà.
+ **Trusted entity (Entità attendibile** – **Lambda**
+ **Permissions (Autorizzazioni)** – ** AWSLambdaBasicExecutionRole**.
+ **Role name (Nome ruolo** – **lambda-role**.
La policy **AWSLambdaBasicExecutionRole** dispone delle autorizzazioni delle quali la funzione necessita per scrivere i log in CloudWatch Logs.
## Creazione di una funzione
Crea una funzione Lambda con un runtime personalizzato. Questo esempio include due file: un file `bootstrap` del runtime e un gestore della funzione. Entrambi sono implementati in Bash.
1. Crea una directory per il progetto, quindi passa a quella directory.
```
mkdir runtime-tutorial
cd runtime-tutorial
```
1. Crea un nuovo file denominato `bootstrap`. Questo è il runtime personalizzato.
**Example bootstrap**
```
#!/bin/sh
set -euo pipefail
# Initialization - load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
Il runtime carica uno script di funzione dal pacchetto di distribuzione. Utilizza due variabili per individuare lo script. `LAMBDA_TASK_ROOT` indica il percorso da cui il pacchetto è stato estratto e `_HANDLER` include il nome dello script.
Dopo che il runtime carica lo script della funzione, utilizza l'API del runtime per recuperare un evento di chiamata da Lambda, passa l'evento al gestore e trasmette la risposta a Lambda. Per ottenere l'ID della richiesta, il runtime salva le intestazioni dalla risposta dell'API in un file temporaneo e legge l'intestazione `Lambda-Runtime-Aws-Request-Id` dal file.
**Nota**
I runtime hanno responsabilità aggiuntive inclusa la gestione degli errori e forniscono al gestore le informazioni sul contesto. Per informazioni dettagliate, vedi [Requisiti](runtimes-custom.md#runtimes-custom-build).
1. Crea uno script per la funzione. Lo script di esempio seguente definisce una funzione del gestore che richiede i dati dell'evento, li registra in `stderr` e li restituisce.
**Example function.sh**
```
function handler () {
EVENT_DATA=$1
echo "$EVENT_DATA" 1>&2;
RESPONSE="Echoing request: '$EVENT_DATA'"
echo $RESPONSE
}
```
L'aspetto della directory `runtime-tutorial` dovrebbe essere simile al seguente:
```
runtime-tutorial
├ bootstrap
└ function.sh
```
1. Rendere i file eseguibili e aggiungerli ad un archive ZIP. Questo è il pacchetto di implementazione.
```
chmod 755 function.sh bootstrap
zip function.zip function.sh bootstrap
```
1. Crea una funzione denominata `bash-runtime`. Per `--role`, inserisci l'ARN del tuo [ruolo di esecuzione](lambda-intro-execution-role.md) Lambda.
```
aws lambda create-function --function-name bash-runtime \
--zip-file fileb://function.zip --handler function.handler --runtime provided.al2023 \
--role arn:aws:iam::123456789012:role/lambda-role
```
1. Richiama la funzione.
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
L'opzione **cli-binary-format** è necessaria se si utilizza la versione 2 della AWS CLI. Per rendere questa impostazione come predefinita, esegui `aws configure set cli-binary-format raw-in-base64-out`. Per ulteriori informazioni, consulta la pagina [AWS CLI supported global command line options](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) nella *Guida per l'utente di AWS Command Line Interface versione 2*.
Dovresti ottenere una risposta simile a questa:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. Verifica la risposta.
```
cat response.txt
```
Dovresti ottenere una risposta simile a questa:
```
Echoing request: '{"text":"Hello"}'
```
## Crea un livello
Per separare il codice del runtime dal codice della funzione, crea un livello che contenga solo il runtime. I livelli consentono di sviluppare le dipendenze della funzione in modo indipendente e possono ridurre l'utilizzo dello storage quando usi lo stesso livello con più funzioni. Per ulteriori informazioni, consulta [Gestione delle dipendenze Lambda con i livelli](chapter-layers.md).
1. Crea un file .zip contenente il file `bootstrap`.
```
zip runtime.zip bootstrap
```
1. Crea un livello con il comando [publish-layer-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-layer-version.html?highlight=nodejs16%20x).
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
In tal modo viene creata la prima versione del livello.
## Aggiorna la funzione
Per utilizzare il livello del runtime nella funzione, configura la funzione affinché utilizzi il livello e rimuovi il codice del runtime dalla funzione.
1. Aggiorna la configurazione della funzione da inserire nel livello.
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:1
```
Questo aggiunge il runtime alla funzione nella directory `/opt`. Per garantire che Lambda utilizzi il runtime nel livello, è necessario rimuovere il `boostrap` dal pacchetto di implementazione della funzione, come illustrato nei due passaggi successivi.
1. Crea un file .zip contenente il codice della funzione.
```
zip function-only.zip function.sh
```
1. Aggiorna il codice della funzione in modo da includere soltanto lo script del gestore.
```
aws lambda update-function-code --function-name bash-runtime --zip-file fileb://function-only.zip
```
1. Chiama la funzione per verificare che funzioni con il livello del runtime.
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
L'opzione **cli-binary-format** è necessaria se si utilizza la versione 2 della AWS CLI. Per rendere questa impostazione come predefinita, esegui `aws configure set cli-binary-format raw-in-base64-out`. Per ulteriori informazioni, consulta la pagina [AWS CLI supported global command line options](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) nella *Guida per l'utente di AWS Command Line Interface versione 2*.
Dovresti ottenere una risposta simile a questa:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. Verifica la risposta.
```
cat response.txt
```
Dovresti ottenere una risposta simile a questa:
```
Echoing request: '{"text":"Hello"}'
```
## Aggiorna il runtime
1. Per registrare le informazioni sull'ambiente di esecuzione, aggiorna lo script del runtime sulle variabili di ambiente di output.
**Example bootstrap**
```
#!/bin/sh
set -euo pipefail
# Configure runtime to output environment variables
echo "## Environment variables:"
env
# Load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
1. Crea un file .zip contenente la nuova versione del file `bootstrap`.
```
zip runtime.zip bootstrap
```
1. Crea una nuova versione del livello `bash-runtime`.
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
1. Configura la funzione per utilizzare la nuova versione del livello.
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2
```
## Condividi il livello
Per condividere un livello con un altro Account AWS, aggiungi una istruzione di autorizzazione multi-account alla [policy basata sulle risorse](access-control-resource-based.md) del livello. Esegui il comando [add-layer-version-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-layer-version-permission.html) e specifica l'ID dell'account come `principal`. In ogni istruzione, puoi concedere l'autorizzazione a un singolo account, a tutti gli account o a un'organizzazione in [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html).
L'esempio seguente concede all'account 111122223333 l'accesso alla versione 2 del livello `bash-runtime`.
```
aws lambda add-layer-version-permission \
--layer-name bash-runtime \
--version-number 2 \
--statement-id xaccount \
--action lambda:GetLayerVersion \
--principal 111122223333 \
--output text
```
Verrà visualizzato un output simile al seguente:
```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2"}
```
Le autorizzazioni si applicano solo a un'unica versione di un livello. Ripeti la procedura ogni volta che crei la nuova versione di un livello.
## Eliminazione
Eliminare ciascuna versione del livello.
```
aws lambda delete-layer-version --layer-name bash-runtime --version-number 1
aws lambda delete-layer-version --layer-name bash-runtime --version-number 2
```
Poiché contiene un riferimento alla versione 2 del livello, la funzione è ancora presente in Lambda. Continua a operare, ma le funzioni non possono più essere configurate per utilizzare la versione eliminata. Se modifichi l'elenco dei livelli sulla funzione, devi specificare una nuova versione oppure omettere il livello eliminato.
Elimina la funzione con il comando [delete-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-function.html).
```
aws lambda delete-function --function-name bash-runtime
```