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.
# Quand utiliser les environnements d’exécution réservés aux systèmes d’exploitation de Lambda
Lambda fournit des [environnements d’exécution gérés](lambda-runtimes.md) pour Java, Python, Node.js, .NET et Ruby. Pour créer des fonctions Lambda dans un langage de programmation qui n’est pas disponible en tant qu’environnement d’exécution géré, utilisez un environnement d’exécution uniquement basé sur le système d’exploitation (famille des environnements d’exécution `provided`). Il existe trois principaux cas d’utilisation pour les environnements d’exécution uniquement basés sur le système d’exploitation :
+ **Compilation native ahead-of-time (AOT)** : des langages tels que Go, Rust, Swift et C\$1\$1 se compilent nativement en un binaire exécutable, qui ne nécessite pas d'exécution de langage dédié. Ces langages ont uniquement besoin d’un environnement de système d’exploitation dans lequel le binaire compilé peut s’exécuter. Vous pouvez également utiliser des environnements d'exécution uniquement pour le système d'exploitation Lambda pour déployer des fichiers binaires compilés avec .NET Native AOT et Java GraalVM Native Image.
Vous devez inclure un client d’interface d’exécution. Le client de l’interface d’exécution appelle l’[Utilisation de l’API de l’environnement d’exécution Lambda pour des environnements d’exécution personnalisés](runtimes-api.md) pour récupérer les invocations de fonction, puis appelle votre gestionnaire de fonctions. Lambda fournit des clients d'interface d'exécution pour [Rust](lambda-rust.md), [Go](golang-package.md#golang-package-mac-linux), [.NET Native AOT](dotnet-native-aot.md), [Swift](https://github.com/awslabs/swift-aws-lambda-runtime) (expérimental) et [C\$1\$1](https://github.com/awslabs/aws-lambda-cpp) (expérimental).
Vous devez compiler votre binaire pour un environnement Linux et pour la même architecture de jeu d’instructions que celle que vous prévoyez d’utiliser pour la fonction (x86\$164 ou arm64).
+ **Runtimes tiers** : vous pouvez exécuter des fonctions Lambda à off-the-shelf l'aide d'environnements d'exécution [tels que](https://bref.sh/docs/news/01-bref-1.0.html#amazon-linux-2) Bref pour PHP.
+ **Exécutions personnalisées** : vous pouvez créer votre propre environnement d’exécution pour une langue ou une version de langue pour laquelle Lambda ne fournit pas d’environnement d’exécution géré, comme Node.js 19. Pour de plus amples informations, veuillez consulter [Création d'un environnement d'exécution personnalisé pour AWS Lambda](runtimes-custom.md). Il s’agit du cas d’utilisation le moins courant pour les environnements d’exécution uniquement basés sur le système d’exploitation.
Lambda prend en charge les environnements d’exécution uniquement basés sur le système d’exploitation suivants :
| Name | Identifiant | Système d’exploitation | Date d’obsolescence | Créer la fonction de blocage | Mettre à jour la fonction de blocage |
| --- | --- | --- | --- | --- | --- |
| Exécution réservée au système d’exploitation | `provided.al2023` | Amazon Linux 2023 | 30 juin 2029 | 31 juillet 2029 | 31 août 2029 |
| Exécution réservée au système d’exploitation | `provided.al2` | Amazon Linux 2 | 31 juillet 2026 | 31 août 2026 | 30 sept. 2026 |
L’environnement d’exécution Amazon Linux 2023 (`provided.al2023`) offre plusieurs avantages par rapport à Amazon Linux 2, notamment un encombrement de déploiement réduit et des versions mises à jour de bibliothèques telles que `glibc`.
L’environnement d’exécution `provided.al2023` utilise `dnf` comme gestionnaire de packages au lieu de `yum`, qui est le gestionnaire de packages par défaut dans Amazon Linux 2. Pour plus d'informations sur les différences entre `provided.al2023` et`provided.al2`, consultez [Présentation du runtime Amazon Linux 2023 AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/) sur le blog AWS Compute.
# 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](chapter-layers.md). Lorsque vous créez la fonction Lambda, choisissez un [environnement d’exécution uniquement pour le système d’exploitation](runtimes-provided.md) (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, consultez[Quand utiliser les environnements d’exécution réservés aux systèmes d’exploitation de Lambda](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.
+ **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](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 via l’encodage de transfert en bloc HTTP/1.1. 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 un format de. ** Par exemple, `Runtime.APIKeyNotFound`.
+ `Lambda-Runtime-Function-Error-Body` : informations encodées en Base64 sur 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 Lambda (par défaut). 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 Lambda (par défaut) 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'appel suivante](runtimes-api.md#runtimes-api-next), jusqu'à 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 une demande unique IDs** : suivez chaque appel séparément à l'aide de l'`Lambda-Runtime-Aws-Request-Id`en-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 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 de plus amples informations, veuillez consulter [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)
# Tutoriel : création d’un environnement d’exécution personnalisé
Dans ce didacticiel, vous allez créer une fonction Lambda avec un runtime personnalisé. Vous commencez par inclure le runtime dans le package de déploiement de la fonction. Ensuite, vous le migrez vers une couche que vous gérez indépendamment de la fonction. Enfin, vous partagez la couche du runtime en mettant à jour sa stratégie d’autorisations basée sur les ressources.
## Prérequis
Ce didacticiel suppose que vous avez quelques connaissances des opérations Lambda de base et de la console Lambda. Si ce n’est déjà fait, suivez les instructions fournies dans [Créer une fonction Lambda à l'aide de la console](getting-started.md#getting-started-create-function) pour créer votre première fonction Lambda.
Pour effectuer les étapes suivantes, vous avez besoin de l’[AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). Les commandes et la sortie attendue sont répertoriées dans des blocs distincts :
```
aws --version
```
Vous devriez voir la sortie suivante:
```
aws-cli/2.13.27 Python/3.11.6 Linux/4.14.328-248.540.amzn2.x86_64 exe/x86_64.amzn.2
```
Pour les commandes longues, un caractère d’échappement (`\`) est utilisé pour les fractionner en plusieurs lignes.
Sur Linux et macOS, utilisez votre gestionnaire de shell et de package préféré.
**Note**
Sous Windows, certaines commandes CLI Bash que vous utilisez couramment avec Lambda (par exemple `zip`) ne sont pas prises en charge par les terminaux intégrés du système d’exploitation. [Installez le sous-système Windows pour Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10) afin d’obtenir une version intégrée à Windows d’Ubuntu et Bash. Les exemples de commandes CLI de ce guide utilisent le formatage Linux. Les commandes qui incluent des documents JSON en ligne doivent être reformatées si vous utilisez la CLI Windows.
Vous avez besoin d’un rôle IAM pour créer une fonction Lambda. Le rôle a besoin d’une autorisation pour envoyer des journaux à CloudWatch Logs et accéder aux Services AWS que votre fonction utilise. Si vous ne possédez pas de rôle pour le développement de fonction, créez-en un.
**Pour créer un rôle d’exécution**
1. Ouvrez la page [Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) dans la console IAM.
1. Sélectionnez **Créer un rôle**.
1. Créez un rôle avec les propriétés suivantes :
+ **Entité de confiance** – **Lambda**.
+ **Autorisations** – **AWSLambdaBasicExecutionRole**.
+ **Nom de rôle** – **lambda-role**.
La stratégie **AWSLambdaBasicExecutionRole** possède les autorisations dont la fonction a besoin pour écrire des journaux dans CloudWatch Logs.
## Créer une fonction
Créez une fonction Lambda avec un runtime personnalisé. Cet exemple comprend deux fichiers : un fichier `bootstrap` d’exécution et un gestionnaire de fonctions. Tous deux sont mis en œuvre en Bash.
1. Créez un répertoire pour le projet, puis passez à ce répertoire.
```
mkdir runtime-tutorial
cd runtime-tutorial
```
1. Créez un nouveau fichier appelé `bootstrap`. Il s’agit de l’environnement d’exécution personnalisé.
**Example amorçage**
```
#!/bin/sh
set -euo pipefail
# Initialization - load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
Le runtime charge un script de fonction à partir du package de déploiement. Il utilise deux variables pour localiser le script. `LAMBDA_TASK_ROOT` lui indique où le package a été extrait et `_HANDLER` inclut le nom du script.
Une fois que l’environnement d’exécution charge le script de la fonction, il utilise l’API d’exécution pour récupérer un événement d’invocation à partir de Lambda, transmet l’événement au gestionnaire, puis renvoie la réponse à Lambda. Pour obtenir l’ID de la demande, le runtime enregistre les en-têtes à partir de la réponse de l’API dans un fichier temporaire et lit l’en-tête `Lambda-Runtime-Aws-Request-Id` à partir du fichier.
**Note**
Les runtimes ont d’autres responsabilités, notamment la gestion des erreurs et la fourniture d’informations de contexte au gestionnaire. Pour plus d'informations, consultez [Exigences](runtimes-custom.md#runtimes-custom-build).
1. Créez un script pour la fonction. L’exemple de script suivant définit une fonction de gestionnaire qui accepte les données des événements, la consigne dans `stderr`, puis la renvoie.
**Example function.sh**
```
function handler () {
EVENT_DATA=$1
echo "$EVENT_DATA" 1>&2;
RESPONSE="Echoing request: '$EVENT_DATA'"
echo $RESPONSE
}
```
Le répertoire `runtime-tutorial` devrait maintenant ressembler à ceci :
```
runtime-tutorial
├ bootstrap
└ function.sh
```
1. Rendez les fichiers exécutables et ajoutez-les dans une archive ZIP. Vous obtiendrez alors le package de déploiement.
```
chmod 755 function.sh bootstrap
zip function.zip function.sh bootstrap
```
1. Créez une fonction nommée `bash-runtime`. Pour `--role`, entrez l’ARN de votre [rôle d’exécution](lambda-intro-execution-role.md) Lambda.
```
aws lambda create-function --function-name bash-runtime \
--zip-file fileb://function.zip --handler function.handler --runtime provided.al2023 \
--role arn:aws:iam::123456789012:role/lambda-role
```
1. Invoquer la fonction.
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
L’option **cli-binary-format** est obligatoire si vous utilisez AWS CLI version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales prises en charge par l’AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
Vous devriez obtenir une réponse comme celle-ci :
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. Vérifiez la réponse.
```
cat response.txt
```
Vous devriez obtenir une réponse comme celle-ci :
```
Echoing request: '{"text":"Hello"}'
```
## Créer une couche
Pour séparer le code du runtime du code de la fonction, créez une couche qui contient uniquement le runtime. Les couches vous permettent de développer les dépendances de votre fonction de manière indépendante et peuvent réduire l’utilisation du stockage lorsque vous utilisez la même couche avec plusieurs fonctions. Pour de plus amples informations, consultez [Gestion des dépendances Lambda à l’aide de couches](chapter-layers.md).
1. Créez un fichier .zip contient le fichier `bootstrap`.
```
zip runtime.zip bootstrap
```
1. Créez une couche avec la commande [publish-layer-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-layer-version.html?highlight=nodejs16%20x).
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
Cela crée la première version de la couche.
## Mettre à jour la fonction
Pour utiliser la couche d’exécution dans la fonction, configurez la fonction pour utiliser la couche et supprimez le code de l’environnement d’exécution de la fonction.
1. Mettez à jour la configuration de la fonction pour extraire la couche.
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:1
```
Cela ajoute le runtime à la fonction dans le répertoire `/opt`. Pour garantir que Lambda utilise l’environnement d’exécution dans la couche, vous devez supprimer `boostrap` du package de déploiement de la fonction, comme indiqué dans les deux étapes suivantes.
1. Créez un fichier .zip reprenant le code de la fonction.
```
zip function-only.zip function.sh
```
1. Mettez à jour le code de la fonction de façon à inclure uniquement le script du gestionnaire.
```
aws lambda update-function-code --function-name bash-runtime --zip-file fileb://function-only.zip
```
1. Invoquez la fonction pour confirmer qu’elle fonctionne avec la couche de l’environnement d’exécution.
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
L’option **cli-binary-format** est obligatoire si vous utilisez AWS CLI version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales prises en charge par l’AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
Vous devriez obtenir une réponse comme celle-ci :
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. Vérifiez la réponse.
```
cat response.txt
```
Vous devriez obtenir une réponse comme celle-ci :
```
Echoing request: '{"text":"Hello"}'
```
## Mettre à jour le runtime
1. Pour enregistrer des informations sur l’environnement d’exécution, mettez à jour le script du runtime pour générer les variables d’environnement.
**Example amorçage**
```
#!/bin/sh
set -euo pipefail
# Configure runtime to output environment variables
echo "## Environment variables:"
env
# Load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
1. Créez un fichier .zip reprenant la nouvelle version du fichier `bootstrap`.
```
zip runtime.zip bootstrap
```
1. Créer une nouvelle version de la couche `bash-runtime`.
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
1. Configurez la fonction pour utiliser la nouvelle version de la couche.
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2
```
## Partager la couche
Pour partager une couche avec un autre Compte AWS, ajoutez une instruction d’autorisations entre comptes à la [politique basée sur les ressources](access-control-resource-based.md) de la couche. Exécutez la commande [add-layer-version-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-layer-version-permission.html) et spécifiez l’ID du compte en tant que `principal`. Dans chaque instruction, vous pouvez accorder une autorisation à un compte unique, à tous les comptes ou à une organisation dans [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html).
L’exemple suivant autorise le compte 111122223333 à accéder à la version 2 de la couche `bash-runtime`.
```
aws lambda add-layer-version-permission \
--layer-name bash-runtime \
--version-number 2 \
--statement-id xaccount \
--action lambda:GetLayerVersion \
--principal 111122223333 \
--output text
```
Vous devez voir des résultats similaires à ce qui suit :
```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2"}
```
Les autorisations ne s’appliquent qu’à une seule version de couche. Répétez le processus chaque fois que vous créez une nouvelle version de la couche.
## Nettoyage
Supprimez chaque version de la couche.
```
aws lambda delete-layer-version --layer-name bash-runtime --version-number 1
aws lambda delete-layer-version --layer-name bash-runtime --version-number 2
```
Étant donné que la fonction contient une référence à la version 2 de la couche, elle existe toujours dans Lambda. La fonction continue de fonctionner, mais les fonctions ne peuvent plus être configurées pour utiliser la version supprimée. Si vous modifiez la liste des couches sur la fonction, vous devez spécifier une nouvelle version ou omettre la couche supprimée.
Supprimez la fonction à l’aide de la commande [delete-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-function.html).
```
aws lambda delete-function --function-name bash-runtime
```