Erstellen einer benutzerdefinierten Laufzeit für AWS Lambda

Sie können eine AWS Lambda -Laufzeit in jeder Programmiersprache implementieren. Eine Laufzeit ist ein Programm, das die Handler-Methode einer Lambda-Funktion ausführt, wenn die Funktion aufgerufen wird. Die Laufzeit kann im Bereitstellungspaket Ihrer Funktion enthalten sein oder in einem Layer verteilt werden. Wenn Sie die Lambda-Funktion erstellen, wählen Sie eine reine OS-Laufzeit (die provided-Laufzeitfamilie) aus.

Anmerkung

Das Erstellen einer benutzerdefinierten Laufzeit ist ein Anwendungsfall für Fortgeschrittene. Informationen zum Kompilieren in einer nativen Binärdatei oder zum Verwenden einer Drittanbieter- off-the-shelf Laufzeit finden Sie unter Nur-Betriebssystem-Laufzeiten für AWS Lambda.

Eine exemplarische Vorgehensweise für die Bereitstellung einer benutzerdefinierten Laufzeit finden Sie unter Tutorial: Erstellen einer benutzerdefinierten Laufzeit. Sie können auch eine in C++ implementierte benutzerdefinierte Laufzeit unter awslabs/aws-lambda-cpp auf erkunden GitHub.

Voraussetzungen

Benutzerdefinierte Laufzeiten müssen bestimmte Initialisierungs- und Verarbeitungsaufgaben abschließen. Eine Laufzeit führt den Setup-Code der Funktion aus, liest den Namen des Handlers aus einer Umgebungsvariablen und liest Aufrufereignisse von der Lambda-Laufzeit-API. Die Laufzeit übergibt die Ereignisdaten an den Funktions-Handler und sendet die Antwort aus dem Handler zurück an Lambda.

Initialisierungsaufgaben

Die Initialisierungsaufgaben werden einmal pro Instance der Funktion ausgeführt, um die Umgebung auf die Verarbeitung von Aufrufen vorzubereiten.

• Einstellungen abrufen – Liest Umgebungsvariablen, um Details zu Funktion und Umgebung abzurufen.

  • _HANDLER – Der Speicherort für den Handler aus der Konfiguration der Funktion. Das Standardformat ist file.method, wobei file der Name der Datei ohne Erweiterung und method der Name einer Methode oder Funktion ist, die in der Datei definiert ist.

  • LAMBDA_TASK_ROOT – Das Verzeichnis, das den Funktionscode enthält.

  • AWS_LAMBDA_RUNTIME_API – Host und Port der Laufzeit-API.

  Unter Definierte Laufzeitumgebungsvariablen finden Sie eine vollständige Liste der verfügbaren Variablen.

• Funktion initialisieren – Lädt die Handler-Datei und führt den globalen oder statischen Code aus, den sie enthält. Funktionen sollten statische Ressourcen wie SDK-Clients und Datenbankverbindungen einmal erstellen und für mehrere Aufrufe wiederverwenden.

• Fehler verarbeiten – Wenn ein Fehler auftritt, werden die Initialisierungsfehler-API aufgerufen die Ausführung sofort beendet.

Die Initialisierung zählt zur fakturierten Ausführungszeit und zum Timeout. Wenn eine Ausführung die Initialisierung einer neuen Instance Ihrer Funktion auslöst, sehen Sie die Initialisierungszeit in den Protokollen und in der AWS X-Ray -Nachverfolgung.

Beispiel log

REPORT RequestId: f8ac1208... Init Duration: 48.26 ms   Duration: 237.17 ms   Billed Duration: 300 ms   Memory Size: 128 MB   Max Memory Used: 26 MB

Verarbeitungsaufgaben

Während der Ausführung verwendet eine Laufzeit die Lambda-Laufzeitschnittstelle, um eingehende Ereignisse zu verwalten und Fehler zu melden. Nach Abschluss der Initialisierungsaufgaben verarbeitet die Laufzeit eingehende Ereignisse in einer Schleife. Führen Sie in Ihrem Laufzeitcode die folgenden Schritte in der angegebenen Reihenfolge aus.

• Ereignis abrufen – Ruft die API für den nächsten Aufruf auf, um das nächste Ereignis abzurufen. Der Antworttext enthält die Ereignisdaten. De Antwort-Header enthalten die Anforderungs-ID und andere Informationen.

• Nachverfolgungs-Header propagieren – Ruft den X-Ray-Nachverfolgungs-Header aus dem Lambda-Runtime-Trace-Id-Header in der API-Antwort ab. Legen Sie die _X_AMZN_TRACE_ID-Umgebungsvariable lokal mit demselben Wert fest. Das X-Ray-SDK verwendet diesen Wert, um Ablaufverfolgungsdaten zwischen Services miteinander zu verbinden.

• Context-Objekt erstellen – Erstellt ein Objekt mit Kontextinformationen aus Umgebungsvariablen und Headern in den API-Antworten.

• Funktions-Handler aufrufen – Übergibt Ereignis und Context-Objekt an den Handler.

• Antwort verarbeiten – Ruft die API für die Aufrufantwort ab, um die Antwort aus dem Handler zu veröffentlichen.

• Fehler verarbeiten – Ruft die API für Aufruffehler auf, wenn ein Fehler auftritt.

• Bereinigen Gibt nicht verwendete Ressourcen frei, sendet Daten an andere Services oder führt zusätzliche Aufgaben aus, bevor das nächste Ereignis abgerufen wird.

Eintrittspunkt

Der Eintrittspunkt einer benutzerdefinierten Laufzeit ist eine ausführbare Datei mit dem Namen bootstrap. Bei der Bootstrap-Datei kann es sich um die Laufzeit handeln oder es wird eine andere Datei aufgerufen, die die Laufzeit erstellt. Wenn das Stammverzeichnis Ihres Bereitstellungspakets keine Datei mit dem Namen bootstrap enthält, sucht Lambda in den Funktionsschichten nach der Datei. Wenn die bootstrap-Datei nicht existiert oder nicht ausgeführt werden kann, gibt die Funktion beim Aufruf einen Runtime.InvalidEntrypoint-Fehler zurück.

Im Folgenden finden Sie eine bootstrap Beispieldatei, die eine gebündelte Version von Node.js verwendet, um eine JavaScript Laufzeit in einer separaten Datei namens auszuführenruntime.js.

Beispiel bootstrap

#!/bin/sh
    cd $LAMBDA_TASK_ROOT
    ./node-v11.1.0-linux-x64/bin/node runtime.js

Implementieren von Antwort-Streaming in einer benutzerdefinierten Laufzeitumgebung

Für Antwort-Streaming-Funktionen haben die Endpunkte response und error ein leicht geändertes Verhalten, das es der Laufzeit ermöglicht, Teilantworten an den Client zu streamen und Nutzlasten in Paketen zurückzugeben. Weitere Informationen zu dem spezifischen Verhalten finden Sie unter:

• /runtime/invocation/AwsRequestId/response – Gibt den Content-Type-Header von der Laufzeit zum Senden an den Client weiter. Lambda gibt die Nutzlasten der Antwort in Blöcken über HTTP/1.1-Blocktransfer-Codierungsschema zurück. Der Antwort-Stream darf maximal 20 MiB groß sein. Um die Antwort an Lambda zu streamen, muss die Laufzeit:

  • Den Lambda-Runtime-Function-Response-Mode-HTTP-Header auf streaming festlegen.

  • Legen Sie den Transfer-Encoding-Header auf chunked fest.

  • Die Antwort in Übereinstimmung mit der HTTP/1.1-Blocktransfer-Codierungsspezifikation schreiben.

  • Schließt die zugrunde liegende Verbindung, nachdem sie die Antwort erfolgreich geschrieben hat.

• /runtime/invocation/AwsRequestId/error – Die Laufzeit kann diesen Endpunkt verwenden, um Funktions- oder Laufzeitfehler an Lambda zu melden, das auch den Transfer-Encoding-Header akzeptiert. Dieser Endpunkt kann nur aufgerufen werden, bevor die Laufzeit mit dem Senden einer Aufrufantwort beginnt.

• Melden von Fehlern in der Mitte des Prozesses mit Hilfe von Fehler-Trailern in /runtime/invocation/AwsRequestId/response – Um Fehler zu melden, die auftreten, nachdem die Laufzeit mit dem Schreiben der Antwort auf den Aufruf begonnen hat, kann die Laufzeit optional HTTP-Trailing-Header namens Lambda-Runtime-Function-Error-Type und Lambda-Runtime-Function-Error-Body anfügen. Lambda behandelt dies als erfolgreiche Antwort und leitet die Fehler-Metadaten, die die Laufzeit bereitstellt, an den Client weiter.

  Anmerkung

  Um nachgestellte Trailer-Header anzufügen, muss die Laufzeit den Header-Wert am Anfang der HTTP-Anfrage festlegen. Dies ist eine Voraussetzung der HTTP/1.1-Blocktransfer-Codierungs-Spezifikation.

  • Lambda-Runtime-Function-Error-Type – Der Fehlertyp, auf den die Laufzeit gestoßen ist. Dieser Header besteht aus einem Zeichenfolgen-Wert. Lambda akzeptiert jede Zeichenfolge, aber wir empfehlen ein Format von <category.reason>. Beispiel: Runtime.APIKeyNotFound

  • Lambda-Runtime-Function-Error-Body – Base64-kodierte Informationen über den Fehler.