En guise de préparation à l'étude de la façon dont l'utilisation des couches Lambda avec la fonction Lambda et le runtime Java 21 affecte les heures de démarrage à froid (avec et sans activation de SnapStart) et à chaud, j'aimerais donner une introduction sur la façon de créer, publier et utiliser des couches pour la fonction Java (21) Lambda dans le modèle SAM.
Une couche Lambda est une archive de fichier .zip qui contient du code ou des données supplémentaires. Les couches contiennent généralement des dépendances de bibliothèque, un environnement d'exécution personnalisé ou des fichiers de configuration.
Il existe plusieurs raisons pour lesquelles vous pourriez envisager d'utiliser des calques :
Par souci d'exploration, nous utiliserons l'exemple d'application pour créer la couche Lambda avec le runtime Java 21 en empaquetant les dépendances suivantes dans la couche :
Pour créer la couche Lambda dont nous avons besoin :
La couche Lambda nécessite que les dépendances soient intégrées dans un seul uber-jar. Pour cela, nous utilisons deux plugins dans le pom.xml. Le plugin maven-compiler-plugin compile le code source. Le plugin maven-shade-plugin regroupe nos artefacts dans un seul uber-jar. Ensuite, nous devons exécuter
mvn clean package
pour construire notre application.
Lorsque nous ajoutons une couche à une fonction Lambda avec le runtime Java, Lambda charge le contenu de la couche dans le répertoire /opt de cet environnement d'exécution. Pour chaque environnement d'exécution Lambda, la variable PATH inclut déjà des chemins de dossier spécifiques dans le répertoire /opt. Pour garantir que la variable PATH récupère le contenu de notre couche, notre fichier .zip de couche doit avoir ses dépendances dans les chemins de dossier suivants : java/lib
Par exemple, le fichier .zip de couche résultant que nous créons avec notre exemple d'application a la structure de répertoires suivante :
aws-pure-java-21-common-lambda-layer-content.zip └ java └ lib └ aws-pure-java-21-common-lambda-layer-1.0.0-SNAPSHOT.jar
ce qui peut être réalisé en exécutant les commandes suivantes sous Linux :
Pour publier cette couche Lambda avec le runtime Java 21, nous devons exécuter la commande suivante avec AWS CLI v2 :
aws lambda publish-layer-version --layer-name aws-pure-java-21-common-lambda-layer --zip-file fileb://aws-pure-java-21-common-lambda-layer-content.zip --compatible-runtimes java21
Avec le paramètre supplémentaire --compatible-architectures "x86", nous pouvons définir les architectures matérielles compatibles comme x86 (par défaut) ou arm64.
En réponse, AWS fournira l'ARN de la couche Lambda que nous devrons référencer plus tard, qui ressemble à celui-ci :
arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:layer:aws-pure-java-21-common-lambda-layer:1
Veuillez noter que le dernier paramètre est la version de la couche Lambda qui est toujours 1 lorsque nous publions la couche pour la première fois et qui sera incrémentée de un avec les mises à jour ultérieures de la couche Lambda existante.
Afin d'attacher le calque à votre fonction, nous pouvons procéder comme suit :
Type: AWS::Serverless::Function Properties: FunctionName: GetProductByIdWithPureJava21LambdaWithCommonLayer AutoPublishAlias: liveVersion Layers: - !Sub arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:layer:aws-pure-java-21-common-lambda-layer:1 Handler: software.amazonaws.example.product.handler.GetProductByIdHandler::handleRequest
In this article I gave an introduction about how to create, publish and use layers for Java 21 Lambda functions AWS CLI v2 and the SAM template. In the next article published under the AWS Lambda SnapStart series I'll explore how the usage of the (different) Lambda layers with function having Java 21 runtime affects the cold (with and without enabling SnapStart) and warm start times.
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!