View a markdown version of this page

Implementazione di SnapStart hook per le immagini dei contenitori - AWS Lambda
Panoramica diPrerequisitiPanoramica del ciclo di vitaImplementazione degli hook del ciclo di vita SnapStartGestione 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 si utilizza SnapStart 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 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

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 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

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

  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 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.

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

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  <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 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.

  2. 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  <Category>.<Reason>
            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-Typeintestazione su un valore nel formato <Category.Reason> (ad esempio, Runtime.BeforeSnapshotError oRuntime.AfterRestoreError). Includi un corpo dell'errore con errorMessageerrorType, e un opzionale. stackTrace

Per le specifiche complete degli endpoint API e i codici di risposta, consulta Errore di inizializzazione e Errore di ripristino (applicabile solo per) SnapStart nel riferimento all'API Runtime.