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à.
# Compilazione di funzioni Lambda con Node.js
Puoi eseguire il JavaScript codice con Node.js in. AWS Lambda Lambda fornisce [Runtime](lambda-runtimes.md) per Node.js che eseguono il tuo codice per elaborare gli eventi. Il codice viene eseguito in un ambiente che include AWS SDK per JavaScript, con le credenziali di un ruolo AWS Identity and Access Management (IAM) gestito dall'utente. Per ulteriori informazioni sulle versioni SDK incluse nei runtime di Node.js, consulta [Versioni SDK incluse nel runtime](#nodejs-sdk-included).
Lambda supporta i seguenti runtime di Node.js.
| Name | Identificatore | Sistema operativo | Data di ritiro | Blocco creazione funzioni | Blocco aggiornamento funzioni |
| --- | --- | --- | --- | --- | --- |
| Node.js 24 | `nodejs24.x` | Amazon Linux 2023 | 30 aprile 2028 | 1 giugno 2028 | 1 luglio 2028 |
| Node.js 22 | `nodejs22.x` | Amazon Linux 2023 | 30 aprile 2027 | 1 giugno 2027 | 1 luglio 2027 |
| Node.js 20 | `nodejs20.x` | Amazon Linux 2023 | 30 aprile 2026 | 31 agosto 2026 | 30 settembre 2026 |
**Per creare una funzione Node.js.**
1. Aprire la [console Lambda](https://console.aws.amazon.com/lambda).
1. Scegli **Crea funzione**.
1. Configura le impostazioni seguenti:
+ **Nome della funzione**: inserisci il nome della funzione.
+ **Runtime**: scegli **Node.js 24.x**.
1. Scegli **Crea funzione**.
La console crea una funzione Lambda con un singolo file di origine denominato `index.mjs`. È possibile modificare questo file e aggiungere altri file nell'editor di codice predefinito. Nella sezione **DEPLOY**, scegli **Implementa** per aggiornare il codice della tua funzione. Quindi, per eseguire il codice, scegli **Crea evento di test** nella sezione **EVENTI DI TEST**.
Il file `index.mjs` esporta una funzione denominata `handler` che richiede un oggetto evento e un oggetto contesto. Questa è la [funzione del gestore](nodejs-handler.md) chiamata da Lambda quando la funzione viene richiamata. Il runtime della funzione Node.js riceve gli eventi di chiamata da Lambda e li passa al gestore. Nella configurazione della funzione il valore del gestore è `index.handler`.
Quando si salva il codice funzione, la console Lambda crea un pacchetto di implementazione dell'archivio di file .zip. Quando sviluppi il codice funzione al di fuori della console (utilizzando un IDE) devi [creare un pacchetto di implementazione](nodejs-package.md) per caricare il codice nella funzione Lambda.
Il runtime della funzione passa un oggetto contesto al gestore, oltre all'evento di chiamata. L'[oggetto contesto](nodejs-context.md) contiene ulteriori informazioni sulla chiamata, sulla funzione e sull'ambiente di esecuzione. Altre informazioni sono disponibili con le variabili di ambiente.
La funzione Lambda include un gruppo di CloudWatch log Logs. Il runtime della funzione invia i dettagli su ogni chiamata a Logs. CloudWatch Si trasmette qualsiasi [log che la tua funzione emette](nodejs-logging.md) durante la chiamata. Se la funzione restituisce un errore, Lambda formatta l'errore e lo restituisce al chiamante.
**Topics**
+ [
## Versioni SDK incluse nel runtime
](#nodejs-sdk-included)
+ [
## Utilizzo di keep-alive per le connessioni TCP
](#nodejs-keep-alive)
+ [
## Caricamento di certificati CA
](#nodejs-certificate-loading)
+ [
## Funzionalità sperimentali di Node.js
](#nodejs-experimental-features)
+ [
# Definire l'handler delle funzioni Lambda in Node.js
](nodejs-handler.md)
+ [
# Distribuisci funzioni Lambda in Node.js con archivi di file .zip
](nodejs-package.md)
+ [
# Distribuisci funzioni Lambda in Node.js con immagini di container
](nodejs-image.md)
+ [
# Utilizzo dei livelli per le funzioni Lambda Node.js
](nodejs-layers.md)
+ [
# Utilizzo dell'oggetto di contesto Lambda per recuperare le informazioni sulla funzione Node.js
](nodejs-context.md)
+ [
# Registrare e monitorare funzioni Lambda in Node.js
](nodejs-logging.md)
+ [
# Strumentazione del codice Node.js in AWS Lambda
](nodejs-tracing.md)
## Versioni SDK incluse nel runtime
[Tutti i [runtime Lambda Node.js supportati](#nodejs-supported-runtimes) includono una versione secondaria specifica della AWS SDK per JavaScript v3, non la versione più recente.](https://github.com/aws/aws-sdk-js-v3/releases) La versione secondaria specifica inclusa nel runtime dipende dalla versione di runtime e dalla tua. Regione AWS Per trovare la versione specifica dell'SDK inclusa nel runtime che stai utilizzando, crea una funzione Lambda con il codice seguente.
**Example index.mjs**
```
import packageJson from '@aws-sdk/client-s3/package.json' with { type: 'json' };
export const handler = async () => ({ version: packageJson.version });
```
Restituisce una risposta nel seguente formato:
```
{
"version": "3.632.0"
}
```
Per ulteriori informazioni, consulta [Utilizzo dell'SDK per JavaScript v3 nel gestore](nodejs-handler.md#nodejs-example-sdk-usage).
## Utilizzo di keep-alive per le connessioni TCP
L' HTTP/HTTPS agente Node.js predefinito crea una nuova connessione TCP per ogni nuova richiesta. Per evitare il costo della creazione di nuove connessioni, keep-alive è abilitato per impostazione predefinita in tutti i runtime Node.js [supportati](#nodejs-supported-runtimes). Il keep-alive può ridurre i tempi di richiesta per le funzioni Lambda che effettuano più chiamate API utilizzando l'SDK.
*Per disabilitare keep-alive, consulta [Riutilizzo delle connessioni con keep-alive in Node.js nella](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/node-reusing-connections.html) Guida per sviluppatori SDK per 3.x.AWS JavaScript * Per ulteriori informazioni sull'utilizzo di keep-alive, consulta [HTTP keep-alive è attivo di default nell'SDK modulare o sul](https://aws.amazon.com/blogs/developer/http-keep-alive-is-on-by-default-in-modular-aws-sdk-for-javascript/) blog Developer Tools. AWS JavaScript AWS
## Caricamento di certificati CA
Per le versioni di runtime di Node.js fino a Node.js 18, Lambda carica automaticamente i certificati CA (autorità di certificazione) specifici di Amazon per semplificare la creazione di funzioni che interagiscono con altri Servizi AWS. Ad esempio, Lambda include i certificati Amazon RDS necessari per convalidare il [certificato di identità del server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) installato sul tuo database Amazon RDS. Questo comportamento può avere un impatto sulle prestazioni durante gli avvii a freddo.
A partire da Node.js 20, Lambda non carica più certificati CA aggiuntivi per impostazione predefinita. Il runtime Node.js 20 contiene un file di certificato con tutti i certificati Amazon CA nella posizione `/var/runtime/ca-cert.pem`. Per ripristinare lo stesso comportamento da Node.js 18 e runtime precedenti, imposta la [variabile di ambiente](configuration-envvars.md) `NODE_EXTRA_CA_CERTS` su `/var/runtime/ca-cert.pem`.
Per prestazioni ottimali, consigliamo di raggruppare nel pacchetto di implementazione solo i certificati necessari e di caricarli tramite la variabile di ambiente `NODE_EXTRA_CA_CERTS`. Il file dei certificati deve essere composto da uno o più certificati CA root o intermedi affidabili in formato PEM. Ad esempio, per RDS, includi i certificati richiesti insieme al codice come `certificates/rds.pem`. Quindi, carica i certificati impostando `NODE_EXTRA_CA_CERTS` su `/var/task/certificates/rds.pem`.
## Funzionalità sperimentali di Node.js
Le versioni originali del linguaggio Node.js abilitano alcune funzionalità sperimentali per impostazione predefinita. Lambda disabilita queste funzionalità per garantire stabilità di runtime e prestazioni costanti. La tabella seguente elenca le funzionalità sperimentali che Lambda disabilita.
| Funzionalità sperimentale | Versioni supportate di Node.js | Bandiera Node.js applicata da Lambda | Bandiera Lambda da riattivare |
| --- | --- | --- | --- |
| Support per l'importazione di moduli utilizzando require in ES modules | Node.js 20, Node.js 22 | `--no-experimental-require-module` | `--experimental-require-module` |
| Support per il rilevamento automatico dei moduli ES vs CommonJS | Node.js 22 | `--no-experimental-detect-module` | `--experimental-detect-module` |
Per abilitare una funzionalità sperimentale disabilitata, imposta il flag re-enable nella variabile di ambiente. `NODE_OPTIONS` Ad esempio, per abilitare il modulo ES require support, imposta su`NODE_OPTIONS`. `--experimental-require-module` Lambda rileva questo override e rimuove il flag di disabilitazione corrispondente.
**Importante**
L'utilizzo di funzionalità sperimentali può portare a problemi di instabilità e prestazioni. Queste funzionalità potrebbero essere modificate o rimosse nelle future versioni di Node.js. Le funzioni che utilizzano funzionalità sperimentali non sono idonee per il Lambda Service Level Agreement (SLA) o. Supporto AWS
# Definire l'handler delle funzioni Lambda in Node.js
Il *gestore* di funzioni Lambda è il metodo nel codice della funzione che elabora gli eventi. Quando viene richiamata la funzione, Lambda esegue il metodo del gestore. La funzione viene eseguita fino a quando il gestore non restituisce una risposta, termina o scade.
Questa pagina descrive come utilizzare i gestori di funzioni Lambda in Node.js, incluse le opzioni per la configurazione del progetto, le convenzioni di denominazione e le migliori pratiche. Questa pagina include anche un esempio di funzione Lambda di Node.js che raccoglie informazioni su un ordine, produce una ricevuta in un file di testo e inserisce questo file in un bucket Amazon Simple Storage Service (Amazon S3). Per informazioni su come distribuire una funzione dopo averla scritta, consulta o. [Distribuisci funzioni Lambda in Node.js con archivi di file .zip](nodejs-package.md) [Distribuisci funzioni Lambda in Node.js con immagini di container](nodejs-image.md)
**Topics**
+ [
## Configurazione del progetto Node.js handler
](#nodejs-handler-setup)
+ [
## Esempio di codice della funzione Lambda Node.js
](#nodejs-example-code)
+ [
## Moduli CommonJS ed ES
](#nodejs-commonjs-es-modules)
+ [
## Inizializzazione di Node.js
](#nodejs-initialization)
+ [
## Convenzioni di denominazione dei gestori
](#nodejs-handler-naming)
+ [
## Definizione e accesso all'oggetto evento di input
](#nodejs-example-input)
+ [
## Modelli di gestione validi per le funzioni Node.js
](#nodejs-handler-signatures)
+ [
## Utilizzo dell'SDK per JavaScript v3 nel gestore
](#nodejs-example-sdk-usage)
+ [
## Accesso alle variabili d'ambiente
](#nodejs-example-envvars)
+ [
## Utilizzo dello stato globale
](#nodejs-handler-state)
+ [
## Best practice di codice per funzioni Lambda in Node.js
](#nodejs-best-practices)
## Configurazione del progetto Node.js handler
Esistono diversi modi per inizializzare un progetto Lambda Node.js. [Ad esempio, è possibile creare un progetto Node.js standard utilizzando`npm`, creare un'[AWS SAM applicazione](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/using-sam-cli-init.html#using-sam-cli-init-new) o creare un'AWS CDK applicazione.](lambda-cdk-tutorial.md#lambda-cdk-step-1)
Per creare il progetto utilizzando`npm`:
```
npm init
```
Questo comando inizializza il progetto e genera un `package.json` file che gestisce i metadati e le dipendenze del progetto.
Il codice della funzione risiede in un file or. `.js` `.mjs` JavaScript Nell'esempio seguente, diamo un nome a questo file `index.mjs` perché utilizza un gestore di moduli ES. Lambda supporta sia il modulo ES che i gestori CommonJS. Per ulteriori informazioni, consulta [Moduli CommonJS ed ES](#nodejs-commonjs-es-modules).
Un tipico progetto di funzione Lambda di Node.js segue questa struttura generale:
```
/project-root
├── index.mjs — Contains main handler
├── package.json — Project metadata and dependencies
├── package-lock.json — Dependency lock file
└── node_modules/ — Installed dependencies
```
## Esempio di codice della funzione Lambda Node.js
Il seguente codice di funzione Lambda di esempio raccoglie le informazioni su un ordine, produce una ricevuta in un file di testo e inserisce questo file in un bucket Amazon S3.
**Example index.mjs, funzione Lambda**
```
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';
// Initialize the S3 client outside the handler for reuse
const s3Client = new S3Client();
/**
* Lambda handler for processing orders and storing receipts in S3.
* @param {Object} event - Input event containing order details
* @param {string} event.order_id - The unique identifier for the order
* @param {number} event.amount - The order amount
* @param {string} event.item - The item purchased
* @returns {Promise} Success message
*/
export const handler = async(event) => {
try {
// Access environment variables
const bucketName = process.env.RECEIPT_BUCKET;
if (!bucketName) {
throw new Error('RECEIPT_BUCKET environment variable is not set');
}
// Create the receipt content and key destination
const receiptContent = `OrderID: ${event.order_id}\nAmount: $${event.amount.toFixed(2)}\nItem: ${event.item}`;
const key = `receipts/${event.order_id}.txt`;
// Upload the receipt to S3
await uploadReceiptToS3(bucketName, key, receiptContent);
console.log(`Successfully processed order ${event.order_id} and stored receipt in S3 bucket ${bucketName}`);
return 'Success';
} catch (error) {
console.error(`Failed to process order: ${error.message}`);
throw error;
}
};
/**
* Helper function to upload receipt to S3
* @param {string} bucketName - The S3 bucket name
* @param {string} key - The S3 object key
* @param {string} receiptContent - The content to upload
* @returns {Promise}
*/
async function uploadReceiptToS3(bucketName, key, receiptContent) {
try {
const command = new PutObjectCommand({
Bucket: bucketName,
Key: key,
Body: receiptContent
});
await s3Client.send(command);
} catch (error) {
throw new Error(`Failed to upload receipt to S3: ${error.message}`);
}
}
```
Questo file `index.mjs` contiene le sezioni seguenti:
+ Blocco `import`: utilizza questo blocco per includere le librerie richieste dalla funzione Lambda, come i [client SDK AWS](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/the-request-object.html).
+ `const s3Client`dichiarazione: inizializza un client [Amazon S3](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/s3/) al di fuori della funzione di gestione. Ciò fa sì che Lambda esegua questo codice durante la [fase di inizializzazione](lambda-runtime-environment.md#runtimes-lifecycle-ib) e il client viene preservato per il [riutilizzo](lambda-runtime-environment.md#execution-environment-reuse) su più chiamate.
+ JSDoc [blocco di commenti: definisci i tipi di input e output per il tuo gestore utilizzando le annotazioni. JSDoc ](https://jsdoc.app/about-getting-started)
+ `export const handler`: Questa è la funzione di gestione principale richiamata da Lambda. [Quando distribuisci la funzione, specifica `index.handler` la proprietà Handler.](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-Handler) Il valore della `Handler` proprietà è il nome del file e il nome del metodo del gestore esportato, separati da un punto.
+ `uploadReceiptToS3`funzione: Questa è una funzione di supporto a cui fa riferimento la funzione di gestione principale.
Affinché questa funzione funzioni correttamente, il suo [ruolo di esecuzione](lambda-intro-execution-role.md) deve consentire l'azione. `s3:PutObject` Inoltre, assicuratevi di definire la variabile di `RECEIPT_BUCKET` ambiente. Dopo una chiamata riuscita, il bucket Amazon S3 dovrebbe contenere un file di ricevuta.
## Moduli CommonJS ed ES
Node.js supporta due sistemi di moduli: CommonJS e ECMAScript modules (moduli ES). [Lambda consiglia di utilizzare i moduli ES in quanto supportano l'attesa di primo livello, che consente il completamento di attività asincrone durante l'inizializzazione dell'ambiente di esecuzione.](#nodejs-initialization)
Node.js tratta i file con estensione come moduli CommonJS mentre un'`.cjs`estensione indica i moduli ES. `.mjs` Per impostazione predefinita, Node.js tratta i file con l'estensione del nome `.js` file come moduli CommonJS. È possibile configurare Node.js per trattare `.js` i file come moduli ES specificando l'`type`as `module` nel file della funzione. `package.json` Puoi configurare Node.js in Lambda per rilevare automaticamente se un `.js` file deve essere trattato come CommonJS o come modulo ES aggiungendo il `—experimental-detect-module` flag alla variabile di ambiente. `NODE_OPTIONS` Per ulteriori informazioni, consulta le funzionalità di [Experimental Node.js](lambda-nodejs.md#nodejs-experimental-features).
Gli esempi seguenti mostrano gestori di funzioni scritti utilizzando sia i moduli ES che i moduli CommonJS. Gli esempi rimanenti in questa pagina utilizzano tutti i moduli ES.
------
#### [ ES module example ]
**Example — Gestore del modulo ES**
```
const url = "https://aws.amazon.com/";
export const handler = async(event) => {
try {
const res = await fetch(url);
console.info("status", res.status);
return res.status;
}
catch (e) {
console.error(e);
return 500;
}
};
```
------
#### [ CommonJS module example ]
**Example — Gestore del modulo CommonJS**
```
const https = require("https");
let url = "https://aws.amazon.com/";
exports.handler = async function (event) {
let statusCode;
await new Promise(function (resolve, reject) {
https.get(url, (res) => {
statusCode = res.statusCode;
resolve(statusCode);
}).on("error", (e) => {
reject(Error(e));
});
});
console.log(statusCode);
return statusCode;
};
```
------
## Inizializzazione di Node.js
Node.js utilizza un I/O modello non bloccante che supporta operazioni asincrone efficienti utilizzando un ciclo di eventi. Ad esempio, se Node.js effettua una chiamata di rete, la funzione continua a elaborare altre operazioni senza bloccare una risposta di rete. Quando viene ricevuta, la risposta di rete viene inserita nella coda di callback. Le attività della coda vengono elaborate al termine dell'operazione corrente.
Lambda consiglia di utilizzare l'await di primo livello in modo che le attività asincrone avviate durante l'inizializzazione dell'ambiente di esecuzione vengano completate durante l'inizializzazione. Le attività asincrone che non vengono completate durante l'inizializzazione vengono in genere eseguite durante la prima chiamata della funzione. Ciò può causare comportamenti o errori imprevisti. Ad esempio, l'inizializzazione della funzione può effettuare una chiamata di rete per recuperare un AWS parametro da Parameter Store. Se questa attività non viene completata durante l'inizializzazione, il valore può essere nullo durante una chiamata. Può inoltre verificarsi un ritardo tra l'inizializzazione e l'invoca, che può causare errori nelle operazioni che richiedono un intervallo di tempo. In particolare, le chiamate AWS di servizio possono basarsi su firme di richiesta sensibili al fattore tempo, con conseguenti errori nelle chiamate di servizio se la chiamata non viene completata durante la fase di inizializzazione. Il completamento delle attività durante l'inizializzazione in genere migliora le prestazioni di avvio a freddo e richiama innanzitutto le prestazioni quando si utilizza Provisioned Concurrency. Per ulteriori informazioni, consulta il nostro post sul blog [Using Node.js ES](https://aws.amazon.com/blogs/compute/using-node-js-es-modules-and-top-level-await-in-aws-lambda) modules and top-level await in. AWS Lambda
## Convenzioni di denominazione dei gestori
Quando si configura una funzione, il valore dell'impostazione [Handler](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-Handler) è il nome del file e il nome del metodo del gestore esportato, separati da un punto. L'impostazione predefinita per le funzioni create nella console e negli esempi in questa guida è `index.handler`. Questo indica il metodo `handler` che viene esportato dal file `index.js` o `index.mjs`.
Se si crea una funzione nella console utilizzando un nome di file o un nome del gestore di funzione diverso, è necessario modificare il nome del gestore predefinito.
**Modifica del nome del gestore funzioni (console)**
1. Apri la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda e scegli la tua funzione.
1. Scegli la scheda **Codice**.
1. Scorri verso il basso fino al riquadro **Impostazioni di runtime** e scegli **Modifica**.
1. In **Gestore**, inserisci il nuovo nome per il tuo gestore di funzioni.
1. Scegli **Save** (Salva).
## Definizione e accesso all'oggetto evento di input
JSON è il formato di input più comune e standard per le funzioni Lambda. In questo esempio, la funzione prevede un input simile a quanto segue:
```
{
"order_id": "12345",
"amount": 199.99,
"item": "Wireless Headphones"
}
```
Quando si utilizzano le funzioni Lambda in Node.js, è possibile definire la forma prevista dell'evento di input utilizzando JSDoc le annotazioni. In questo esempio, definiamo la struttura di input nel commento del gestore: JSDoc
```
/**
* Lambda handler for processing orders and storing receipts in S3.
* @param {Object} event - Input event containing order details
* @param {string} event.order_id - The unique identifier for the order
* @param {number} event.amount - The order amount
* @param {string} event.item - The item purchased
* @returns {Promise} Success message
*/
```
Dopo aver definito questi tipi nel JSDoc commento, potete accedere ai campi dell'oggetto evento direttamente nel codice. Ad esempio, `event.order_id` recupera il valore di `order_id` dall'input originale.
## Modelli di gestione validi per le funzioni Node.js
[Si consiglia di utilizzare [async/await](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/using-async-await.html) per dichiarare il gestore della funzione invece di utilizzare i callback.](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/using-a-callback-function.html) Async/await è un modo conciso e leggibile per scrivere codice asincrono, senza la necessità di callback annidati o di concatenare promesse. Con async/await puoi scrivere codice che si legga come codice sincrono, pur rimanendo asincrono e privo di blocchi.
### gestori di funzioni asincrone (consigliati)
La parola chiave `async` contrassegna una funzione come asincrona, mentre la parola chiave `await` mette in pausa l'esecuzione della funzione fino alla risoluzione di `Promise`. Il gestore accetta i seguenti argomenti:
+ `event`: contiene i dati di input passati alla funzione.
+ `context`: contiene informazioni sull'invocazione, sulla funzione e sull'ambiente di esecuzione. Per ulteriori informazioni, consulta [Utilizzo dell'oggetto di contesto Lambda per recuperare le informazioni sulla funzione Node.js](nodejs-context.md).
Ecco le firme valide per il async/await modello:
```
export const handler = async (event) => { };
```
```
export const handler = async (event, context) => { };
```
### Gestori di funzioni sincroni
Se la funzione non esegue attività asincrone, è possibile utilizzare un gestore di funzioni sincrono, utilizzando una delle seguenti firme di funzione:
```
export const handler = (event) => { };
```
```
export const handler = (event, context) => { };
```
### Gestori di funzioni di streaming delle risposte
Lambda supporta lo streaming delle risposte con Node.js. I gestori delle funzioni di streaming delle risposte utilizzano il `awslambda.streamifyResponse()` decoratore e accettano 3 parametri:`event`, e. `responseStream` `context` La firma della funzione è:
```
export const handler = awslambda.streamifyResponse(async (event, responseStream, context) => { });
```
Per ulteriori informazioni, consulta [Streaming di risposte per le funzioni Lambda](configuration-response-streaming.md).
### gestori di funzioni basati su callback
**Nota**
I gestori di funzioni basati su callback sono supportati solo fino a Node.js 22. A partire da Node.js 24, le attività asincrone devono essere implementate utilizzando gestori di funzioni asincrone.
I gestori di funzioni basati sul callback devono utilizzare gli argomenti event, context e callback. Esempio:
```
export const handler = (event, context, callback) => { };
```
La funzione di callback prevede una risposta e una, che deve essere serializzabile in `Error` formato JSON. La funzione continua a essere eseguita fino a quando il [ciclo di eventi non è vuoto o fino al timeout](https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/) della funzione. La risposta non viene inviata all'invoker finché tutte le attività del ciclo di eventi non giungono a termine. Se la funzione va in timeout, viene invece restituito un errore. È possibile configurare il runtime per inviare immediatamente la risposta impostando il [contesto. callbackWaitsForEmptyEventLoop](nodejs-context.md)a false.
**Example – richiesta HTTP con callback**
La seguente funzione di esempio controlla un URL e restituisce il codice di stato all'invoker.
```
import https from "https";
let url = "https://aws.amazon.com/";
export const handler = (event, context, callback) => {
https.get(url, (res) => {
callback(null, res.statusCode);
}).on("error", (e) => {
callback(Error(e));
});
};
```
## Utilizzo dell'SDK per JavaScript v3 nel gestore
Spesso, utilizzerai le funzioni Lambda per interagire o aggiornare altre AWS risorse. Il modo più semplice per interfacciarsi con queste risorse è usare la AWS SDK per JavaScript. Tutti i [runtime Lambda Node.js supportati](lambda-nodejs.md#nodejs-supported-runtimes) includono l'[SDK per la versione](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/introduction/) 3. JavaScript Tuttavia, consigliamo vivamente di includere i client AWS SDK necessari nel pacchetto di distribuzione. Ciò massimizza la [compatibilità con le versioni precedenti durante](runtimes-update.md#runtime-update-compatibility) i futuri aggiornamenti del runtime Lambda. Affidati all'SDK fornito in fase di esecuzione solo quando non puoi includere pacchetti aggiuntivi (ad esempio, quando usi l'editor di codice della console Lambda o il codice in linea in un modello). AWS CloudFormation
Per aggiungere dipendenze SDK alla tua funzione, usa il `npm install` comando per i client SDK specifici di cui hai bisogno. Nel codice di esempio, abbiamo usato il client [Amazon S3](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/s3/). Aggiungi queste dipendenze eseguendo i seguenti comandi nella directory che contiene il file `package.json`:
```
npm install @aws-sdk/client-s3
```
Nel codice della funzione, importa il client e i comandi di cui hai bisogno, come dimostra la funzione di esempio:
```
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';
```
Quindi, inizializza un client [Amazon S3:](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/s3/)
```
const s3Client = new S3Client();
```
In questo esempio, abbiamo inizializzato il nostro client Amazon S3 all’esterno della funzione del gestore principale per evitare di doverlo inizializzare ogni volta che invochiamo la nostra funzione. Dopo aver inizializzato il client SDK, puoi utilizzarlo per effettuare chiamate API per quel servizio. AWS Il codice di esempio richiama l'azione dell'[PutObject](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/s3/command/PutObjectCommand/)API Amazon S3 nel modo seguente:
```
const command = new PutObjectCommand({
Bucket: bucketName,
Key: key,
Body: receiptContent
});
```
## Accesso alle variabili d'ambiente
Nel codice del gestore, puoi fare riferimento a qualsiasi [variabile di ambiente utilizzando](configuration-envvars.md). `process.env` In questo esempio, facciamo riferimento alla variabile di ambiente `RECEIPT_BUCKET` definita utilizzando le seguenti righe di codice:
```
// Access environment variables
const bucketName = process.env.RECEIPT_BUCKET;
if (!bucketName) {
throw new Error('RECEIPT_BUCKET environment variable is not set');
}
```
## Utilizzo dello stato globale
Lambda esegue il codice statico durante la [fase di inizializzazione](lambda-runtime-environment.md#runtimes-lifecycle-ib) prima di richiamare la funzione per la prima volta. Le risorse create durante l'inizializzazione restano in memoria tra le invocazioni, in modo da evitare di doverle creare ogni volta che si invoca la funzione.
Nel codice di esempio, il codice di inizializzazione del client S3 è esterno al gestore. Il runtime inizializza il client prima che la funzione gestisca il primo evento e il client rimane disponibile per il riutilizzo in tutte le chiamate.
## Best practice di codice per funzioni Lambda in Node.js
Segui queste linee guida durante la creazione di funzioni Lambda:
+ **Separare il gestore Lambda dalla logica principale.** In questo modo è possibile creare una funzione di cui è più semplice eseguire l'unit test.
+ **Controllare le dipendenze nel pacchetto di distribuzione della funzione. ** L'ambiente di AWS Lambda esecuzione contiene diverse librerie. Per i runtime Node.js e Python, questi includono. AWS SDKs Per abilitare il set di caratteristiche e aggiornamenti della sicurezza più recenti, Lambda aggiorna periodicamente tali librerie. Tali aggiornamenti possono introdurre lievi modifiche al comportamento della funzione Lambda. Per mantenere il controllo completo delle dipendenze utilizzate dalla funzione, inserire tutte le dipendenze nel pacchetto di implementazione.
+ **Ridurre la complessità delle dipendenze.** Preferire framework più semplici che si caricano velocemente all'avvio del [contesto di esecuzione](lambda-runtime-environment.md).
+ **Ridurre al minimo le dimensioni del pacchetto di implementazione al fine di soddisfare le esigenze di runtime. ** In questo modo viene ridotta la quantità di tempo necessaria per il download del pacchetto e per la relativa decompressione prima dell'invocazione.
**Sfruttare il riutilizzo del contesto di esecuzione per migliorare le prestazioni della funzione.** Inizializzare i client SDK e le connessioni al database all'esterno del gestore di funzioni e memorizzare localmente nella cache gli asset statici nella directory `/tmp`. Le chiamate successive elaborate dalla stessa istanza della funzione possono riutilizzare queste risorse. Ciò consente di risparmiare sui costi riducendo i tempi di esecuzione delle funzioni.
Per evitare potenziali perdite di dati tra le chiamate, non utilizzare il contesto di esecuzione per archiviare dati utente, eventi o altre informazioni con implicazioni di sicurezza. Se la funzione si basa su uno stato mutabile che non può essere archiviato in memoria all'interno del gestore, considerare la possibilità di creare una funzione separata o versioni separate di una funzione per ogni utente.
**Utilizzare una direttiva keep-alive per mantenere le connessioni persistenti.** Lambda elimina le connessioni inattive nel tempo. Se si tenta di riutilizzare una connessione inattiva quando si richiama una funzione, si verificherà un errore di connessione. Per mantenere la connessione persistente, utilizzare la direttiva keep-alive associata al runtime. Per un esempio, vedere [Riutilizzo delle connessioni con Keep-Alive in Node.js](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/node-reusing-connections.html).
**Utilizzare [le variabili di ambiente](configuration-envvars.md) per passare i parametri operativi alla funzione.** Se ad esempio si scrive in un bucket Amazon S3 anziché impostare come hard-coded il nome del bucket in cui si esegue la scrittura, configurare tale nome come una variabile di ambiente.
**Evita di usare invocazioni ricorsive** nella tua funzione Lambda, in cui la funzione si richiama da sola o avvia un processo che potrebbe richiamare nuovamente la funzione. Ciò potrebbe provocare un volume non desiderato di invocazioni della funzione e un aumento dei costi. Se noti un volume indesiderato di invocazioni, imposta immediatamente la simultaneità riservata della funzione su `0` per interrompere tutte le invocazioni della funzione mentre si aggiorna il codice.
**Non utilizzare documenti non documentati e non pubblici APIs** nel codice della funzione Lambda. Per i runtime AWS Lambda gestiti, Lambda applica periodicamente aggiornamenti di sicurezza e funzionalità all'interno di Lambda. APIs Questi aggiornamenti delle API interne possono essere incompatibili con le versioni precedenti e portare a conseguenze indesiderate, come errori di chiamata se la funzione dipende da questi elementi non pubblici. APIs [Consulta il riferimento alle API per un elenco di quelle disponibili al pubblico.](https://docs.aws.amazon.com/lambda/latest/api/welcome.html) APIs
**Scrivi un codice idempotente.** La scrittura di un codice idempotente per le tue funzioni garantisce che gli eventi duplicati vengano gestiti allo stesso modo. Il tuo codice dovrebbe convalidare correttamente gli eventi e gestire con garbo gli eventi duplicati. Per ulteriori informazioni, consulta [Come posso rendere idempotente la mia funzione Lambda?](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-function-idempotent/).
# Distribuisci funzioni Lambda in Node.js con archivi di file .zip
Il codice della AWS Lambda funzione comprende un file .js o .mjs contenente il codice del gestore della funzione, insieme a tutti i pacchetti e moduli aggiuntivi da cui dipende il codice. Per implementare questo codice della funzione in Lambda, utilizza un *pacchetto di implementazione*. Questo pacchetto può essere un archivio di file .zip o un'immagine di container. Per ulteriori informazioni sull'uso delle immagini di container con Node.js, consulta la pagina [Implementazione di funzioni Lambda in Node.js con immagini di container](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-image.html).
Per creare un pacchetto di implementazione come archivio di file .zip, puoi utilizzare l'utilità di archiviazione di file .zip incorporata del tuo strumento della linea di comando o qualsiasi altra utilità file .zip, come ad esempio [7zip](https://www.7-zip.org/download.html). Gli esempi mostrati nelle sezioni seguenti presuppongono che tu stia utilizzando uno strumento della linea di comando `zip` in un ambiente Linux o MacOS. Per utilizzare gli stessi comandi in Windows, puoi [installare il sottosistema Windows per Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10) per ottenere una versione di Ubuntu e Bash integrata con Windows.
Nota che Lambda utilizza le autorizzazioni dei file POSIX, quindi potresti aver bisogno di [impostare le autorizzazioni per la cartella del pacchetto di implementazione](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-deployment-package-errors/) prima di creare l'archivio di file .zip.
**Topics**
+ [
## Dipendenze di runtime in Node.js
](#nodejs-package-dependencies)
+ [
## Creazione di un pacchetto di implementazione .zip senza dipendenze
](#nodejs-package-create-no-dependencies)
+ [
## Creazione di un pacchetto di implementazione .zip con dipendenze
](#nodejs-package-create-dependencies)
+ [
## Creazione di un livello Node.js per dipendenze
](#nodejs-package-dependencies-layers)
+ [
## Percorso di ricerca delle dipendenze e librerie incluse nel runtime
](#nodejs-package-searchpath)
+ [
## Creazione e aggiornamento delle funzioni Lambda di Node.js utilizzando file .zip
](#nodejs-package-create-update)
## Dipendenze di runtime in Node.js
Per le funzioni Lambda che utilizzano il runtime di Node.js, una dipendenza può essere qualsiasi modulo Node.js. Il runtime di Node.js include una serie di librerie comuni, oltre a una versione di AWS SDK per JavaScript. Tutti i [runtime Node.js supportati](lambda-nodejs.md#nodejs-supported-runtimes) includono la versione 3 dell'SDK. Per utilizzare la versione 2 dell'SDK, è necessario aggiungere l'SDK al pacchetto di distribuzione del file.zip. Per trovare la versione specifica dell'SDK inclusa nel runtime che stai utilizzando, consulta. [Versioni SDK incluse nel runtime](lambda-nodejs.md#nodejs-sdk-included)
Lambda aggiorna periodicamente le librerie SDK nel runtime di Node.js per includere le funzionalità e gli aggiornamenti di sicurezza più recenti. Lambda applica anche patch di sicurezza e aggiornamenti alle altre librerie incluse nel runtime. Per avere il pieno controllo delle dipendenze del pacchetto, puoi aggiungere la tua versione preferita di qualsiasi dipendenza inclusa nel runtime al tuo pacchetto di implementazione. Ad esempio, se desideri utilizzare una versione particolare dell'SDK per JavaScript, puoi includerla nel tuo file.zip come dipendenza. Per ulteriori informazioni sull'aggiunta di dipendenze incluse nel runtime al tuo file .zip, consulta la pagina [Percorso di ricerca delle dipendenze e librerie incluse nel runtime](#nodejs-package-searchpath).
In base al [modello di responsabilità condivisa di AWS](lambda-runtimes.md#runtimes-shared-responsibility), è tua responsabilità gestire eventuali dipendenze nei pacchetti di implementazione delle tue funzioni. Ciò include l'applicazione di aggiornamenti e patch di sicurezza. Per aggiornare le dipendenze nel pacchetto di implementazione della funzione, crea prima un nuovo file .zip e poi caricalo su Lambda. Per ulteriori informazioni, consulta [Creazione di un pacchetto di implementazione .zip con dipendenze](#nodejs-package-create-dependencies) e [Creazione e aggiornamento delle funzioni Lambda di Node.js utilizzando file .zip](#nodejs-package-create-update).
## Creazione di un pacchetto di implementazione .zip senza dipendenze
Se il codice della funzione non ha dipendenze oltre alle librerie incluse nel runtime Lambda, il file .zip contiene solo il file `index.js` o `index.mjs` con il codice del gestore della funzione. Utilizza il tuo strumento di compressione preferito per creare un file .zip con il file `index.js` o `index.mjs` nella directory principale. Se il file contenente il codice del gestore della funzione non si trova nella directory principale del file .zip, Lambda non è in grado di eseguire il codice.
Per informazioni su come implementare il file .zip per creare una nuova funzione Lambda o aggiornarne una esistente, consulta la sezione [Creazione e aggiornamento delle funzioni Lambda di Node.js utilizzando file .zip](#nodejs-package-create-update).
## Creazione di un pacchetto di implementazione .zip con dipendenze
Se il codice della funzione dipende da pacchetti o moduli non inclusi nel runtime Node.js di Lambda, puoi aggiungere queste dipendenze al file .zip con il codice della funzione oppure utilizzare un [livello Lambda](chapter-layers.md). Le istruzioni in questa sezione mostrano come includere le dipendenze nel pacchetto di implementazione .zip. Per istruzioni sull'inclusione di dipendenze in un livello, consulta [Creazione di un livello Node.js per dipendenze](#nodejs-package-dependencies-layers).
I seguenti comandi della CLI di esempio creano un file .zip denominato `my_deployment_package.zip` contenente il file `index.js` o `index.mjs` con il codice del gestore della funzione e le relative dipendenze. Nell'esempio, installi le dipendenze utilizzando il gestore di pacchetti npm.
**Per creare il pacchetto di implementazione**
1. Passa alla directory del progetto contenente il file del codice sorgente `index.js` o `index.mjs`. In questo esempio, la directory è denominata `my_function`.
```
cd my_function
```
1. Installa le librerie richieste dalla tua funzione nella directory `node_modules` utilizzando il comando `npm install`. In questo esempio installi l' SDK AWS X-Ray per Node.js.
```
npm install aws-xray-sdk
```
Questo crea una struttura di cartelle simile alla seguente:
```
~/my_function
├── index.mjs
└── node_modules
├── async
├── async-listener
├── atomic-batcher
├── aws-sdk
├── aws-xray-sdk
├── aws-xray-sdk-core
```
Al tuo pacchetto di implementazione puoi anche aggiungere moduli personalizzati che crei in autonomia. Crea una directory in `node_modules` con il nome del tuo modulo e salva lì i tuoi pacchetti personalizzati.
1. Crea un file .zip dei contenuti della cartella di progetto della directory principale. Utilizza l'opzione (ricorsiva) `r` per garantire che lo zip comprima le sottocartelle.
```
zip -r my_deployment_package.zip .
```
## Creazione di un livello Node.js per dipendenze
Le istruzioni in questa sezione spiegano come includere dipendenze in un livello. Per istruzioni sull'inclusione di dipendenze in un pacchetto di implementazione, consulta [Creazione di un pacchetto di implementazione .zip con dipendenze](#nodejs-package-create-dependencies).
Quando si aggiunge un livello a una funzione, Lambda carica il contenuto del livello nella directory `/opt` di quell'ambiente di esecuzione. Per ogni runtime Lambda, la variabile `PATH` include percorsi di cartelle specifici nella directory `/opt`. Per garantire che Lambda raccolga il contenuto del layer, il file.zip del layer deve avere le sue dipendenze in uno dei seguenti percorsi di cartella:
+ `nodejs/node_modules`
+ `nodejs/node18/node_modules (NODE_PATH)`
+ `nodejs/node20/node_modules (NODE_PATH)`
+ `nodejs/node22/node_modules (NODE_PATH)`
Ad esempio, la struttura del file .zip del livello potrebbe essere simile alla seguente:
```
xray-sdk.zip
└ nodejs/node_modules/aws-xray-sdk
```
Lambda rileva automaticamente tutte le librerie nella directory `/opt/lib` e tutti i file binari nella directory `/opt/bin`. Per accertarti che Lambda trovi correttamente il contenuto del tuo livello, crea un livello con la seguente struttura:
```
custom-layer.zip
└ lib
| lib_1
| lib_2
└ bin
| bin_1
| bin_2
```
Dopo aver creato un pacchetto del livello, consulta [Creazione ed eliminazione di livelli in Lambda](creating-deleting-layers.md) e [Aggiunta di livelli alle funzioni](adding-layers.md) per completare l'impostazione del livello.
## Percorso di ricerca delle dipendenze e librerie incluse nel runtime
Il runtime di Node.js include una serie di librerie comuni, oltre a una versione di AWS SDK per JavaScript. Se desideri utilizzare una versione diversa di una libreria inclusa nel runtime, puoi farlo raggruppandola con la tua funzione o aggiungendola come dipendenza nel tuo pacchetto di implementazione. Ad esempio, puoi utilizzare una versione diversa dell'SDK aggiungendola al tuo pacchetto di implementazione .zip. Puoi anche includerlo in un [livello Lambda](chapter-layers.md) per la tua funzione.
Quando utilizzi un'istruzione `import` o `require` nel codice, il runtime di Node.js cerca nelle directory nel percorso `NODE_PATH` finché non trova il modulo. Per impostazione predefinita, la prima posizione cercata dal runtime è la directory in cui il pacchetto di implementazione .zip viene decompresso e montato (`/var/task`). Se includi una versione di una libreria inclusa nel runtime nel tuo pacchetto di implementazione, questa versione avrà la precedenza sulla versione inclusa nel runtime. Le dipendenze nel pacchetto di implementazione hanno la precedenza anche sulle dipendenze nei livelli.
Quando aggiungi una dipendenza a un livello, Lambda la estrae in `/opt/nodejs/nodexx/node_modules`, dove `nodexx` rappresenta la versione del runtime che stai utilizzando. Nel percorso di ricerca, questa directory ha la precedenza sulla directory contenente le librerie incluse nel runtime (`/var/lang/lib/node_modules`). Le librerie nei livelli di funzione hanno quindi la precedenza sulle versioni incluse nel runtime.
Puoi visualizzare il percorso di ricerca completo per la tua funzione Lambda aggiungendo la seguente riga di codice.
```
console.log(process.env.NODE_PATH)
```
Puoi anche aggiungere dipendenze in una cartella separata all'interno del tuo pacchetto .zip. Ad esempio, potresti aggiungere un modulo personalizzato a una cartella del tuo pacchetto .zip denominata `common`. Quando il pacchetto .zip viene decompresso e montato, questa cartella viene inserita nella directory `/var/task`. Per utilizzare una dipendenza da una cartella del pacchetto di implementazione .zip nel codice, utilizza un'istruzione `import { } from` o `const { } = require()`, a seconda che tu stia utilizzando la risoluzione del modulo CJS o ESM. Esempio:
```
import { myModule } from './common'
```
Se raggruppi il codice con `esbuild`, `rollup` o qualcosa di simile, le dipendenze utilizzate dalla funzione vengono raggruppate in uno o più file. Si consiglia di utilizzare questo metodo per eliminare le dipendenze ogni volta che è possibile. Rispetto all'aggiunta di dipendenze al pacchetto di distribuzione, il raggruppamento del codice consente di migliorare le prestazioni grazie alla riduzione delle operazioni. I/O
## Creazione e aggiornamento delle funzioni Lambda di Node.js utilizzando file .zip
Dopo aver creato il pacchetto di implementazione .zip, puoi utilizzarlo per creare una nuova funzione Lambda o aggiornarne una esistente. Puoi distribuire il tuo pacchetto.zip utilizzando la console Lambda, l'API Lambda AWS Command Line Interface e l'API Lambda. Puoi anche creare e aggiornare le funzioni Lambda usando AWS Serverless Application Model (AWS SAM) e CloudFormation.
La dimensione massima per un pacchetto di implementazione .zip per Lambda è di 250 MB (dopo l'estrazione). Nota che questo limite si applica alla dimensione combinata di tutti i file caricati, inclusi eventuali livelli Lambda.
Il runtime Lambda necessita dell'autorizzazione per leggere i file nel pacchetto di distribuzione. Nella notazione ottale delle autorizzazioni Linux, Lambda richiede 644 permessi per i file non eseguibili (rw-r--r--) e 755 permessi () per le directory e i file eseguibili. rwxr-xr-x
In Linux e macOS, utilizza il comando `chmod` per modificare le autorizzazioni file su file e directory nel pacchetto di implementazione. Ad esempio, per assegnare a un file non eseguibile le autorizzazioni corrette, utilizza il comando seguente.
```
chmod 644
```
Per modificare le autorizzazioni file in Windows, consulta [Set, View, Change, or Remove Permissions on an Object](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731667(v=ws.10)) nella documentazione di Microsoft Windows.
**Nota**
Se non concedi a Lambda le autorizzazioni necessarie per accedere alle directory nel pacchetto di distribuzione, Lambda imposta le autorizzazioni per tali directory su 755 (). rwxr-xr-x
### Creazione e aggiornamento delle funzioni con file .zip utilizzando la console
Per creare una nuova funzione, devi prima creare la funzione nella console, quindi devi caricare il tuo archivio .zip. Per aggiornare una funzione esistente, apri la pagina relativa alla funzione, quindi segui la stessa procedura per aggiungere il file .zip aggiornato.
Se il file .zip ha dimensioni inferiori a 50 MB, è possibile creare o aggiornare una funzione caricando il file direttamente dal computer locale. Per i file .zip di dimensioni superiori a 50 MB, prima è necessario caricare il pacchetto in un bucket Amazon S3. Per istruzioni su come caricare un file in un bucket Amazon S3 utilizzando Console di gestione AWS, consulta la [Guida introduttiva ad Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html). *Per caricare file utilizzando la AWS CLI, consulta [Move objects](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) nella Guida per l'AWS CLI utente.*
**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.
**Creazione di una nuova funzione (console)**
1. Apri la [pagina Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda e scegli **Crea funzione**.
1. Scegli **Author from scratch** (Crea da zero).
1. In **Basic information (Informazioni di base)** eseguire queste operazioni:
1. In **Nome funzione**, inserisci il nome della funzione.
1. Per **Runtime**, seleziona il runtime che desideri utilizzare.
1. (Facoltativo) Per **Architettura**, scegli l'architettura del set di istruzioni per la funzione. L'architettura predefinita è x86\$164. Assicurati che il pacchetto di implementazione per la tua funzione sia compatibile con l'architettura del set di istruzioni scelta.
1. (Opzionale) In **Autorizzazioni** espandere **Modifica ruolo di esecuzione predefinito**. Puoi creare un nuovo **ruolo di esecuzione** o utilizzare un ruolo esistente.
1. Scegli **Crea funzione**. Lambda crea una funzione di base "Hello world" utilizzando il runtime scelto.
**Caricamento di un archivio .zip dal computer locale (console)**
1. Nella [pagina Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda, scegli la funzione per cui vuoi caricare il file .zip.
1. Scegli la scheda **Codice**.
1. Nel riquadro **Origine del codice**, scegli **Carica da**.
1. Scegli **File .zip**.
1. Per caricare il file .zip, procedi come segue:
1. Seleziona **Carica**, quindi seleziona il tuo file .zip nel selettore di file.
1. Seleziona **Apri**.
1. Scegli **Save** (Salva).
**Caricamento di un archivio .zip da un bucket Amazon S3 (console)**
1. Nella [pagina Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda, scegli la funzione per cui vuoi caricare un nuovo file .zip.
1. Scegli la scheda **Codice**.
1. Nel riquadro **Origine del codice**, scegli **Carica da**.
1. Scegli **Posizione Amazon S3**.
1. Incolla l'URL del link Amazon S3 del tuo file .zip e scegli **Salva**.
### Aggiornamento delle funzioni dei file .zip tramite l'editor di codice della console
Per alcune funzioni con pacchetti di implementazione .zip, puoi utilizzare l'editor di codice integrato nella console Lambda per aggiornare direttamente il codice della funzione. Per utilizzare questa funzione, la funzione deve soddisfare i seguenti criteri:
+ La funzione deve utilizzare uno dei runtime del linguaggio interpretato (Python, Node.js o Ruby)
+ Il pacchetto di implementazione della funzione deve avere dimensioni inferiori a 50 MB (non compresso).
Il codice della funzione per le funzioni con pacchetti di implementazione di immagini di container non può essere modificato direttamente nella console.
**Aggiornamento del codice della funzione utilizzando l'editor di codice della console**
1. Apri la [pagina Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda e scegli la tua funzione.
1. Scegli la scheda **Codice**.
1. Nel riquadro **Origine del codice**, seleziona il tuo file di codice sorgente e modificalo nell'editor di codice integrato.
1. Nella sezione **DEPLOY**, scegli **Implementa** per aggiornare il codice della tua funzione:
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/getting-started-tutorial/deploy-console.png)
### Creazione e aggiornamento di funzioni con file.zip utilizzando il AWS CLI
È possibile utilizzare la [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) per creare una nuova funzione o aggiornare una funzione esistente mediante un file .zip. Usa la funzione [create-function](https://docs.aws.amazon.com/cli/latest/reference/lambda/create-function.html) e [update-function-code](https://docs.aws.amazon.com/cli/latest/reference/lambda/create-function.html)i comandi per distribuire il tuo pacchetto .zip. Se il file .zip ha dimensioni inferiori a 50 MB, è possibile caricare il pacchetto .zip da una posizione di file nella macchina di compilazione locale. Per i file di dimensioni maggiori, è necessario caricare il pacchetto .zip da un bucket Amazon S3. *Per istruzioni su come caricare un file su un bucket Amazon S3 utilizzando AWS CLI, consulta [Move objects](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) nella User Guide.AWS CLI *
**Nota**
Se carichi il tuo file.zip da un bucket Amazon S3 utilizzando AWS CLI il, il bucket deve trovarsi nella stessa posizione della Regione AWS tua funzione.
Per creare una nuova funzione utilizzando un file.zip con AWS CLI, devi specificare quanto segue:
+ Il nome della funzione (`--function-name`)
+ Il runtime della tua funzione (`--runtime`)
+ Il nome della risorsa Amazon (ARN) del [ruolo di esecuzione](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) della funzione (`--role`)
+ Il nome del metodo del gestore nel codice della funzione (`--handler`)
È inoltre necessario specificare la posizione del file .zip. Se il file .zip si trova in una cartella sulla macchina di compilazione locale, utilizza l'opzione `--zip-file` per specificare il percorso del file, come mostrato nel seguente comando di esempio.
```
aws lambda create-function --function-name myFunction \
--runtime nodejs24.x --handler index.handler \
--role arn:aws:iam::111122223333:role/service-role/my-lambda-role \
--zip-file fileb://myFunction.zip
```
Per specificare la posizione del file .zip in un bucket Amazon S3, utilizza l'opzione `--code` illustrata nel seguente comando di esempio. È necessario utilizzare il parametro `S3ObjectVersion` solo per gli oggetti con controllo delle versioni.
```
aws lambda create-function --function-name myFunction \
--runtime nodejs24.x --handler index.handler \
--role arn:aws:iam::111122223333:role/service-role/my-lambda-role \
--code S3Bucket=amzn-s3-demo-bucket,S3Key=myFileName.zip,S3ObjectVersion=myObjectVersion
```
Per aggiornare una funzione esistente mediante la CLI, specifica il nome della funzione utilizzando il parametro `--function-name`. È inoltre necessario specificare la posizione del file .zip che desideri utilizzare per aggiornare il codice della funzione. Se il file .zip si trova in una cartella sulla macchina di compilazione locale, utilizza l'opzione `--zip-file` per specificare il percorso del file, come mostrato nel seguente comando di esempio.
```
aws lambda update-function-code --function-name myFunction \
--zip-file fileb://myFunction.zip
```
Per specificare la posizione del file .zip in un bucket Amazon S3, utilizza le opzioni `--s3-bucket` e `--s3-key` come illustrato nel seguente comando di esempio. È necessario utilizzare il parametro `--s3-object-version` solo per gli oggetti con controllo delle versioni.
```
aws lambda update-function-code --function-name myFunction \
--s3-bucket amzn-s3-demo-bucket --s3-key myFileName.zip --s3-object-version myObject Version
```
### Creazione e aggiornamento delle funzioni con file .zip utilizzando l'API Lambda
Per creare e aggiornare le funzioni mediante un archivio di file .zip, utilizza le seguenti operazioni API:
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)
+ [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html)
### Creazione e aggiornamento di funzioni con file.zip utilizzando AWS SAM
Il AWS Serverless Application Model (AWS SAM) è un toolkit che aiuta a semplificare il processo di creazione ed esecuzione di applicazioni serverless su. AWS Definisci le risorse per la tua applicazione in un modello YAML o JSON e utilizzi l'interfaccia a riga di AWS SAM comando (AWS SAM CLI) per creare, impacchettare e distribuire le tue applicazioni. Quando crei una funzione Lambda da un AWS SAM modello, crea AWS SAM automaticamente un pacchetto di distribuzione.zip o un'immagine del contenitore con il codice della funzione e le eventuali dipendenze specificate. Per ulteriori informazioni sull'utilizzo AWS SAM per creare e distribuire funzioni Lambda, [consulta la Guida introduttiva AWS Serverless Application Model](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-getting-started.html) *alla AWS SAM* Developer Guide.
È inoltre possibile utilizzare AWS SAM per creare una funzione Lambda utilizzando un archivio di file.zip esistente. Per creare una funzione Lambda utilizzando AWS SAM, puoi salvare il tuo file.zip in un bucket Amazon S3 o in una cartella locale sulla tua macchina di compilazione. *Per istruzioni su come caricare un file su un bucket Amazon S3 utilizzando AWS CLI, consulta [Move objects](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) nella User Guide.AWS CLI *
Nel AWS SAM modello, la `AWS::Serverless::Function` risorsa specifica la funzione Lambda. In questa risorsa, imposta le seguenti proprietà per creare una funzione utilizzando un archivio di file .zip:
+ `PackageType`: imposta il valore su `Zip`
+ `CodeUri`- impostato sull'URI Amazon S3 del codice della funzione, sul percorso della cartella locale o sull'oggetto [FunctionCode](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-function-functioncode.html)
+ `Runtime`: imposta il runtime prescelto
Inoltre AWS SAM, se il tuo file.zip è più grande di 50 MB, non è necessario caricarlo prima in un bucket Amazon S3. AWS SAM puoi caricare pacchetti.zip fino alla dimensione massima consentita di 250 MB (decompressi) da una posizione sulla macchina di compilazione locale.
*Per ulteriori informazioni sulla distribuzione delle funzioni utilizzando il file.zip in AWS SAM, consulta la Guida per gli sviluppatori. [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)AWS SAM *
### Creazione e aggiornamento di funzioni con file.zip utilizzando CloudFormation
È possibile utilizzare CloudFormation per creare una funzione Lambda utilizzando un archivio di file.zip. Per creare una funzione Lambda da un file .zip, devi prima caricare il file su un bucket Amazon S3. *Per istruzioni su come caricare un file su un bucket Amazon S3 utilizzando AWS CLI, consulta [Move objects](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) nella User Guide.AWS CLI *
Nel CloudFormation modello, la `AWS::Lambda::Function` risorsa specifica la funzione Lambda. In questa risorsa, imposta le seguenti proprietà per creare una funzione utilizzando un archivio di file .zip:
+ `PackageType`: imposta il valore su `Zip`
+ `Code`: inserisci il nome del bucket Amazon S3 e il nome del file .zip nei campi `S3Bucket` e `S3Key`
+ `Runtime`: imposta il runtime prescelto
Il file.zip che CloudFormation genera non può superare i 4 MB. *Per ulteriori informazioni sulla distribuzione delle funzioni utilizzando il file.zip in CloudFormation, [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)consultate la Guida per l'utente.CloudFormation *
# Distribuisci funzioni Lambda in Node.js con immagini di container
Esistono tre modi per creare un'immagine di container per una funzione Lambda in Node.js:
+ [Utilizzo di un'immagine di AWS base per Node.js](#nodejs-image-instructions)
[Le immagini di base AWS](images-create.md#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](images-create.md#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 al fine di implementare un [runtime personalizzato](runtimes-custom.md). Per rendere l'immagine compatibile con Lambda, devi includere il [client di interfaccia di runtime per Node.js](#nodejs-image-clients) nell'immagine.
+ [Utilizzo di un'immagine non di base AWS ](#nodejs-image-clients)
È 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 il [client di interfaccia di runtime per Node.js](#nodejs-image-clients) nell'immagine.
**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/).
Questa pagina spiega come creare, testare e implementare le immagini di container per Lambda.
**Topics**
+ [
## AWS immagini di base per Node.js
](#nodejs-image-base)
+ [
## Utilizzo di un'immagine di AWS base per Node.js
](#nodejs-image-instructions)
+ [
## Utilizzo di un'immagine di base alternativa con il client di interfaccia di runtime
](#nodejs-image-clients)
## AWS immagini di base per Node.js
AWS fornisce le seguenti immagini di base per Node.js:
| Tag | Runtime | Sistema operativo | Dockerfile | Raggiunta obsolescenza |
| --- | --- | --- | --- | --- |
| 24 | Node.js 24 | Amazon Linux 2023 | [Dockerfile per Node.js 24 ore su 24 GitHub](https://github.com/aws/aws-lambda-base-images/blob/nodejs24.x/Dockerfile.nodejs24.x) | 30 aprile 2028 |
| 22 | Node.js 22 | Amazon Linux 2023 | [Dockerfile per Node.js dalla 22 in poi GitHub](https://github.com/aws/aws-lambda-base-images/blob/nodejs22.x/Dockerfile.nodejs22.x) | 30 aprile 2027 |
| 20 | Node.js 20 | Amazon Linux 2023 | [Dockerfile per Node.js dalla versione 20 in poi GitHub](https://github.com/aws/aws-lambda-base-images/blob/nodejs20.x/Dockerfile.nodejs20.x) | 30 aprile 2026 |
[Archivio Amazon ECR: gallery.ecr. aws/lambda/nodejs](https://gallery.ecr.aws/lambda/nodejs)
Le immagini di base Node.js 20 e successive si basano sull'[immagine minima del contenitore 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.
## Utilizzo di un'immagine di AWS base per Node.js
### Prerequisiti
Per completare le fasi riportate in questa sezione, è necessario:
+ [AWS CLI versione 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+ [Docker](https://docs.docker.com/get-docker) (versione minima 25.0.0)
+ Il [plugin buildx](https://github.com/docker/buildx/blob/master/README.md) di Docker.
+ Node.js
### Creazione di un'immagine da un'immagine di base
**Per creare un'immagine del contenitore da un'immagine di AWS base per Node.js**
1. Crea una directory per il progetto, quindi passa a quella directory.
```
mkdir example
cd example
```
1. Crea un nuovo progetto Node.js con `npm`. Per accettare le opzioni predefinite fornite nell'esperienza interattiva, premi `Enter`.
```
npm init
```
1. Crea un nuovo file denominato `index.js`. A fini di test, puoi utilizzare il codice della funzione di esempio seguente o sostituirlo con il tuo codice personalizzato.
**Example Gestore CommonJS**
```
exports.handler = async (event) => {
const response = {
statusCode: 200,
body: JSON.stringify('Hello from Lambda!'),
};
return response;
};
```
1. Se la tua funzione dipende da librerie diverse da AWS SDK per JavaScript, usa [npm](https://www.npmjs.com/) per aggiungerle al tuo pacchetto.
1. Crea un nuovo Dockerfile con la seguente configurazione:
+ Imposta la proprietà `FROM` sull'[URI dell'immagine di base](https://gallery.ecr.aws/lambda/nodejs).
+ Utilizza il comando COPY per copiare il codice della funzione e le dipendenze di runtime in `{LAMBDA_TASK_ROOT}`, una [variabile d'ambiente definita da Lambda](configuration-envvars.md#configuration-envvars-runtime).
+ Imposta l'argomento `CMD` specificando il gestore della funzione Lambda.
Nota che l'esempio Dockerfile non include un'[istruzione USER](https://docs.docker.com/reference/dockerfile/#user). Quando implementi un'immagine di container su Lambda, Lambda definisce automaticamente un utente Linux predefinito con autorizzazioni con privilegi minimi. Questo è diverso dal comportamento standard di Docker, che per impostazione predefinita è l'utente `root` quando non viene fornita alcuna istruzione `USER`.
**Example Dockerfile**
```
FROM public.ecr.aws/lambda/nodejs:22
# Copy function code
COPY index.js ${LAMBDA_TASK_ROOT}
# Set the CMD to your handler (could also be done as a parameter override outside of the Dockerfile)
CMD [ "index.handler" ]
```
1. Crea l'immagine Docker con il comando [docker build](https://docs.docker.com/engine/reference/commandline/build/). L'esempio seguente assegna un nome all'immagine `docker-image` e le assegna il [tag](https://docs.docker.com/engine/reference/commandline/build/#tag) `test`. Per rendere l'immagine compatibile con Lambda, è necessario utilizzare l'`--provenance=false`opzione.
```
docker buildx build --platform linux/amd64 --provenance=false -t docker-image:test .
```
**Nota**
Il comando specifica l’opzione `--platform linux/amd64` per garantire che il container sia compatibile con l'ambiente di esecuzione di Lambda, indipendentemente dall'architettura della macchina di sviluppo. Se intendi creare una funzione Lambda utilizzando l'architettura del set di ARM64 istruzioni, assicurati di modificare il comando per utilizzare invece l'`--platform linux/arm64`opzione.
### (Facoltativo) Test dell'immagine in locale
1. Avvia l'immagine Docker con il comando **docker run**. In questo esempio, `docker-image` è il nome dell'immagine e `test` è il tag.
```
docker run --platform linux/amd64 -p 9000:8080 docker-image:test
```
Questo comando esegue l'immagine come container e crea un endpoint locale in `localhost:9000/2015-03-31/functions/function/invocations`.
**Nota**
Se hai creato l'immagine Docker per l'architettura del set di ARM64 istruzioni, assicurati di utilizzare l'`--platform linux/arm64`opzione invece di. `--platform linux/amd64`
1. Da una nuova finestra di terminale, invia un evento all'endpoint locale.
------
#### [ Linux/macOS ]
Su MacOS o Linux, esegui il comando seguente `curl`:
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{}'
```
Questo comando richiama la funzione con un evento vuoto e restituisce una risposta. Se stai utilizzando il tuo codice della funzione anziché quello di esempio, potresti voler richiamare la funzione con un payload JSON. Esempio:
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{"payload":"hello world!"}'
```
------
#### [ PowerShell ]
In PowerShell, esegui il seguente `Invoke-WebRequest` comando:
```
Invoke-WebRequest -Uri "http://localhost:9000/2015-03-31/functions/function/invocations" -Method Post -Body '{}' -ContentType "application/json"
```
Questo comando richiama la funzione con un evento vuoto e restituisce una risposta. Se stai utilizzando il tuo codice della funzione anziché quello di esempio, potresti voler richiamare la funzione con un payload JSON. Esempio:
```
Invoke-WebRequest -Uri "http://localhost:9000/2015-03-31/functions/function/invocations" -Method Post -Body '{"payload":"hello world!"}' -ContentType "application/json"
```
------
1. Ottieni l'ID del container.
```
docker ps
```
1. Utilizza il comando [docker kill](https://docs.docker.com/engine/reference/commandline/kill/) per arrestare il container. In questo comando, sostituisci `3766c4ab331c` con l'ID del container del passaggio precedente.
```
docker kill 3766c4ab331c
```
### Implementazione dell'immagine
**Caricamento dell'immagine su Amazon ECR e creazione della funzione Lambda**
1. Esegui il [get-login-password](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/get-login-password.html)comando per autenticare la CLI Docker nel tuo registro Amazon ECR.
+ Imposta il `--region` valore nel Regione AWS punto in cui desideri creare il repository Amazon ECR.
+ Sostituiscilo `111122223333` con il tuo ID. Account AWS
```
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-east-1.amazonaws.com
```
1. Crea un repository in Amazon ECR utilizzando il commando [create-repository](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/create-repository.html).
```
aws ecr create-repository --repository-name hello-world --region us-east-1 --image-scanning-configuration scanOnPush=true --image-tag-mutability MUTABLE
```
**Nota**
Il repository Amazon ECR deve corrispondere alla funzione Lambda. Regione AWS
In caso di esito positivo, dovresti ottenere una risposta simile a questa:
```
{
"repository": {
"repositoryArn": "arn:aws:ecr:us-east-1:111122223333:repository/hello-world",
"registryId": "111122223333",
"repositoryName": "hello-world",
"repositoryUri": "111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world",
"createdAt": "2023-03-09T10:39:01+00:00",
"imageTagMutability": "MUTABLE",
"imageScanningConfiguration": {
"scanOnPush": true
},
"encryptionConfiguration": {
"encryptionType": "AES256"
}
}
}
```
1. Copia il `repositoryUri` dall'output del passaggio precedente.
1. Esegui il comando [docker tag](https://docs.docker.com/engine/reference/commandline/tag/) per etichettare l'immagine locale nel repository Amazon ECR come versione più recente. In questo comando:
+ `docker-image:test` è il nome e [tag](https://docs.docker.com/engine/reference/commandline/build/#tag) dell'immagine Docker. Si tratta del nome e del tag dell'immagine specificati nel comando `docker build`.
+ Sostituisci l’`` con l’`repositoryUri` copiato. Assicurati di includere `:latest` alla fine dell'URI.
```
docker tag docker-image:test :latest
```
Esempio:
```
docker tag docker-image:test 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. Esegui il comando [docker push](https://docs.docker.com/engine/reference/commandline/push/) per implementare la tua immagine locale sul repository Amazon ECR. Assicurati di includere `:latest` alla fine dell'URI del repository.
```
docker push 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. [Crea un ruolo di esecuzione](lambda-intro-execution-role.md#permissions-executionrole-api) per la funzione, se non lo hai già fatto. Il nome della risorsa Amazon (ARN) del ruolo ti occorrerà nel passaggio successivo.
1. Creazione della funzione Lambda Per `ImageUri`, specifica l'URI del repository creato in precedenza. Assicurati di includere `:latest` alla fine dell'URI.
```
aws lambda create-function \
--function-name hello-world \
--package-type Image \
--code ImageUri=111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--role arn:aws:iam::111122223333:role/lambda-ex
```
**Nota**
È 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](images-create.md#configuration-images-xaccount-permissions).
1. Richiama la funzione.
```
aws lambda invoke --function-name hello-world response.json
```
Dovresti ottenere una risposta simile a questa:
```
{
"ExecutedVersion": "$LATEST",
"StatusCode": 200
}
```
1. Per vedere l'output della funzione, controlla il file `response.json`.
Per aggiornare il codice della funzione, devi creare nuovamente l'immagine, caricare la nuova immagine nell'archivio Amazon ECR e quindi utilizzare il [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)comando per distribuire l'immagine nella funzione Lambda.
Lambda risolve il tag dell'immagine in un digest di immagine specifico. Ciò significa che se punti il tag immagine utilizzato per implementare la funzione su una nuova immagine in Amazon ECR, Lambda non aggiorna automaticamente la funzione per utilizzare la nuova immagine.
Per distribuire la nuova immagine nella stessa funzione Lambda, è necessario utilizzare [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)il comando, anche se il tag dell'immagine in Amazon ECR rimane lo stesso. Nell'esempio seguente, l'opzione `--publish` crea una nuova versione della funzione utilizzando l'immagine del container aggiornata.
```
aws lambda update-function-code \
--function-name hello-world \
--image-uri 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--publish
```
## Utilizzo di un'immagine di base alternativa con il client di interfaccia di runtime
Se utilizzi un'[immagine di base solo per il sistema operativo](images-create.md#runtimes-images-provided) o un'immagine di base alternativa, devi includere il client dell'interfaccia di runtime nell'immagine. Il client dell'interfaccia di runtime estende l'[API Runtime](runtimes-api.md), che gestisce l'interazione tra Lambda e il codice della funzione.
Installa il [client di interfaccia di runtime per Node.js](https://www.npmjs.com/package/aws-lambda-ric) utilizzando il gestore di pacchetti npm:
```
npm install aws-lambda-ric
```
È inoltre possibile scaricare il [client dell'interfaccia di runtime Node.js](https://github.com/aws/aws-lambda-nodejs-runtime-interface-client) da GitHub.
L'esempio seguente dimostra come creare un'immagine contenitore per Node.js utilizzando un'immagine non di AWS base. Il Dockerfile di esempio utilizza l'immagine di base `bookworm`. Il Dockerfile include il client di interfaccia di runtime.
### Prerequisiti
Per completare le fasi riportate in questa sezione, è necessario:
+ [AWS CLI versione 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+ [Docker](https://docs.docker.com/get-docker) (versione minima 25.0.0)
+ Il [plugin buildx](https://github.com/docker/buildx/blob/master/README.md) di Docker.
+ Node.js
### Creazione di un'immagine da un'immagine di base alternativa
**Per creare un'immagine contenitore da un'immagine non di AWS base**
1. Crea una directory per il progetto, quindi passa a quella directory.
```
mkdir example
cd example
```
1. Crea un nuovo progetto Node.js con `npm`. Per accettare le opzioni predefinite fornite nell'esperienza interattiva, premi `Enter`.
```
npm init
```
1. Crea un nuovo file denominato `index.js`. A fini di test, puoi utilizzare il codice della funzione di esempio seguente o sostituirlo con il tuo codice personalizzato.
**Example Gestore CommonJS**
```
exports.handler = async (event) => {
const response = {
statusCode: 200,
body: JSON.stringify('Hello from Lambda!'),
};
return response;
};
```
1. Crea un nuovo Dockerfile. Il seguente Dockerfile utilizza un'immagine di base `bookworm` anziché un'[immagine di base AWS](images-create.md#runtimes-images-lp). Il Dockerfile include il [client di interfaccia di runtime](https://www.npmjs.com/package/aws-lambda-ric), che rende l'immagine compatibile con Lambda. Il seguente Dockerfile utilizza una [build multi-fase](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#use-multi-stage-builds). Nella prima fase viene creata un'immagine della build, che è un ambiente Node.js standard in cui sono installate le dipendenze della funzione. Nella seconda fase viene creata un'immagine più leggera con il codice della funzione e le relative dipendenze. Ciò riduce la dimensione finale dell'immagine.
+ Imposta la proprietà `FROM` sull'identificativo dell'immagine di base.
+ Utilizza il comando `COPY` per copiare il codice della funzione e le dipendenze di runtime.
+ Imposta l'`ENTRYPOINT` sul modulo su cui desideri che il container Docker venga eseguito all'avvio. In questo caso, il modulo è il client di interfaccia di runtime.
+ Imposta l'argomento `CMD` specificando il gestore della funzione Lambda.
Nota che l'esempio Dockerfile non include un'[istruzione USER](https://docs.docker.com/reference/dockerfile/#user). Quando implementi un'immagine di container su Lambda, Lambda definisce automaticamente un utente Linux predefinito con autorizzazioni con privilegi minimi. Questo è diverso dal comportamento standard di Docker, che per impostazione predefinita è l'utente `root` quando non viene fornita alcuna istruzione `USER`.
**Example Dockerfile**
```
# Define custom function directory
ARG FUNCTION_DIR="/function"
FROM node:20-bookworm as build-image
# Include global arg in this stage of the build
ARG FUNCTION_DIR
# Install build dependencies
RUN apt-get update && \
apt-get install -y \
g++ \
make \
cmake \
unzip \
libcurl4-openssl-dev
# Copy function code
RUN mkdir -p ${FUNCTION_DIR}
COPY . ${FUNCTION_DIR}
WORKDIR ${FUNCTION_DIR}
# Install Node.js dependencies
RUN npm install
# Install the runtime interface client
RUN npm install aws-lambda-ric
# Grab a fresh slim copy of the image to reduce the final size
FROM node:20-bookworm-slim
# Required for Node runtimes which use npm@8.6.0+ because
# by default npm writes logs under /home/.npm and Lambda fs is read-only
ENV NPM_CONFIG_CACHE=/tmp/.npm
# Include global arg in this stage of the build
ARG FUNCTION_DIR
# Set working directory to function root directory
WORKDIR ${FUNCTION_DIR}
# Copy in the built dependencies
COPY --from=build-image ${FUNCTION_DIR} ${FUNCTION_DIR}
# Set runtime interface client as default command for the container runtime
ENTRYPOINT ["/usr/local/bin/npx", "aws-lambda-ric"]
# Pass the name of the function handler as an argument to the runtime
CMD ["index.handler"]
```
1. Crea l'immagine Docker con il comando [docker build](https://docs.docker.com/engine/reference/commandline/build/). L'esempio seguente assegna un nome all'immagine `docker-image` e le assegna il [tag](https://docs.docker.com/engine/reference/commandline/build/#tag) `test`. Per rendere l'immagine compatibile con Lambda, è necessario utilizzare l'`--provenance=false`opzione.
```
docker buildx build --platform linux/amd64 --provenance=false -t docker-image:test .
```
**Nota**
Il comando specifica l’opzione `--platform linux/amd64` per garantire che il container sia compatibile con l'ambiente di esecuzione di Lambda, indipendentemente dall'architettura della macchina di sviluppo. Se intendi creare una funzione Lambda utilizzando l'architettura del set di ARM64 istruzioni, assicurati di modificare il comando per utilizzare invece l'`--platform linux/arm64`opzione.
### (Facoltativo) Test dell'immagine in locale
Usa il [simulatore dell'interfaccia di runtime](https://github.com/aws/aws-lambda-runtime-interface-emulator/) per testare localmente l'immagine. Puoi [creare l'emulatore nella tua immagine](https://github.com/aws/aws-lambda-runtime-interface-emulator/?tab=readme-ov-file#build-rie-into-your-base-image) o seguire la procedura riportata e installarlo sul tuo computer locale.
**Installazione ed esecuzione dell'emulatore di interfaccia di runtime sul computer locale**
1. Dalla directory del progetto, esegui il comando seguente per scaricare l'emulatore di interfaccia di runtime (architettura x86-64) GitHub e installarlo sul computer locale.
------
#### [ Linux/macOS ]
```
mkdir -p ~/.aws-lambda-rie && \
curl -Lo ~/.aws-lambda-rie/aws-lambda-rie https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie && \
chmod +x ~/.aws-lambda-rie/aws-lambda-rie
```
Per installare l'emulatore arm64, sostituisci l'URL del GitHub repository nel comando precedente con il seguente:
```
https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie-arm64
```
------
#### [ PowerShell ]
```
$dirPath = "$HOME\.aws-lambda-rie"
if (-not (Test-Path $dirPath)) {
New-Item -Path $dirPath -ItemType Directory
}
$downloadLink = "https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie"
$destinationPath = "$HOME\.aws-lambda-rie\aws-lambda-rie"
Invoke-WebRequest -Uri $downloadLink -OutFile $destinationPath
```
Per installare l'emulatore arm64, sostituisci `$downloadLink` con quanto segue:
```
https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie-arm64
```
------
1. Avvia l'immagine Docker con il comando **docker run**. Tenere presente quanto segue:
+ `docker-image` è il nome dell'immagine e `test` è il tag.
+ `/usr/local/bin/npx aws-lambda-ric index.handler` è l'`ENTRYPOINT` seguito dal `CMD` del Dockerfile.
------
#### [ Linux/macOS ]
```
docker run --platform linux/amd64 -d -v ~/.aws-lambda-rie:/aws-lambda -p 9000:8080 \
--entrypoint /aws-lambda/aws-lambda-rie \
docker-image:test \
/usr/local/bin/npx aws-lambda-ric index.handler
```
------
#### [ PowerShell ]
```
docker run --platform linux/amd64 -d -v "$HOME\.aws-lambda-rie:/aws-lambda" -p 9000:8080 `
--entrypoint /aws-lambda/aws-lambda-rie `
docker-image:test `
/usr/local/bin/npx aws-lambda-ric index.handler
```
------
Questo comando esegue l'immagine come container e crea un endpoint locale in `localhost:9000/2015-03-31/functions/function/invocations`.
**Nota**
Se hai creato l'immagine Docker per l'architettura del set di ARM64 istruzioni, assicurati di utilizzare l'`--platform linux/arm64`opzione invece di. `--platform linux/amd64`
1. Pubblica un evento nell'endpoint locale.
------
#### [ Linux/macOS ]
Su MacOS o Linux, esegui il comando seguente `curl`:
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{}'
```
Questo comando richiama la funzione con un evento vuoto e restituisce una risposta. Se stai utilizzando il tuo codice della funzione anziché quello di esempio, potresti voler richiamare la funzione con un payload JSON. Esempio:
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{"payload":"hello world!"}'
```
------
#### [ PowerShell ]
In PowerShell, esegui il seguente `Invoke-WebRequest` comando:
```
Invoke-WebRequest -Uri "http://localhost:9000/2015-03-31/functions/function/invocations" -Method Post -Body '{}' -ContentType "application/json"
```
Questo comando richiama la funzione con un evento vuoto e restituisce una risposta. Se stai utilizzando il tuo codice della funzione anziché quello di esempio, potresti voler richiamare la funzione con un payload JSON. Esempio:
```
Invoke-WebRequest -Uri "http://localhost:9000/2015-03-31/functions/function/invocations" -Method Post -Body '{"payload":"hello world!"}' -ContentType "application/json"
```
------
1. Ottieni l'ID del container.
```
docker ps
```
1. Utilizza il comando [docker kill](https://docs.docker.com/engine/reference/commandline/kill/) per arrestare il container. In questo comando, sostituisci `3766c4ab331c` con l'ID del container del passaggio precedente.
```
docker kill 3766c4ab331c
```
### Implementazione dell'immagine
**Caricamento dell'immagine su Amazon ECR e creazione della funzione Lambda**
1. Esegui il [get-login-password](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/get-login-password.html)comando per autenticare la CLI Docker nel tuo registro Amazon ECR.
+ Imposta il `--region` valore nel Regione AWS punto in cui desideri creare il repository Amazon ECR.
+ Sostituiscilo `111122223333` con il tuo ID. Account AWS
```
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-east-1.amazonaws.com
```
1. Crea un repository in Amazon ECR utilizzando il commando [create-repository](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/create-repository.html).
```
aws ecr create-repository --repository-name hello-world --region us-east-1 --image-scanning-configuration scanOnPush=true --image-tag-mutability MUTABLE
```
**Nota**
Il repository Amazon ECR deve corrispondere alla funzione Lambda. Regione AWS
In caso di esito positivo, dovresti ottenere una risposta simile a questa:
```
{
"repository": {
"repositoryArn": "arn:aws:ecr:us-east-1:111122223333:repository/hello-world",
"registryId": "111122223333",
"repositoryName": "hello-world",
"repositoryUri": "111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world",
"createdAt": "2023-03-09T10:39:01+00:00",
"imageTagMutability": "MUTABLE",
"imageScanningConfiguration": {
"scanOnPush": true
},
"encryptionConfiguration": {
"encryptionType": "AES256"
}
}
}
```
1. Copia il `repositoryUri` dall'output del passaggio precedente.
1. Esegui il comando [docker tag](https://docs.docker.com/engine/reference/commandline/tag/) per etichettare l'immagine locale nel repository Amazon ECR come versione più recente. In questo comando:
+ `docker-image:test` è il nome e [tag](https://docs.docker.com/engine/reference/commandline/build/#tag) dell'immagine Docker. Si tratta del nome e del tag dell'immagine specificati nel comando `docker build`.
+ Sostituisci l’`` con l’`repositoryUri` copiato. Assicurati di includere `:latest` alla fine dell'URI.
```
docker tag docker-image:test :latest
```
Esempio:
```
docker tag docker-image:test 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. Esegui il comando [docker push](https://docs.docker.com/engine/reference/commandline/push/) per implementare la tua immagine locale sul repository Amazon ECR. Assicurati di includere `:latest` alla fine dell'URI del repository.
```
docker push 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. [Crea un ruolo di esecuzione](lambda-intro-execution-role.md#permissions-executionrole-api) per la funzione, se non lo hai già fatto. Il nome della risorsa Amazon (ARN) del ruolo ti occorrerà nel passaggio successivo.
1. Creazione della funzione Lambda Per `ImageUri`, specifica l'URI del repository creato in precedenza. Assicurati di includere `:latest` alla fine dell'URI.
```
aws lambda create-function \
--function-name hello-world \
--package-type Image \
--code ImageUri=111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--role arn:aws:iam::111122223333:role/lambda-ex
```
**Nota**
È 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](images-create.md#configuration-images-xaccount-permissions).
1. Richiama la funzione.
```
aws lambda invoke --function-name hello-world response.json
```
Dovresti ottenere una risposta simile a questa:
```
{
"ExecutedVersion": "$LATEST",
"StatusCode": 200
}
```
1. Per vedere l'output della funzione, controlla il file `response.json`.
Per aggiornare il codice della funzione, devi creare nuovamente l'immagine, caricare la nuova immagine nell'archivio Amazon ECR e quindi utilizzare il [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)comando per distribuire l'immagine nella funzione Lambda.
Lambda risolve il tag dell'immagine in un digest di immagine specifico. Ciò significa che se punti il tag immagine utilizzato per implementare la funzione su una nuova immagine in Amazon ECR, Lambda non aggiorna automaticamente la funzione per utilizzare la nuova immagine.
Per distribuire la nuova immagine nella stessa funzione Lambda, è necessario utilizzare [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)il comando, anche se il tag dell'immagine in Amazon ECR rimane lo stesso. Nell'esempio seguente, l'opzione `--publish` crea una nuova versione della funzione utilizzando l'immagine del container aggiornata.
```
aws lambda update-function-code \
--function-name hello-world \
--image-uri 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--publish
```
# Utilizzo dei livelli per le funzioni Lambda Node.js
Usa i [livelli Lambda](chapter-layers.md) per impacchettare codice e dipendenze che desideri riutilizzare in più funzioni. I livelli di solito contengono dipendenze dalla libreria, un [runtime personalizzato](runtimes-custom.md) o file di configurazione. La creazione di un livello prevede tre passaggi generali:
1. Crea un pacchetto per il contenuto del livello. Ciò significa creare un archivio di file con estensione .zip che contiene le dipendenze che desideri utilizzare nelle funzioni.
1. Crea il livello in Lambda.
1. Aggiungi il livello alle tue funzioni.
**Topics**
+ [
## Crea un pacchetto per il contenuto del livello
](#nodejs-layers-package)
+ [
## Crea il layer in Lambda
](#publishing-layer)
+ [
## Aggiungete il layer alla vostra funzione
](#nodejs-layer-adding)
+ [
## App di esempio
](#nodejs-layer-sample-app)
## Crea un pacchetto per il contenuto del livello
Per creare un layer, raggruppa i pacchetti in un archivio di file.zip che soddisfi i seguenti requisiti:
+ Create il layer utilizzando la stessa versione di Node.js che intendete utilizzare per la funzione Lambda. Ad esempio, se create il layer utilizzando Node.js 24, utilizzate il runtime Node.js 24 per la funzione.
+ Il file.zip del livello deve utilizzare una di queste strutture di directory:
+ `nodejs/node_modules`
+ `nodejs/nodeX/node_modules`(*X*dov'è la versione di Node.js, ad esempio`node22`)
Per ulteriori informazioni, consulta [Percorsi dei livelli per ciascun runtime Lambda](packaging-layers.md#packaging-layers-paths).
+ I pacchetti del livello devono essere compatibili con Linux. Le funzioni Lambda vengono eseguite su Amazon Linux.
Puoi creare livelli che contengono librerie Node.js di terze parti installate con `npm` (come `axios` or`lodash`) o JavaScript moduli personalizzati.
### Dipendenze da terze parti
**Per creare un livello utilizzando i pacchetti npm**
1. Crea la struttura di directory richiesta e installa i pacchetti direttamente al suo interno:
```
mkdir -p nodejs
npm install --prefix nodejs lodash axios
```
Questo comando installa i pacchetti direttamente nella `nodejs/node_modules` directory, che è la struttura richiesta da Lambda.
**Nota**
[Per i pacchetti con dipendenze native o componenti binari (come [sharp](https://www.npmjs.com/package/sharp) o [bcrypt](https://www.npmjs.com/package/bcrypt)), assicurati che siano compatibili con l'ambiente Lambda Linux e l'architettura della tua funzione.](foundation-arch.md) Potrebbe essere necessario utilizzare il flag: `--platform`
```
npm install --prefix nodejs --platform=linux --arch=x64 sharp
```
Per dipendenze native più complesse, potrebbe essere necessario compilarle in un ambiente Linux che corrisponda al runtime Lambda. Puoi usare Docker per questo scopo.
1. Comprimi il contenuto del livello:
------
#### [ Linux/macOS ]
```
zip -r layer.zip nodejs/
```
------
#### [ PowerShell ]
```
Compress-Archive -Path .\nodejs -DestinationPath .\layer.zip
```
------
La struttura delle cartelle del file.zip dovrebbe essere simile alla seguente:
```
nodejs/
├── package.json
├── package-lock.json
└── node_modules/
├── lodash/
├── axios/
└── (dependencies of the other packages)
```
**Nota**
Assicurati che il tuo file.zip includa la `nodejs` directory a livello principale al `node_modules` suo interno. Questa struttura assicura che Lambda possa localizzare e importare i tuoi pacchetti.
I file `package.json` e `package-lock.json` nella directory `nodejs/` vengono utilizzati da npm per la gestione delle dipendenze ma non sono richiesti da Lambda per la funzionalità dei livelli. Ogni pacchetto installato contiene già il proprio `package.json` file che definisce il modo in cui Lambda importa il pacchetto.
### Moduli personalizzati JavaScript
**Per creare un livello utilizzando il proprio codice**
1. Crea la struttura di directory richiesta per il tuo livello:
```
mkdir -p nodejs/node_modules/validator
cd nodejs/node_modules/validator
```
1. Crea un `package.json` file per il tuo modulo personalizzato per definire come deve essere importato:
**Example nodejs/node\$1modules/validator/package.json**
```
{
"name": "validator",
"version": "1.0.0",
"type": "module",
"main": "index.mjs"
}
```
1. Crea il tuo file del JavaScript modulo:
**Example nodejs/node\$1modules/validator/index.mjs**
```
export function validateOrder(orderData) {
// Validates an order and returns formatted data
const requiredFields = ['productId', 'quantity'];
// Check required fields
const missingFields = requiredFields.filter(field => !(field in orderData));
if (missingFields.length > 0) {
throw new Error(`Missing required fields: ${missingFields.join(', ')}`);
}
// Validate quantity
const quantity = orderData.quantity;
if (!Number.isInteger(quantity) || quantity < 1) {
throw new Error('Quantity must be a positive integer');
}
// Format and return the validated data
return {
productId: String(orderData.productId),
quantity: quantity,
shippingPriority: orderData.priority || 'standard'
};
}
export function formatResponse(statusCode, body) {
// Formats the API response
return {
statusCode: statusCode,
body: JSON.stringify(body)
};
}
```
1. Comprimi il contenuto del livello:
------
#### [ Linux/macOS ]
```
zip -r layer.zip nodejs/
```
------
#### [ PowerShell ]
```
Compress-Archive -Path .\nodejs -DestinationPath .\layer.zip
```
------
La struttura delle cartelle del file.zip dovrebbe essere simile alla seguente:
```
nodejs/
└── node_modules/
└── validator/
├── package.json
└── index.mjs
```
1. Nella tua funzione, importa e usa i moduli. Esempio:
```
import { validateOrder, formatResponse } from 'validator';
export const handler = async (event) => {
try {
// Parse the order data from the event body
const orderData = JSON.parse(event.body || '{}');
// Validate and format the order
const validatedOrder = validateOrder(orderData);
return formatResponse(200, {
message: 'Order validated successfully',
order: validatedOrder
});
} catch (error) {
if (error instanceof Error && error.message.includes('Missing required fields')) {
return formatResponse(400, {
error: error.message
});
}
return formatResponse(500, {
error: 'Internal server error'
});
}
};
```
È possibile utilizzare il seguente [evento di test](testing-functions.md#invoke-with-event) per richiamare la funzione:
```
{
"body": "{\"productId\": \"ABC123\", \"quantity\": 2, \"priority\": \"express\"}"
}
```
Risposta prevista:
```
{
"statusCode": 200,
"body": "{\"message\":\"Order validated successfully\",\"order\":{\"productId\":\"ABC123\",\"quantity\":2,\"shippingPriority\":\"express\"}}"
}
```
## Crea il layer in Lambda
È possibile pubblicare il layer utilizzando la console AWS CLI o la console Lambda.
------
#### [ AWS CLI ]
Esegui il [publish-layer-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-layer-version.html) AWS CLI comando per creare il livello Lambda:
```
aws lambda publish-layer-version --layer-name my-layer --zip-file fileb://layer.zip --compatible-runtimes nodejs24.x
```
Il parametro di [runtime compatibile](https://docs.aws.amazon.com/lambda/latest/api/API_PublishLayerVersion.html#lambda-PublishLayerVersion-request-CompatibleRuntimes) è facoltativo. Quando specificato, Lambda utilizza questo parametro per filtrare i livelli nella console Lambda.
------
#### [ Console ]
**Creazione di un livello (console)**
1. Apri la [pagina Layers](https://console.aws.amazon.com/lambda/home#/layers) (Livelli) nella console Lambda.
1. Scegli **Create layer** (Crea livello).
1. Scegli **Carica un file.zip**, quindi carica l'archivio.zip che hai creato in precedenza.
1. (Facoltativo) Per i **runtime compatibili**, scegliete il runtime Node.js che corrisponde alla versione Node.js utilizzata per creare il layer.
1. Scegli **Create** (Crea).
------
## Aggiungete il layer alla vostra funzione
------
#### [ AWS CLI ]
Per collegare il layer alla tua funzione, esegui il [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html) AWS CLI comando. Per il `--layers` parametro, utilizzate il livello ARN. L'ARN deve specificare la versione (ad esempio,`arn:aws:lambda:us-east-1:123456789012:layer:my-layer:1`). Per ulteriori informazioni, consulta [Livelli e versioni di livelli](chapter-layers.md#lambda-layer-versions).
```
aws lambda update-function-configuration --function-name my-function --cli-binary-format raw-in-base64-out --layers "arn:aws:lambda:us-east-1:123456789012:layer:my-layer:1"
```
L'**cli-binary-format**opzione è obbligatoria se si utilizza la AWS CLI versione 2. 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*.
------
#### [ Console ]
**Aggiunta di un livello a una funzione**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegli la funzione.
1. Scorri verso il basso fino alla sezione **Livelli**, quindi scegli **Aggiungi un livello**.
1. In **Scegli un livello**, seleziona **Livelli personalizzati**, quindi scegli il tuo livello.
**Nota**
Se non hai aggiunto un [runtime compatibile](https://docs.aws.amazon.com/lambda/latest/api/API_PublishLayerVersion.html#lambda-PublishLayerVersion-request-CompatibleRuntimes) quando hai creato il layer, il tuo layer non verrà elencato qui. È possibile specificare invece il livello ARN.
1. Scegliere **Aggiungi**.
------
## App di esempio
Per altri esempi di utilizzo dei layer Lambda, consulta l'applicazione di esempio [layer-nodejs](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/layer-nodejs) nel repository Developer Guide. AWS Lambda GitHub [Questa applicazione include un livello che contiene la libreria lodash.](https://www.npmjs.com/package/lodash) Dopo aver creato il layer, è possibile implementare e richiamare la funzione corrispondente per confermare che il layer funzioni come previsto.
# Utilizzo dell'oggetto di contesto Lambda per recuperare le informazioni sulla funzione Node.js
Quando Lambda esegue la funzione, passa un oggetto Context al [gestore](nodejs-handler.md). Questo oggetto fornisce i metodi e le proprietà che forniscono le informazioni sulla chiamata, sulla funzione e sull'ambiente di esecuzione.
**Metodi del contesto**
+ `getRemainingTimeInMillis()`: restituisce il numero di millisecondi rimasti prima del timeout dell'esecuzione.
**Proprietà del contesto**
+ `functionName`: il nome della funzione Lambda.
+ `functionVersion`: la [versione](configuration-versions.md) della funzione.
+ `invokedFunctionArn`: l'Amazon Resource Name (ARN) utilizzato per richiamare la funzione. Indica se l'invoker ha specificato un numero di versione o un alias.
+ `memoryLimitInMB`: la quantità di memoria allocata per la funzione.
+ `awsRequestId`: l'identificatore della richiesta di invocazione.
+ `logGroupName`: il gruppo di log per la funzione.
+ `logStreamName`: il flusso di log per l'istanza della funzione.
+ `identity`: (app per dispositivi mobili) Informazioni relative all'identità Amazon Cognito che ha autorizzato la richiesta.
+ `cognitoIdentityId`: l'identità autenticata di Amazon Cognito.
+ `cognitoIdentityPoolId`: il pool di identità Amazon Cognito che ha autorizzato l'invocazione.
+ `clientContext`: (app per dispositivi mobili) Contesto client fornito a Lambda dall'applicazione client.
+ `client.installation_id`
+ `client.app_title`
+ `client.app_version_name`
+ `client.app_version_code`
+ `client.app_package_name`
+ `env.platform_version`
+ `env.platform`
+ `env.make`
+ `env.model`
+ `env.locale`
+ `custom`: valori personalizzati impostati dall'applicazione mobile.
+ `callbackWaitsForEmptyEventLoop`— Per impostazione predefinita (`true`), quando si utilizza un gestore di funzioni basato sul callback, Lambda attende che il ciclo di eventi sia vuoto dopo l'esecuzione del callback prima di terminare l'invoca della funzione. Imposta su `false` per inviare la risposta e terminare la chiamata immediatamente dopo l'esecuzione del callback anziché attendere che il ciclo di eventi sia vuoto. Gli eventi eccezionali continuano a verificarsi durante la chiamata successiva. Nota che Lambda supporta gestori di funzioni basati su callback solo per Node.js 22 e runtime precedenti.
La seguente funzione di esempio registra le informazioni di contesto e restituisce la posizione dei log.
**Example File index.js**
```
exports.handler = async function(event, context) {
console.log('Remaining time: ', context.getRemainingTimeInMillis())
console.log('Function name: ', context.functionName)
return context.logStreamName
}
```
# Registrare e monitorare funzioni Lambda in Node.js
AWS Lambda monitora automaticamente le funzioni Lambda per tuo conto e invia i log ad Amazon. CloudWatch La funzione Lambda include un gruppo di log CloudWatch Logs e un flusso di log per ogni istanza della funzione. L'ambiente del runtime Lambda invia i dettagli su ogni richiamo al flusso di log e inoltra i log e l'output del codice della funzione. Per ulteriori informazioni, consulta [Lambda invia automaticamente i log delle funzioni a CloudWatch Logs.](monitoring-cloudwatchlogs.md).
Questa pagina descrive come produrre un output di registro dal codice della funzione Lambda e accedere ai log utilizzando AWS Command Line Interface la console Lambda o la console. CloudWatch
**Topics**
+ [
## Creazione di una funzione che restituisce i registri
](#node-logging-output)
+ [
## Utilizzo dei controlli di registrazione avanzati di Lambda con Node.js
](#node-js-logging-advanced)
+ [
## Visualizzazione dei log nella console Lambda
](#nodejs-logging-console)
+ [
## Visualizzazione dei log nella console CloudWatch
](#nodejs-logging-cwconsole)
+ [
## Visualizzazione dei log utilizzando () AWS Command Line Interface AWS CLI
](#nodejs-logging-cli)
+ [
## Eliminazione dei log
](#nodejs-logging-delete)
## Creazione di una funzione che restituisce i registri
Per generare i log dal codice della funzione, è possibile utilizzare i metodi dell'[oggetto console](https://developer.mozilla.org/en-US/docs/Web/API/Console) o di qualsiasi libreria di registrazione che scriva su `stdout` o `stderr`. L'esempio seguente registra i valori delle variabili di ambiente e l'oggetto evento.
**Nota**
Si consiglia di utilizzare tecniche come la convalida dell'input e la codifica dell'output durante la registrazione degli input. Se registri direttamente i dati di input, un utente malintenzionato potrebbe essere in grado di utilizzare il codice per rendere difficile l'individuazione delle manomissioni, falsificare le voci di log o aggirare i monitor dei log. Per ulteriori informazioni, consulta [Neutralizzazione di output non corretta per i log](https://cwe.mitre.org/data/definitions/117.html) in *Enumerazione delle debolezze comuni*.
**Example File index.js – Registrazione dei log**
```
exports.handler = async function(event, context) {
console.log("ENVIRONMENT VARIABLES\n" + JSON.stringify(process.env, null, 2))
console.info("EVENT\n" + JSON.stringify(event, null, 2))
console.warn("Event not processed.")
return context.logStreamName
}
```
**Example Formato dei log**
```
START RequestId: c793869b-ee49-115b-a5b6-4fd21e8dedac Version: $LATEST
2019-06-07T19:11:20.562Z c793869b-ee49-115b-a5b6-4fd21e8dedac INFO ENVIRONMENT VARIABLES
{
"AWS_LAMBDA_FUNCTION_VERSION": "$LATEST",
"AWS_LAMBDA_LOG_GROUP_NAME": "/aws/lambda/my-function",
"AWS_LAMBDA_LOG_STREAM_NAME": "2019/06/07/[$LATEST]e6f4a0c4241adcd70c262d34c0bbc85c",
"AWS_EXECUTION_ENV": "AWS_Lambda_nodejs12.x",
"AWS_LAMBDA_FUNCTION_NAME": "my-function",
"PATH": "/var/lang/bin:/usr/local/bin:/usr/bin/:/bin:/opt/bin",
"NODE_PATH": "/opt/nodejs/node10/node_modules:/opt/nodejs/node_modules:/var/runtime/node_modules",
...
}
2019-06-07T19:11:20.563Z c793869b-ee49-115b-a5b6-4fd21e8dedac INFO EVENT
{
"key": "value"
}
2019-06-07T19:11:20.564Z c793869b-ee49-115b-a5b6-4fd21e8dedac WARN Event not processed.
END RequestId: c793869b-ee49-115b-a5b6-4fd21e8dedac
REPORT RequestId: c793869b-ee49-115b-a5b6-4fd21e8dedac Duration: 128.83 ms Billed Duration: 296 ms Memory Size: 128 MB Max Memory Used: 74 MB Init Duration: 166.62 ms XRAY TraceId: 1-5d9d007f-0a8c7fd02xmpl480aed55ef0 SegmentId: 3d752xmpl1bbe37e Sampled: true
```
Il runtime di Node.js registra le voci `START`, `END` e `REPORT` per ogni chiamata. A ogni voce registrata dalla funzione aggiunge un timestamp, l'ID della richiesta e il livello di log. La riga del report fornisce i seguenti dettagli.
**Campi dati della riga REPORT**
+ **RequestId**— L'ID univoco della richiesta per la chiamata.
+ **Durata** – La quantità di tempo che il metodo del gestore della funzione impiega durante l'elaborazione dell'evento.
+ **Durata fatturata** – La quantità di tempo fatturata per la chiamata.
+ **Dimensioni memoria** – La quantità di memoria allocata per la funzione.
+ **Quantità max utilizzata** – La quantità di memoria utilizzata dalla funzione. Quando le invocazioni condividono un ambiente di esecuzione, Lambda riporta la memoria massima utilizzata in tutte le invocazioni. Questo comportamento potrebbe comportare un valore riportato superiore al previsto.
+ **Durata Init** – Per la prima richiesta servita, la quantità di tempo impiegato dal runtime per caricare la funzione ed eseguire il codice al di fuori del metodo del gestore.
+ **XRAY TraceId** [— Per le richieste tracciate, l'ID di traccia.AWS X-Ray](services-xray.md)
+ **SegmentId**— Per le richieste tracciate, l'ID del segmento X-Ray.
+ **Campionato** – Per le richieste tracciate, il risultato del campionamento.
Puoi visualizzare i log nella console Lambda, nella CloudWatch console Logs o dalla riga di comando.
## Utilizzo dei controlli di registrazione avanzati di Lambda con Node.js
Per avere un maggiore controllo sul modo in cui i log delle tue funzioni vengono acquisiti, elaborati e utilizzati, puoi configurare le seguenti opzioni di registrazione per i runtime Node.js supportati:
+ **Formato di log**: scegli tra i formati di testo normale e JSON strutturato per i log della funzione
+ **Livello di log**: per i log in formato JSON, scegli il livello di dettaglio dei log che Lambda invia ad CloudWatch Amazon, come ERROR, DEBUG o INFO
+ Gruppo di **log: scegli il gruppo** di log a cui la CloudWatch funzione invia i log
Per ulteriori informazioni su queste opzioni di registrazione e istruzioni su come configurare la funzione per utilizzarle, consulta la pagina [Configurazione dei controlli di registrazione avanzati per le funzioni Lambda](monitoring-logs.md#monitoring-cloudwatchlogs-advanced).
Per utilizzare le opzioni del formato di log e del livello di log con le funzioni Lambda in Node.js, consulta le istruzioni nelle sezioni seguenti.
### Utilizzo di log JSON strutturati con Node.js
Se si seleziona JSON per il formato di registro della funzione, Lambda invierà l'output dei log utilizzando i metodi della console `console.trace` di`console.debug`,,, `console.log` `console.info``console.error`, `console.warn` e CloudWatch a come JSON strutturato. Ogni oggetto di log JSON contiene almeno quattro coppie chiave-valore con le seguenti chiavi:
+ `"timestamp"`: l'ora in cui è stato generato il messaggio di log
+ `"level"`: il livello di log assegnato al messaggio
+ `"message"`: il contenuto del messaggio di log
+ `"requestId"`: l'ID di richiesta univoco dell'invocazione alla funzione
A seconda del metodo di registrazione di log utilizzato dalla funzione, questo oggetto JSON può anche contenere coppie di chiavi aggiuntive. Ad esempio, se la funzione utilizza metodi della `console` per registrare i log degli oggetti di errore con più argomenti, l'oggetto JSON conterrà coppie chiave-valore aggiuntive con le chiavi `errorMessage`, `errorType` e `stackTrace`.
Se il codice utilizza già un'altra libreria di registrazione, come Powertools for AWS Lambda, per produrre log strutturati JSON, non è necessario apportare alcuna modifica. Lambda non codifica due volte i log che sono già codificati in JSON, quindi i log delle applicazioni della funzione continueranno a essere acquisiti come prima.
Per ulteriori informazioni sull'utilizzo del pacchetto Powertools for AWS Lambda logging per creare log strutturati JSON nel runtime Node.js, vedere. [Registra e monitora le funzioni TypeScript Lambda](typescript-logging.md)
#### Esempi di output di log in formato JSON
Gli esempi seguenti mostrano come i vari output di log generati utilizzando i `console` metodi con argomenti singoli e multipli vengono acquisiti in CloudWatch Logs quando si imposta il formato di registro della funzione su JSON.
Il primo esempio utilizza il metodo `console.error` per generare una stringa semplice.
**Example Codice di registrazione di Node.js**
```
export const handler = async (event) => {
console.error("This is a warning message");
...
}
```
**Example Record di log JSON**
```
{
"timestamp":"2025-11-01T00:21:51.358Z",
"level":"ERROR",
"message":"This is a warning message",
"requestId":"93f25699-2cbf-4976-8f94-336a0aa98c6f"
}
```
Con i metodi della `console`, puoi anche generare messaggi di log strutturati più complessi utilizzando argomenti singoli o multipli. Nel prossimo esempio, viene utilizzato `console.log` per generare due coppie chiave-valore con un singolo argomento. Nota che il `"message"` campo nell'oggetto JSON che Lambda invia CloudWatch ai log non è stringato.
**Example Codice di registrazione di Node.js**
```
export const handler = async (event) => {
console.log({data: 12.3, flag: false});
...
}
```
**Example Record di log JSON**
```
{
"timestamp": "2025-12-08T23:21:04.664Z",
"level": "INFO",
"requestId": "405a4537-9226-4216-ac59-64381ec8654a",
"message": {
"data": 12.3,
"flag": false
}
}
```
Nel prossimo esempio, viene utilizzato ancora una volta il metodo `console.log` per creare un output di log. Nella fattispecie, il metodo richiede due argomenti, una mappa contenente due coppie chiave-valore e una stringa identificativa. Tieni presente che in questo caso, poiché hai fornito due argomenti, Lambda rende il campo `"message"` in formato stringa.
**Example Codice di registrazione di Node.js**
```
export const handler = async (event) => {
console.log('Some object - ', {data: 12.3, flag: false});
...
}
```
**Example Record di log JSON**
```
{
"timestamp": "2025-12-08T23:21:04.664Z",
"level": "INFO",
"requestId": "405a4537-9226-4216-ac59-64381ec8654a",
"message": "Some object - { data: 12.3, flag: false }"
}
```
Lambda assegna gli output generati utilizzando il livello di log INFO della `console.log`.
L'ultimo esempio mostra come gli oggetti di errore possono essere inviati ai log utilizzando i metodi. CloudWatch `console` Tieni presente che quando esegui il log di oggetti di errore utilizzando più argomenti, Lambda aggiunge i campi `errorMessage`, `errorType` e `stackTrace` all'output del log.
**Example Codice di registrazione di Node.js**
```
export const handler = async (event) => {
let e1 = new ReferenceError("some reference error");
let e2 = new SyntaxError("some syntax error");
console.log(e1);
console.log("errors logged - ", e1, e2);
};
```
**Example Record di log JSON**
```
{
"timestamp": "2025-12-08T23:21:04.632Z",
"level": "INFO",
"requestId": "405a4537-9226-4216-ac59-64381ec8654a",
"message": {
"errorType": "ReferenceError",
"errorMessage": "some reference error",
"stackTrace": [
"ReferenceError: some reference error",
" at Runtime.handler (file:///var/task/index.mjs:3:12)",
" at Runtime.handleOnceNonStreaming (file:///var/runtime/index.mjs:1173:29)"
]
}
}
{
"timestamp": "2025-12-08T23:21:04.646Z",
"level": "INFO",
"requestId": "405a4537-9226-4216-ac59-64381ec8654a",
"message": "errors logged - ReferenceError: some reference error\n at Runtime.handler (file:///var/task/index.mjs:3:12)\n at Runtime.handleOnceNonStreaming
(file:///var/runtime/index.mjs:1173:29) SyntaxError: some syntax error\n at Runtime.handler (file:///var/task/index.mjs:4:12)\n at Runtime.handleOnceNonStreaming
(file:///var/runtime/index.mjs:1173:29)",
"errorType": "ReferenceError",
"errorMessage": "some reference error",
"stackTrace": [
"ReferenceError: some reference error",
" at Runtime.handler (file:///var/task/index.mjs:3:12)",
" at Runtime.handleOnceNonStreaming (file:///var/runtime/index.mjs:1173:29)"
]
}
```
Quando si registrano i log di più tipi di errore, i campi aggiuntivi `errorMessage`, `errorType` e `stackTrace` vengono estratti dal primo tipo di errore fornito al metodo della `console`.
### Utilizzo di librerie client formato del parametro incorporato (EMF) con log JSON strutturati
AWS fornisce librerie client open source per Node.js che è possibile utilizzare per creare log in [formato metrico incorporato](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Libraries.html) (EMF). Se disponi di funzioni esistenti che utilizzano queste librerie e modifichi il formato di registro della funzione in JSON, CloudWatch potresti non riconoscere più le metriche emesse dal tuo codice.
Se attualmente il codice emette i log EMF direttamente utilizzando `console.log` o utilizzando Powertools for AWS Lambda (TypeScript), non CloudWatch sarà inoltre in grado di analizzarli se modificate il formato di registro della funzione in JSON.
**Importante**
[https://www.npmjs.com/package/aws-embedded-metrics](https://www.npmjs.com/package/aws-embedded-metrics) Se passi al formato di log JSON, ti consigliamo di eseguire dei test anche per garantire la compatibilità con i parametri incorporati della tua funzione. Se il tuo codice emette i log EMF direttamente utilizzando `console.log`, modifica il codice in modo che emetta tali parametri direttamente a `stdout`, come mostrato nel seguente esempio di codice.
**Example codice che emette parametri incorporati a `stdout`**
```
process.stdout.write(JSON.stringify(
{
"_aws": {
"Timestamp": Date.now(),
"CloudWatchMetrics": [{
"Namespace": "lambda-function-metrics",
"Dimensions": [["functionVersion"]],
"Metrics": [{
"Name": "time",
"Unit": "Milliseconds",
"StorageResolution": 60
}]
}]
},
"functionVersion": "$LATEST",
"time": 100,
"requestId": context.awsRequestId
}
) + "\n")
```
### Utilizzo del filtraggio a livello di log con Node.js
Per AWS Lambda filtrare i log delle applicazioni in base al loro livello di registro, la funzione deve utilizzare log in formato JSON. Puoi farlo in due modi:
+ Crea output di log utilizzando i metodi standard della console e configura la tua funzione per utilizzare la formattazione dei log JSON. AWS Lambda quindi filtra gli output di log utilizzando la coppia chiave-valore «level» nell'oggetto JSON descritto in. [Utilizzo di log JSON strutturati con Node.js](#nodejs-logging-advanced-JSON) Per informazioni su come configurare il formato di log della funzione, consulta la pagina [Configurazione dei controlli di registrazione avanzati per le funzioni Lambda](monitoring-logs.md#monitoring-cloudwatchlogs-advanced).
+ Utilizza un'altra libreria o metodo di registrazione per creare nel codice dei log JSON strutturati che includono una coppia chiave-valore "livello" che definisce il livello dell'output log. Ad esempio, puoi utilizzare Powertools per generare output AWS Lambda di log strutturati JSON dal tuo codice. Per ulteriori informazioni sull'utilizzo di Powertools con il runtime Node.js, consulta la pagina [Registra e monitora le funzioni TypeScript Lambda](typescript-logging.md).
Per consentire a Lambda di filtrare i log della funzione, è necessario includere anche una coppia chiave-valore `"timestamp"` nell'output log JSON. L'ora deve essere specificata in un formato di timestamp [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) valido. Se non fornisci un timestamp valido, Lambda assegnerà al log il livello INFO e aggiungerà un timestamp per tuo conto.
Quando configuri la tua funzione per utilizzare il filtraggio a livello di log, selezioni il livello di log che desideri inviare AWS Lambda a Logs tra le seguenti opzioni: CloudWatch
| Livello di log | Utilizzo standard |
| --- | --- |
| TRACE (dettaglio massimo) | Le informazioni più dettagliate utilizzate per tracciare il percorso di esecuzione del codice |
| DEBUG | Informazioni dettagliate per il debug del sistema |
| INFO | Messaggi che registrano il normale funzionamento della funzione |
| WARN | Messaggi relativi a potenziali errori che possono portare a comportamenti imprevisti se non risolti |
| ERRORE | Messaggi relativi a problemi che impediscono al codice di funzionare come previsto |
| FATAL (dettaglio minimo) | Messaggi relativi a errori gravi che causano l'interruzione del funzionamento dell'applicazione |
Lambda invia i log del livello selezionato e inferiore a. CloudWatch Ad esempio, se configuri un livello di log WARN, Lambda invierà i log corrispondenti ai livelli WARN, ERROR e FATAL.
## Visualizzazione dei log nella console Lambda
È possibile utilizzare la console Lambda per visualizzare l'output del log dopo aver richiamato una funzione Lambda.
Se il codice può essere testato dall'editor del **codice** incorporato, troverai i log nei **risultati dell’esecuzione**. Quando utilizzi la funzionalità di test della console per richiamare una funzione, troverai l’**output del log** nella sezione **Dettagli**.
## Visualizzazione dei log nella console CloudWatch
Puoi utilizzare la CloudWatch console Amazon per visualizzare i log di tutte le chiamate di funzioni Lambda.
**Per visualizzare i log sulla console CloudWatch**
1. Apri la [pagina Registra gruppi](https://console.aws.amazon.com/cloudwatch/home?#logs:) sulla CloudWatch console.
1. Scegli il gruppo di log per la tua funzione (***your-function-name*/aws/lambda/**).
1. Creare un flusso di log.
Ogni flusso di log corrisponde a un'[istanza della funzione](lambda-runtime-environment.md). Viene visualizzato un flusso di log quando aggiorni la funzione Lambda e quando vengono create istanze aggiuntive per gestire le chiamate simultanee. Per trovare i log per una chiamata specifica, consigliamo di strumentare la funzione con. AWS X-Ray X-Ray registra i dettagli sulla richiesta e il flusso di log nella traccia.
## Visualizzazione dei log utilizzando () AWS Command Line Interface AWS CLI
AWS CLI È uno strumento open source che consente di interagire con i AWS servizi utilizzando i comandi nella shell della riga di comando. Per completare le fasi riportate in questa sezione, è necessario disporre della [AWS CLI versione 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
È possibile utilizzare [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) per recuperare i log per una chiamata utilizzando l'opzione di comando `--log-type`. La risposta include un campo `LogResult` che contiene fino a 4 KB di log con codifica base64 del richiamo.
**Example recuperare un ID di log**
Nell'esempio seguente viene illustrato come recuperare un *ID di log* dal `LogResult` campo per una funzione denominata `my-function`.
```
aws lambda invoke --function-name my-function out --log-type Tail
```
Verrà visualizzato l’output seguente:
```
{
"StatusCode": 200,
"LogResult": "U1RBUlQgUmVxdWVzdElkOiA4N2QwNDRiOC1mMTU0LTExZTgtOGNkYS0yOTc0YzVlNGZiMjEgVmVyc2lvb...",
"ExecutedVersion": "$LATEST"
}
```
**Example decodificare i log**
Nello stesso prompt dei comandi, utilizzare l'`base64` utilità per decodificare i log. Nell'esempio seguente viene illustrato come recuperare i log codificati in base64 per `my-function`.
```
aws lambda invoke --function-name my-function out --log-type Tail \
--query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode
```
L'**cli-binary-format**opzione è obbligatoria se si utilizza la AWS CLI versione 2. 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*.
Verrà visualizzato l’output seguente:
```
START RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Version: $LATEST
"AWS_SESSION_TOKEN": "AgoJb3JpZ2luX2VjELj...", "_X_AMZN_TRACE_ID": "Root=1-5d02e5ca-f5792818b6fe8368e5b51d50;Parent=191db58857df8395;Sampled=0"",ask/lib:/opt/lib",
END RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8
REPORT RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Duration: 79.67 ms Billed Duration: 80 ms Memory Size: 128 MB Max Memory Used: 73 MB
```
L'utilità `base64` è disponibile su Linux, macOS e [Ubuntu su Windows](https://docs.microsoft.com/en-us/windows/wsl/install-win10). Gli utenti macOS potrebbero dover utilizzare `base64 -D`.
**Example Script get-logs.sh**
Nello stesso prompt dei comandi, utilizzare lo script seguente per scaricare gli ultimi cinque eventi di log. Lo script utilizza `sed` per rimuovere le virgolette dal file di output e rimane in sospensione per 15 secondi in attesa che i log diventino disponibili. L'output include la risposta di Lambda e l'output del comando `get-log-events`.
Copiare il contenuto del seguente esempio di codice e salvare nella directory del progetto Lambda come `get-logs.sh`.
L'**cli-binary-format**opzione è obbligatoria se utilizzi la AWS CLI versione 2. 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*.
```
#!/bin/bash
aws lambda invoke --function-name my-function --cli-binary-format raw-in-base64-out --payload '{"key": "value"}' out
sed -i'' -e 's/"//g' out
sleep 15
aws logs get-log-events --log-group-name /aws/lambda/my-function --log-stream-name stream1 --limit 5
```
**Example (solo) macOS e Linux**
Nello stesso prompt dei comandi, gli utenti macOS e Linux potrebbero dover eseguire il seguente comando per assicurarsi che lo script sia eseguibile.
```
chmod -R 755 get-logs.sh
```
**Example recuperare gli ultimi cinque eventi di log**
Nello stesso prompt dei comandi, eseguire lo script seguente per ottenere gli ultimi cinque eventi di log.
```
./get-logs.sh
```
Verrà visualizzato l’output seguente:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
{
"events": [
{
"timestamp": 1559763003171,
"message": "START RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf Version: $LATEST\n",
"ingestionTime": 1559763003309
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tENVIRONMENT VARIABLES\r{\r \"AWS_LAMBDA_FUNCTION_VERSION\": \"$LATEST\",\r ...",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tEVENT\r{\r \"key\": \"value\"\r}\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "END RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "REPORT RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\tDuration: 26.73 ms\tBilled Duration: 27 ms \tMemory Size: 128 MB\tMax Memory Used: 75 MB\t\n",
"ingestionTime": 1559763018353
}
],
"nextForwardToken": "f/34783877304859518393868359594929986069206639495374241795",
"nextBackwardToken": "b/34783877303811383369537420289090800615709599058929582080"
}
```
## Eliminazione dei log
I gruppi di log non vengono eliminati automaticamente quando si elimina una funzione. Per evitare di archiviare i log a tempo indeterminato, eliminare il gruppo di log o [configurare un periodo di conservazione](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention) trascorso il quale i log vengono eliminati automaticamente.
# Strumentazione del codice Node.js in AWS Lambda
Lambda si integra con AWS X-Ray per aiutarti a tracciare, eseguire il debug e ottimizzare le applicazioni Lambda. Puoi utilizzare X-Ray per tracciare una richiesta mentre attraversa le risorse nell'applicazione, che possono includere funzioni Lambda e altri servizi AWS .
Per inviare dati di tracciamento a X-Ray, è possibile utilizzare una delle due librerie SDK:
+ [AWS Distro for OpenTelemetry (ADOT)](https://aws.amazon.com/otel): una distribuzione sicura, pronta per la produzione e supportata dell'SDK (). AWS OpenTelemetry OTel
+ [SDK AWS X-Ray per Node.js](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-nodejs.html): un SDK per generare e inviare i dati di traccia su X-Ray.
Ciascuno di essi SDKs offre modi per inviare i dati di telemetria al servizio X-Ray. Puoi quindi utilizzare X-Ray per visualizzare, filtrare e analizzare le metriche delle prestazioni dell'applicazione per identificare i problemi e le opportunità di ottimizzazione.
**Importante**
X-Ray e Powertools per AWS Lambda SDKs fanno parte di una soluzione di strumentazione strettamente integrata offerta da. AWS I livelli Lambda ADOT fanno parte di uno standard di settore per la strumentazione di tracciamento che in generale raccoglie più dati, ma potrebbero non essere adatti a tutti i casi d'uso. È possibile implementare il end-to-end tracciamento in X-Ray utilizzando entrambe le soluzioni. Per saperne di più sulla scelta tra di esse, consulta [Scelta tra AWS Distro for Open Telemetry](https://docs.aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html#xray-instrumenting-choosing) e X-Ray. SDKs
**Topics**
+ [
## Utilizzo di ADOT per strumentare le funzioni Node.js
](#nodejs-adot)
+ [
## Utilizzo dell'SDK X-Ray per strumentare le funzioni Node.js
](#nodejs-xray-sdk)
+ [
## Attivazione del tracciamento con la console Lambda
](#nodejs-tracing-console)
+ [
## Attivazione del tracciamento con l'API Lambda
](#nodejs-tracing-api)
+ [
## Attivazione del tracciamento con CloudFormation
](#nodejs-tracing-cloudformation)
+ [
## Interpretazione di una traccia X-Ray
](#nodejs-tracing-interpretation)
+ [
## Memorizzazione delle dipendenze di runtime in un livello (SDK X-Ray)
](#nodejs-tracing-layers)
## Utilizzo di ADOT per strumentare le funzioni Node.js
ADOT fornisce layer [Lambda](chapter-layers.md) completamente gestiti che racchiudono tutto il necessario per raccogliere dati di telemetria utilizzando l'SDK. OTel Usando questo livello, è possibile strumentare le funzioni Lambda senza dover modificare alcun codice funzione. Puoi anche configurare il tuo layer per eseguire l'inizializzazione personalizzata di. OTel Per ulteriori informazioni, consulta la sezione relativa alla [configurazione personalizzata per ADOT Collector su Lambda](https://aws-otel.github.io/docs/getting-started/lambda#custom-configuration-for-the-adot-collector-on-lambda) nella documentazione di ADOT.
Per i runtime Node.js, puoi aggiungere il **livello Lambda gestito da AWS per ADOT Javascript** per strumentare automaticamente le tue funzioni. Per istruzioni dettagliate su come aggiungere questo layer, consulta [AWS Distro for OpenTelemetry Lambda JavaScript Support](https://aws-otel.github.io/docs/getting-started/lambda/lambda-js) nella documentazione ADOT.
## Utilizzo dell'SDK X-Ray per strumentare le funzioni Node.js
Per registrare i dettagli sulle chiamate effettuate dalla funzione Lambda ad altre risorse nell'applicazione, è anche possibile utilizzare il SDK AWS X-Ray per Node.js. Per ottenere l'SDK, aggiungere il pacchetto `aws-xray-sdk-core` alle dipendenze dell'applicazione.
**Example [blank-nodejs/package.json](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs/package.json)**
```
{
"name": "blank-nodejs",
"version": "1.0.0",
"private": true,
"devDependencies": {
"jest": "29.7.0"
},
"dependencies": {
"@aws-sdk/client-lambda": "3.345.0",
"aws-xray-sdk-core": "3.5.3"
},
"scripts": {
"test": "jest"
}
}
```
Per strumentare i client AWS SDK nella versione [AWS SDK per JavaScript v3](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/welcome.html), avvolgete l'istanza del client con il metodo. `captureAWSv3Client`
**Example [blank- nodejs/function/index .js](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs/function/index.js) — Tracciamento di un client SDK AWS**
```
const AWSXRay = require('aws-xray-sdk-core');
const { LambdaClient, GetAccountSettingsCommand } = require('@aws-sdk/client-lambda');
// Create client outside of handler to reuse
const lambda = AWSXRay.captureAWSv3Client(new LambdaClient());
// Handler
exports.handler = async function(event, context) {
event.Records.forEach(record => {
...
```
Il runtime Lambda imposta alcune variabili di ambiente per configurare l'SDK X-Ray. Ad esempio, Lambda imposta `AWS_XRAY_CONTEXT_MISSING` su `LOG_ERROR` per evitare di generare errori di runtime dall'SDK X-Ray. Per impostare una strategia mancante di contesto personalizzato, sovrascrivi la variabile di ambiente nella configurazione della funzione in modo da non avere alcun valore, quindi puoi impostare la strategia mancante di contesto a livello di programmazione.
**Example Esempio di codice di inizializzazione**
```
const AWSXRay = require('aws-xray-sdk-core');
// Configure the context missing strategy to do nothing
AWSXRay.setContextMissingStrategy(() => {});
```
Per ulteriori informazioni, consulta [Utilizzo delle variabili di ambiente Lambda](configuration-envvars.md).
Dopo aver aggiunto le dipendenze corrette e aver apportato le modifiche necessarie al codice, attivare il tracciamento nella configurazione della funzione tramite la console Lambda o l'API.
## Attivazione del tracciamento con la console Lambda
Per attivare il tracciamento attivo sulla funzione Lambda con la console, attenersi alla seguente procedura:
**Per attivare il tracciamento attivo**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere una funzione.
1. Scegliere **Configuration** (Configurazione) e quindi **Monitoring and operations tools** (Strumenti di monitoraggio e operazioni).
1. In **Strumenti di monitoraggio aggiuntivi** scegli **Modifica**.
1. In **CloudWatch Application Signals e AWS X-Ray**, scegli **Enable** for **Lambda service trace**.
1. Scegli **Save** (Salva).
## Attivazione del tracciamento con l'API Lambda
Configura il tracciamento sulla tua funzione Lambda con AWS o SDK, utilizza AWS CLI le seguenti operazioni API:
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)
**Il AWS CLI comando di esempio seguente abilita il tracciamento attivo su una funzione denominata my-function.**
```
aws lambda update-function-configuration --function-name my-function \
--tracing-config Mode=Active
```
La modalità di tracciamento fa parte della configurazione specifica della versione quando si pubblica una versione della funzione. Non è possibile modificare la modalità di tracciamento in una versione pubblicata.
## Attivazione del tracciamento con CloudFormation
Per attivare il tracciamento su una `AWS::Lambda::Function` risorsa in un CloudFormation modello, utilizzate la proprietà. `TracingConfig`
**Example [function-inline.yml](https://github.com/awsdocs/aws-lambda-developer-guide/blob/master/templates/function-inline.yml) – Configurazione del tracciamento**
```
Resources:
function:
Type: [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)
Properties:
TracingConfig:
Mode: Active
...
```
Per una `AWS::Serverless::Function` risorsa AWS Serverless Application Model (AWS SAM), utilizzate la `Tracing` proprietà.
**Example [template.yml](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs/template.yml) – Configurazione del tracciamento**
```
Resources:
function:
Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
Properties:
Tracing: Active
...
```
## Interpretazione di una traccia X-Ray
La funzione ha bisogno dell'autorizzazione per caricare i dati di traccia su X-Ray. Quando si attiva il tracciamento nella console Lambda, Lambda aggiunge le autorizzazioni necessarie al [ruolo di esecuzione](lambda-intro-execution-role.md) della funzione. Altrimenti, aggiungete la [AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess)politica al ruolo di esecuzione.
Dopo aver configurato il tracciamento attivo, è possibile osservare richieste specifiche tramite l'applicazione. Il [grafico dei servizi X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html#xray-concepts-servicegraph) mostra informazioni sull'applicazione e tutti i suoi componenti. Il seguente esempio mostra un'applicazione con due funzioni. La funzione principale elabora gli eventi e talvolta restituisce errori. La seconda funzione in alto elabora gli errori che compaiono nel gruppo di log della prima e utilizza l' AWS SDK per chiamare X-Ray, Amazon Simple Storage Service (Amazon S3) e Amazon Logs. CloudWatch
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/sample-errorprocessor-servicemap.png)
X-Ray non traccia tutte le richieste nell'applicazione. X-Ray applica un algoritmo di campionamento per garantire che il tracciamento avvenga in modo efficiente, continuando allo stesso tempo a fornire un campione rappresentativo di tutte le richieste. La frequenza di campionamento è di una richiesta al secondo e del 5% delle altre richieste. Non è possibile configurare la frequenza di campionamento di X-Ray per le funzioni.
In X-Ray, una *traccia* registra informazioni su una richiesta elaborata da uno o più *servizi*. Lambda registra 2 segmenti per traccia, che creano due nodi sul grafico del servizio. L'immagine seguente evidenzia questi due nodi:
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/xray-servicemap-function.png)
Il primo nodo a sinistra rappresenta il servizio Lambda che riceve la richiesta di chiamata. Il secondo nodo rappresenta la specifica funzione Lambda. L'esempio seguente mostra una traccia con questi 2 segmenti. Entrambi sono nominati **my-function**, ma uno ha l'origine `AWS::Lambda` e l'altro ha l'origine `AWS::Lambda::Function`. Se il segmento `AWS::Lambda` mostra un errore, il servizio Lambda ha avuto un problema. Se il `AWS::Lambda::Function` segmento mostra un errore, la funzione ha avuto un problema.
![\[\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/V2_sandbox_images/my-function-2-v1.png)
Questo esempio espande il segmento `AWS::Lambda::Function` per visualizzare i relativi tre sottosegmenti.
**Nota**
AWS sta attualmente implementando modifiche al servizio Lambda. A causa di queste modifiche, potresti notare piccole differenze tra la struttura e il contenuto dei messaggi di log di sistema e dei segmenti di traccia emessi da diverse funzioni Lambda nel tuo Account AWS.
La traccia di esempio mostrata qui illustra il segmento di funzione vecchio stile. Le differenze tra i segmenti vecchio e nuovo stile sono descritte nei paragrafi seguenti.
Queste modifiche verranno implementate nelle prossime settimane e tutte le funzioni, Regioni AWS ad eccezione della Cina e delle GovCloud regioni, passeranno all'utilizzo dei messaggi di registro e dei segmenti di traccia di nuovo formato.
Il segmento di funzioni vecchio stile contiene i seguenti sottosegmenti:
+ **Inizializzazione** – Rappresenta il tempo trascorso a caricare la funzione e ad eseguire il [codice di inizializzazione](foundation-progmodel.md). Questo sottosegmento viene visualizzato solo per il primo evento che viene elaborato da ogni istanza della funzione.
+ **Chiamata**: rappresenta il tempo impiegato per eseguire il codice del gestore.
+ **Overhead**: rappresenta il tempo impiegato dal runtime Lambda per prepararsi a gestire l'evento successivo.
Il segmento di funzione di nuovo stile non contiene un sottosegmento `Invocation`. I sottosegmenti dei clienti sono invece collegati direttamente al segmento di funzioni. Per ulteriori informazioni sulla struttura dei segmenti di funzioni vecchio e nuovo stile, consulta [Informazioni sui monitoraggi di X-Ray](services-xray.md#services-xray-traces).
È inoltre possibile strumentare i client HTTP, registrare query SQL e creare segmenti secondari personalizzati con annotazioni e metadati. Per ulteriori informazioni, consulta [SDK AWS X-Ray per Node.js](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-nodejs.html) nella *Guida per gli sviluppatori di AWS X-Ray *.
**Prezzi**
Puoi utilizzare il tracciamento X-Ray gratuitamente ogni mese fino a un determinato limite come parte del AWS piano gratuito. Oltre la soglia, X-Ray addebita lo storage di traccia e il recupero. Per ulteriori informazioni, consultare [Prezzi di AWS X-Ray](https://aws.amazon.com/xray/pricing/).
## Memorizzazione delle dipendenze di runtime in un livello (SDK X-Ray)
Se utilizzate X-Ray SDK per strumentare i client AWS SDK del codice della funzione, il pacchetto di distribuzione può diventare piuttosto grande. Per evitare di caricare dipendenze di runtime ogni volta che si aggiorna il codice della funzione, includere l'SDK X-Ray in un [livello Lambda](chapter-layers.md).
L'esempio seguente mostra una risorsa `AWS::Serverless::LayerVersion` che memorizza SDK AWS X-Ray per Node.js.
**Example [template.yml](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs/template.yml) – Livello delle dipendenze**
```
Resources:
function:
Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
Properties:
CodeUri: function/.
Tracing: Active
Layers:
- !Ref libs
...
libs:
Type: [AWS::Serverless::LayerVersion](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-layerversion.html)
Properties:
LayerName: blank-nodejs-lib
Description: Dependencies for the blank sample app.
ContentUri: lib/.
CompatibleRuntimes:
- nodejs24.x
```
Con questa configurazione, si aggiorna il livello della libreria solo se si modificano le dipendenze di runtime. Poiché il pacchetto di implementazione della funzione contiene solo il codice, questo può contribuire a ridurre i tempi di caricamento.
La creazione di un layer per le dipendenze richiede modifiche alla compilazione per generare l'archivio dei layer prima della distribuzione. Per un esempio funzionante, vedere l'applicazione di esempio [blank-nodejs](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs) .