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.
# Wann sollten die reinen OS-Laufzeiten verwendet werden
Lambda bietet [verwaltete Laufzeiten](lambda-runtimes.md) für Java, Python, Node.js, .NET und Ruby. Um Lambda-Funktionen in einer Programmiersprache zu erstellen, die nicht als verwaltete Laufzeit verfügbar ist, verwenden Sie eine reine OS-Laufzeit (die `provided`-Laufzeitfamilie). Es gibt drei Hauptanwendungsfälle für reine OS-Laufzeiten:
+ **Native Kompilierung ahead-of-time (AOT)**: Sprachen wie Go, Rust, Swift und C\$1\$1 werden nativ zu einer ausführbaren Binärdatei kompiliert, für die keine spezielle Sprachlaufzeit erforderlich ist. Diese Sprachen benötigen nur eine Betriebssystemumgebung, in der die kompilierte Binärdatei ausgeführt werden kann. Sie können auch Laufzeiten verwenden, die nur auf Lambda OS basieren, um Binärdateien bereitzustellen, die mit.NET Native AOT und Java GraalVM Native Image kompiliert wurden.
Sie müssen einen Laufzeitschnitten-Client in Ihre Binärdatei aufnehmen. Der Laufzeitenschnittstellen-Client ruft die [Verwenden der Lambda-Laufzeit-API für benutzerdefinierte Laufzeiten](runtimes-api.md) auf, um Funktionsaufrufe abzurufen, und ruft dann den Funktionshandler auf. Lambda bietet Runtime-Schnittstellenclients für [Rust](lambda-rust.md), [Go](golang-package.md#golang-package-mac-linux), [.NET Native AOT](dotnet-native-aot.md), [Swift](https://github.com/awslabs/swift-aws-lambda-runtime) (experimentell) und [C\$1\$1](https://github.com/awslabs/aws-lambda-cpp) (experimentell).
Sie müssen Ihre Binärdatei für eine Linux-Umgebung und für dieselbe Befehlssatzarchitektur kompilieren, die Sie für die Funktion verwenden möchten (x86\$164 oder arm64).
+ **Laufzeiten von Drittanbietern**: Sie können Lambda-Funktionen mit off-the-shelf Laufzeiten wie [Bref](https://bref.sh/docs/news/01-bref-1.0.html#amazon-linux-2) für PHP ausführen.
+ **Benutzerdefinierte Laufzeiten**: Sie können Ihre eigene Laufzeit für eine Sprache oder Sprachversion erstellen, für die Lambda keine verwaltete Laufzeit bereitstellt, z. B. Node.js 19. Weitere Informationen finden Sie unter [Erstellen einer benutzerdefinierten Laufzeit für AWS Lambda](runtimes-custom.md). Dies ist der am wenigsten verbreitete Anwendungsfall für reine OS-Laufzeiten.
Lambda unterstützt die folgenden reinen OS-Laufzeiten.
| Name | ID | Betriebssystem | Datum der Veraltung | Blockfunktion erstellen | Blockfunktion aktualisieren |
| --- | --- | --- | --- | --- | --- |
| Reine OS-Laufzeit | `provided.al2023` | Amazon Linux 2023 | 30. Juni 2029 | 31. Juli 2029 | 31. August 2029 |
| Reine OS-Laufzeit | `provided.al2` | Amazon Linux 2 | 31. Juli 2026 | 31. August 2026 | 30. September 2026 |
Die Laufzeit von Amazon Linux 2023 (`provided.al2023`) bietet mehrere Vorteile gegenüber Amazon Linux 2, darunter einen geringeren Bereitstellungsaufwand und aktualisierte Versionen von Bibliotheken wie `glibc`.
Die `provided.al2023`-Laufzeit verwendet `dnf` als Paketmanager anstelle von `yum`, was der Standard-Paketmanager in Amazon Linux 2 ist. Weitere Informationen zu den Unterschieden zwischen `provided.al2023` und `provided.al2` finden Sie unter [Einführung in die Amazon Linux 2023 Runtime for AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/) im AWS Compute-Blog.
# 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).
# Tutorial: Erstellen einer benutzerdefinierten Laufzeit
In diesem Tutorial erstellen Sie eine Lambda-Funktion mit einer benutzerdefinierten Laufzeit. Sie beginnen, indem Sie die Laufzeit in das Bereitstellungspaket der Funktion einfügen. Anschließend migrieren Sie sie zu einer Ebene, die Sie unabhängig von der Funktion verwalten. Schließlich geben Sie die Laufzeitebene frei, indem Sie ihre ressourcenbasierte Berechtigungsrichtlinie aktualisieren.
## Voraussetzungen
In diesem Tutorial wird davon ausgegangen, dass Sie über Kenntnisse zu den grundlegenden Lambda-Operationen und der Lambda-Konsole verfügen. Sofern noch nicht geschehen, befolgen Sie die Anweisungen unter [Erstellen einer Lambda-Funktion mit der Konsole](getting-started.md#getting-started-create-function), um Ihre erste Lambda-Funktion zu erstellen.
Um die folgenden Schritte durchzuführen, benötigen Sie die [AWS CLI Version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). Befehle und die erwartete Ausgabe werden in separaten Blöcken aufgeführt:
```
aws --version
```
Die Ausgabe sollte folgendermaßen aussehen:
```
aws-cli/2.13.27 Python/3.11.6 Linux/4.14.328-248.540.amzn2.x86_64 exe/x86_64.amzn.2
```
Bei langen Befehlen wird ein Escape-Zeichen (`\`) wird verwendet, um einen Befehl über mehrere Zeilen zu teilen.
Verwenden Sie auf Linux und macOS Ihren bevorzugten Shell- und Paket-Manager.
**Anmerkung**
In Windows werden einige Bash-CLI-Befehle, die Sie häufig mit Lambda verwenden (z. B. `zip`), von den integrierten Terminals des Betriebssystems nicht unterstützt. Um eine in Windows integrierte Version von Ubuntu und Bash zu erhalten, [installieren Sie das Windows-Subsystem für Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10). Die CLI-Beispielbefehle in diesem Handbuch verwenden die Linux-Formatierung. Befehle, die Inline-JSON-Dokumente enthalten, müssen neu formatiert werden, wenn Sie die Windows-CLI verwenden.
Sie benötigen eine IAM-Rolle, um eine Lambda Funktion zu erstellen. Die Rolle benötigt die Berechtigung zum Senden von Protokollen an CloudWatch Logs und zum Zugriff auf die AWS-Services, die Ihre Funktion verwendet. Wenn Sie nicht über eine Rolle für die Funktionserstellung verfügen, erstellen Sie jetzt eine.
**So erstellen Sie eine Ausführungsrolle**
1. Öffnen Sie die Seite [Roles (Rollen)](https://console.aws.amazon.com/iam/home#/roles) in der IAM-Konsole.
1. Wählen Sie **Create role** aus.
1. Erstellen Sie eine Rolle mit den folgenden Eigenschaften.
+ **Trusted entity (Vertrauenswürdige Entität)** – **Lambda**.
+ **Permissions (Berechtigungen)** – **AWSLambdaBasicExecutionRole**.
+ **Role name (Name der Rolle** – **lambda-role**.
Die Richtlinie **AWSLambdaBasicExecutionRole** verfügt über die Berechtigungen, die die Funktion zum Schreiben von Protokollen in CloudWatch Logs benötigt.
## Erstellen einer -Funktion
Erstellen Sie eine Lambda-Funktion mit einer benutzerdefinierten Laufzeit. Dieses Beispiel enthält zwei Dateien: eine `bootstrap`-Laufzeitdatei und einen Funktions-Handler. Beide sind in Bash implementiert.
1. Erstellen Sie ein Verzeichnis für das Projekt und wechseln Sie dann zu diesem Verzeichnis.
```
mkdir runtime-tutorial
cd runtime-tutorial
```
1. Erstellen Sie eine neue Datei mit dem Namen `bootstrap`. Dies ist die benutzerdefinierte Laufzeit.
**Example bootstrap**
```
#!/bin/sh
set -euo pipefail
# Initialization - load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
Die Laufzeit lädt ein Funktionsskript aus dem Bereitstellungspaket. Sie verwendet zwei Variablen, um das Skript zu finden. `LAMBDA_TASK_ROOT` gibt an, wohin das Paket extrahiert wurde, und `_HANDLER` enthält den Namen des Skripts.
Nachdem die Laufzeit das Funktionsskript geladen hat, verwendet sie die Laufzeit-API, um ein Aufrufereignis aus Lambda abzurufen, übergibt das Ereignis an den Handler und sendet die Antwort zurück an Lambda. Um die Anforderungs-ID abzurufen, speichert die Laufzeit die Header aus der API-Antwort in einer temporären Datei und liest den `Lambda-Runtime-Aws-Request-Id`-Header aus der Datei.
**Anmerkung**
Laufzeit besitzen zusätzliche Verantwortlichkeiten, darunter Fehlerbehandlung und Bereitstellung von Kontextinformationen für den Handler. Details hierzu finden Sie unter [Voraussetzungen](runtimes-custom.md#runtimes-custom-build).
1. Erstellen Sie ein Skript für die Funktion. Das folgende Beispielskript definiert eine Handler-Funktion, die Ereignisdaten annimmt, protokolliert sie in `stderr` und gibt sie zurück.
**Example function.sh**
```
function handler () {
EVENT_DATA=$1
echo "$EVENT_DATA" 1>&2;
RESPONSE="Echoing request: '$EVENT_DATA'"
echo $RESPONSE
}
```
Das `runtime-tutorial`-Verzeichnis sollte jetzt wie folgt aussehen:
```
runtime-tutorial
├ bootstrap
└ function.sh
```
1. Konvertieren Sie die Dateien zu ausführbaren Dateien und fügen Sie sie einem ZIP-Dateiarchiv hinzu. Dies ist das Bereitstellungspaket.
```
chmod 755 function.sh bootstrap
zip function.zip function.sh bootstrap
```
1. Erstellen Sie eine Funktion mit dem Namen `bash-runtime`. Geben Sie für `--role` den ARN Ihrer Lambda-[Ausführungsrolle](lambda-intro-execution-role.md) ein.
```
aws lambda create-function --function-name bash-runtime \
--zip-file fileb://function.zip --handler function.handler --runtime provided.al2023 \
--role arn:aws:iam::123456789012:role/lambda-role
```
1. Die Funktion aufrufen.
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
Die **cli-binary-format**-Option ist erforderlich, wenn Sie AWS CLI Version 2 verwenden. Um dies zur Standardeinstellung zu machen, führen Sie `aws configure set cli-binary-format raw-in-base64-out` aus. Weitere Informationen finden Sie unter [Von AWS CLI unterstützte globale Befehlszeilenoptionen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) im *AWS Command Line Interface-Benutzerhandbuch für Version 2*.
Das Ergebnis sollte ungefähr wie folgt aussehen:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. Überprüfen Sie die Antwort.
```
cat response.txt
```
Das Ergebnis sollte ungefähr wie folgt aussehen:
```
Echoing request: '{"text":"Hello"}'
```
## Erstellen einer Ebene
Um Laufzeitcode und Funktionscode voneinander zu trennen, erstellen Sie eine Ebene, die nur die Laufzeit enthält. Mit Ebenen können Sie die Abhängigkeiten Ihrer Funktion unabhängig entwickeln. Sie können darüber hinaus die Speichernutzung reduzieren, wenn Sie dieselbe Ebene für mehrere Funktionen verwenden. Weitere Informationen finden Sie unter [Verwaltung von Lambda-Abhängigkeiten mit Ebenen](chapter-layers.md).
1. Erstellen Sie eine ZIP-Datei, die die `bootstrap`-Datei enthält.
```
zip runtime.zip bootstrap
```
1. Erstellen Sie eine Ebene mit dem [publish-layer-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-layer-version.html?highlight=nodejs16%20x)-Befehl.
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
Hierdurch wird die erste Version der Ebene erstellt.
## Aktualisieren der Funktion
Um die Laufzeitebene in der Funktion zu verwenden, konfigurieren Sie die Funktion für die Verwendung der Ebene und entfernen den Laufzeitcode aus der Funktion.
1. Aktualisieren Sie die Konfiguration der Funktion, um die Ebene einzubeziehen.
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:1
```
Dadurch wird die Laufzeit zur Funktion im `/opt`-Verzeichnis hinzugefügt. Um sicherzustellen, dass Lambda die Laufzeit in der Ebene verwendet, müssen Sie die `boostrap`-Datei aus dem Bereitstellungspaket der Funktion entfernen, wie in den nächsten beiden Schritten gezeigt.
1. Erstellen Sie eine ZIP-Datei, die den Funktionscode enthält.
```
zip function-only.zip function.sh
```
1. Aktualisieren Sie den Funktionscode so, dass er nur das Handler-Skript enthält.
```
aws lambda update-function-code --function-name bash-runtime --zip-file fileb://function-only.zip
```
1. Rufen Sie die Funktion auf, um zu überprüfen, ob sie mit der Laufzeitebene funktioniert.
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
Die **cli-binary-format**-Option ist erforderlich, wenn Sie AWS CLI Version 2 verwenden. Um dies zur Standardeinstellung zu machen, führen Sie `aws configure set cli-binary-format raw-in-base64-out` aus. Weitere Informationen finden Sie unter [Von AWS CLI unterstützte globale Befehlszeilenoptionen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) im *AWS Command Line Interface-Benutzerhandbuch für Version 2*.
Das Ergebnis sollte ungefähr wie folgt aussehen:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. Überprüfen Sie die Antwort.
```
cat response.txt
```
Das Ergebnis sollte ungefähr wie folgt aussehen:
```
Echoing request: '{"text":"Hello"}'
```
## Aktualisieren der Laufzeit
1. Um Informationen zur Ausführungsumgebung zu protokollieren, aktualisieren Sie das Laufzeitskript, sodass es Umgebungsvariablen ausgibt.
**Example bootstrap**
```
#!/bin/sh
set -euo pipefail
# Configure runtime to output environment variables
echo "## Environment variables:"
env
# Load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
1. Erstellen Sie eine ZIP-Datei mit der neuen Version der `bootstrap`-Datei.
```
zip runtime.zip bootstrap
```
1. Erstellt eine neue Version der `bash-runtime`-Ebene.
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
1. Konfigurieren Sie die Funktion für die Verwendung der neuen Version der Ebene.
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2
```
## Freigeben der Ebene
Um eine Ebene mit einem anderen AWS-Konto gemeinsam zu nutzen, fügen Sie der [ressourcenbasierten Richtlinie](access-control-resource-based.md) der Ebene eine kontenübergreifende Berechtigungsanweisung hinzu. Führen Sie den Befehl [add-layer-version-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-layer-version-permission.html) aus und geben Sie die Konto-ID als `principal` an. In jeder Anweisung können Sie einem einzelnen Konto, allen Konten oder einer Organisation in [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) eine Berechtigung erteilen.
Im folgenden Beispiel wird dem Konto 111122223333 Zugriff auf Version 2 der `bash-runtime`-Ebene gewährt.
```
aws lambda add-layer-version-permission \
--layer-name bash-runtime \
--version-number 2 \
--statement-id xaccount \
--action lambda:GetLayerVersion \
--principal 111122223333 \
--output text
```
Die Ausgabe sollte folgendermaßen oder ähnlich aussehen:
```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2"}
```
Berechtigungen gelten nur für eine Version mit einer Ebene. Wiederholen Sie den Vorgang bei jeder Erstellung einer neuen Ebenenversion.
## Bereinigen
Löschen Sie alle Versionen der Ebene.
```
aws lambda delete-layer-version --layer-name bash-runtime --version-number 1
aws lambda delete-layer-version --layer-name bash-runtime --version-number 2
```
Da die Funktion einen Verweis auf Version 2 der Ebene enthält, ist diese nach wie vor in Lambda vorhanden. Die Funktion funktioniert weiter. Es können jedoch keine weiteren Funktionen für die Verwendung der gelöschten Version konfiguriert werden. Wenn Sie die Liste der Ebenen in der Funktion ändern, müssen Sie eine neue Version angeben oder die gelöschte Ebene auslassen.
Löschen Sie die Funktion mit dem Befehl [delete-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-function.html).
```
aws lambda delete-function --function-name bash-runtime
```