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 Container-Image-Funktion muss die Runtime 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 Einsetzen 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 Snapshots der Lambda-Ereignisfunktion

Wenn Sie Ihre eigenen Basis-Container-Images, Runtime Interface Clients (RICs) oder die Basis-Images von Lambda für bereitgestellte.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 während der Initialisierung definierte Status, wie Zufallszahlengeneratoren, eindeutige IDs und zwischengespeicherte Anmeldeinformationen, von allen Ausführungsumgebungen gemeinsam genutzt, die aus diesem Snapshot wiederhergestellt wurden. Überprüfen Sie vor der Verwendung SnapStart mit Ihrer Lambda-Ereignisfunktion, die auf Container-Images basiert, Umgang mit Einzigartigkeit mit Lambda SnapStart und stellen Sie sicher, 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 aus:

  1. Option 1: Wenn Sie Hooks vor 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 Sie sie SnapStart für 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 bereitstellen.

Ü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, wohingegen die Aufrufe #3, #4, #5 und #6 spezifisch sind SnapStart.

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

Implementierung von Lebenszyklus-Hooks SnapStart

Gehen Sie wie folgt vor, um sie SnapStart mit Ihren Container-Image-Funktionen zu verwenden:

  1. Führen Sie Before-Snapshot-Hooks aus und lösen Sie den Snapshot-Vorgang aus: Führen Sie als letzten Schritt des Initialisierungscodes Ihrer Funktion bei Bedarf die Before-Snapshot-Hooks aus und lösen Sie den Snapshot-Vorgang aus. Führen Sie diese Schritte nur aus, wenn die Option 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 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 das Pseudocode-Beispiel unten 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 der Init-Phase und die Hooks vor dem Snapshot haben gemeinsam ein Timeout von. max(function_timeout, 130 seconds) Wenn dieses Limit überschritten wird, schlägt Lambda die PublishVersion Anfrage fehl. Außerdem ist /runtime/restore/next Call /runtime/invocation/next quasi ein blockierender Anruf. Es blockiert, bis Lambda die Ausführungsumgebung aus dem Snapshot wiederherstellt.

  2. Führen Sie Hooks nach der Wiederherstellung aus und rufen Sie dann die Aufrufschleife auf. Wenn 200 GET /runtime/restore/next zurückgegeben wird, muss Ihre Runtime alle registrierten Hooks nach der Wiederherstellung ausführen, bevor sie zur Aufrufschleife übergeht. Wenn ein Hook nach der Wiederherstellung fehlschlägt, melden Sie den Fehler an. /runtime/restore/error Wenn die Hooks nach der Wiederherstellung abgeschlossen sind, rufen Sie die Standard-Aufrufschleife auf, indem Sie aufrufen. GET /runtime/invocation/next Ab diesem Zeitpunkt ist das Verhalten identisch mit dem einer Funktion, die diese Funktion nicht verwendet. SnapStart Sehen Sie sich das Pseudocode-Beispiel unten 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
       GET /runtime/invocation/next

Fehlerbehandlung

Wenn ein Hook fehlschlägt, muss die Runtime den Fehler an den entsprechenden API-Endpunkt melden und den Prozess beenden. In der folgenden Tabelle ist das Verhalten für jede Phase zusammengefasst:

Phase Fehler beim API-Endpunkt Was passiert bei einem Fehler
Init//vor dem Snapshot POST /runtime/init/error Lambda schlägt die PublishVersion Anfrage fehl. Beenden Sie den Prozess.
After-restore POST /runtime/restore/error Lambda schlägt beim In-Flight-Aufruf fehl und zerstört die Ausführungsumgebung. Beenden Sie den Prozess.

Legen Sie für beide API-Endpunkte den Lambda-Runtime-Function-Error-Type Header auf einen Wert im Format fest <Category.Reason> (z. B. Runtime.BeforeSnapshotError oderRuntime.AfterRestoreError). Fügen Sie einen Fehlertext mit errorMessageerrorType, und ein optionales 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.