Erstellen von Lambda-Funktionen mit Node.js

Sie können JavaScript-Code mit Node.js in AWS Lambda ausführen. Lambda bietet Laufzeiten für Node.js, die Ihren Code ausführen, um Ereignisse zu verarbeiten. Ihr Code wird in einer Umgebung ausgeführt, der das AWS SDK für JavaScript enthält, mit Anmeldeinformationen von einer von Ihnen verwalteten AWS Identity and Access Management (IAM)-Rolle. Weitere Informationen zu den SDK-Versionen, die in den Laufzeiten von Node.js enthalten sind, finden Sie unter SDK-Versionen, die zur Laufzeit enthalten sind.

Lambda unterstützt die folgenden Node.js-Laufzeiten.

Die Upstream-Sprachversionen von Node.js ermöglichen standardmäßig einige experimentelle Features. Lambda deaktiviert diese Features, um die Laufzeitstabilität und eine konsistente Leistung zu gewährleisten. In der folgenden Tabelle sind die experimentellen Features aufgeführt, die Lambda deaktiviert.

Um ein deaktiviertes experimentelles Feature zu aktivieren, setzen Sie das Reaktivierungs-Flag in der Umgebungsvariablen „NODE_OPTIONS“. Beispiel: Um die Unterstützung für „require“ in ES-Modulen zu aktivieren, setzen Sie „NODE_OPTIONS“ auf „--experimental-require-module“. Lambda erkennt diese Überschreibung und entfernt das entsprechende Deaktivierungs-Flag.

Die Konsole erstellt eine Lambda-Funktion mit einer einzigen Quelldatei mit dem Namen index.mjs. Mit dem integrierten Code-Editor können Sie diese Datei bearbeiten und weitere Dateien hinzufügen. Wählen Sie im Abschnitt BEREITSTELLEN die Option Bereitstellen aus, um den Code Ihrer Funktion zu aktualisieren. Um Ihren Code auszuführen, wählen Sie anschließend im Abschnitt TESTEREIGNISSE die Option Testereignis erstellen aus.

Die index.mjs-Datei exportiert eine Funktion mit dem Namen handler, die ein Ereignisobjekt und ein Kontext-Objekt übernimmt. Dies ist die Handler-Funktion, die bei einem Aufruf der Funktion von Lambda aufgerufen wird. Die Node.js-Funktionslaufzeit ruft Aufrufereignisse von Lambda ab und leitet sie an den Handler weiter. In der Konfiguration der Funktion lautet der Wert für den Handler index.handler.

Wenn Sie Ihren Funktionscode speichern, erstellt die Lambda-Konsole ein Bereitstellungspaket für das ZIP-Dateiarchiv. Wenn Sie Ihren Funktionscode außerhalb der Konsole (mit einer IDE) entwickeln, müssen Sie ein Bereitstellungspaket erstellen, um Ihren Code in die Lambda-Funktion hochzuladen.

Die Funktionslaufzeit übergibt neben dem Aufrufereignis ein Context-Objekt an den Handler. Das Context-Objekt enthält zusätzliche Informationen zum Aufruf, zur Funktion und zur Ausführungsumgebung. Weitere Informationen erhalten Sie über die Umgebungsvariablen.

Ihre Lambda-Funktion verfügt über eine CloudWatch-Logs-Protokollgruppe. Die Funktionslaufzeit sendet Details zu jedem Aufruf an CloudWatch Logs. Es leitet alle Protokolle weiter, die Ihre Funktion während des Aufrufs ausgibt. Wenn Ihre Funktion einen Fehler zurückgibt, formatiert Lambda den Fehler und gibt ihn an den Aufrufer zurück.

Initialisierung von Node.js

Node.js verfügt über ein eindeutiges Ereignisschleifenmodell, das bewirkt, dass sich das Initialisierungsverhalten von anderen Laufzeiten unterscheidet. Insbesondere verwendet Node.js ein nicht blockierendes I/O-Modell, das asynchrone Operationen unterstützt. Dieses Modell ermöglicht es Node.js, für die meisten Workloads effizient zu arbeiten. Wenn beispielsweise eine Node.js-Funktion einen Netzwerkaufruf durchführt, kann diese Anforderung als asynchrone Operation bezeichnet und in eine Callback-Warteschlange gestellt werden. Die Funktion verarbeitet möglicherweise andere Vorgänge innerhalb des Hauptaufruf-Batches, ohne blockiert zu werden, indem sie darauf wartet, dass der Netzwerkaufruf zurückgegeben wird. Sobald der Netzwerkaufruf abgeschlossen ist, wird sein Rückruf ausgeführt und dann aus der Rückrufwarteschlange entfernt.

Einige Initialisierungsaufgaben werden möglicherweise asynchron ausgeführt. Diese asynchronen Aufgaben garantieren nicht, dass sie die Ausführung vor einem Aufruf abschließen. Zum Beispiel Code, der einen Netzwerkaufruf zum Abrufen eines Parameters aus AWS Parameter Store macht, ist möglicherweise noch nicht vollständig abgeschlossen, wenn Lambda die Handler-Funktion ausführt. Infolgedessen kann die Variable während eines Aufrufs null sein. Es kann auch zu einer Verzögerung zwischen INIT und INVOKE kommen, was bei zeitkritischen Vorgängen zu Fehlern führen kann. Insbesondere können AWS-Serviceaufrufe auf zeitkritischen Anforderungssignaturen basieren, was zu Fehlern beim Serviceaufruf führt, wenn der Aufruf nicht während der INIT-Phase abgeschlossen wird.

Um dies zu vermeiden, empfehlen wir, Ihren Code als ECMAScript-Modul (ES-Modul) bereitzustellen und await auf oberster Ebene zu verwenden, um sicherzustellen, dass alle Initialisierungen während der INIT-Phase der Funktion abgeschlossen sind. Dadurch wird sichergestellt, dass Initialisierungsaufgaben vor Handler-Aufrufen abgeschlossen werden, Verzögerungen zwischen INIT und INVOKE vermieden werden, die zeitkritische Vorgänge stören könnten, und die Effektivität der bereitgestellten Gleichzeitigkeit bei der Reduzierung der Kaltstartlatenz maximiert wird. Weitere Informationen und ein Beispiel finden Sie unter Verwenden von Node.js-ES-Modulen und Erwarten auf oberster Ebene in AWS Lambda.

Designieren eines Funktionshandlers als ES-Modul

Standardmäßig behandelt Lambda Dateien mit dem .js-Suffix als CommonJS-Module. Optional können Sie Ihren Code als ES-Modul festlegen. Sie können dies auf zwei Arten tun: durch Angabe von type als module in der package.json-Datei der Funktion oder durch Verwendung der Dateinamenerweiterung .mjs. Im ersten Ansatz behandelt Ihr Funktionscode alle .js-Dateien als ES-Module, während im zweiten Szenario nur die Datei, die Sie mit .mjs angeben, ein ES-Modul ist. Sie können ES-Module und CommonJS-Module mischen, indem Sie sie als .mjs bzw. .cjs benennen, da .mjs-Dateien immer ES-Module sind und .cjs-Dateien immer CommonJS-Module sind.

Lambda beim Laden von ES-Modulen Ordner in der NODE_PATH-Umgebungsvariable. Sie können das in der Laufzeit enthaltene AWS-SDK mithilfe von import-ES-Modulanweisungen laden. Sie können ES-Module auch aus Ebenen laden.

SDK-Versionen, die zur Laufzeit enthalten sind

Alle unterstützten Lambda-Node.js-Laufzeiten enthalten eine bestimmte Nebenversion von AWS SDK für JavaScript v3, nicht die neueste Version. Welche Nebenversion in der Laufzeit enthalten ist, hängt von der Laufzeitversion und Ihrer AWS-Region ab. Um die spezifische Version des SDK zu finden, die in der von Ihnen verwendeten Laufzeit enthalten ist, erstellen Sie eine Lambda-Funktion mit dem folgenden Code.

import packageJson from '@aws-sdk/client-s3/package.json' with { type: 'json' };

export const handler = async () => ({ version: packageJson.version });

{
  "version": "3.632.0"
}

Weitere Informationen finden Sie unter Verwenden des SDK für JavaScript v3 in Ihrem Handler.

Verwenden von Keepalive für TCP-Verbindungen

Der standardmäßige Node.js-HTTP/HTTPS-Agent erstellt eine neue TCP-Verbindung für jede neue Anforderung. Um die Kosten für den Aufbau neuer Verbindungen zu vermeiden, ist Keep-alive in allen unterstützten Node.js-Laufzeiten standardmäßig aktiviert. Keepalive kann die Anforderungszeiten für Lambda-Funktionen reduzieren, die mehrere API-Aufrufe unter Verwendung des SDK ausführen.

Informationen zum Deaktivieren von Keepalive finden Sie im Entwicklerleitfaden für das AWS-SDK für JavaScript 3.x unter Wiederverwenden von Verbindungen mit Keep-Alive in Node.js. Weitere Informationen zur Verwendung von Keepalive finden Sie im Blog zu AWS-Entwicklungstools unter HTTP keep-alive is on by default in modular AWS SDK for JavaScript.

CA-Zertifikat wird geladen

Für Node.js-Laufzeitversionen bis Node.js 18 lädt Lambda automatisch Amazon-spezifische CA-Zertifikate (Certificate Authority, Zertifizierungsstelle), um Ihnen die Erstellung von Funktionen zu erleichtern, die mit anderen AWS-Services interagieren. Lambda enthält beispielsweise die Amazon-RDS-Zertifikate, die für die Validierung des in Ihrer Amazon-RDS-Datenbank installierten Server-Identitätszertifikats erforderlich sind. Dieses Verhalten kann sich bei Kaltstarts auf die Leistung auswirken.

Ab Node.js 20 lädt Lambda standardmäßig keine zusätzlichen CA-Zertifikate mehr. Die Laufzeit Node.js 20 enthält eine Zertifikatsdatei mit allen Amazon-CA-Zertifikaten, die sich unter /var/runtime/ca-cert.pem befinden. Um dasselbe Verhalten aus Node.js 18 und früheren Laufzeiten wiederherzustellen, setzen Sie die Umgebungsvariable NODE_EXTRA_CA_CERTS auf /var/runtime/ca-cert.pem.

Für eine optimale Leistung empfehlen wir, nur die benötigten Zertifikate mit Ihrem Bereitstellungspaket zu bündeln und diese über die Umgebungsvariable NODE_EXTRA_CA_CERTS zu laden. Die Zertifikatsdatei sollte aus einem oder mehreren vertrauenswürdigen Stammzertifikaten oder Zertifikaten von Zwischenzertifizierungsstellen im PEM-Format bestehen. Fügen Sie für RDS die erforderlichen Zertifikate beispielsweise zusammen mit Ihrem Code als certificates/rds.pem hinzu. Laden Sie dann die Zertifikate, indem Sie NODE_EXTRA_CA_CERTS auf /var/task/certificates/rds.pem festlegen.