Ein Tool zum Ausführen von Webanwendungen auf AWS Lambda
Mit AWS Lambda Web Adapter können Entwickler Webanwendungen (http-API) mit vertrauten Frameworks (z. B. Express.js, Next.js, Flask, SpringBoot, ASP.NET und Laravel, alles spricht HTTP 1.1/1.0) erstellen und auf AWS Lambda ausführen . Das gleiche Docker-Image kann auf AWS Lambda, Amazon EC2, AWS Fargate und lokalen Computern ausgeführt werden.
AWS Lambda Web Adapter funktioniert mit Lambda-Funktionen, die sowohl als Docker-Images als auch als Zip-Pakete gepackt sind.
Um Lambda Web Adaptor mit Docker-Images zu verwenden, packen Sie Ihre Web-App (http-API) in eine Docker-Datei und fügen Sie eine Zeile hinzu, um die Lambda Web Adaptor-Binärdatei nach /opt/extensions in Ihrem Container zu kopieren:
COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.8.4 /lambda-adapter /opt/extensions/lambda-adapter
Es können Nicht-AWS-Basisimages verwendet werden, da der Runtime Interface Client mit dem Lambda Web Adaptor geliefert wird.
Standardmäßig geht Lambda Web Adaptor davon aus, dass die Web-App Port 8080 überwacht. Wenn nicht, können Sie den Port über die Konfiguration angeben.
Vorkompilierte Lambda Web Adaptor-Binärdateien werden im öffentlichen ECR-Repository bereitgestellt: public.ecr.aws/awsguru/aws-lambda-adapter. In diesem Repo werden auch Multi-Arch-Bilder bereitgestellt. Es funktioniert sowohl auf x86_64- als auch auf arm64-CPU-Architekturen.
Unten finden Sie eine Docker-Datei für eine Beispiel-NodeJS-Anwendung.
FROM public.ecr.aws/docker/library/node:20-slim
COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.8.4 /lambda-adapter /opt/extensions/lambda-adapter
ENV PORT=7000
WORKDIR "/var/task"
ADD src/package.json /var/task/package.json
ADD src/package-lock.json /var/task/package-lock.json
RUN npm install --omit=dev
ADD src/ /var/task
CMD [ "node" , "index.js" ]
Dies funktioniert mit allen Basis-Images außer von AWS verwalteten Basis-Images. Um von AWS verwaltete Basisimages zu verwenden, müssen Sie den ENTRYPOINT überschreiben, um Ihre Web-App zu starten.
AWS Lambda Web Adapter funktioniert auch mit von AWS verwalteten Lambda-Laufzeiten. Sie müssen drei Dinge tun:
Fügen Sie Ihrer Funktion die Lambda Web Adaptor-Ebene hinzu.
arn:aws:lambda:${AWS::Region}:753240598075:layer:LambdaAdapterLayerX86:23
arn:aws:lambda:${AWS::Region}:753240598075:layer:LambdaAdapterLayerArm64:23
arn:aws-cn:lambda:cn-north-1:041581134020:layer:LambdaAdapterLayerX86:23
arn:aws-cn:lambda:cn-northwest-1:069767869989:layer:LambdaAdapterLayerX86:23
Konfigurieren Sie die Lambda-Umgebungsvariable AWS_LAMBDA_EXEC_WRAPPER
auf /opt/bootstrap
.
Legen Sie den Funktionshandler für das Startskript Ihrer Webanwendung fest. zB run.sh
.
Weitere Informationen finden Sie in der Beispielanwendung Node.js.
Wenn eine neue Lambda-Ausführungsumgebung gestartet wird, wird Lambda Web Adaptor als Lambda-Erweiterung gestartet, gefolgt von der Webanwendung.
Standardmäßig sendet Lambda Web Adaptor HTTP-GET-Anfragen an die Webanwendung unter http://127.0.0.1:8080/
. Der Port und der Pfad können mit zwei Umgebungsvariablen angepasst werden: AWS_LWA_READINESS_CHECK_PORT
und AWS_LWA_READINESS_CHECK_PATH
.
Lambda Web Adaptor wiederholt diese Anfrage alle 10 Millisekunden, bis die Webanwendung eine HTTP-Antwort zurückgibt ( Statuscode >= 100 und < 500 ) oder die Funktion das Zeitlimit überschreitet.
Darüber hinaus können Sie den Adapter so konfigurieren, dass er eine Bereitschaftsprüfung mit TCP-Verbindung durchführt, indem Sie AWS_LWA_READINESS_CHECK_PROTOCOL
auf tcp
setzen.
Nach bestandener Bereitschaftsprüfung startet Lambda Web Adaptor Lambda Runtime und leitet die Aufrufe an die Webanwendung weiter.
Der Bereitschaftsprüfungsport/-pfad und der Verkehrsport können mithilfe von Umgebungsvariablen konfiguriert werden. Diese Umgebungsvariablen können entweder innerhalb der Docker-Datei oder als Lambda-Funktionskonfiguration definiert werden.
Umgebungsvariable | Beschreibung | Standard |
---|---|---|
AWS_LWA_PORT / PORT* | Verkehrshafen | „8080“ |
AWS_LWA_READINESS_CHECK_PORT / READINESS_CHECK_PORT* | Bereitschaftsprüfport, standardmäßig der Verkehrsport | HAFEN |
AWS_LWA_READINESS_CHECK_PATH / READINESS_CHECK_PATH* | Pfad zur Bereitschaftsprüfung | „/“ |
AWS_LWA_READINESS_CHECK_PROTOCOL / READINESS_CHECK_PROTOCOL* | Bereitschaftsprüfungsprotokoll: „http“ oder „tcp“, Standard ist „http“ | „http“ |
AWS_LWA_READINESS_CHECK_MIN_UNHEALTHY_STATUS | Der minimale HTTP-Statuscode, der als fehlerhaft gilt | „500“ |
AWS_LWA_ASYNC_INIT / ASYNC_INIT* | Aktivieren Sie die asynchrone Initialisierung für lange Initialisierungsfunktionen | "FALSCH" |
AWS_LWA_REMOVE_BASE_PATH / REMOVE_BASE_PATH* | Der Basispfad, der aus dem Anforderungspfad entfernt werden soll | Keiner |
AWS_LWA_ENABLE_COMPRESSION | Aktivieren Sie die GZIP-Komprimierung für den Antworttext | "FALSCH" |
AWS_LWA_INVOKE_MODE | Aufrufmodus der Lambda-Funktion: „buffered“ oder „response_stream“, Standard ist „buffered“ | „gepuffert“ |
AWS_LWA_PASS_THROUGH_PATH | der Pfad zum Empfangen von Ereignisnutzdaten, die von Nicht-HTTP-Triggern weitergeleitet werden | „/events“ |
AWS_LWA_AUTHORIZATION_SOURCE | ein Header-Name, der durch Authorization ersetzt werden soll | Keiner |
Hinweis: Wir verwenden das Präfix „AWS_LWA_“, um alle von Lambda Web Adaptor verwendeten Umgebungsvariablen zu benennen. Die Originalversionen werden bis zur Version 1.0 unterstützt.
AWS_LWA_PORT / PORT – Lambda Web Adaptor sendet Datenverkehr an diesen Port. Dies ist der Port, den Ihre Webanwendung überwacht. In der Lambda-Ausführungsumgebung wird die Webanwendung als Nicht-Root-Benutzer ausgeführt und darf keine Ports unter 1024 abhören. Bitte vermeiden Sie auch die Ports 9001 und 3000. Die Lambda Runtime API befindet sich auf Port 9001. Die CloudWatch Lambda Insight-Erweiterung verwendet Port 3000 .
AWS_LWA_ASYNC_INIT / ASYNC_INIT – Von Lambda verwaltete Laufzeiten bieten bis zu 10 Sekunden für die Funktionsinitialisierung. Während dieser Zeit wird die CPU der Lambda-Funktionen ausgelastet, um die Initialisierung zu beschleunigen, und die Nutzung ist kostenlos. Wenn eine Lambda-Funktion die Initialisierung nicht innerhalb von 10 Sekunden abschließen konnte, startet Lambda die Funktion neu und stellt die Initialisierung in Rechnung. Damit Funktionen diese kostenlose Initialisierungszeit von 10 Sekunden nutzen und einen Neustart vermeiden können, unterstützt Lambda Web Adaptor die asynchrone Initialisierung. Wenn diese Funktion aktiviert ist, führt Lambda Web Adaptor eine Bereitschaftsprüfung nach bis zu 9,8 Sekunden durch. Wenn die Web-App bis dahin noch nicht bereit ist, signalisiert Lambda Web Adaptor dem Lambda-Dienst, dass die Initialisierung abgeschlossen ist, und setzt die Bereitschaftsprüfung im Handler fort. Diese Funktion ist standardmäßig deaktiviert. Aktivieren Sie es, indem Sie die Umgebungsvariable AWS_LWA_ASYNC_INIT
auf true
setzen.
AWS_LWA_REMOVE_BASE_PATH / REMOVE_BASE_PATH – Der Wert dieser Umgebungsvariablen teilt dem Adapter mit, ob die Anwendung unter einem Basispfad ausgeführt wird. Beispielsweise könnten Sie Ihr API-Gateway so konfiguriert haben, dass es über eine /orders/{proxy+}- und eine /catalog/{proxy+}-Ressource verfügt. Jede Ressource wird von separaten Lambda-Funktionen verwaltet. Aus diesem Grund ist sich die Anwendung in Lambda möglicherweise nicht der Tatsache bewusst, dass der Pfad /orders vorhanden ist. Verwenden Sie REMOVE_BASE_PATH, um das Präfix /orders zu entfernen, wenn Sie Anforderungen an die Anwendung weiterleiten. Standardmäßig ist eine leere Zeichenfolge. Schauen Sie sich das SpringBoot-Beispiel an.
AWS_LWA_ENABLE_COMPRESSION – Lambda Web Adaptor unterstützt die GZIP-Komprimierung für den Antworttext. Diese Funktion ist standardmäßig deaktiviert. Aktivieren Sie es, indem Sie die Umgebungsvariable AWS_LWA_ENABLE_COMPRESSION
auf true
setzen. Wenn diese Option aktiviert ist, werden Antworten komprimiert, es sei denn, es handelt sich um ein Bild, wie durch den Inhaltstyp festgelegt, der mit image
beginnt, oder die Antwort ist weniger als 32 Bytes groß. Dadurch wird auch die HTTP/1.1-Chunked-Streaming-Antwort komprimiert.
AWS_LWA_INVOKE_MODE – Lambda-Funktionsaufrufmodus, dieser sollte mit dem Funktions-URL-Aufrufmodus übereinstimmen. Der Standardwert ist „gepuffert“. Bei der Konfiguration als „response_stream“ streamt Lambda Web Adaptor die Antwort an den Lambda-Service-Blog. Bitte schauen Sie sich das Beispiel für FastAPI mit Antwort-Streaming an.
AWS_LWA_READINESS_CHECK_MIN_UNHEALTHY_STATUS – ermöglicht Ihnen die Anpassung, welche HTTP-Statuscodes als fehlerfrei gelten und welche nicht
AWS_LWA_PASS_THROUGH_PATH – Pfad zum Empfang von Ereignisnutzlasten, die von Nicht-HTTP-Ereignisauslösern weitergeleitet werden. Der Standardwert ist „/events“.
AWS_LWA_AUTHORIZATION_SOURCE – Wenn diese Einstellung festgelegt ist, ersetzt Lambda Web Adaptor den angegebenen Headernamen durch Authorization
, bevor eine Anfrage weitergeleitet wird. Dies ist nützlich, wenn Sie die Lambda-Funktions-URL mit dem IAM-Authentifizierungstyp verwenden, der den Autorisierungsheader für die IAM-Authentifizierung reserviert, Sie aber weiterhin den Autorisierungsheader für Ihre Backend-Apps verwenden möchten. Diese Funktion ist standardmäßig deaktiviert.
Der Anforderungskontext besteht aus Metadaten, die API Gateway für eine Anforderung an Lambda sendet. Es enthält normalerweise requestId, requestTime, apiId, Identity und Authorizer. Identität und Autorisierer sind nützlich, um die Clientidentität für die Autorisierung abzurufen. Weitere Details finden Sie im API Gateway Developer Guide hier.
Lambda Web Adaptor leitet diese Informationen in einem HTTP-Header mit dem Namen „x-amzn-request-context“ an die Webanwendung weiter. In der Webanwendung können Sie den Wert dieses HTTP-Headers abrufen und ihn in ein JSON-Objekt deserialisieren. Sehen Sie sich Express.js in Zip an und erfahren Sie, wie Sie es verwenden.
Lambda-Kontext ist ein Objekt, das Lambda an den Funktionshandler übergibt. Dieses Objekt stellt Informationen über den Aufruf, die Funktion und die Ausführungsumgebung bereit. Eine vollständige Liste der Eigenschaften, auf die über den Lambda-Kontext zugegriffen werden kann, finden Sie hier
Lambda Web Adaptor leitet diese Informationen in einem HTTP-Header mit dem Namen „x-amzn-lambda-context“ an die Webanwendung weiter. In der Webanwendung können Sie den Wert dieses HTTP-Headers abrufen und ihn in ein JSON-Objekt deserialisieren. Sehen Sie sich Express.js in Zip an und erfahren Sie, wie Sie es verwenden.
Für eine Funktion mit registrierten Lambda-Erweiterungen aktiviert Lambda die Abschaltphase für die Funktion. Wenn der Lambda-Dienst im Begriff ist, eine Lambda-Ausführungsumgebung herunterzufahren, sendet er ein SIGTERM-Signal an die Laufzeit und dann ein SHUTDOWN-Ereignis an jede registrierte externe Erweiterung. Entwickler könnten das SIGTERM-Signal in den Lambda-Funktionen abfangen und ordnungsgemäße Shutdown-Aufgaben durchführen. Express.js gibt ein einfaches Beispiel. Weitere Details in diesem Repo.
Mit Lambda Web Adapter können Entwickler Webanwendungen lokal mit vertrauten Tools und Debuggern entwickeln: Führen Sie die Web-App einfach lokal aus und testen Sie sie. Wenn Sie die Lambda-Laufzeitumgebung lokal simulieren möchten, können Sie AWS SAM CLI verwenden. Der folgende Befehl startet einen lokalen API-Gateway-Endpunkt und simuliert die Lambda-Laufzeitausführungsumgebung.
sam local start-api
Bitte beachten Sie, dass sam local
einen Lambda Runtime Interface Emulator auf Port 8080 startet. Daher sollte Ihre Webanwendung Port 8080
meiden, wenn Sie vorhaben sam local
zu verwenden.
Der Lambda Web Adaptor unterstützt auch alle Nicht-HTTP-Ereignisauslöser wie SQS, SNS, S3, DynamoDB, Kinesis, Kafka, EventBridge und Bedrock Agents. Der Adapter leitet die Ereignisnutzlast per HTTP-Post an die Webanwendung an einen Pfad weiter, der durch die Umgebungsvariable AWS_LWA_PASS_THROUGH_PATH
definiert ist. Standardmäßig ist dieser Pfad auf /events
eingestellt. Nach Erhalt der Ereignisnutzdaten aus dem Anforderungstext sollte die Webanwendung diese verarbeiten und die Ergebnisse als JSON-Antwort zurückgeben. Bitte schauen Sie sich SQS Express.js und Bedrock Agent FastAPI in Zip-Beispielen an.
Dieses Projekt wurde von mehreren Community-Projekten inspiriert.
Mehrere Projekte bieten auch ähnliche Funktionen als sprachspezifische Pakete/Frameworks.
Weitere Informationen finden Sie unter BEITRAGEN.
Dieses Projekt ist unter der Apache-2.0-Lizenz lizenziert.