Lambda-Funktion mit Docker Container Image – Teilweise zum Entwickeln und Bereitstellen einer Lambda-Funktion mit Java (Runtime).

Einführung

In diesem Artikel möchte ich untersuchen, wie man Lambda-Funktionen mit Docker Container Image und Java Runtime entwickelt und bereitstellt. In diesem Artikel verwende ich die Java 21 Corretto-Laufzeitumgebung. Aber wie bei Container-Images können wir auch die neuesten Java-Laufzeiten wie Java 22 verwenden und nicht nur Java-Laufzeiten mit Langzeitunterstützung (LTS) wie Java 17 und 21. Es ist einfach, dieses Beispiel zu aktualisieren, wenn eine neuere Java-Version veröffentlicht wird (wie Java). Version 23 im September 2024).

So entwickeln und implementieren Sie eine Lambda-Funktion mithilfe des AWS Lambda-Basis-Docker-Container-Images und der Java (21)-Laufzeit

Auf den AWS-Basisbildern sind eine Sprachlaufzeit, ein Laufzeitschnittstellen-Client zur Verwaltung der Interaktion zwischen Lambda und Ihrem Funktionscode sowie ein Laufzeitschnittstellen-Emulator für lokale Tests vorinstalliert. Informationen zur Verwendung eines AWS-Basisimages für Java finden Sie in diesem Artikel.

Zur Erläuterung verwenden wir unsere Beispielanwendung und verwenden die Java 21-Laufzeitumgebung für unsere Lambda-Funktionen.

In dieser Anwendung erstellen und rufen wir Produkte ab und verwenden DynamoDB als NoSQL-Datenbank. Die DynamoProductDao.java-Implementierung finden Sie hier. Wir haben auch Amazon API Gateway davor platziert, wie in der AWS SAM-Vorlage definiert. In dieser Vorlage haben wir auch zwei Lambda-Funktionen definiert: PutProductWithPureJava21DockerImage und GetProductByIdWithPureJava21DockerImage.

Wir müssen eine Docker-Datei definieren, in der wir das AWS Lambda-Basis-Docker-Image public.ecr.aws/lambda/java:21 für Java 21 aus dem öffentlichen Amazon ECR-Repository verwenden. Hier finden Sie alle von AWS bereitgestellten Lambda-Basis-Docker-Images für Java.

Im Docker-Image kopieren wir auch Funktionscode und Laufzeitabhängigkeiten vom Maven-Layout in die Laufzeitumgebungsvariable LAMBDA_TASK_ROOT – den Pfad zu Ihrem Lambda-Funktionscode.

COPY target/classes ${LAMBDA_TASK_ROOT}
COPY target/dependency/* ${LAMBDA_TASK_ROOT}/lib/

Alles andere ist in der Lambda-Funktionsdeklaration in der AWS SAM-Vorlage definiert.

 GetProductByIdFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: GetProductByIdWithPureJava21DockerImage
      PackageType: Image
      ImageUri: !Sub ${AWS::AccountId}.dkr.ecr.eu-central-1.amazonaws.com/aws-pure-lambda-java21-custom-docker-image:v1
      ImageConfig:
        Command: ["software.amazonaws.example.product.handler.GetProductByIdHandler::handleRequest"]

Die wichtigen Teile sind:

• PackageType: Bild, das besagt, dass wir unsere Lambda-Funktion als Docker-Container-Image verpacken
• ImageUri: !Sub ${AWS::AccountId}.dkr.ecr.eu-central-1.amazonaws.com/aws-pure-lambda-java21-custom-docker-image:v1, das auf den Pfad des verweist Docker-Container-Image in der Amazon Elastic Container Registry. Mehr darüber, wie man das Bild dorthin verschiebt, später. -ImageConfig: Befehl: ["software.amazonaws.example.product.handler.GetProductByIdHandler::handleRequest"] wird CMD für unseren GetProductById-Handler überschrieben. Da dieser CMD für jede Lambda-Funktion einzigartig ist, ist es besser, ihn auf der Ebene der Lambda-Funktion wie in der Docker-Datei zu deklarieren.

Beantworten wir nun die Frage, wie ein Docker-Container-Image erstellt und in das ECR-Repository übertragen wird. Sie können dies automatisch tun und dann die Befehlskette sam build und sam deploy ausführen. Wenn Sie die Anwendung außerhalb des SAM erstellen und verpacken und nur mit SAM bereitstellen, müssen Sie sie manuell wie folgt ausführen

Build Docker image with name aws-pure-lambda-java21-custom-docker-image:

docker build --no-cache -t aws-pure-lambda-java21-custom-docker-image:v1 .

Login to Amazon ECR in case the credentials are expired:

aws ecr get-login-password --region eu-central-1 | docker login --username AWS --password-stdin {aws_account_id}.dkr.ecr.eu-central-1.amazonaws.com  

Create Amazon ECR repository if not exists with the name aws-pure-lambda-java21-custom-docker-image:

aws ecr create-repository --repository-name aws-pure-lambda-java21-custom-docker-image --image-scanning-configuration scanOnPush=true --region eu-central-1  

Tag our local Docker image and  link it with Amazon ECR repository. Exactly this image is referenced as ImageUri in the Lambda function:

docker tag aws-pure-lambda-java21-custom-docker-image:v1 {aws_account_id}.dkr.ecr.eu-central-1.amazonaws.com/aws-pure-lambda-java21-custom-docker-image:v1

Push the Docker image to the Amazon ECR repository:
docker push {aws_account_id}.dkr.ecr.eu-central-1.amazonaws.com/aws-pure-lambda-java21-custom-docker-image:v1 

Beim Bereitstellen der Funktion mit samploy -g müssen wir zusätzlich die Amazon ECR-URL mit der Sam-Parameteroption --image-repository bereitstellen, siehe Sam-Deploy-Parameter.

So entwickeln und implementieren Sie eine Lambda-Funktion mithilfe des Nur-AWS-Betriebssystem-Basisimages und der Java (21)-Laufzeit

Nur ​​AWS OS-Basisimages enthalten eine Amazon Linux-Distribution und den Laufzeitschnittstellen-Emulator. Diese Images werden häufig verwendet, um Container-Images für kompilierte Sprachen wie Java und Rust sowie für eine Sprache oder Sprachversion zu erstellen, für die Lambda kein Basis-Image bereitstellt, wie etwa Node.js 19. Wir können auch Betriebssystem-Images verwenden. Nur Basis-Images zur Implementierung einer benutzerdefinierten Laufzeit.

Wenn wir ein Basis-Image nur für das AWS-Betriebssystem für Java verwenden möchten, müssen wir den Laufzeitschnittstellen-Client in unser Image- oder Abhängigkeitsmanagement einbeziehen. Der Laufzeitschnittstellen-Client erweitert die Lambda-Laufzeit-API, die die Interaktion zwischen Lambda und Ihrem Funktionscode verwaltet.

Ich habe auch für diesen Anwendungsfall eine Beispielanwendung bereitgestellt.

Ich habe den AWS Lambda Java Runtime Interface Client wie folgt in die pom.xml eingefügt:

<dependency>
   <groupId>com.amazonaws</groupId>
   <artifactId>aws-lambda-java-runtime-interface-client</artifactId>
</dependency>

Auch Dockerfile sieht in diesem Fall etwas anders aus.
Wir verwendeten amazoncorretto:21-alpine als Basis-Docker-Image und mussten einen Einstiegspunkt definieren, der explizit auf die Einstiegsklasse AWSLambda vom AWS Lambda Java Runtime Interface Client verweist.

ENTRYPOINT [ "/usr/bin/java", "-cp", "./*", "com.amazonaws.services.lambda.runtime.api.client.AWSLambda" ]

Alle anderen Dinge: SAM-Vorlage, Quellcode und Anwendungs- und Docker-Image-Erstellungs- und Bereitstellungsschritte bleiben die gleichen wie im AWS Lambda-Basis-Docker-Container-Image-Beispiel.

Abschluss

In diesem Artikel haben wir untersucht, wie man Lambda-Funktionen mit Docker Container Image und Java Runtime entwickelt und bereitstellt. Wir haben zwei Anwendungsfälle berücksichtigt:

• AWS Lambda-Basis-Docker-Container-Image
• Nur ​​AWS OS-Basisimage

Im nächsten Artikel messen wir die Kalt- und Warmstartzeiten der Lambda-Funktion mithilfe des AWS Lambda-Basis-Docker-Container-Images.

Das obige ist der detaillierte Inhalt vonLambda-Funktion mit Docker Container Image – Teilweise zum Entwickeln und Bereitstellen einer Lambda-Funktion mit Java (Runtime).. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!