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 Lambda-Funktion mit einem Container-Image
Der Code Ihrer AWS Lambda Funktion besteht aus Skripten oder kompilierten Programmen und deren Abhängigkeiten. Sie verwenden ein *Bereitstellungspaket*, um Ihren Funktionscode in Lambda bereitzustellen. Lambda unterstützt zwei Arten von Bereitstellungspaketen: Container-Images und ZIP-Dateiarchiven.
Es gibt drei Möglichkeiten, ein Container-Image für eine Lambda-Funktion zu erstellen:
+ [Mit einem AWS Basisbild für Lambda](#runtimes-images-lp)
Die [AWS -Basis-Images](#runtimes-images-lp) sind mit einer Sprachlaufzeit, einem Laufzeitschnittstellen-Client zur Verwaltung der Interaktion zwischen Lambda und Ihrem Funktionscode und einem Laufzeitschnittstellen-Emulator für lokale Tests vorinstalliert.
+ [Mit einem AWS OS-only Basisbild](#runtimes-images-provided)
[AWS OS-only Basis-Images](https://gallery.ecr.aws/lambda/provided) enthalten eine Amazon Linux-Distribution und den [Runtime-Interface-Emulator](https://github.com/aws/aws-lambda-runtime-interface-emulator/). Diese Images werden häufig verwendet, um Container-Images für kompilierte Sprachen wie [Go](go-image.md#go-image-provided) und [Rust](lambda-rust.md) und für eine Sprache oder Sprachversion zu erstellen, für die Lambda kein Basis-Image bereitstellt, wie z. B. Node.js 19. Sie können auch OS-only Basis-Images verwenden, um eine [benutzerdefinierte Laufzeit](runtimes-custom.md) zu implementieren. Um das Image mit Lambda kompatibel zu machen, müssen Sie den [Laufzeitschnittstellen-Client](#images-ric) für Ihre Sprache in das Image aufnehmen.
+ [Mit einem nicht-AWS Basisbild](#images-types)
Sie können auch ein alternatives Basis-Image aus einer anderen Container-Registry verwenden. Sie können auch ein von Ihrer Organisation erstelltes benutzerdefiniertes Image verwenden. Um das Image mit Lambda kompatibel zu machen, müssen Sie den [Laufzeitschnittstellen-Client](#images-ric) für Ihre Sprache in das Image aufnehmen.
**Tipp**
Um die Zeit zu reduzieren, die benötigt wird, bis Lambda-Container-Funktionen aktiv werden, siehe die Docker-Dokumentation unter [Verwenden mehrstufiger Builds](https://docs.docker.com/build/building/multi-stage/). Um effiziente Container-Images zu erstellen, folgen Sie den [Bewährte Methoden für das Schreiben von Dockerfiles](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/).
Um eine Lambda-Funktion aus einem Container-Image zu erstellen, erstellen Sie Ihr Image lokal und laden es in ein Amazon Elastic Container Registry (Amazon ECR)-Repository hoch. Wenn Sie ein von einem [AWS Marketplace](https://docs.aws.amazon.com/marketplace/latest/userguide/container-based-products.html)-Verkäufer bereitgestelltes Container-Image verwenden, müssen Sie das Image zuerst in Ihr privates Amazon-ECR-Repository klonen. Geben Sie dann den Repository-URI an, wenn Sie die Funktion erstellen. Das Amazon ECR-Repository muss sich im selben Format AWS-Region wie die Lambda-Funktion befinden. Sie können eine Funktion mit einem Bild in einem anderen AWS Konto erstellen, sofern sich das Bild in derselben Region wie die Lambda-Funktion befindet. Weitere Informationen finden Sie unter [Kontoübergreifende Berechtigungen von Amazon ECR](#configuration-images-xaccount-permissions).
**Anmerkung**
Lambda unterstützt Amazon-ECR-FIPS-Endpunkte für Container-Images nicht. Wenn Ihr Repository-URI ein `ecr-fips` enthält, verwenden Sie einen FIPS-Endpunkt. Beispiel: `111122223333.dkr.ecr-fips.us-east-1.amazonaws.com`.
Auf dieser Seite werden die Basis-Image-Typen und die Anforderungen für die Erstellung von Lambda-compatible Container-Images erläutert.
**Anmerkung**
Sie können den [Bereitstellungspakettyp](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-PackageType) (.zip oder Container-Image) für eine vorhandene Funktion nicht ändern. Sie können zum Beispiel eine Container-Image-Funktion nicht so umwandeln, dass sie ein .zip-Archiv verwendet. Sie müssen eine neue Funktion erstellen.
**Topics**
+ [Voraussetzungen](#images-reqs)
+ [Mit einem AWS Basisbild für Lambda](#runtimes-images-lp)
+ [Mit einem AWS OS-only Basisbild](#runtimes-images-provided)
+ [Mit einem nicht-AWS Basisbild](#images-types)
+ [Laufzeitschnittstellen-Clients](#images-ric)
+ [Amazon-ECR-Berechtigungen](#gettingstarted-images-permissions)
+ [Lebenszyklus der Funktion](#images-lifecycle)
## Voraussetzungen
Installieren Sie die [AWS CLI -Version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) und die [Docker-CLI](https://docs.docker.com/get-docker). Beachten Sie außerdem die folgenden Anforderungen:
+ Das Container-Image muss die [Verwenden der Lambda-Laufzeit-API für benutzerdefinierte Laufzeiten](runtimes-api.md) implementieren. Die AWS Open-Source-[Laufzeitschnittstellen-Clients](#images-ric) implementieren die API. Sie können Ihrem bevorzugten Basis-Image einen Laufzeitschnittstellen-Client hinzufügen, damit es mit Lambda kompatibel ist.
+ Das Container-Image muss auf einem schreibgeschützten Dateisystem laufen können. Ihr Funktionscode kann auf ein beschreibbares `/tmp`-Verzeichnis mit einem Speicherplatz zwischen 512 MB bis 10 240 MB, in 1-MB-Schritten, zugreifen.
+ Der Lambda-Standardbenutzer muss in der Lage sein, alle Dateien zu lesen, die zum Ausführen Ihres Funktionscodes erforderlich sind. Lambda folgt den bewährten Methoden für die Sicherheit, indem es einen Standard-Linux-Benutzer mit den geringsten Berechtigungen definiert. Das bedeutet, dass Sie in Ihrem Dockerfile keinen [BENUTZER](https://docs.docker.com/reference/dockerfile/#user) angeben müssen. Stellen Sie sicher, dass Ihr Anwendungscode nicht auf Dateien angewiesen ist, von denen andere Linux-Benutzer nicht ausgeführt werden können.
+ Lambda unterstützt nur Linux-based Container-Images.
+ Lambda bietet Multi-Architektur-Basis-Images. Das Image, das Sie für Ihre Funktion erstellen, muss jedoch nur auf eine der Architekturen abzielen. Lambda unterstützt keine Funktionen, die Container-Images mit mehreren Architekturen verwenden.
## Mit einem AWS Basisbild für Lambda
Sie können eines der [AWS -Basis-Images](https://gallery.ecr.aws/lambda/) für Lambda verwenden, um das Container-Image für Ihren Funktionscode zu erstellen. Die Basis-Images sind mit einer Sprachlaufzeit und anderen Komponenten vorgeladen, die zum Ausführen eines Container-Images in Lambda erforderlich sind. Sie fügen Ihren Funktionscode und Ihre Abhängigkeiten dem Basis-Image hinzu und verpacken es dann als Container-Image.
AWS stellt regelmäßig Updates für die AWS Basis-Images für Lambda bereit. Wenn Ihr Dockerfile den Image-Namen in der FROM-Eigenschaft enthält, ruft Ihr Docker-Client die aktuelle Version des Images aus dem [Amazon-ECR-Repository](https://gallery.ecr.aws/lambda/) ab.. Um das aktualisierte Basis-Image verwenden zu können, müssen Sie Ihr Container-Image neu erstellen und [den Funktionscode aktualisieren](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html).
Die Basis-Images Node.js 20, Python 3.12, Java 21, .NET 8, Ruby 3.3 und höher basieren auf dem [minimalen Container-Image von Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/minimal-container.html). Frühere Basis-Images verwenden Amazon Linux 2. AL2023 bietet mehrere Vorteile gegenüber Amazon Linux 2, darunter einen geringeren Bereitstellungsaufwand und aktualisierte Versionen von Bibliotheken wie `glibc`.
AL2023-based Bilder verwenden `microdnf` (symbolisiert als`dnf`) als Paketmanager anstelle von`yum`, was der Standard-Paketmanager in Amazon Linux 2 ist. `microdnf`ist eine eigenständige Implementierung von. `dnf` Eine Liste der Pakete, die in AL2023-based Images enthalten sind, finden Sie in den Spalten **Minimal Container** unter [Comparing packages installed on Amazon Linux 2023 Container Images](https://docs.aws.amazon.com/linux/al2023/ug/al2023-container-image-types.html). Weitere Informationen zu den Unterschieden zwischen AL2023 und Amazon Linux 2 finden Sie unter [Introducing the 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.
**Anmerkung**
Um AL2023-based Images lokal auszuführen, auch mit AWS Serverless Application Model (AWS SAM), müssen Sie Docker-Version 20.10.10 oder höher verwenden.
Um ein Container-Image mit einem AWS Basis-Image zu erstellen, wählen Sie die Anweisungen für Ihre bevorzugte Sprache aus:
+ [Node.js](nodejs-image.md#nodejs-image-instructions)
+ [TypeScript](typescript-image.md#base-image-typescript)(verwendet ein Node.js Basis-Image)
+ [Python](python-image.md#python-image-instructions)
+ [Java](java-image.md#java-image-instructions)
+ [Go](go-image.md#go-image-provided)
+ [.NET](csharp-image.md#csharp-image-instructions)
+ [Ruby](ruby-image.md#ruby-image-instructions)
## Mit einem AWS OS-only Basisbild
[AWS OS-only Basis-Images](https://gallery.ecr.aws/lambda/provided) enthalten eine Amazon Linux-Distribution und den [Runtime-Interface-Emulator](https://github.com/aws/aws-lambda-runtime-interface-emulator/). Diese Images werden häufig verwendet, um Container-Images für kompilierte Sprachen wie [Go](go-image.md#go-image-provided) und [Rust](lambda-rust.md) und für eine Sprache oder Sprachversion zu erstellen, für die Lambda kein Basis-Image bereitstellt, wie z. B. Node.js 19. Sie können auch OS-only Basis-Images verwenden, um eine [benutzerdefinierte Laufzeit](runtimes-custom.md) zu implementieren. Um das Image mit Lambda kompatibel zu machen, müssen Sie den [Laufzeitschnittstellen-Client](#images-ric) für Ihre Sprache in das Image aufnehmen.
| Tags (Markierungen) | Laufzeit | Betriebssystem | Dockerfile | Ablehnung |
| --- | --- | --- | --- | --- |
| al2023 | OS-only Laufzeit | Amazon Linux 2023 | [Dockerfile für Runtime auf OS-only GitHub](https://github.com/aws/aws-lambda-base-images/blob/provided.al2023/Dockerfile.provided.al2023) | 30. Juni 2029 |
| al2 | OS-only Laufzeit | Amazon Linux 2 | [Dockerfile für Runtime auf OS-only GitHub](https://github.com/aws/aws-lambda-base-images/blob/provided.al2/Dockerfile.provided.al2) | 31. Juli 2026 |
Öffentliche Galerie von Amazon Elastic Container Registry: [gallery.ecr. aws/lambda](https://gallery.ecr.aws/lambda/provided)/bereitgestellt
## Mit einem nicht-AWS Basisbild
Lambda unterstützt jedes Image, das einem der folgenden Image-Manifestformate entspricht:
+ Docker Image Manifest V2 Schema 2 (mit Docker-Version 1.10 und neuer)
+ Open Container Initiative (OCI)-Spezifikationen (v1.0.0 und höher)
Lambda unterstützt eine maximale unkomprimierte Image-Größe von 10 GB, einschließlich aller Ebenen.
**Anmerkung**
Um das Image mit Lambda kompatibel zu machen, müssen Sie den [Laufzeitschnittstellen-Client](#images-ric) für Ihre Sprache in das Image aufnehmen.
Für eine optimale Leistung sollte die Größe Ihres Bildmanifests unter 25 400 Byte liegen. Um die Größe des Bildmanifests zu reduzieren, minimieren Sie die Anzahl der Ebenen in Ihrem Bild und reduzieren Sie Anmerkungen.
## Laufzeitschnittstellen-Clients
Wenn Sie ein [OS-only Basis-Image](#runtimes-images-provided) oder ein alternatives Basis-Image verwenden, müssen Sie einen Runtime-Interface-Client in Ihr Image aufnehmen. Der Runtime-Schnittstellenclient muss den erweitern[Verwenden der Lambda-Laufzeit-API für benutzerdefinierte Laufzeiten](runtimes-api.md), der die Interaktion zwischen Lambda und Ihrem Funktionscode verwaltet. AWS stellt Open-Source-Runtime-Interface-Clients für die folgenden Sprachen bereit:
+ [Node.js](nodejs-image.md#nodejs-image-clients)
+ [Python](python-image.md#python-image-clients)
+ [Java](java-image.md#java-image-clients)
+ [.NET](csharp-image.md#csharp-image-clients)
+ [Go](go-image.md#go-image-clients)
+ [Ruby](ruby-image.md#ruby-image-clients)
+ [Rust](lambda-rust.md) —
Wenn Sie eine Sprache verwenden, für die kein Runtime-Interface-Client AWS zur Verfügung steht, müssen Sie Ihren eigenen erstellen.
## Amazon-ECR-Berechtigungen
Bevor Sie eine Lambda-Funktion aus einem Container-Image erstellen, müssen Sie das Image lokal erstellen und es in ein Amazon-ECR-Repository hochladen. Geben Sie beim Erstellen der Funktion den URI des Amazon-ECR-Repositorys an.
Stellen Sie sicher, dass die Berechtigungen für den Benutzer oder die Rolle, die die Funktion erstellt`GetRepositoryPolicy`, `SetRepositoryPolicy``BatchGetImage`, und `GetDownloadUrlForLayer` beinhalten.
Verwenden Sie beispielsweise die IAM-Konsole, um eine Rolle mit der folgenden Richtlinie zu erstellen:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"ecr:SetRepositoryPolicy",
"ecr:GetRepositoryPolicy",
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": "arn:aws:ecr:{{us-east-1}}{{:111122223333}}:repository/{{hello-world}}"
}
]
}
```
------
Die Berechtigungen, die Lambda zum Abrufen Ihres Container-Images benötigt, hängen davon ab, ob sich das Amazon ECR-Repository im selben AWS Konto wie die Funktion oder in einem anderen Konto befindet. In den folgenden Abschnitten werden die Anforderungen für jedes Szenario erläutert.
**Anmerkung**
In IAM muss für den Zugriff auf dasselbe Konto nur eine Seite die Erlaubnis erteilen — entweder die identitätsbasierte Richtlinie (für die Rolle) oder die ressourcenbasierte Richtlinie (für das Amazon ECR-Repository). Cross-account Für den Zugriff müssen beide Seiten eine Genehmigung erteilen — die identitätsbasierte Richtlinie für die Rolle im verbrauchenden Konto UND die ressourcenbasierte Richtlinie für das Amazon ECR-Repository im Eigentümerkonto müssen beide die Aktion zulassen.
### Same-account Amazon ECR-Repository-Richtlinien
Für eine Funktion in demselben Konto wie das Container-Image in Amazon ECR können Sie Lambda-Zugriff entweder über die identitätsbasierte Richtlinie für die Ausführungsrolle oder die ressourcenbasierte Richtlinie für das Amazon ECR-Repository gewähren. Nur eine Seite muss den Zugriff zulassen.
Wenn Sie sich für die Verwendung einer Amazon ECR-Repository-Richtlinie entscheiden, fügen Sie `ecr:GetDownloadUrlForLayer` Berechtigungen `ecr:BatchGetImage` hinzu. Das folgende Beispiel zeigt die Mindestrichtlinie:
```
{
"Sid": "LambdaECRImageRetrievalPolicy",
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
]
}
```
Weitere Informationen zu Amazon-ECR-Repository-Berechtigungen finden Sie unter [Private Repository-Richtlinien](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policies.html) im *Benutzerhandbuch zu Amazon Elastic Container Registry*.
Wenn das Amazon-ECR-Repository diese Berechtigungen nicht enthält, versucht Lambda, sie automatisch hinzuzufügen. Lambda kann Berechtigungen nur hinzufügen, wenn der Lambda aufrufende Prinzipal über `ecr:getRepositoryPolicy`- und `ecr:setRepositoryPolicy`-Berechtigungen verfügt.
Um Ihre Repository-Berechtigungen für Amazon ECR anzuzeigen oder zu bearbeiten, befolgen Sie die Anweisungen unter [Festlegung einer privaten Repository-Richtlinienanweisung](https://docs.aws.amazon.com/AmazonECR/latest/userguide/set-repository-policy.html) im *Benutzerhandbuch zu Amazon Elastic Container Registry*.
#### Kontoübergreifende Berechtigungen von Amazon ECR
Wenn eine Funktion in einem Konto ein Container-Image aus einem Amazon ECR-Repository in einem anderen Konto verwendet, müssen beide Seiten Zugriff gewähren. Die identitätsbasierte Richtlinie für die Rolle im verbrauchenden Konto muss `ecr:BatchGetImage` und zulassen`ecr:GetDownloadUrlForLayer`, und die ressourcenbasierte Richtlinie für das Amazon ECR-Repository im besitzenden Konto muss diese Aktionen ebenfalls zulassen.
Im folgenden Beispiel benötigt die [Berechtigungsrichtlinie Ihres Amazon-ECR-Repository](https://docs.aws.amazon.com/AmazonECR/latest/userguide/set-repository-policy.html) die folgenden Anweisungen, um den Zugriff auf Kontonummer 123456789012 zu gewähren.
+ **CrossAccountPermission**— Ermöglicht dem Konto 123456789012 das Erstellen und Aktualisieren von Lambda-Funktionen, die Bilder aus diesem ECR-Repository verwenden.
+ **LambdaECRImageCrossAccountRetrievalPolicy**— Lambda setzt den Status einer Funktion irgendwann auf inaktiv, wenn sie über einen längeren Zeitraum nicht aufgerufen wird. Diese Anweisung ist erforderlich, damit Lambda das Container-Image zur Optimierung und Zwischenspeicherung im Namen der Funktion abrufen kann, die 123456789012 besitzt.
**Example – Ihrem Repository kontoübergreifende Berechtigungen hinzufügen**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CrossAccountPermission",
"Effect": "Allow",
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Principal": {
"AWS": "arn:aws:iam::{{123456789012}}:root"
},
"Resource": "arn:aws:ecr:{{us-east-1}}:{{123456789012}}:repository/{{example-lambda-repository}}"
},
{
"Sid": "LambdaECRImageCrossAccountRetrievalPolicy",
"Effect": "Allow",
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Condition": {
"ArnLike": {
"aws:sourceARN": "arn:aws:lambda:{{us-east-1}}:{{123456789012}}:function:*"
}
},
"Resource": "arn:aws:ecr:{{us-east-1}}:{{123456789012}}:repository/{{example-lambda-repository}}"
}
]
}
```
Um den Zugriff auf mehrere Konten zu gewähren, fügen Sie die Konto-IDs der Liste der Prinzipalen in der `CrossAccountPermission`-Richtlinie hinzu sowie zur Bedingungs-Auswertungsliste der Bedingung in `LambdaECRImageCrossAccountRetrievalPolicy`.
Wenn Sie mit mehreren Konten in einer AWS Organisation arbeiten, empfehlen wir, dass Sie jede Konto-ID in der ECR-Berechtigungsrichtlinie auflisten. Dieser Ansatz entspricht der bewährten AWS Sicherheitsmethode, enge Berechtigungen in IAM-Richtlinien festzulegen.
Zusätzlich zur Amazon ECR-Repository-Richtlinie muss der Benutzer oder die Rolle, die die Funktion erstellt, auch über `GetDownloadUrlForLayer` Berechtigungen in ihrer identitätsbasierten Richtlinie verfügen`BatchGetImage`.
## Lebenszyklus der Funktion
Nachdem Sie ein neues oder aktualisiertes Container-Image hochgeladen haben, optimiert Lambda das Image, bevor die Funktion Aufrufe verarbeiten kann. Der Optimierungsprozess kann einige Sekunden dauern. Die Funktion verbleibt im Zustand `Pending`, bis der Prozess abgeschlossen ist, dann geht der Zustand in `Active` über. Sie können die Funktion erst dann aufrufen, wenn sie den `Active`-Zustand erreicht hat.
Wenn eine Funktion mehrere Wochen lang nicht aufgerufen wird, gewinnt Lambda seine optimierte Version zurück und die Funktion wechselt in den `Inactive`-Zustand. Um die Funktion wieder zu aktivieren, müssen Sie sie aufrufen. Lambda lehnt den ersten Aufruf ab und die Funktion tritt in den `Pending`-Zustand, bis Lambda das Image neu optimiert. Die Funktion kehrt dann zum `Active`-Zustand zurück.
Lambda ruft regelmäßig das zugehörige Container-Image aus dem Amazon ECR Repository ab. Wenn das entsprechende Container-Image in Amazon ECR nicht mehr vorhanden ist oder Berechtigungen widerrufen werden, wechselt die Funktion in den `Failed`-Zustand und Lambda gibt einen Fehler für alle Funktionsaufrufe zurück.
Sie können die Lambda-API verwenden, um Informationen über den Zustand einer Funktion abzurufen. Weitere Informationen finden Sie unter [Lambda-Funktionszustände](functions-states.md).