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. # 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](chapter-layers.md) verteilt werden. Wenn Sie die Lambda-Funktion erstellen, wählen Sie eine [reine OS-Laufzeit](runtimes-provided.md) (die `provided`-Laufzeitfamilie) aus. **Anmerkung** Das Erstellen einer benutzerdefinierten Laufzeit ist ein Anwendungsfall für Fortgeschrittene. Informationen zur Kompilierung in eine native Binärdatei oder zur Verwendung einer off-the-shelf Runtime eines Drittanbieters finden Sie unter[Wann sollten die reinen OS-Laufzeiten verwendet werden](runtimes-provided.md). Eine exemplarische Vorgehensweise für die Bereitstellung einer benutzerdefinierten Laufzeit finden Sie unter [Tutorial: Erstellen einer benutzerdefinierten Laufzeit](runtimes-walkthrough.md). **Topics** + [Voraussetzungen](#runtimes-custom-build) + [Implementieren von Antwort-Streaming in einer benutzerdefinierten Laufzeitumgebung](#runtimes-custom-response-streaming) + [Erstellung benutzerdefinierter Laufzeiten für Lambda Managed Instances](#runtimes-custom-managed-instances) ## 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](lambda-runtime-environment.md) 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](configuration-envvars.md#configuration-envvars-runtime) 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](runtimes-api.md#runtimes-api-initerror)-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](services-xray.md). **Example 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](runtimes-api.md), 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](runtimes-api.md#runtimes-api-next) 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](runtimes-api.md#runtimes-api-response) ab, um die Antwort aus dem Handler zu veröffentlichen. + **Fehler verarbeiten** – Ruft die API für [Aufruffehler](runtimes-api.md#runtimes-api-invokeerror) 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. Hier ist eine `bootstrap` Beispieldatei, die eine gebündelte Version von Node.js verwendet, um eine JavaScript Runtime in einer separaten Datei mit dem Namen auszuführen. `runtime.js` **Example 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](configuration-response-streaming.md) 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. 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, wir empfehlen jedoch ein Format von**. Beispiel, `Runtime.APIKeyNotFound`. + `Lambda-Runtime-Function-Error-Body` – Base64-kodierte Informationen über den Fehler. ## Erstellung benutzerdefinierter Laufzeiten für Lambda Managed Instances Lambda Managed Instances verwenden dieselbe Runtime-API wie Lambda-Funktionen (Standard). Es gibt jedoch wesentliche Unterschiede darin, wie benutzerdefinierte Laufzeiten implementiert werden müssen, um das Modell der gleichzeitigen Ausführung von Managed Instances zu unterstützen. ### Gleichzeitige Bearbeitung von Anfragen Der Hauptunterschied bei der Erstellung benutzerdefinierter Laufzeiten für verwaltete Instanzen ist die Unterstützung gleichzeitiger Aufrufe. Im Gegensatz zu Lambda-Funktionen (Standard), bei denen die Laufzeit jeweils einen Aufruf verarbeitet, können Managed Instances mehrere Aufrufe gleichzeitig innerhalb einer einzigen Ausführungsumgebung verarbeiten. Ihre benutzerdefinierte Laufzeit muss: + **Support gleichzeitiger `/next` Anfragen** — Die Runtime kann mehrere gleichzeitige Aufrufe an die [nächste Aufruf-API](runtimes-api.md#runtimes-api-next) tätigen, bis zu dem in der `AWS_LAMBDA_MAX_CONCURRENCY` Umgebungsvariablen angegebenen Grenzwert. + **Gleichzeitige `/response` Anfragen verarbeiten** [— Bei mehreren Aufrufen kann die Aufruf-Antwort-API gleichzeitig aufgerufen werden.](runtimes-api.md#runtimes-api-response) + **Implementieren Sie eine threadsichere Bearbeitung von Anfragen** — Stellen Sie sicher, dass sich gleichzeitige Aufrufe nicht gegenseitig behindern, indem Sie gemeinsam genutzte Ressourcen und den Status ordnungsgemäß verwalten. + **Verwenden Sie eine eindeutige Anfrage IDs** — Verfolgen Sie jeden Aufruf separat, indem Sie den `Lambda-Runtime-Aws-Request-Id` Header verwenden, um Antworten den entsprechenden Anfragen zuzuordnen. ### Implementierungsmuster Ein typisches Implementierungsmuster für Laufzeiten von Managed Instances beinhaltet die Erstellung von Worker-Threads oder Prozessen zur Verarbeitung gleichzeitiger Aufrufe: 1. **Das Parallelitätslimit auslesen** — Lesen Sie bei der Initialisierung die `AWS_LAMBDA_MAX_CONCURRENCY` Umgebungsvariable, um zu bestimmen, wie viele gleichzeitige Aufrufe unterstützt werden sollen. 1. **Worker-Pool erstellen** — Initialisieren Sie einen Worker-Pool (Threads, Prozesse oder asynchrone Aufgaben), der dem Parallelitätslimit entspricht. 1. **Worker-Verarbeitungsschleife** — Jeder Worker unabhängig: + Ruft `/runtime/invocation/next` auf, um ein Aufrufereignis abzurufen + Ruft den Funktionshandler mit den Ereignisdaten auf + Sendet die Antwort an `/runtime/invocation/AwsRequestId/response` + Wiederholt die Schleife ### Weitere Überlegungen + **Protokollierungsformat** — Verwaltete Instances unterstützen nur das JSON-Protokollformat. Stellen Sie sicher, dass Ihre Laufzeit die `AWS_LAMBDA_LOG_FORMAT` Umgebungsvariable respektiert und nur das JSON-Format verwendet. Weitere Informationen finden Sie unter [Konfiguration der JSON- und Klartext-Protokollformate](monitoring-cloudwatchlogs-logformat.md). + **Gemeinsam genutzte Ressourcen** — Seien Sie vorsichtig, wenn Sie gemeinsam genutzte Ressourcen wie das `/tmp` Verzeichnis mit gleichzeitigen Aufrufen verwenden. Implementieren Sie geeignete Schließmechanismen, um Rennbedingungen zu vermeiden. Weitere Informationen zu Ausführungsumgebungen für Lambda Managed Instances finden Sie unter[Grundlegendes zur Ausführungsumgebung von Lambda Managed Instances](lambda-managed-instances-execution-environment.md).