View a markdown version of this page

Création d'un environnement d'exécution personnalisé pour AWS Lambda - AWS Lambda
ExigencesImplémentation du flux de réponses dans un environnement d’exécution personnaliséCréation de runtimes personnalisés pour les instances gérées Lambda

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Création d'un environnement d'exécution personnalisé pour AWS Lambda

Vous pouvez implémenter un AWS Lambda environnement d'exécution 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’invocation de la fonction. Vous pouvez inclure le runtime dans le package de déploiement de votre fonction ou le distribuer dans une couche. Lorsque vous créez la fonction Lambda, choisissez un OS-only environnement d'exécution (la famille provided d'exécution).

Note

La création d’un environnement d’exécution personnalisé est un cas d’utilisation avancé. Si vous recherchez des informations sur la compilation vers un binaire natif ou sur l’utilisation d’un environnement d’exécution tiers prêt à l’emploi, consultez Quand utiliser les environnements d'exécution de Lambda OS-only.

Pour une présentation détaillée du processus de déploiement d’un environnement d’exécution personnalisé, voir Tutoriel : création d’un environnement d’exécution personnalisé.

Exigences

Les environnements d’exécution personnalisés doivent effectuer certaines tâches d’initialisation et de traitement. Une exécution exécute le code d’installation de la fonction, lit le nom du gestionnaire à partir d’une variable d’environnement et lit les événements d’invocation à partir de l’API 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.

Tâches d’initialisation

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 invocations.

  • 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 invocations.

  • 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 journal
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

Traitement des tâches

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.

  • Obtenir un événement – Appeler l’API d’invocation suivante 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.

  • Propagation de l'en-tête de suivi  : récupérez l'en-tête de X-Ray suivi à partir de l'Lambda-Runtime-Trace-Iden-tête de la réponse de l'API. Définissez la variable d’environnement _X_AMZN_TRACE_ID localement avec la même valeur. Le X-Ray SDK utilise cette valeur pour connecter les données de trace 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.

  • Invoquer 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’invocation pour afficher la réponse du gestionnaire.

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

  • 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.

Entrypoint

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 invoquer un autre fichier qui crée le runtime. Si la racine de votre package de déploiement ne contient pas de fichier nommé bootstrap, Lambda recherche le fichier dans les couches de la fonction. Si le fichier bootstrap n’existe pas ou n’est pas exécutable, votre fonction renvoie une erreur Runtime.InvalidEntrypoint au moment de l’invocation.

Voici un exemple de bootstrap fichier qui utilise une version groupée de Node.js pour exécuter un JavaScript environnement d'exécution dans un fichier distinct nomméruntime.js.

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

Implémentation du flux de réponses dans un environnement d’exécution personnalisé

Pour les fonctions de streaming de réponses, les points de terminaison response et error ont un comportement légèrement modifié qui permet à l’exécution de diffuser des réponses partielles au client et de renvoyer les charges utiles par morceaux. Pour plus d’informations sur le comportement spécifique, consultez ce qui suit :

  • /runtime/invocation/AwsRequestId/response : propage l’en-tête Content-Type de l’environnement d’exécution pour l’envoyer au client. Lambda renvoie la charge utile de la réponse par segments en utilisant un codage de transfert par HTTP/1.1 segments. Pour envoyer le flux de réponse à Lambda, l’environnement d’exécution doit :

    • Définir l’en-tête HTTP Lambda-Runtime-Function-Response-Mode sur streaming.

    • Définissez l’en-tête Transfer-Encoding sur chunked.

    • Écrivez la réponse conformément à la spécification de codage HTTP/1.1 par transfert fragmenté.

    • Fermer la connexion sous-jacente après avoir écrit la réponse avec succès.

  • /runtime/invocation/AwsRequestId/error : l’exécution peut utiliser ce point de terminaison pour signaler des erreurs de fonction ou d’exécution à Lambda, qui accepte également l’en-tête Transfer-Encoding. Ce point de terminaison ne peut être appelé qu’avant que l’environnement d’exécution ne commence à envoyer une réponse à l’invocation.

  • Signaler les erreurs en cours de diffusion à l’aide des en-têtes de suivi d’erreur dans /runtime/invocation/AwsRequestId/response. Pour signaler les erreurs qui se produisent après que l’exécution commence à écrire la réponse à l’invocation, l’exécution peut optionnellement attacher des en-têtes de fin HTTP nommés Lambda-Runtime-Function-Error-Type et Lambda-Runtime-Function-Error-Body. Lambda considère cette réponse comme une réponse réussie et transmet les métadonnées d’erreur que l’exécution fournit au client.

    Note

    Pour joindre des en-têtes de fin, l’environnement d’exécution doit définir la valeur de l’en-tête Trailer au début de la demande HTTP. Il s'agit d'une exigence de la spécification de codage HTTP/1.1 par transfert fragmenté.

    • Lambda-Runtime-Function-Error-Type : le type d’erreur que l’exécution a rencontré. Cet en-tête se compose d’une valeur de chaîne. Lambda accepte n'importe quelle chaîne, mais nous recommandons d'utiliser le format. <category.reason> Par exemple, Runtime.APIKeyNotFound.

    • Lambda-Runtime-Function-Error-Body— Base64-encoded informations sur l'erreur.

Création de runtimes personnalisés pour les instances gérées Lambda

Les instances gérées Lambda utilisent la même API d'exécution que les fonctions Lambda (par défaut). Il existe toutefois des différences majeures dans la manière dont les environnements d'exécution personnalisés doivent être mis en œuvre pour prendre en charge le modèle d'exécution simultanée des instances gérées.

Gestion des demandes simultanées

La principale différence lors de la création d'environnements d'exécution personnalisés pour les instances gérées est la prise en charge des appels simultanés. Contrairement aux fonctions Lambda (par défaut) dans lesquelles le moteur d'exécution traite un appel à la fois, les instances gérées peuvent traiter plusieurs appels simultanément dans un seul environnement d'exécution.

Votre environnement d'exécution personnalisé doit :

  • Prise en charge /next des demandes simultanées  : le moteur d'exécution peut effectuer plusieurs appels simultanés vers la prochaine API d'invocation, jusqu'à la limite spécifiée par la variable d'AWS_LAMBDA_MAX_CONCURRENCYenvironnement.

  • Gérez les /response demandes simultanées  : plusieurs appels peuvent appeler simultanément l'API de réponse aux invocations.

  • Implémentez une gestion des requêtes adaptée aux threads  : assurez-vous que les appels simultanés n'interfèrent pas les uns avec les autres en gérant correctement les ressources et l'état partagés.

  • Utilisez des identifiants de demande uniques  : suivez chaque appel séparément à l'aide de l'Lambda-Runtime-Aws-Request-Iden-tête pour faire correspondre les réponses aux demandes correspondantes.

Modèle de mise en œuvre

Un modèle d'implémentation typique pour les environnements d'exécution des instances gérées consiste à créer des threads ou des processus de travail pour gérer les appels simultanés :

  1. Lisez la limite de simultanéité  : lors de l'initialisation, lisez la variable d'AWS_LAMBDA_MAX_CONCURRENCYenvironnement pour déterminer le nombre d'appels simultanés à prendre en charge.

  2. Créer un pool de travailleurs  : initialisez un pool de travailleurs (threads, processus ou tâches asynchrones) égal à la limite de simultanéité.

  3. Boucle de traitement des travailleurs — Chaque travailleur indépendamment :

    • Appels /runtime/invocation/next pour obtenir un événement d'invocation

    • Invoque le gestionnaire de fonctions avec les données de l'événement

    • Publie la réponse à /runtime/invocation/AwsRequestId/response

    • Répète la boucle

Considérations supplémentaires

  • Format de journalisation  : les instances gérées ne prennent en charge que le format de journal JSON. Assurez-vous que votre environnement d'exécution respecte la variable d'AWS_LAMBDA_LOG_FORMATenvironnement et utilise uniquement le format JSON. Pour de plus amples informations, veuillez consulter Configuration des formats de journal JSON et en texte brut.

  • Ressources partagées  : soyez prudent lorsque vous utilisez des ressources partagées telles que le /tmp répertoire avec des appels simultanés. Mettez en place des mécanismes de verrouillage appropriés pour éviter les conditions de course.

Pour plus d'informations sur les environnements d'exécution des instances gérées Lambda, consultezComprendre l'environnement d'exécution des instances gérées Lambda.