Environnements d’exécution AWS Lambda personnalisés - AWS Lambda

Environnements d’exécution AWS Lambda personnalisés

Vous pouvez implémenter un environnement d’exécution AWS Lambda dans n’importe quel langage de programmation. Un environnement d’exécution est un programme qui exécute la méthode de gestionnaire d’une fonction Lambda lors de l’appel de la fonction. Vous pouvez inclure un environnement d’exécution dans le package de déploiement de votre fonction sous la forme d’un fichier exécutable nommé bootstrap.

Le runtime est responsable de l’exécution du code de configuration de la fonction, de la lecture du nom du gestionnaire dans une variable d’environnement et de la lecture des événements d’appels dans l’API d’environnement d’exécution Lambda. L’environnement d’exécution transmet les données d’événements au gestionnaire de la fonction, et renvoie la réponse du gestionnaire à Lambda.

Votre runtime personnalisé s’exécute dans l’environnement d’exécution Lambda standard. Il peut s’agir d’un script d’environnement d’exécution, d’un script dans un langage inclus dans Amazon Linux, ou d’un fichier binaire exécutable compilé dans Amazon Linux.

Pour commencer à avec les environnements d’exécution personnalisés, consultez Didacticiel – Publication d'un runtime personnalisé. Vous pouvez également explorer un environnement d’exécution personnalisé implémenté en C++ à l’adresse awslabs/aws-lambda-cpp sur GitHub.

Utilisation d’un environnement d’exécution personnalisé

Pour utiliser un runtime personnalisé, définissez l’environnement d’exécution de votre fonction sur provided. Le runtime peut être inclus dans le package de déploiement de votre fonction ou dans une couche.

Exemple function.zip

. ├── bootstrap ├── function.sh

Si votre package de déploiement contient un fichier nommé bootstrap, Lambda l’exécute. Dans le cas contraire, Lambda recherche un runtime dans les couches de la fonction. Si le fichier d’amorçage est introuvable ou n’est pas exécutable, votre fonction renvoie une erreur au moment de l’appel.

Création d’un environnement d’exécution personnalisé

Le point d’entrée d’un runtime personnalisé est un fichier exécutable nommé bootstrap. Le fichier d’amorçage peut être l’environnement d’exécution, ou il peut appeler un autre fichier qui crée le runtime. L’exemple suivant utilise une version groupée de Node.js pour exécuter un environnement d’exécution JavaScript dans un fichier séparé nommé runtime.js.

Exemple amorçage

#!/bin/sh cd $LAMBDA_TASK_ROOT ./node-v11.1.0-linux-x64/bin/node runtime.js

Le code de votre runtime est responsable de l’exécution de certaines tâches d’initialisation. Ensuite, il traite les événements d’appels dans une boucle jusqu’à ce qu’à son arrêt. Les tâches d’initialisation sont exécutées une seule fois par instance de la fonction pour préparer l’environnement à la gestion des appels.

Tâches d’initialisation

  • Récupérer les paramètres – Lecture des variables d’environnement pour obtenir des détails sur la fonction et l’environnement.

    • _HANDLER – Emplacement du gestionnaire, issu de la configuration de la fonction. Le format standard est file.method, où file est le nom du fichier sans extension et method est le nom d’une méthode ou fonction qui est définie dans le fichier.

    • LAMBDA_TASK_ROOT – Répertoire contenant le code de la fonction.

    • AWS_LAMBDA_RUNTIME_API – Hôte et port de l’API d’exécution.

    Pour obtenir la liste complète des variables disponibles, consultez Variables d’environnement d’exécution définies.

  • Initialiser la fonction – Charger le fichier de gestionnaire et exécuter tout code global ou statique qu’il contient. Les fonctions doivent créer des ressources statiques telles que des clients de kit SDK et des connexions de base de données une seule fois, puis les réutiliser pour plusieurs appels.

  • Gérer les erreurs : si une erreur se produit, appelez l’API erreur de l’initialisation et quittez immédiatement.

L’initialisation est comptabilisée dans le délai d’attente et la durée d’exécution facturés. Lorsqu’une exécution déclenche l’initialisation d’une nouvelle instance de votre fonction, vous pouvez voir le temps d’initialisation dans les journaux et le suivi AWS X-Ray.

Exemple log

REPORT RequestId: f8ac1208... Init Duration: 48.26 ms Duration: 237.17 ms Billed Duration: 300 ms Memory Size: 128 MB Max Memory Used: 26 MB

Pendant son exécution, l’environnement d’exécution utilise l’interface d’environnement d’exécution Lambda pour gérer les événements entrants et signaler des erreurs. Après avoir terminé les tâches d’initialisation, l’environnement d’exécution traite les événements entrants dans une boucle. Dans votre code d’exécution, effectuez les étapes suivantes dans l’ordre.

Traitement des tâches

  • Obtenir un événement – Appeler l’API d’appel suivant pour obtenir l’événement suivant. Le corps de la réponse contient les données de l’événement. Les en-têtes de la réponse contiennent l’ID de la demande et d’autres informations.

  • Propager l’en-tête de suivi – Obtenir l’en-tête de suivi X-Ray à partir de l’en-tête Lambda-Runtime-Trace-Id dans la réponse de l’API. Définissez la variable d’environnement _X_AMZN_TRACE_ID localement avec la même valeur. Le kit SDK X-Ray utilise cette valeur pour connecter les données de suivi entre les services.

  • Créer un objet de contexte – Créer un objet avec des informations de contexte à partir des variables d’environnement et des en-têtes de la réponse de l’API.

  • Appeler le gestionnaire de fonctions – Transmettre l’événement et l’objet contexte au gestionnaire.

  • Gérer la réponse – Appeler l’API réponse d’appel pour afficher la réponse du gestionnaire.

  • Gérer les erreurs : si une erreur se produit, appelez l’API erreur de l’appel.

  • Nettoyage : libérer les ressources inutilisées, envoyer des données à d’autres services ou accomplir des tâches supplémentaires avant de passer à l’événement suivant.

Vous pouvez inclure l’environnement d’exécution dans le package de déploiement de votre fonction ou distribuer le runtime séparément dans une couche de fonction. Pour afficher un exemple de procédure, veuillez consulter Didacticiel – Publication d'un runtime personnalisé.