Fonction Lambda utilisant Docker Container Image -Partie ow pour développer et déployer la fonction Lambda avec Java (runtime

Introduction

Dans cet article, j'aimerais découvrir comment développer et déployer la fonction Lambda à l'aide de Docker Container Image et du runtime Java. Dans cet article, j'utiliserai le runtime Java 21 Corretto. Mais comme pour les images de conteneurs, nous pouvons utiliser même les environnements d'exécution Java récents comme Java 22 et pas seulement les environnements d'exécution Java à support à long terme (LTS) comme Java 17 et 21. Il est facile de mettre à jour cet exemple lorsqu'une version plus récente de Java sera publiée (comme Java version 23 en septembre 2024).

Comment développer et déployer la fonction Lambda à l'aide de l'image du conteneur Docker de base AWS Lambda et du runtime Java (21)

Les images de base AWS sont préchargées avec un environnement d'exécution de langage, un client d'interface d'exécution pour gérer l'interaction entre Lambda et votre code de fonction, et un émulateur d'interface d'exécution pour les tests locaux. Pour utiliser une image de base AWS pour Java, veuillez vous référer à cet article.

Par souci d'explication, nous utiliserons notre exemple d'application et utiliserons le runtime Java 21 pour nos fonctions Lambda.

Dans cette application, nous allons créer et récupérer des produits et utiliser DynamoDB comme base de données NoSQL. Vous pouvez trouver l'implémentation de DynamoProductDao.java ici. Nous plaçons également Amazon API Gateway devant, comme défini dans le modèle AWS SAM. Dans ce modèle nous avons également défini 2 fonctions Lambda : PutProductWithPureJava21DockerImage et GetProductByIdWithPureJava21DockerImage.

Nous devons définir Dockerfile dans lequel nous utilisons l'image Docker de base AWS Lambda public.ecr.aws/lambda/java:21 pour Java 21 à partir du référentiel public Amazon ECR. Vous trouverez ici toutes les images Docker de base Lambda pour Java fournies par AWS.

Dans l'image Docker, nous copions également le code de fonction et les dépendances d'exécution de la disposition Maven vers la variable d'environnement d'exécution LAMBDA_TASK_ROOT – Le chemin d'accès à votre code de fonction Lambda.

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

Tout le reste est défini dans la déclaration de la fonction Lambda dans le modèle AWS SAM.

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"]

Les pièces importantes sont :

• PackageType : Image qui indique que nous emballons notre fonction Lambda en tant qu'image de conteneur Docker
• ImageUri : !Sub ${AWS::AccountId}.dkr.ecr.eu-central-1.amazonaws.com/aws-pure-lambda-java21-custom-docker-image:v1 qui fait référence au chemin du conteneur Docker Image dans Amazon Elastic Container Registry. Plus d’informations sur la façon d’y placer l’image plus tard. -ImageConfig : La commande : ["software.amazonaws.example.product.handler.GetProductByIdHandler::handleRequest"] est remplacée par CMD par notre gestionnaire GetProductById. Comme ce CMD est unique pour chaque fonction Lambda il vaut mieux le déclarer au niveau de la fonction Lambda comme dans le fichier Docker.

Répondons maintenant à la question de savoir comment créer et transférer l'image du conteneur Docker vers le référentiel ECR. Vous pouvez le faire automatiquement, puis vous exécutez la chaîne de commandesam build et sam déployerou si vous créez et emballez l'application en dehors du SAM et que vous la déployez uniquement avec SAM, vous devez la créer manuellement comme ceci

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

Lors du déploiement de la fonction avec sam déployer -g, nous devons en outre fournir l'URL Amazon ECR à l'aide de l'option de paramètre sam --image-repository, voir les paramètres de déploiement sam.

Comment développer et déployer la fonction Lambda à l'aide de l'image de base du système d'exploitation AWS uniquement et du runtime Java (21)

Les images de base réservées au système d'exploitation AWS contiennent une distribution Amazon Linux et l'émulateur d'interface d'exécution. Ces images sont couramment utilisées pour créer des images de conteneur pour les langages compilés, tels que Java et Rust, et pour un langage ou une version de langage pour lequel Lambda ne fournit pas d'image de base, comme Node.js 19. Nous pouvons également utiliser OS- uniquement des images de base pour implémenter un runtime personnalisé.

Si nous souhaitons utiliser une image de base du système d'exploitation AWS uniquement pour Java, nous devons inclure le client de l'interface d'exécution dans notre gestion des images ou des dépendances. Le client d'interface d'exécution étend l'API d'exécution Lambda, qui gère l'interaction entre Lambda et votre code de fonction.

J'ai également fourni un exemple d'application pour ce cas d'utilisation.

J'ai inclus le client d'interface d'exécution Java AWS Lambda dans le pom.xml comme ceci :

 com.amazonaws aws-lambda-java-runtime-interface-client 

Dockerfile est également un peu différent dans ce cas.
Nous avons utilisé amazoncorretto:21-alpine comme image Docker de base et avons dû définir un point d'entrée pointant explicitement vers la classe d'entrée AWSLambda d'AWS Lambda Java Runtime Interface Client.

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

Toutes les autres choses : le modèle SAM, le code source et les étapes de création et de déploiement d'images d'application et Docker restent les mêmes que dans l'exemple d'image de conteneur Docker de base AWS Lambda.

Conclusion

Dans cet article, nous avons exploré comment développer et déployer la fonction Lambda à l'aide de Docker Container Image et du runtime Java. Nous avons considéré 2 cas d'usage :

• Image du conteneur Docker de base AWS Lambda
• Image de base du système d'exploitation AWS uniquement

Dans le prochain article, nous mesurerons les heures de démarrage à froid et à chaud de la fonction Lambda à l'aide de l'image du conteneur Docker de base AWS Lambda.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!