Verpacken Ihres Ebeneninhalts - AWS Lambda

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.

Verpacken Ihres Ebeneninhalts

Eine Lambda-Ebene ist ein ZIP-Dateiarchiv mit ergänzendem Code oder ergänzenden Daten. Ebenen enthalten üblicherweise Bibliotheksabhängigkeiten, eine benutzerdefinierte Laufzeit oder Konfigurationsdateien.

In diesem Abschnitt erfahren Sie, wie Sie Ihren Ebeneninhalt ordnungsgemäß verpacken. Weitere konzeptionelle Informationen zu Ebenen sowie dazu, warum Sie ggf. welche verwenden sollten, finden Sie unter Verwaltung von Lambda-Abhängigkeiten mit Ebenen.

Der erste Schritt beim Erstellen einer Ebene besteht darin, den gesamten Ebeneninhalt in einem ZIP-Dateiarchiv zu bündeln. Da Lambda-Funktionen unter Amazon Linux ausgeführt werden, muss Ihr Ebeneninhalt in einer Linux-Umgebung kompiliert und erstellt werden können.

Um sicherzustellen, dass Ihr Layer-Inhalt in einer Linux-Umgebung ordnungsgemäß funktioniert, empfehlen wir, Ihren Layer-Inhalt mit einem Tool wie Docker oder AWS Cloud9zu erstellen. AWS Cloud9 ist eine cloudbasierte integrierte Entwicklungsumgebung (IDE), die integrierten Zugriff auf einen Linux-Server zum Ausführen und Testen von Code bietet. Weitere Informationen finden Sie im AWS -Computing-Blog unter Verwenden von Lambda-Ebenen zur Vereinfachung Ihres Entwicklungsprozesses.

Ebenenpfade für jede Lambda-Laufzeit

Wenn Sie einer Funktion eine Ebene hinzufügen, lädt Lambda den Ebeneninhalt in das Verzeichnis /opt der Ausführungsumgebung. Für jede Lambda-Laufzeit enthält die Variable PATH bereits spezifische Ordnerpfade innerhalb des Verzeichnisses /opt. Um sicherzustellen, dass Lambda Ihren Layer-Inhalt aufnimmt, sollte Ihre Layer-.zip-Datei ihre Abhängigkeiten in den folgenden Ordnerpfaden haben:

Laufzeit Pfad

Node.js

nodejs/node_modules

nodejs/node16/node_modules (NODE_PATH)

nodejs/node18/node_modules (NODE_PATH)

nodejs/node20/node_modules (NODE_PATH)

Python

python

python/lib/python3.x/site-packages (Site-Verzeichnisse)

Java

java/lib (CLASSPATH)

Ruby

ruby/gems/3.3.0 (GEM_PATH)

ruby/lib (RUBYLIB)

Alle Laufzeiten

bin (PATH)

lib (LD_LIBRARY_PATH)

Die folgenden Beispiele zeigen, wie Sie die Ordner im ZIP-Archiv Ihrer Ebene strukturieren können.

Node.js
Beispiel Dateistruktur für das AWS X-Ray SDK für Node.js
xray-sdk.zip └ nodejs/node_modules/aws-xray-sdk
Python
Beispiel Dateistruktur für die Anforderungsbibliothek
layer_content.zip └ python └ lib └ python3.11 └ site-packages └ requests └ <other_dependencies> (i.e. dependencies of the requests package) └ ...
Ruby
Beispiel Dateistruktur für das JSON-Gem
json.zip └ ruby/gems/3.3.0/ | build_info | cache | doc | extensions | gems | └ json-2.1.0 └ specifications └ json-2.1.0.gemspec
Java
Beispiel Dateistruktur für Jackson-JAR-Datei
layer_content.zip └ java └ lib └ jackson-core-2.17.0.jar └ <other potential dependencies> └ ...
All
Beispiel Dateistruktur für jq-Bibliothek
jq.zip └ bin/jq

Eine sprachspezifische Anleitung zum Verpacken, Erstellen und Hinzufügen einer Ebene finden Sie auf den folgenden Seiten:

Wir empfehlen, Ebenen nicht zu verwenden, um Abhängigkeiten für Lambda-Funktionen zu verwalten, die in Go und Rust geschrieben wurden. Dies liegt daran, dass in diesen Sprachen geschriebene Lambda-Funktionen zu einer einzigen ausführbaren Datei kompiliert werden, die Sie Lambda bei der Bereitstellung Ihrer Funktion zur Verfügung stellen. Diese ausführbare Datei enthält Ihren kompilierten Funktionscode zusammen mit all seinen Abhängigkeiten. Die Verwendung von Ebenen verkompliziert nicht nur diesen Vorgang, sondern führt auch zu längeren Kaltstartzeiten, da Ihre Funktionen während der Init-Phase zusätzliche Assemblys manuell in den Speicher laden müssen.

Um externe Abhängigkeiten mit Go- und Rust Lambda-Funktionen zu verwenden, nehmen Sie sie direkt in Ihr Bereitstellungspaket auf.