View a markdown version of this page

Implementierung von SnapStart Hooks für Container-Images - AWS Lambda
-ÜbersichtVoraussetzungenÜberblick über den LebenszyklusImplementierung von Lebenszyklus-Hooks SnapStartFehlerbehandlung

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Implementierung von SnapStart Hooks für Container-Images

-Übersicht

Bei Verwendung SnapStart mit einer Erstellen einer Lambda-Funktion mit einem Container-Image Container-Image-Funktion muss die Laufzeit den Lebenszyklus der Funktion koordinieren und die Hooks vor dem Snapshot und nach der Wiederherstellung während der entsprechenden Lebenszyklusphasen aufrufen. Mit diesen Hooks können Sie benutzerdefinierte Logik (z. B. das Aktualisieren von Anmeldeinformationen oder das erneute Setzen von Zufallszahlengeneratoren) an bestimmten Punkten im Snapshot- und Wiederherstellungszyklus ausführen. Wenn Sie eine verwaltete Laufzeit verwenden, die unterstützt SnapStart wird, oder die entsprechenden Basis-Images für diese Laufzeiten (Java-Version 11+, Python-Version 3.12+ und.NET-Version 8+), koordiniert Lambda den Lebenszyklus für Sie. Registrieren Sie Ihre Hooks über die unter beschriebene API. Implementieren Sie Code vor oder nach Lambda-Funktions-Snapshots

Wenn Sie Ihre eigenen Basis-Container-Images, Runtime Interface Clients (RICs) oder Lambdas Basis-Images für provided.al2023 oder Ruby verwenden Node.js, folgen Sie zur Verwendung den Schritten auf dieser Seite. SnapStart

Voraussetzungen

Wenn Lambda eine Funktion aus einem Snapshot wiederherstellt, wird jeder bei der Initialisierung definierte Status, wie Zufallszahlengeneratoren, eindeutige IDs und zwischengespeicherte Anmeldeinformationen, von allen Ausführungsumgebungen gemeinsam genutzt, die aus diesem Snapshot wiederhergestellt wurden. Bevor Sie Ihre auf Container-Images basierende Lambda-Funktion verwenden SnapStart , überprüfen Umgang mit Einzigartigkeit mit Lambda SnapStart und vergewissern Sie sich, dass die unter Verwenden von kryptografisch sicheren Pseudozufallszahlengeneratoren (CSPRNGs) beschriebenen Anforderungen erfüllt sind.

Nachdem Sie überprüft haben, ob die Anforderungen erfüllt sind, wählen Sie eine der folgenden beiden Optionen:

  1. Option 1: Wenn Sie Hooks vor dem Snapshot und nach der Wiederherstellung benötigen, um benutzerdefinierte Logik auszuführen, wenn der Snapshot Ihrer Funktion wieder aufgenommen wird, folgen Sie den Anweisungen im Abschnitt. Implementierung von Lebenszyklus-Hooks SnapStart

  2. Option 2: Wenn Sie diese Hooks nicht benötigen, aktivieren SnapStart Sie dieses Container-Image, indem Sie das folgende Label in Ihrem Dockerfile angeben:

LABEL com.amazonaws.lambda.feature.snapstart="Allow"

Wenn Ihr Container-Image weder die /restore/next API implementiert noch das Label enthält, schlägt die Versionsveröffentlichung fehl.

Anmerkung

Diese Voraussetzungen sind nicht erforderlich, wenn Sie von Lambda verwaltete Basis-Images für Java (Version 11+), Python (Version 3.12+) und.NET (Version 8+) verwenden, da sie den Lebenszyklus bereits koordinieren und die SnapStart Eindeutigkeitsanforderungen erfüllen.

Überblick über den Lebenszyklus

Das folgende Diagramm zeigt die Reihenfolge der Runtime-API-Aufrufe, die von einer SnapStart benutzerdefinierten Runtime erwartet werden. Alle Aufrufe sind Teil des Runtime-API-Vertrags; die Aufrufe #3, #4, #5 und #6 sind dagegen spezifisch für SnapStart.

Das Sequenzdiagramm zeigt die Reihenfolge der Runtime-API-Aufrufe für eine SnapStart benutzerdefinierte Laufzeit: Init, Before-Snapshot-Hooks, GET/runtime/restore/next, Hooks nach der Wiederherstellung und die Standard-Invoke-Schleife.

Implementierung von Lebenszyklus-Hooks SnapStart

Gehen Sie zur Verwendung SnapStart mit Ihren Container-Image-Funktionen wie folgt vor:

  1. Führen Sie Before-Snapshot-Hooks aus und lösen Sie den Snapshot-Prozess aus: Führen Sie als letzten Schritt des Initialisierungscodes Ihrer Funktion bei Bedarf die Before-Snapshot-Hooks aus und lösen Sie den Snapshot-Prozess aus. Führen Sie diese Schritte nur aus, wenn sie aktiviert SnapStart ist, indem Sie überprüfen, ob der Wert der Umgebungsvariablen auf gesetzt ist. AWS_LAMBDA_INITIALIZATION_TYPE snap-start Führen Sie Ihre registrierten Before-Snapshot-Hooks aus und rufen Sie dann auf, GET /runtime/restore/next um den Snapshot-Vorgang auszulösen. Wenn ein Before-Snapshot-Hook einen Fehler auslöst oder zurückgibt, sendet die Runtime den Fehler an den Endpunkt. /runtime/init/error Sehen Sie sich die folgenden Pseudocode-Beispiele an:

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

    Die Hooks „Init-Phase“ und „Before-Snapshot“ teilen sich einen kombinierten Timeout von. max(function_timeout, 130 seconds) Wenn dieses Limit überschritten wird, schlägt Lambda die Anfrage fehl. PublishVersion Außerdem ist like/runtime/invocation/next, /runtime/restore/next call ein blockierender Anruf. Er blockiert, bis Lambda die Ausführungsumgebung aus dem Snapshot wiederherstellt.

  2. Führen Sie Hooks nach der Wiederherstellung aus und treten Sie dann in die Invoke-Schleife ein. Wenn 200 GET /runtime/restore/next zurückgegeben wird, muss Ihre Runtime alle registrierten Hooks nach der Wiederherstellung ausführen, bevor sie mit der Aufrufschleife fortfährt. Wenn ein Hook nach der Wiederherstellung fehlschlägt, melden Sie den Fehler an. /runtime/restore/error Nachdem die Hooks nach der Wiederherstellung abgeschlossen sind, rufen Sie die Standardaufrufschleife auf, indem Sie aufrufen. GET /runtime/invocation/next Ab diesem Zeitpunkt ist das Verhalten identisch mit einer Funktion, die nicht verwendet wird. SnapStart Sehen Sie sich die folgenden Pseudocode-Beispiele an:

    # 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

Fehlerbehandlung

Wenn ein Hook fehlschlägt, muss die Runtime den Fehler an den entsprechenden API-Endpunkt melden und den Prozess beenden. Die folgende Tabelle fasst das Verhalten für jede Phase zusammen:

Phase API-Endpunkt ist fehlerhaft Was passiert bei einem Ausfall
Init/before -Snapshot POST /runtime/init/error Lambda schlägt bei der Anfrage fehl. PublishVersion Beenden Sie den Prozess.
After-restore POST /runtime/restore/error Lambda schlägt beim Aufruf während des Fluges fehl und zerstört die Ausführungsumgebung. Beenden Sie den Prozess.

Setzen Sie für beide API-Endpunkte den Lambda-Runtime-Function-Error-Type Header auf einen Wert im Format <Category.Reason> (z. B. Runtime.BeforeSnapshotError oderRuntime.AfterRestoreError). Fügen Sie einen Fehlertext mit errorMessageerrorType, und einem optionalen stackTrace ein.

Die vollständige API-Endpunktspezifikation und die Antwortcodes finden Sie unter Initialisierungsfehler und Wiederherstellungsfehler (gilt nur für SnapStart) in der Runtime-API-Referenz.