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 Fonctions événementielles
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 gestion d'une fonction d'événement Lambda lorsque la fonction est invoquée. Vous pouvez inclure le runtime dans le package de déploiement de votre fonction ou le distribuer dans une [couche](chapter-layers.md). Lorsque vous créez la fonction, choisissez un [OS-only environnement d'exécution](runtimes-provided.md) (la famille `provided` d'environnements 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](runtimes-provided.md).
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é](runtimes-walkthrough.md).
**Topics**
+ [Exigences](#runtimes-custom-build)
+ [Implémentation du flux de réponses dans un environnement d’exécution personnalisé](#runtimes-custom-response-streaming)
+ [Création d'environnements d'exécution personnalisés pour les instances gérées Lambda](#runtimes-custom-managed-instances)
## 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](lambda-runtime-environment.md) 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](configuration-envvars.md#configuration-envvars-runtime).
+ **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](runtimes-api.md#runtimes-api-initerror) 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](services-xray.md).
**Example 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](runtimes-api.md) 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](runtimes-api.md#runtimes-api-next) 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** : obtenez l'en-tête de X-Ray suivi à partir de l'`Lambda-Runtime-Trace-Id`en-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 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](runtimes-api.md#runtimes-api-response) pour afficher la réponse du gestionnaire.
+ **Gérer les erreurs** : si une erreur se produit, appelez l’API [erreur de l’invocation](runtimes-api.md#runtimes-api-invokeerror).
+ **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`.
**Example 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](configuration-response-streaming.md), 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 en utilisant HTTP/1.1 un codage de transfert fragmenté. 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`.
+ Rédigez la réponse conformément à la spécification de codage de transfert HTTP/1.1 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 de transfert HTTP/1.1 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 un format de. {{}} Par exemple : `Runtime.APIKeyNotFound`.
+ `Lambda-Runtime-Function-Error-Body`— Base64-encoded des informations relatives à l'erreur.
## Création d'environnements d'exécution 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 qui utilisent le fournisseur de capacité par défaut Lambda. Cependant, il existe 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 qui utilisent le fournisseur de capacité par défaut Lambda, où le moteur d'exécution traite un appel à la fois, les instances gérées peuvent traiter plusieurs appels simultanément au sein d'un même environnement d'exécution.
Votre environnement d'exécution personnalisé doit :
+ **Support des `/next` demandes simultanées** : le moteur d'exécution peut effectuer plusieurs appels simultanés à l'API d'[invocation suivante](runtimes-api.md#runtimes-api-next), dans la limite spécifiée par la variable d'`AWS_LAMBDA_MAX_CONCURRENCY`environnement.
+ **Gérer les `/response` demandes simultanées** : plusieurs invocations peuvent appeler simultanément l'API de [réponse à](runtimes-api.md#runtimes-api-response) l'appel.
+ **Mettez en œuvre une gestion des demandes 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 les états partagés.
+ **Utiliser correctement les identifiants de demande et d'invocation** : un identifiant de demande identifie l'événement ; utilisez-le dans le chemin de l'URL. Un ID d'appel représente une seule tentative d'invocation : un seul ID de demande peut entraîner plusieurs tentatives, chacune avec un ID d'appel unique. Réactivez l'identifiant d'invocation `/response` et les `/error` appels. L'en-tête est facultatif ; son omission est acceptée pour des raisons de rétrocompatibilité. Lambda rejette uniquement with `400 InvalidInvocationId` lorsque l'en-tête est présent mais que sa valeur ne correspond pas.
### Modèle de mise en œuvre
Un modèle d'implémentation typique pour les environnements d'exécution des instances gérées implique la création de threads de travail ou de processus pour gérer les invocations simultanées :
1. **Lire la limite de simultanéité** : lors de l'initialisation, lisez la variable d'`AWS_LAMBDA_MAX_CONCURRENCY`environnement pour déterminer le nombre d'appels simultanés à prendre en charge.
1. **Créer un pool de travailleurs** : initialisez un pool de travailleurs (threads, processus ou tâches asynchrones) égal à la limite de simultanéité.
1. **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 sur `/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_FORMAT`environnement et utilise uniquement le format JSON. Pour plus d’informations, consultez [Configuration des formats de journal JSON et en texte brut](monitoring-cloudwatchlogs-logformat.md).
+ **Ressources partagées** : soyez prudent lorsque vous utilisez des ressources partagées, telles que le `/tmp` répertoire avec des invocations simultanées. 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, consultez. [Comprendre l'environnement d'exécution des instances gérées Lambda](lambda-managed-instances-execution-environment.md)