View a markdown version of this page

Implementazione di SnapStart hook per le immagini dei contenitori - AWS Lambda
Panoramica diPrerequisitiPanoramica del ciclo di vitaSnapStart Implementazione degli hook del ciclo di vitaGestione degli errori

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 viene utilizzato SnapStart con una funzione di immagine del 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 logiche personalizzate (ad esempio l'aggiornamento delle credenziali o il reseeding di generatori di numeri casuali) in alcuni punti del ciclo di vita di snapshot e 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. Implementa il codice prima o dopo le istantanee di Lambda Event Function

Se utilizzi le tue immagini dei contenitori di base, i Runtime Interface Clients (RIC) o le immagini di base di Lambda per provided.al2023 o Ruby Node.js, segui i passaggi 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 tra tutti gli ambienti di esecuzione ripristinati da quell'istantanea. Prima di utilizzarla SnapStart con la tua funzione Lambda Event basata su immagini container, esamina Gestire l'unicità con Lambda SnapStart e assicurati che siano soddisfatti i requisiti delineati in Utilizzare generatori di numeri pseudocasuali (CSPRNG) crittograficamente sicuri.

Dopo aver verificato che i requisiti siano soddisfatti, scegli una delle due opzioni seguenti:

  1. Opzione 1: se hai bisogno degli hook before-snapshot e after-restore per eseguire la logica personalizzata quando l'istantanea della funzione viene ripresa, segui le istruzioni nella sezione. SnapStart Implementazione degli hook del ciclo di vita

  2. 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/nextAPI né include l'etichetta, la pubblicazione della versione avrà esito negativo.

Nota

Questi prerequisiti non sono necessari se si utilizzano immagini di base gestite Lambda per Java (versione 11+), Python (versione 3.12+) e.NET (versione 8+) poiché già coordinano il ciclo di vita e forniscono i requisiti di unicità. SnapStart

Panoramica del ciclo di vita

Il diagramma seguente mostra l'ordine delle chiamate all'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.

Diagramma di sequenza che mostra l'ordine delle chiamate all'API Runtime per un runtime SnapStart personalizzato: init, before-snapshot hooks, GET/runtime/restore/next, after-restore hooks e il ciclo di invoke standard.

SnapStart Implementazione degli hook del ciclo di vita

Per utilizzarle SnapStart con le funzioni relative all'immagine 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 Vedi l'esempio di pseudo-codice riportato di seguito:

    # 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  <Category.Reason>
                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 riesce PublishVersion a completare la richiesta. Inoltre, ad esempio/runtime/invocation/next, la /runtime/restore/next chiamata è una chiamata bloccante. Si blocca finché Lambda non ripristina l'ambiente di esecuzione dall'istantanea.

  2. Esegui gli hook after-restore, 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 post-ripristino fallisce, segnala l'errore a. /runtime/restore/error Una volta completati gli hook post-restore, inserisci il ciclo di invoke standard chiamando. GET /runtime/invocation/next Da questo punto in poi, il comportamento è identico a quello di una funzione che non utilizza. SnapStart Vedi l'esempio di pseudo-codice riportato di seguito:

    # 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  <Category.Reason>
            SET body    TO  { errorMessage, errorType, stackTrace }

# Proceed to the invoke loop
       GET /runtime/invocation/next

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 di ciascuna fase:

Fase Errore nell'endpoint dell'API Cosa succede in caso di errore
Init//before-snapshot POST /runtime/init/error Lambda non riesce a completare la richiesta. PublishVersion Esci dal processo.
After-restore POST /runtime/restore/error Lambda fallisce l'invocazione in volo e distrugge l'ambiente di esecuzione. Esci dal processo.

Per entrambi gli endpoint dell'API, imposta l'Lambda-Runtime-Function-Error-Typeintestazione su un valore nel formato <Category.Reason> (ad esempio Runtime.BeforeSnapshotError oRuntime.AfterRestoreError). Includi un corpo di errore con errorMessageerrorType, e un elemento opzionale. stackTrace

Per la specifica completa degli endpoint dell'API e i codici di risposta, consulta Errore di inizializzazione e Errore di ripristino (applicabile solo per) SnapStart nel riferimento all'API Runtime.