AWS Lambda
Manuel du développeur

Runtimes AWS Lambda personnalisés

Vous pouvez implémenter un runtime AWS Lambda dans n'importe quel langage de programmation. Un runtime est un programme qui exécute la méthode de gestionnaire d'une fonction Lambda lorsque la fonction est appelée. Vous pouvez inclure un runtime 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 la variable d'environnement et de la lecture des événements d'appels dans l'API de runtime de Lambda. Le runtime 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 Lambda et, plus précisément, dans son environnement d'exécution standard. Il peut s'agir d'un script shell, d'un script dans un langage qui est inclus dans Amazon Linux ou d'un fichier exécutable binaire compilé dans Amazon Linux.

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

Utilisation d'un runtime personnalisé

Pour utiliser un runtime personnalisé, définissez le runtime 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

S'il y a un fichier nommé bootstrap dans votre package de déploiement, Lambda exécute ce fichier. 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 runtime personnalisé

Le point d'entrée d'un runtime personnalisé est un fichier exécutable nommé bootstrap. Le fichier d'amorçage peut être le runtime, 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 runtime 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 de l'environnement pour obtenir les 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 qui contient le code de la fonction.

    • AWS_LAMBDA_RUNTIME_API – Hôte et port de l'API du runtime.

    Pour obtenir une liste complète des variables disponibles, consultez Variables d'environnement disponibles pour les fonctions Lambda.

  • Initialiser la fonction – Chargez le fichier de gestionnaire et exécutez 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 d'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

        Temps d'initialisation dans un suivi X-Ray.

Pendant son exécution, le runtime utilise l'interface de runtime Lambda pour gérer les événements entrants et signaler des erreurs. Après avoir terminé les tâches d'initialisation, le runtime traite les événements entrants dans une boucle.

Traitement des tâches

  • Obtenir un événement – Appelez l'API prochain appel 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 – Obtenez 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 avec la même valeur pour le kit SDK X-Ray à utiliser.

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

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

  • Gérer la réponse – Appelez 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 d'appel.

  • Nettoyage – Libérez les ressources inutilisées, envoyez des données à d'autres services ou réalisez des tâches supplémentaires avant de passer à l'événement suivant.

Vous pouvez inclure le runtime 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, consultez Didacticiel – Publication d'un runtime personnalisé.