Création d'un environnement d'exécution personnalisé pour AWS Lambda - AWS Lambda
PrérequisImplémentation du flux de réponses dans un environnement d’exécution personnalisé

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 environnement d'exécution uniquement pour le système d'exploitation (la famille d'exécution provided).

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 off-the-shelf environnement d'exécution tiers, consultezQuand utiliser les environnements d'exécution uniquement pour le système d'exploitation de Lambda.

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é. Vous pouvez également explorer un environnement d'exécution personnalisé implémenté en C++ sur awslabs/ aws-lambda-cpp on. GitHub

Prérequis

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.

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

  • 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 amorçage
#!/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 en morceaux via l’encodage de transfert en bloc HTTP/1.1. Le flux de réponse peut avoir une taille maximale de 20 Mio. 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.

    • Écrire la réponse conformément à la spécification d’encodage de transfert en bloc HTTP/1.1.

    • 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. C’est une exigence de la spécification de l’encodage de transfert en bloc HTTP/1.1.

    • 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 le format <category.reason>. Par exemple, Runtime.APIKeyNotFound.

    • Lambda-Runtime-Function-Error-Body : informations encodées en Base64 sur l’erreur.