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à.
# Implementazione di SnapStart hook per le immagini dei contenitori
## Panoramica di
Quando si utilizza SnapStart una [ funzione di immagine del ](images-create.md) contenitore, il runtime deve coordinare il ciclo di vita della funzione e richiamare gli hook before-snapshot e after-restore durante le fasi appropriate del ciclo di vita. Questi hook consentono di eseguire una logica personalizzata (come l'aggiornamento delle credenziali o il reseeding di generatori di numeri casuali) in alcuni punti del ciclo di vita dell'istantanea e del ripristino. Se utilizzi un runtime gestito dove SnapStart è supportato o le immagini di base corrispondenti per tali runtime (Java versione 11\+, Python versione 3.12\+ e .NET versione 8\+), Lambda coordina il ciclo di vita per te. Registra i tuoi hook tramite l'API descritta in. [Implementare il codice prima o dopo gli snapshot della funzione Lambda](snapstart-runtime-hooks.md)
Se utilizzi le tue immagini del contenitore di base, i Runtime Interface Client (RIC) o le immagini di base di Lambda per provided.al2023 o Ruby Node.js, segui i passaggi indicati in questa pagina per utilizzarli. SnapStart
## Prerequisiti
Quando Lambda ripristina una funzione da un'istantanea, qualsiasi stato definito durante l'inizializzazione, come generatori di numeri casuali, ID univoci e credenziali memorizzate nella cache, viene condiviso in tutti gli ambienti di esecuzione ripristinati da quell'istantanea. Prima di utilizzarla SnapStart con la funzione Lambda basata su immagini di contenitori, rivedi [Gestire l'unicità con Lambda SnapStart](snapstart-uniqueness.md) e assicurati che i requisiti descritti in Usa generatori di numeri pseudorandom numerici (CSPRNG) crittograficamente sicuri siano soddisfatti. [https://docs.aws.amazon.com/lambda/latest/dg/snapstart-uniqueness.html#snapstart-csprng](https://docs.aws.amazon.com/lambda/latest/dg/snapstart-uniqueness.html#snapstart-csprng)
Dopo aver verificato che i requisiti siano soddisfatti, scegli una delle due opzioni seguenti:
1. **Opzione 1: ** se hai bisogno di hook before-snapshot e after-restore per eseguire una logica personalizzata quando viene ripresa l'istantanea della funzione, segui le istruzioni nella sezione. [Implementazione degli hook del ciclo di vita SnapStart](#snapstart-custom-implement)
1. **Opzione 2: ** se non hai bisogno di questi hook, abilita questa immagine del contenitore specificando la seguente etichetta all'interno del tuo SnapStart Dockerfile:
```
LABEL com.amazonaws.lambda.feature.snapstart="Allow"
```
Se l'immagine del contenitore non implementa l'`/restore/next`API né include l'etichetta, la pubblicazione della versione fallirà.
**Nota**
Questi prerequisiti non sono richiesti se utilizzi immagini di base gestite da Lambda per Java (versione 11\+), Python (versione 3.12\+) e.NET (versione 8\+) poiché coordinano già il ciclo di vita e forniscono i requisiti di unicità. SnapStart
## Panoramica del ciclo di vita
Il diagramma seguente mostra l'ordine delle chiamate API Runtime che un runtime SnapStart personalizzato dovrebbe effettuare. Tutte le chiamate fanno parte del contratto Runtime API; mentre le chiamate \#3, \#4, \#5 e \#6 sono specifiche per SnapStart.
## Implementazione degli hook del ciclo di vita SnapStart
Per utilizzarle SnapStart con le funzioni relative alle immagini del contenitore, procedi nel seguente modo:
1. **Esegui gli hook before-snapshot e attiva il processo di snapshotting: ** come ultimo passaggio del codice di inizializzazione della funzione, esegui gli hook before-snapshot, se necessario, e attiva il processo di snapshotting. Esegui questi passaggi solo se è abilitato, controllando che il valore della variabile di ambiente sia impostato su. SnapStart `AWS_LAMBDA_INITIALIZATION_TYPE` `snap-start` Esegui gli hook before-snapshot registrati, quindi chiama `GET /runtime/restore/next` per attivare il processo di snapshotting. Se un hook before-snapshot genera o restituisce un errore, il runtime invia l'errore all'endpoint. `/runtime/init/error` Guarda gli esempi di pseudo-codice qui sotto:
```
# After all initialization code has finished:
READ initialization_type FROM environment variable "AWS_LAMBDA_INITIALIZATION_TYPE"
IF initialization_type IS "snap-start" THEN
TRY
EXECUTE registered before-snapshot hooks
ON ERROR
POST error to /runtime/init/error
SET header Lambda-Runtime-Function-Error-Type TO .
SET body TO { errorMessage, errorType, stackTrace }
EXIT process with non-zero code
# Signal readiness for snapshot
SEND GET request to /runtime/restore/next
# The request blocks until Lambda restores the execution environment from the snapshot, then returns HTTP 200.
END IF
```
**Nota**
Gli hook init phase e before-snapshot condividono un timeout combinato di. `max(function_timeout, 130 seconds)` Se questo limite viene superato, Lambda non risponde alla richiesta. PublishVersion Inoltre, ad esempio`/runtime/invocation/next`, una `/runtime/restore/next` chiamata è una chiamata bloccante. Si blocca finché Lambda non ripristina l'ambiente di esecuzione dall'istantanea.
1. **Esegui gli hook dopo il ripristino, quindi entra nel ciclo di invoke. ** Quando `GET /runtime/restore/next` restituisce 200, il runtime deve eseguire tutti gli hook post-ripristino registrati prima di procedere al ciclo di invoke. Se un hook dopo il ripristino fallisce, segnala l'errore a. `/runtime/restore/error` Una volta completati gli hook dopo il ripristino, entrate nel ciclo di invocazione standard chiamando. `GET /runtime/invocation/next` Da questo punto in poi, il comportamento è identico a una funzione che non utilizza. SnapStart Guarda gli esempi di pseudo-codice qui sotto:
```
# After the snapshot has been restored
# (i.e., GET /runtime/restore/next has returned HTTP 200):
TRY
EXECUTE registered after-restore hooks
ON ERROR
POST error to /runtime/restore/error
SET header Lambda-Runtime-Function-Error-Type TO .
SET body TO { errorMessage, errorType, stackTrace }
# Proceed to the invoke loop
```
## Gestione degli errori
Se un hook fallisce, il runtime deve segnalare l'errore all'endpoint API appropriato e uscire dal processo. La tabella seguente riassume il comportamento per ciascuna fase:
| Fase | Endpoint API di errore | Cosa succede in caso di errore |
| --- | --- | --- |
| Istantanea iniziata/prima | POST /runtime/init/error | Lambda non risponde alla richiesta. PublishVersion Uscire dal processo. |
| After-restore | POST /runtime/restore/error | Lambda fallisce l'invocazione in volo e distrugge l'ambiente di esecuzione. Uscire dal processo. |
Per entrambi gli endpoint API, imposta l'`Lambda-Runtime-Function-Error-Type`intestazione su un valore nel formato `` (ad esempio, `Runtime.BeforeSnapshotError` o`Runtime.AfterRestoreError`). Includi un corpo dell'errore con `errorMessage``errorType`, e un opzionale. `stackTrace`
Per le specifiche complete degli endpoint API e i codici di risposta, consulta [Errore di inizializzazione](runtimes-api.md#runtimes-api-initerror) e [Errore di ripristino (applicabile solo per) SnapStart](runtimes-api.md#runtimes-api-restore-error) nel riferimento all'API Runtime.