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.
# 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
```