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 de fonctions Lambda avec Python
Vous pouvez exécuter du code Python dans AWS Lambda. Lambda fournit des [runtimes](lambda-runtimes.md) pour Python qui exécutent votre code afin de traiter des événements. Votre code s'exécute dans un environnement qui inclut le SDK pour Python (Boto3), avec les informations d'identification d'un rôle (IAM) que vous Gestion des identités et des accès AWS gérez. Pour en savoir plus sur les versions du kit SDK incluses dans les environnements d’exécution Python, consultez [Versions du SDK incluses dans l’environnement d’exécution](#python-sdk-included).
Lambda prend en charge les runtimes Python suivants.
| Name | Identifiant | Système d’exploitation | Date d’obsolescence | Créer la fonction de blocage | Mettre à jour la fonction de blocage |
| --- | --- | --- | --- | --- | --- |
| Python 3.14 | `python3.14` | Amazon Linux 2023 | 30 juin 2029 | 31 juillet 2029 | 31 août 2029 |
| Python 3.13 | `python3.13` | Amazon Linux 2023 | 30 juin 2029 | 31 juillet 2029 | 31 août 2029 |
| Python 3.12 | `python3.12` | Amazon Linux 2023 | 31 octobre 2028 | 30 novembre 2028 | 10 janvier 2029 |
| Python 3.11 | `python3.11` | Amazon Linux 2 | 30 juin 2027 | 31 juillet 2027 | 31 août 2027 |
| Python 3.10 | `python3.10` | Amazon Linux 2 | 31 octobre 2026 | 30 novembre 2026 | 15 janvier 2027 |
**Pour créer une fonction Python**
1. Ouvrez la [console Lambda](https://console.aws.amazon.com/lambda).
1. Sélectionnez **Créer une fonction**.
1. Configurez les paramètres suivants :
+ **Nom de la fonction** : saisissez le nom de la fonction.
+ **Runtime** : choisissez **Python 3.14**.
1. Choisissez **Créer une fonction**.
La console crée une fonction Lambda avec un seul fichier source nommé `lambda_function`. Vous pouvez modifier ce fichier et ajouter d'autres fichiers dans l'éditeur de code intégré. Dans la section **DÉPLOYER**, choisissez **Déployer** pour mettre à jour le code de votre fonction. Ensuite, pour exécuter votre code, choisissez **Créer un événement de test** dans la section **ÉVÉNEMENTS DE TEST**.
Votre fonction Lambda est fournie avec un groupe de CloudWatch journaux Logs. La fonction runtime envoie les détails de chaque appel à CloudWatch Logs. Il relaie tous les [journaux que votre fonction génère](python-logging.md) pendant l’invocation. Si votre fonction renvoie une erreur, Lambda met en forme l’erreur et la renvoie à l’appelant.
**Topics**
+ [Versions du SDK incluses dans l’environnement d’exécution](#python-sdk-included)
+ [Fonctionnalités Python désactivées](#python-disabled-features)
+ [Format de la réponse](#python-response-format)
+ [Arrêt progressif pour les extensions](#python-graceful-shutdown)
+ [Définition du gestionnaire de fonction Lambda en Python](python-handler.md)
+ [Travailler avec des archives de fichiers .zip pour les fonctions Lambda Python](python-package.md)
+ [Déployer des fonctions Lambda en Python avec des images conteneurs](python-image.md)
+ [Utilisation de couches pour les fonctions Lambda Python](python-layers.md)
+ [Utilisation de l’objet de contexte Lambda pour récupérer les informations de la fonction Python](python-context.md)
+ [Journalisation et surveillance des fonctions Lambda Python](python-logging.md)
+ [Test de la fonction AWS Lambda dans Python](python-testing.md)
+ [Instrumentation du code Python dans AWS Lambda](python-tracing.md)
## Versions du SDK incluses dans l’environnement d’exécution
La version du AWS SDK incluse dans le runtime Python dépend de la version d'exécution et de votre Région AWS. Pour trouver la version du kit SDK incluse dans l’environnement d’exécution que vous utilisez, créez une fonction Lambda avec le code suivant.
```
import boto3
import botocore
def lambda_handler(event, context):
print(f'boto3 version: {boto3.__version__}')
print(f'botocore version: {botocore.__version__}')
```
## Fonctionnalités Python désactivées
Le tableau suivant répertorie les fonctionnalités Python qui sont désactivées dans les environnements d'exécution gérés par Lambda et les images de base de conteneurs pour Python. Ces fonctionnalités doivent être activées lors de la compilation de l'exécutable Python et ne peuvent pas être activées à l'aide d'un indicateur d'exécution. Pour utiliser ces fonctionnalités dans Lambda, vous pouvez déployer votre propre version d'exécution Python avec ces fonctionnalités activées, à l'aide d'une [image de conteneur](python-image.md#python-image-clients) ou d'un environnement d'exécution [personnalisé](runtimes-custom.md).
| Fonctionnalité Python | Versions de Python concernées | Statut |
| --- | --- | --- |
| Just-in-Time compilateur (JIT) | Python 3.13 et versions ultérieures | Le compilateur JIT est expérimental et n'est pas recommandé pour les charges de travail de production. Il est donc désactivé dans les environnements d'exécution Lambda Python. |
| Filetage gratuit | Python 3.13 et versions ultérieures | Le threading gratuit (option permettant de désactiver le verrouillage global de l'interpréteur) est désactivé dans les versions Lambda Python en raison de l'impact sur les performances du code à thread unique. |
## Format de la réponse
Dans les environnements d'exécution Python 3.12 et versions ultérieures, les fonctions renvoient des caractères Unicode dans le cadre de leur réponse JSON. Les environnements d'exécution Python antérieurs renvoyaient des séquences échappées pour les caractères Unicode dans les réponses. Par exemple, dans Python 3.11, si vous renvoyez une chaîne Unicode telle que « こんにちは », elle échappe le caractères Unicode et renvoie « \$1u3053\$1u3093\$1u306b\$1u3061\$1u306f ». L’environnement d’exécution Python 3.12 renvoie le « こんにちは » d'origine.
L'utilisation de réponses Unicode réduit la taille des réponses Lambda, ce qui facilite l'adaptation de réponses plus importantes à la taille de charge utile maximale de 6 Mo pour les fonctions synchrones. Dans l'exemple précédent, la version échappée est de 32 octets, contre 17 octets pour la chaîne Unicode.
Lors de la mise à niveau vers Python 3.12 ou à une version ultérieure de l’environnement d’exécution Python, vous devrez peut-être ajuster votre code pour tenir compte du nouveau format de réponse. Si l'appelant s'attend à une chaîne Unicode échappée, vous devez soit ajouter du code à la fonction de renvoi pour échapper l'Unicode manuellement, soit ajuster l'appelant pour qu'il gère le retour Unicode.
## Arrêt progressif pour les extensions
Les environnements d’exécution Python 3.12 et versions ultérieures offrent des fonctionnalités d'arrêt progressif améliorées pour les fonctions dotées d'[extensions externes](lambda-extensions.md). Quand Lambda arrête l'exécution, il envoie un signal `SIGTERM` à l'exécution, puis un événement `SHUTDOWN` à chaque extension externe enregistrée. Vous pouvez intercepter le signal `SIGTERM` dans votre fonction Lambda et nettoyer les ressources telles que les connexions de base de données créées par la fonction.
Pour en savoir plus sur le cycle de vie de l'environnement d'exécution, veuillez consulter [Comprendre le cycle de vie de l’environnement d’exécution Lambda](lambda-runtime-environment.md). Pour des exemples d'utilisation de l'arrêt progressif avec des extensions, consultez le [ GitHub référentiel AWS Samples](https://github.com/aws-samples/graceful-shutdown-with-aws-lambda).
# Définition du gestionnaire de fonction Lambda en Python
Le *gestionnaire* de fonction Lambda est la méthode dans votre code de fonction qui traite les événements. Lorsque votre fonction est invoquée, Lambda exécute la méthode du gestionnaire. Votre fonction s’exécute jusqu’à ce que le gestionnaire renvoie une réponse, se ferme ou expire.
Cette page explique comment utiliser les gestionnaires de fonctions Lambda dans Python, notamment les conventions de dénomination, les signatures de gestionnaire valides et les bonnes pratiques. Cette page inclut également un exemple de fonction Lambda Python qui collecte des informations relatives à une commande, produit un reçu sous forme de fichier texte et place ce fichier dans un compartiment Amazon Simple Storage Service (Amazon S3).
**Topics**
+ [Exemple de fonction Lambda Python](#python-handler-example)
+ [Convention de nommage du gestionnaire](#python-handler-naming)
+ [Utilisation de l’objet d’événement Lambda](#python-handler-event)
+ [Accès et utilisation de l’objet de contexte Lambda](#python-handler-context)
+ [Signatures de gestionnaire valides pour les gestionnaires Python](#python-handler-signature)
+ [Renvoi d’une valeur](#python-handler-return)
+ [Utilisation d’AWS SDK pour Python (Boto3) dans votre gestionnaire](#python-handler-sdk)
+ [Accès aux variables d’environnement](#python-handler-env-vars)
+ [Pratiques exemplaires en matière de code pour les fonctions Lambda Python](#python-handler-best-practices)
## Exemple de fonction Lambda Python
L’exemple de code de fonction Lambda Python suivant prend en compte les informations relatives à une commande, produit un reçu sous forme de fichier texte et place ce fichier dans un compartiment Amazon S3 :
**Example Fonction Lambda Python**
```
import json
import os
import logging
import boto3
# Initialize the S3 client outside of the handler
s3_client = boto3.client('s3')
# Initialize the logger
logger = logging.getLogger()
logger.setLevel("INFO")
def upload_receipt_to_s3(bucket_name, key, receipt_content):
"""Helper function to upload receipt to S3"""
try:
s3_client.put_object(
Bucket=bucket_name,
Key=key,
Body=receipt_content
)
except Exception as e:
logger.error(f"Failed to upload receipt to S3: {str(e)}")
raise
def lambda_handler(event, context):
"""
Main Lambda handler function
Parameters:
event: Dict containing the Lambda function event data
context: Lambda runtime context
Returns:
Dict containing status message
"""
try:
# Parse the input event
order_id = event['Order_id']
amount = event['Amount']
item = event['Item']
# Access environment variables
bucket_name = os.environ.get('RECEIPT_BUCKET')
if not bucket_name:
raise ValueError("Missing required environment variable RECEIPT_BUCKET")
# Create the receipt content and key destination
receipt_content = (
f"OrderID: {order_id}\n"
f"Amount: ${amount}\n"
f"Item: {item}"
)
key = f"receipts/{order_id}.txt"
# Upload the receipt to S3
upload_receipt_to_s3(bucket_name, key, receipt_content)
logger.info(f"Successfully processed order {order_id} and stored receipt in S3 bucket {bucket_name}")
return {
"statusCode": 200,
"message": "Receipt processed successfully"
}
except Exception as e:
logger.error(f"Error processing order: {str(e)}")
raise
```
Ce fichier comprend les sections suivantes :
+ Bloc `import` : utilisez ce bloc pour inclure les bibliothèques que votre fonction Lambda requiert.
+ Initialisation globale du client SDK et de l’enregistreur : l’inclusion du code d’initialisation en dehors du gestionnaire permet de tirer parti de la réutilisation de l’[environnement d’exécution](lambda-runtime-environment.md) afin d’améliorer les performances de votre fonction. Pour en savoir plus, veuillez consulter [Pratiques exemplaires en matière de code pour les fonctions Lambda Python](#python-handler-best-practices).
+ `def upload_receipt_to_s3(bucket_name, key, receipt_content):` une fonction d’assistance appelée par la fonction `lambda_handler` principale.
+ `def lambda_handler(event, context):` la **fonction de gestion principale** de votre code, qui contient la logique principale de votre application. Lorsque Lambda invoque votre gestionnaire de fonction, l’[environnement d’exécution Lambda](concepts-basics.md#gettingstarted-concepts-runtime) transmet deux arguments à la fonction, l’[objet d’événement](#python-handler-event) qui contient les données à traiter par votre fonction, et l’[objet de contexte](#python-handler-context) qui contient des informations sur l’invocation de la fonction.
## Convention de nommage du gestionnaire
Le nom du gestionnaire de fonction défini au moment de la création d’une fonction Lambda est dérivé des éléments suivants :
+ Nom du fichier dans lequel se trouve la fonction du gestionnaire Lambda.
+ Nom de la fonction du gestionnaire Python.
Dans l’exemple ci-dessus, si le fichier est nommé `lambda_function.py`, le gestionnaire sera spécifié comme `lambda_function.lambda_handler`. Il s’agit du nom de gestionnaire par défaut donné aux fonctions que vous créez avec la console Lambda.
Si vous créez une fonction dans la console en utilisant un nom de fichier ou un nom de gestionnaire de fonction différent, vous devez modifier le nom du gestionnaire par défaut.
**Pour modifier le nom du gestionnaire de fonction (console)**
1. Ouvrez la page [Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda et choisissez votre fonction.
1. Cliquez sur l’onglet **Code**.
1. Faites défiler l’écran jusqu’au volet **Paramètres d’exécution** et choisissez **Modifier**.
1. Dans **Gestionnaire**, saisissez le nouveau nom de votre gestionnaire de fonction.
1. Choisissez **Enregistrer**.
## Utilisation de l’objet d’événement Lambda
Lorsque Lambda invoque votre fonction, il transmet un argument d’[objet d’événement](concepts-basics.md#gettingstarted-concepts-event) au gestionnaire de fonction. Les objets JSON constituent le format d’événement le plus courant pour les fonctions Lambda. Dans l’exemple de code de la section précédente, la fonction exige une entrée au format suivant :
```
{
"Order_id": "12345",
"Amount": 199.99,
"Item": "Wireless Headphones"
}
```
Si votre fonction est invoquée par un autre Service AWS, l’événement d’entrée est également un objet JSON. Le format exact de l’objet d’événement dépend du service qui invoque votre fonction. Pour connaître le format de l’événement pour un service en particulier, reportez-vous à la page appropriée du chapitre [Invoquer Lambda avec des événements provenant d'autres services AWS](lambda-services.md).
Si l’événement d’entrée est sous la forme d’un objet JSON, le moteur d’exécution Lambda le convertit en dictionnaire Python. Pour attribuer des valeurs dans le JSON d’entrée aux variables de votre code, utilisez les méthodes standard des dictionnaires Python, comme illustré dans l’exemple de code.
Vous pouvez également transmettre des données à votre fonction sous forme de tableau JSON ou de n’importe quel autre type de données JSON valide. Le tableau suivant définit la manière dont le moteur d’exécution Python convertit ces types JSON.
| Type de données JSON | Type de données Python |
| --- | --- |
| objet | dictionnaire (dict) |
| array | liste (list) |
| nombre | entier (int) ou nombre à virgule flottante (float) |
| chaîne | chaîne (str) |
| Booléen | Booléen (bool) |
| null | sans type (NoneType) |
## Accès et utilisation de l’objet de contexte Lambda
L’objet de contexte Lambda contient des informations sur la fonction, l’invocation et l’environnement d’exécution. Lambda transmet automatiquement l’objet de contexte à votre fonction lors de son invocation. Vous pouvez utiliser l'objet de contexte pour générer des informations sur l'invocation de votre fonction à des fins de surveillance.
L’objet de contexte est une classe Python définie dans le [client d’interface d’environnement d’exécution Lambda](https://github.com/aws/aws-lambda-python-runtime-interface-client/blob/main/awslambdaric/lambda_context.py). Pour renvoyer la valeur de l’une des propriétés de l’objet de contexte, utilisez la méthode correspondante sur l’objet de contexte. Par exemple, l’extrait de code suivant attribue la valeur de la propriété `aws_request_id` (l’identifiant de la demande d’invocation) à une variable nommée `request`.
```
request = context.aws_request_id
```
Pour en savoir plus sur l’utilisation de l’objet de contexte Lambda et pour consulter la liste complète des méthodes et propriétés disponibles, consultez [Utilisation de l’objet de contexte Lambda pour récupérer les informations de la fonction Python](python-context.md).
## Signatures de gestionnaire valides pour les gestionnaires Python
Lorsque vous définissez votre fonction de gestionnaire en Python, la fonction doit prendre deux arguments. Le premier de ces arguments est l’[objet d’événement](#python-handler-event) Lambda, et le second est l’[objet de contexte](#python-handler-context) Lambda. Par convention, ces arguments d’entrée sont généralement nommés `event` et `context`, mais vous pouvez leur donner le nom que vous souhaitez. Si vous déclarez votre fonction de gestionnaire avec un seul argument d’entrée, Lambda générera une erreur lorsqu’il tentera d’exécuter votre fonction. La méthode la plus courante pour déclarer une fonction de gestionnaire en Python est la suivante :
```
def lambda_handler(event, context):
```
Vous pouvez également utiliser des indications de type Python dans votre déclaration de fonction, comme illustré dans l’exemple suivant :
```
from typing import Dict, Any
def lambda_handler(event: Dict[str, Any], context: Any) -> Dict[str, Any]:
```
Pour utiliser un typage AWS spécifique pour les événements générés par d’autres Services AWS et pour l’objet de contexte, ajoutez le package `aws-lambda-typing` au package de déploiement de votre fonction. Vous pouvez installer cette bibliothèque dans votre environnement de développement en exécutant `pip install aws-lambda-typing`. L’exemple de code suivant vous montre comment utiliser des indications de type spécifiques à AWS. Dans cet exemple, l’événement attendu est un événement Amazon S3.
```
from aws_lambda_typing.events import S3Event
from aws_lambda_typing.context import Context
from typing import Dict, Any
def lambda_handler(event: S3Event, context: Context) -> Dict[str, Any]:
```
Vous ne pouvez pas utiliser le type de fonction `async` Python pour votre fonction de gestionnaire.
## Renvoi d’une valeur
Un gestionnaire peut renvoyer une valeur, qui doit être sérialisable en JSON. Les types de retour les plus courants comprennent `dict`, `list`, `str`, `int`, `float` et `bool`.
Ce qu’il advient de la valeur renvoyée dépend du [type d’invocation](lambda-invocation.md) et du [service](lambda-services.md) qui a invoqué la fonction. Par exemple :
+ Si vous utilisez le type d’invocation `RequestResponse` pour [invoquer une fonction Lambda de façon asynchrone](invocation-sync.md), Lambda renvoie le résultat de l’appel de la fonction Python au client qui invoque la fonction Lambda (dans la réponse HTTP à la demande d’invocation, sérialisée dans le JSON). Par exemple, la console AWS Lambda utilise le type d’invocation `RequestResponse`. Dès lors, lorsque vous invoquez la fonction par le biais de la console, cette dernière affiche la valeur renvoyée.
+ Si le gestionnaire renvoie des objets qui ne peuvent pas être sérialisées par `json.dumps`, le runtime renvoie une erreur.
+ Si le gestionnaire renvoie `None`, comme le font implicitement les fonctions Python sans une instruction `return`, le runtime renvoie `null`.
+ Si vous exécutez le type d’invocation `Event` (une [invocation asynchrone](invocation-async.md)), la valeur sera ignorée.
Dans l’exemple de code, le gestionnaire renvoie le dictionnaire Python suivant :
```
{
"statusCode": 200,
"message": "Receipt processed successfully"
}
```
L’environnement d’exécution Lambda sérialise ce dictionnaire et le renvoie au client qui a invoqué la fonction sous forme de chaîne JSON.
**Note**
Dans Python 3.9 et les versions ultérieures, Lambda inclut le requestId de l’invocation dans la réponse d’erreur.
## Utilisation d’AWS SDK pour Python (Boto3) dans votre gestionnaire
Vous utiliserez souvent les fonctions Lambda pour interagir avec d’autres ressources et Services AWS. Le moyen le plus simple d’interagir avec ces ressources est d’utiliser AWS SDK pour Python (Boto3). Tous les [environnements d’exécution Python Lambda pris en charge](lambda-runtimes.md#runtimes-supported) incluent une version du SDK pour Python. Toutefois, nous vous recommandons vivement d’inclure le SDK dans le package de déploiement de votre fonction si votre code doit l’utiliser. L’inclusion du SDK dans votre package de déploiement vous permet de contrôler totalement vos dépendances et de réduire le risque de problèmes de désalignement des versions avec les autres bibliothèques. Pour en savoir plus, consultez [Dépendances d’exécution dans Python](python-package.md#python-package-dependencies) et [Rétrocompatibilité](runtimes-update.md#runtime-update-compatibility).
Pour utiliser le SDK pour Python dans votre fonction Lambda, ajoutez l’instruction suivante au bloc import au début du code de votre fonction :
```
import boto3
```
Utilisez la commande `pip install` pour ajouter la bibliothèque `boto3` au package de déploiement de votre fonction. Pour des instructions détaillées sur l’ajout de dépendances à un package de déploiement .zip, consultez [Création d’un package de déploiement .zip avec dépendances](python-package.md#python-package-create-dependencies). Pour en savoir plus sur l’ajout de dépendances aux fonctions Lambda déployées sous forme d’images de conteneur, consultez [Création d’une image à partir d’une image de base](python-image.md#python-image-create) ou [Création d’une image à partir d’une image de base alternative](python-image.md#python-alt-create).
Lorsque vous utilisez `boto3` dans votre code, vous n’avez pas besoin de fournir des informations d’identification pour initialiser un client. Par exemple, dans l’exemple de code, nous utilisons la ligne de code suivante pour initialiser un client Amazon S3 :
```
# Initialize the S3 client outside of the handler
s3_client = boto3.client('s3')
```
Avec Python, Lambda crée automatiquement des variables d’environnement avec des informations d’identification. Le SDK `boto3` vérifie la présence de ces informations d’identification dans les variables d’environnement de votre fonction lors de l’initialisation.
## Accès aux variables d’environnement
Dans le code de votre gestionnaire, vous pouvez référencer les [variables d’environnement](configuration-envvars.md) à l’aide de la méthode `os.environ.get`. Dans l’exemple de code, nous référençons la variable d’environnement `RECEIPT_BUCKET` définie à l’aide de la ligne de code suivante :
```
# Access environment variables
bucket_name = os.environ.get('RECEIPT_BUCKET')
```
N’oubliez pas d’inclure une instruction `import os` dans le bloc import au début de votre code.
## Pratiques exemplaires en matière de code pour les fonctions Lambda Python
Respectez les directives de la liste suivante pour utiliser les pratiques exemplaires de codage lors de la création de vos fonctions Lambda :
+ **Séparez le gestionnaire Lambda de votre logique principale.** Cela vous permet de créer une fonction testable plus unitaire. Par exemple, en Python, vous pouvez observer ce qui suit :
```
def lambda_handler(event, context):
foo = event['foo']
bar = event['bar']
result = my_lambda_function(foo, bar)
def my_lambda_function(foo, bar):
// MyLambdaFunction logic here
```
+ **Contrôlez les dépendances du package de déploiement de vos fonctions.** L’environnement d’exécution AWS Lambda contient un certain nombre de bibliothèques. Pour les environnements d’exécution Node.js et Python, ceux-ci incluent les kits SDK AWS. Pour activer le dernier ensemble de mises à jour des fonctionnalités et de la sécurité, Lambda met régulièrement à jour ces bibliothèques. Ces mises à jour peuvent introduire de subtiles modifications dans le comportement de votre fonction Lambda. Pour disposer du contrôle total des dépendances que votre fonction utilise, empaquetez toutes vos dépendances avec votre package de déploiement.
+ **Réduisez la complexité de vos dépendances.** Privilégiez les infrastructures plus simples qui se chargent rapidement au démarrage de l’[environnement d’exécution](lambda-runtime-environment.md).
+ **Réduisez la taille de votre package de déploiement selon ses besoins relatifs à l’environnement d’exécution. ** Cela contribue à réduire le temps nécessaire au téléchargement et à la décompression de votre package de déploiement avant l'invocation.
**Tirez parti de la réutilisation de l’environnement d’exécution pour améliorer les performances de votre fonction.** Initialisez les clients SDK et les connexions à la base de données en dehors du gestionnaire de fonctions et mettez en cache les actifs statiques localement dans le répertoire `/tmp`. Les invocations ultérieures traitées par la même instance de votre fonction peuvent réutiliser ces ressources. Cela permet d’économiser des coûts, tout en réduisant le temps d’exécution de la fonction.
Pour éviter des éventuelles fuites de données entre les invocations, n’utilisez pas l’environnement d’exécution pour stocker des données utilisateur, des événements ou d’autres informations ayant un impact sur la sécurité. Si votre fonction repose sur un état réversible qui ne peut pas être stocké en mémoire dans le gestionnaire, envisagez de créer une fonction distincte ou des versions distinctes d’une fonction pour chaque utilisateur.
**Utilisez une directive keep-alive pour maintenir les connexions persistantes.** Lambda purge les connexions inactives au fil du temps. Si vous tentez de réutiliser une connexion inactive lorsque vous invoquez une fonction, cela entraîne une erreur de connexion. Pour maintenir votre connexion persistante, utilisez la directive Keep-alive associée à votre environnement d’exécution. Pour obtenir un exemple, consultez [Réutilisation des connexions avec Keep-Alive dans Node.js](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/node-reusing-connections.html).
**Utilisez des [variables d’environnement](configuration-envvars.md) pour transmettre des paramètres opérationnels à votre fonction.** Par exemple, si vous écrivez dans un compartiment Amazon S3 au lieu de coder en dur le nom du compartiment dans lequel vous écrivez, configurez le nom du compartiment comme variable d’environnement.
**Évitez d’utiliser des invocations récursives** dans votre fonction Lambda, lorsque la fonction s’invoque elle-même ou démarre un processus susceptible de l’invoquer à nouveau. Cela peut entraîner un volume involontaire d’invocations de fonction et des coûts accrus. Si vous constatez un volume involontaire d’invocations, définissez immédiatement la simultanéité réservée à la fonction sur `0` afin de limiter toutes les invocations de la fonction, pendant que vous mettez à jour le code.
**N’utilisez pas d’API non publiques non documentées** dans le code de votre fonction Lambda. Pour les exécutions gérées AWS Lambda, Lambda applique périodiquement des mises à jour de sécurité et fonctionnelles aux API internes de Lambda. Ces mises à jour internes de l’API peuvent être incompatibles avec les versions antérieures, entraînant des conséquences imprévues telles que des échecs d’invocation si votre fonction dépend de ces API non publiques. Consultez la [Référence d’API](https://docs.aws.amazon.com/lambda/latest/api/welcome.html) pour obtenir la liste des API accessibles au public.
**Écriture du code idempotent.** L’écriture de code idempotent pour vos fonctions garantit ne gestion identique des événements dupliqués. Votre code doit valider correctement les événements et gérer correctement les événements dupliqués. Pour de plus amples informations, veuillez consulter[Comment faire en sorte que ma fonction Lambda soit idempotente ?](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-function-idempotent/).
# Travailler avec des archives de fichiers .zip pour les fonctions Lambda Python
Le code de votre AWS Lambda fonction comprend un fichier .py contenant le code du gestionnaire de votre fonction, ainsi que les packages et modules supplémentaires dont dépend votre code. Pour déployer ce code de fonction vers Lambda, vous utilisez un *package de déploiement*. Ce package peut être une archive de fichier .zip ou une image de conteneur. Pour plus d’informations sur l’utilisation d’images de conteneur avec Python, consultez la page [Déployer des fonctions Lambda Python avec des images de conteneur](https://docs.aws.amazon.com/lambda/latest/dg/python-image.html).
Pour créer votre package de déploiement sous forme d’archive de fichier .zip, vous pouvez utiliser l’utilitaire d’archivage .zip intégré à votre outil de ligne de commande, ou tout autre utilitaire .zip tel que [7zip](https://www.7-zip.org/download.html). Les exemples présentés dans les sections suivantes supposent que vous utilisez un outil `zip` de ligne de commande dans un environnement Linux ou macOS. Pour utiliser les mêmes commandes sous Windows, vous pouvez [installer 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 de Bash.
Notez que Lambda utilise les autorisations de fichiers POSIX. Ainsi, vous pourriez devoir [définir des autorisations pour le dossier du package de déploiement](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-deployment-package-errors/) avant de créer l’archive de fichiers .zip.
**Topics**
+ [Dépendances d’exécution dans Python](#python-package-dependencies)
+ [Création d’un package de déploiement .zip sans dépendances](#python-package-create-no-dependencies)
+ [Création d’un package de déploiement .zip avec dépendances](#python-package-create-dependencies)
+ [Chemin de recherche des dépendances et bibliothèques incluses dans l’exécution](#python-package-searchpath)
+ [Utilisation des dossiers \$1\$1pycache\$1\$1](#python-package-pycache)
+ [Création de packages de déploiement .zip avec des bibliothèques natives](#python-package-native-libraries)
+ [Création et mise à jour de fonctions Lambda Python à l’aide de fichiers .zip](#python-package-create-update)
## Dépendances d’exécution dans Python
Pour les fonctions Lambda qui utilisent l’exécution Python, une dépendance peut être n’importe quel package ou module Python. Lorsque vous déployez votre fonction à l’aide d’une archive .zip, vous pouvez soit ajouter ces dépendances à votre fichier .zip avec votre code de fonction, soit utiliser une [couche Lambda](chapter-layers.md). Une couche est un fichier .zip séparé qui peut contenir du code supplémentaire et d’autres contenus. Pour en savoir plus sur l’utilisation des couches Lambda dans Python, consultez [Utilisation de couches pour les fonctions Lambda Python](python-layers.md).
Les environnements d'exécution Lambda Python incluent le AWS SDK pour Python (Boto3) et ses dépendances. Lambda fournit le kit SDK dans l’environnement d’exécution pour les scénarios de déploiement où vous n’êtes pas en mesure d’ajouter vos propres dépendances. Ces scénarios incluent la création de fonctions dans la console à l'aide de l'éditeur de code intégré ou à l'utilisation de fonctions intégrées dans AWS Serverless Application Model (AWS SAM) ou de CloudFormation modèles.
Lambda met régulièrement à jour les bibliothèques d’exécution Python afin d’inclure les dernières mises à jour et correctifs de sécurité. Si votre fonction utilise la version du kit SDK Boto3 incluse dans l’exécution, mais que votre package de déploiement inclut des dépendances du kit SDK, cela peut entraîner des problèmes d’alignement de versions. Par exemple, votre package de déploiement peut inclure la dépendance du kit SDK urllib3. Lorsque Lambda met à jour le kit SDK dans l’exécution, des problèmes de compatibilité entre la nouvelle version de l’exécution et la version d’urllib3 de votre package de déploiement peuvent faire échouer votre fonction.
**Important**
Pour conserver un contrôle total sur vos dépendances et éviter d’éventuels problèmes d’alignement de versions, nous vous recommandons d’ajouter toutes les dépendances de votre fonction à votre package de déploiement, même si des versions de celles-ci sont incluses dans l’exécution Lambda. Cela inclut le kit SDK Boto3.
Pour savoir quelle version du kit SDK pour Python (Boto3) est incluse dans l’environnement d’exécution que vous utilisez, consultez [Versions du SDK incluses dans l’environnement d’exécution](lambda-python.md#python-sdk-included).
Dans le cadre du [modèle de responsabilité partagée AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/shared-responsibility-model.html), vous êtes responsable de la gestion de toutes les dépendances dans les packages de déploiement de vos fonctions. Cela inclut l’application de mises à jour et de correctifs de sécurité. Pour mettre à jour les dépendances dans le package de déploiement de votre fonction, créez d’abord un nouveau fichier .zip, puis chargez-le sur Lambda. Pour plus d’informations, consultez [Création d’un package de déploiement .zip avec dépendances](#python-package-create-dependencies) et [Création et mise à jour de fonctions Lambda Python à l’aide de fichiers .zip](#python-package-create-update).
## Création d’un package de déploiement .zip sans dépendances
Si le code de votre fonction ne comporte aucune dépendance, votre fichier .zip contient uniquement le fichier .py contenant le code du gestionnaire de votre fonction. Utilisez votre utilitaire zip préféré pour créer un fichier .zip avec votre fichier .py à la racine. Si le fichier .py ne se trouve pas à la racine de votre fichier .zip, Lambda ne sera pas en mesure d’exécuter votre code.
Pour savoir comment déployer votre fichier .zip pour créer une nouvelle fonction Lambda ou mettre à jour une fonction Lambda existante, veuillez consulter la rubrique [Création et mise à jour de fonctions Lambda Python à l’aide de fichiers .zip](#python-package-create-update).
## Création d’un package de déploiement .zip avec dépendances
Si votre code de fonction dépend de packages ou de modules supplémentaires, vous pouvez soit ajouter ces dépendances à votre fichier .zip avec votre code de fonction, soit [utiliser une couche Lambda](python-layers.md). Les instructions de cette section vous indiquent comment inclure vos dépendances dans votre package de déploiement .zip. Pour que Lambda puisse exécuter votre code, le fichier .py contenant le code de votre gestionnaire et toutes les dépendances de votre fonction doit être installé à la racine du fichier .zip.
Supposons que votre code de fonction soit enregistré dans un fichier nommé `lambda_function.py`. L’exemple de commandes d’interface de ligne de commande suivant crée un fichier .zip nommé `my_deployment_package.zip` contenant le code de votre fonction et ses dépendances. Vous pouvez soit installer vos dépendances directement dans un dossier du répertoire de votre projet, soit utiliser un environnement virtuel Python.
**Pour créer le package de déploiement (répertoire du projet)**
1. Accédez au répertoire du projet qui contient votre fichier de code source `lambda_function.py`. Dans cet exemple, le répertoire est nommé `my_function`.
```
cd my_function
```
1. Créez un nouveau répertoire nommé « package » dans lequel vous installerez vos dépendances.
```
mkdir package
```
Notez que pour un package de déploiement .zip, Lambda s’attend à ce que votre code source et ses dépendances se trouvent tous à la racine du fichier .zip. Toutefois, l’installation de dépendances directement dans le répertoire de votre projet peut introduire un grand nombre de nouveaux fichiers et dossiers et rendre la navigation dans votre IDE difficile. Vous créez ici un répertoire `package` distinct pour séparer vos dépendances de votre code source.
1. Installez les dépendances dans le répertoire `package`. L’exemple ci-dessous installe le kit SDK Boto3 à partir de l’index du Python Package Index à l’aide de pip. Si le code de votre fonction utilise des packages Python que vous avez créés vous-même, enregistrez-les dans le répertoire `package`.
```
pip install --target ./package boto3
```
1. Créez un fichier .zip avec les bibliothèques installées à la racine.
```
cd package
zip -r ../my_deployment_package.zip .
```
Cela génère un fichier `my_deployment_package.zip` dans votre répertoire de projet.
1. Ajoutez le fichier lambda\$1function.py à la racine du fichier .zip.
```
cd ..
zip my_deployment_package.zip lambda_function.py
```
Votre fichier .zip doit avoir une structure de répertoires horizontale, avec le code du gestionnaire de votre fonction et tous vos dossiers de dépendances installés à la racine comme suit.
```
my_deployment_package.zip
|- bin
| |-jp.py
|- boto3
| |-compat.py
| |-data
| |-docs
...
|- lambda_function.py
```
Si le fichier .py contenant le code du gestionnaire de votre fonction ne se trouve pas à la racine de votre fichier .zip, Lambda ne sera pas en mesure d’exécuter votre code.
**Pour créer le package de déploiement (environnement virtuel)**
1. Créez et activez un environnement virtuel dans le répertoire de votre projet. Dans cet exemple, le répertoire du projet est nommé `my_function`.
```
~$ cd my_function
~/my_function$ python3.14 -m venv my_virtual_env
~/my_function$ source ./my_virtual_env/bin/activate
```
1. Installez les bibliothèques requises à l’aide de pip. L’exemple suivant permet d’installer le kit SDK Boto3
```
(my_virtual_env) ~/my_function$ pip install boto3
```
1. Utilisez `pip show` pour trouver l’emplacement dans votre environnement virtuel où pip a installé vos dépendances.
```
(my_virtual_env) ~/my_function$ pip show
```
Le dossier dans lequel pip installe vos bibliothèques peut être nommé `site-packages` ou `dist-packages`. Ce dossier peut se trouver dans le répertoire `lib/python3.x` ou `lib64/python3.x` (où python3.x représente la version de Python que vous utilisez).
1. Désactivation de l’environnement virtuel
```
(my_virtual_env) ~/my_function$ deactivate
```
1. Accédez au répertoire contenant les dépendances que vous avez installées avec pip et créez un fichier .zip dans le répertoire de votre projet avec les dépendances installées à la racine. Dans cet exemple, pip a installé vos dépendances dans le répertoire `my_virtual_env/lib/python3.14/site-packages`.
```
~/my_function$ cd my_virtual_env/lib/python3.14/site-packages
~/my_function/my_virtual_env/lib/python3.14/site-packages$ zip -r ../../../../my_deployment_package.zip .
```
1. Accédez à la racine du répertoire de votre projet où se trouve le fichier .py contenant le code de votre gestionnaire et ajoutez ce fichier à la racine de votre package .zip. Dans cet exemple, votre fichier de code de fonction est nommé `lambda_function.py`.
```
~/my_function/my_virtual_env/lib/python3.14/site-packages$ cd ../../../../
~/my_function$ zip my_deployment_package.zip lambda_function.py
```
## Chemin de recherche des dépendances et bibliothèques incluses dans l’exécution
Lorsque vous utilisez une instruction `import` dans votre code, l’exécution Python recherche les répertoires dans son chemin de recherche jusqu’à ce qu’elle trouve le module ou le package. Par défaut, le premier emplacement dans lequel recherche l’exécution est le répertoire dans lequel votre package de déploiement .zip est décompressé et monté (`/var/task`). Si vous ajoutez une version d’une bibliothèque incluse dans l’exécution dans votre package de déploiement, votre version aura la priorité sur la version incluse dans l’exécution. Les dépendances de votre package de déploiement ont également la priorité sur les dépendances des couches.
Lorsque vous ajoutez une dépendance à une couche, Lambda l’extrait vers `/opt/python/lib/python3.x/site-packages` (où `python3.x` représente la version de l’exécution que vous utilisez) ou `/opt/python`. Dans le chemin de recherche, ces répertoires ont la priorité sur les répertoires contenant les bibliothèques incluses dans l’exécution et les bibliothèques installées par pip (`/var/runtime` et `/var/lang/lib/python3.x/site-packages`). Les bibliothèques des couches de fonctions ont donc la priorité sur les versions incluses dans l’exécution.
**Note**
Dans le runtime géré et l'image de base de Python 3.11, le AWS SDK et ses dépendances sont installés dans le `/var/lang/lib/python3.11/site-packages` répertoire.
Vous pouvez voir le chemin de recherche complet de votre fonction Lambda en ajoutant l’extrait de code suivant.
```
import sys
search_path = sys.path
print(search_path)
```
**Note**
Étant donné que les dépendances de votre package de déploiement ou de vos couches sont prioritaires sur les bibliothèques incluses dans l’exécution, cela peut entraîner des problèmes d’alignement de versions si vous incluez une dépendance du kit SDK telle que urllib3 dans votre package sans inclure également le kit SDK. Si vous déployez votre propre version d’une dépendance de Boto3, vous devez également déployer Boto3 en tant que dépendance dans votre package de déploiement. Nous vous recommandons de regrouper toutes les dépendances de votre fonction, même si des versions de celles-ci sont incluses dans l’exécution.
Vous pouvez également ajouter des dépendances dans un dossier distinct au sein de votre package .zip. Par exemple, vous pouvez ajouter une version du kit SDK Boto3 dans un dossier de votre package .zip appelé `common`. Lorsque votre package .zip est décompressé et monté, ce dossier est placé dans le répertoire `/var/task`. Pour utiliser dans votre code une dépendance provenant d’un dossier de votre package de déploiement .zip, utilisez une instruction `import from`. Par exemple, pour utiliser une version de Boto3 provenant d’un dossier nommé `common` dans votre package .zip, utilisez l’instruction suivante.
```
from common import boto3
```
## Utilisation des dossiers \$1\$1pycache\$1\$1
Nous vous recommandons de ne pas inclure de dossiers `__pycache__` dans le package de déploiement de votre fonction. Le bytecode Python compilé sur une machine de génération avec une architecture ou un système d’exploitation différent peut ne pas être compatible avec l’environnement d’exécution Lambda.
## Création de packages de déploiement .zip avec des bibliothèques natives
Si votre fonction utilise uniquement des packages et des modules Python purs, vous pouvez utiliser la commande `pip install` pour installer vos dépendances sur n’importe quelle machine de génération locale et créer votre fichier .zip. De nombreuses bibliothèques Python populaires, y compris NumPy Pandas, ne sont pas du Python pur et contiennent du code écrit en C ou C\$1\$1. Lorsque vous ajoutez des bibliothèques contenant du code C/C\$1\$1 à votre package de déploiement, vous devez créer votre package correctement pour vous assurer qu’il est compatible avec l’environnement d’exécution Lambda.
La plupart des packages disponibles sur le Python Package Index ([PyPI](https://pypi.org/)) sont disponibles sous forme de « wheels » (fichiers .whl). Un fichier .whl est un type de fichier ZIP qui contient une distribution intégrée avec des fichiers binaires précompilés pour un système d’exploitation et une architecture de l’ensemble des instructions particuliers. Pour rendre votre package de déploiement compatible avec Lambda, vous devez installer le fichier wheel pour les systèmes d’exploitation Linux et l’architecture de l’ensemble d’instructions de votre fonction.
Certains packages peuvent uniquement être disponibles en tant que distributions sources. Pour ces packages, vous devez compiler et créer vous-même les composants C/C\$1\$1.
Pour connaître les distributions disponibles pour le package dont vous avez besoin, procédez comme suit :
1. Recherchez le nom du package sur la [page principale du Python Package Index](https://pypi.org/).
1. Choisissez la version du package que vous souhaitez utiliser.
1. Choisissez **Télécharger les fichiers**.
### Utilisation des distributions intégrées (fichiers wheels)
Pour télécharger un fichier wheel compatible avec Lambda, utilisez l’option `--platform` pip.
Si votre fonction Lambda utilise l’architecture de l’ensemble d’instructions **x86\$164**, exécutez la commande `pip install` suivante pour installer un fichier wheel compatible dans votre répertoire `package`. Remplacez `--python 3.x` par la version d’exécution Python que vous utilisez.
```
pip install \
--platform manylinux2014_x86_64 \
--target=package \
--implementation cp \
--python-version 3.x \
--only-binary=:all: --upgrade \
```
Si votre fonction utilise l’architecture de l’ensemble d’instructions **arm64**, exécutez la commande suivante. Remplacez `--python 3.x` par la version d’exécution Python que vous utilisez.
```
pip install \
--platform manylinux2014_aarch64 \
--target=package \
--implementation cp \
--python-version 3.x \
--only-binary=:all: --upgrade \
```
### Utilisation des distributions sources
Si votre package n’est disponible que sous la forme d’une distribution source, vous devez créer vous-même les bibliothèques C/C\$1\$1. Pour rendre votre package compatible avec l’environnement d’exécution Lambda, vous devez le créer dans un environnement qui utilise le même système d’exploitation Amazon Linux. Pour ce faire, créez votre package dans une instance Linux Amazon Elastic Compute Cloud (Amazon EC2).
Pour savoir comment lancer une instance Amazon EC2 Linux et s'y connecter, consultez la section [Commencer avec Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html) dans le *guide de EC2 l'utilisateur Amazon*.
## Création et mise à jour de fonctions Lambda Python à l’aide de fichiers .zip
Une fois que vous avez créé votre package de déploiement .zip, vous pouvez l’utiliser pour créer une nouvelle fonction Lambda ou mettre à jour une fonction Lambda existante. Vous pouvez déployer votre package .zip à l'aide de la console Lambda, de l'API Lambda et AWS Command Line Interface de l'API Lambda. Vous pouvez également créer et mettre à jour des fonctions Lambda à l’aide de l’ AWS Serverless Application Model (AWS SAM) et de CloudFormation.
La taille maximale d’un package de déploiement .zip pour Lambda est de 250 Mo (décompressé). Notez que cette limite s’applique à la taille combinée de tous les fichiers que vous chargez, y compris les couches Lambda.
Le runtime Lambda a besoin d’une autorisation pour lire les fichiers de votre package de déploiement. Dans la notation octale des autorisations Linux, Lambda a besoin de 644 autorisations pour les fichiers non exécutables (rw-r--r--) et de 755 autorisations () pour les répertoires et les fichiers exécutables. rwxr-xr-x
Sous Linux et macOS, utilisez la commande `chmod` pour modifier les autorisations de fichiers sur les fichiers et les répertoires de votre package de déploiement. Par exemple, pour octroyer à un fichier non exécutable les autorisations correctes, exécutez la commande suivante.
```
chmod 644
```
Pour modifier les autorisations relatives aux fichiers dans Windows, voir [Définir, afficher, modifier ou supprimer des autorisations sur un objet](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731667(v=ws.10)) dans la documentation Microsoft Windows.
**Note**
Si vous n'accordez pas à Lambda les autorisations nécessaires pour accéder aux répertoires de votre package de déploiement, Lambda définit les autorisations pour ces répertoires sur 755 (). rwxr-xr-x
### Création et mise à jour de fonctions avec des fichiers .zip à l’aide de la console
Pour créer une nouvelle fonction, vous devez d’abord créer la fonction dans la console, puis charger votre archive .zip. Pour mettre à jour une fonction existante, ouvrez la page de votre fonction, puis suivez la même procédure pour ajouter votre fichier .zip mis à jour.
Si votre fichier .zip fait moins de 50 Mo, vous pouvez créer ou mettre à jour une fonction en chargeant le fichier directement à partir de votre ordinateur local. Pour les fichiers .zip de plus de 50 Mo, vous devez d’abord charger votre package dans un compartiment Amazon S3. Pour savoir comment charger un fichier dans un compartiment Amazon S3 à l'aide du AWS Management Console, consultez [Getting started with Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html). Pour télécharger des fichiers à l'aide de AWS CLI, voir [Déplacer des objets](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) dans le *guide de AWS CLI l'utilisateur*.
**Note**
Vous ne pouvez pas modifier le [type de package de déploiement](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-PackageType) (.zip ou image de conteneur) d’une fonction existante. Par exemple, vous ne pouvez pas convertir une fonction d’image de conteneur pour utiliser un fichier d’archive .zip à la place. Vous devez créer une nouvelle fonction.
**Pour créer une nouvelle fonction (console)**
1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda et choisissez **Créer une fonction**.
1. Choisissez **Créer à partir de zéro**.
1. Sous **Informations de base**, procédez comme suit :
1. Pour **Nom de la fonction**, saisissez le nom de la fonction.
1. Pour **Exécution**, sélectionnez l’exécution que vous souhaitez utiliser.
1. (Facultatif) Pour **Architecture**, choisissez l’architecture de l’ensemble des instructions pour votre fonction. L’architecture par défaut est x86\$164. Assurez-vous que le package de déploiement .zip pour votre fonction est compatible avec l’architecture de l’ensemble d’instructions que vous sélectionnez.
1. (Facultatif) Sous **Permissions (Autorisations)**, développez **Change default execution role (Modifier le rôle d’exécution par défaut)**. Vous pouvez créer un **rôle d’exécution** ou en utiliser un existant.
1. Choisissez **Créer une fonction**. Lambda crée une fonction de base « Hello world » à l’aide de l’exécution de votre choix.
**Pour charger une archive .zip à partir de votre ordinateur local (console)**
1. Sur la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda, choisissez la fonction pour laquelle vous souhaitez charger le fichier .zip.
1. Sélectionnez l’onglet **Code**.
1. Dans le volet **Source du code**, choisissez **Charger à partir de**.
1. Choisissez **Fichier .zip**.
1. Pour charger un fichier .zip, procédez comme suit :
1. Sélectionnez **Charger**, puis choisissez votre fichier .zip dans le sélecteur de fichiers.
1. Choisissez **Ouvrir**.
1. Choisissez **Enregistrer**.
**Pour charger une archive .zip depuis un compartiment Amazon S3 (console)**
1. Sur la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda, choisissez la fonction pour laquelle vous souhaitez charger un nouveau fichier .zip.
1. Sélectionnez l’onglet **Code**.
1. Dans le volet **Source du code**, choisissez **Charger à partir de**.
1. Choisissez l’**emplacement Amazon S3**.
1. Collez l’URL du lien Amazon S3 de votre fichier .zip et choisissez **Enregistrer**.
### Mise à jour des fonctions du fichier .zip à l’aide de l’éditeur de code de la console
Pour certaines fonctions avec des packages de déploiement .zip, vous pouvez utiliser l’éditeur de code intégré de la console Lambda pour mettre à jour le code de votre fonction directement. Pour utiliser cette fonctionnalité, votre fonction doit répondre aux critères suivants :
+ Votre fonction doit utiliser l’une des exécutions des langages interprétés (Python, Node.js ou Ruby).
+ La taille du package de déploiement de votre fonction doit être inférieure à 50 Mo (décompressé).
Le code des fonctions avec les packages de déploiement d’images de conteneurs ne peut pas être édité directement dans la console.
**Pour mettre à jour le code de fonction à l’aide de l’éditeur de code de la console**
1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda et choisissez votre fonction.
1. Sélectionnez l’onglet **Code**.
1. Dans le volet **Source du code**, sélectionnez votre fichier de code source et modifiez-le dans l’éditeur de code intégré.
1. Dans la section **DÉPLOYER**, choisissez **Déployer** pour mettre à jour le code de votre fonction :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/getting-started-tutorial/deploy-console.png)
### Création et mise à jour de fonctions avec des fichiers .zip à l'aide du AWS CLI
Vous pouvez utiliser l’[AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) pour créer une nouvelle fonction ou pour mettre à jour une fonction existante à l’aide d’un fichier .zip. Utilisez la [fonction de création](https://docs.aws.amazon.com/cli/latest/reference/lambda/create-function.html) et [update-function-code](https://docs.aws.amazon.com/cli/latest/reference/lambda/create-function.html)les commandes pour déployer votre package .zip. Si votre fichier .zip est inférieur à 50 Mo, vous pouvez charger le package .zip à partir d’un emplacement de fichier sur votre machine de génération locale. Pour les fichiers plus volumineux, vous devez charger votre package .zip à partir d’un compartiment Amazon S3. Pour savoir comment charger un fichier dans un compartiment Amazon S3 à l'aide du AWS CLI, consultez la section [Déplacer des objets](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) dans le *guide de AWS CLI l'utilisateur*.
**Note**
Si vous chargez votre fichier .zip depuis un compartiment Amazon S3 à l'aide de AWS CLI, le compartiment doit se trouver au même endroit Région AWS que votre fonction.
Pour créer une nouvelle fonction à l'aide d'un fichier .zip avec le AWS CLI, vous devez spécifier les éléments suivants :
+ Le nom de votre fonction (`--function-name`)
+ L’exécution de votre fonction (`--runtime`)
+ L’Amazon Resource Name (ARN) du [rôle d’exécution](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) de votre fonction (`--role`)
+ Le nom de la méthode du gestionnaire dans votre code de fonction (`--handler`)
Vous devez également indiquer l’emplacement de votre fichier .zip. Si votre fichier .zip se trouve dans un dossier sur votre machine de génération locale, utilisez l’option `--zip-file` pour spécifier le chemin d’accès du fichier, comme le montre l’exemple de commande suivant.
```
aws lambda create-function --function-name myFunction \
--runtime python3.14 --handler lambda_function.lambda_handler \
--role arn:aws:iam::111122223333:role/service-role/my-lambda-role \
--zip-file fileb://myFunction.zip
```
Pour spécifier l’emplacement du fichier .zip dans un compartiment Amazon S3, utilisez l’option `--code` comme le montre l’exemple de commande suivant. Vous devez uniquement utiliser le paramètre `S3ObjectVersion` pour les objets soumis à la gestion des versions.
```
aws lambda create-function --function-name myFunction \
--runtime python3.14 --handler lambda_function.lambda_handler \
--role arn:aws:iam::111122223333:role/service-role/my-lambda-role \
--code S3Bucket=amzn-s3-demo-bucket,S3Key=myFileName.zip,S3ObjectVersion=myObjectVersion
```
Pour mettre à jour une fonction existante à l’aide de l’interface de ligne de commande, vous devez spécifier le nom de votre fonction à l’aide du paramètre `--function-name`. Vous devez également spécifier l’emplacement du fichier .zip que vous souhaitez utiliser pour mettre à jour votre code de fonction. Si votre fichier .zip se trouve dans un dossier sur votre machine de génération locale, utilisez l’option `--zip-file` pour spécifier le chemin d’accès du fichier, comme le montre l’exemple de commande suivant.
```
aws lambda update-function-code --function-name myFunction \
--zip-file fileb://myFunction.zip
```
Pour spécifier l’emplacement du fichier .zip dans un compartiment Amazon S3, utilisez les options `--s3-bucket` et `--s3-key` comme le montre l’exemple de commande suivant. Vous devez uniquement utiliser le paramètre `--s3-object-version` pour les objets soumis à la gestion des versions.
```
aws lambda update-function-code --function-name myFunction \
--s3-bucket amzn-s3-demo-bucket --s3-key myFileName.zip --s3-object-version myObject Version
```
### Création et mise à jour de fonctions avec des fichiers .zip à l’aide de l’API Lambda
Pour créer et mettre à jour des fonctions à l’aide d’une archive de fichiers .zip, utilisez les opérations d’API suivantes :
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)
+ [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html)
### Création et mise à jour de fonctions avec des fichiers .zip à l'aide de AWS SAM
The AWS Serverless Application Model (AWS SAM) est une boîte à outils qui permet de rationaliser le processus de création et d'exécution d'applications sans serveur sur AWS. Vous définissez les ressources de votre application dans un modèle YAML ou JSON et vous utilisez l'interface de ligne de AWS SAM commande (AWS SAM CLI) pour créer, empaqueter et déployer vos applications. Lorsque vous créez une fonction Lambda à partir d'un AWS SAM modèle, elle crée AWS SAM automatiquement un package de déploiement ou une image de conteneur .zip avec le code de votre fonction et les dépendances que vous spécifiez. Pour en savoir plus sur l'utilisation des fonctions Lambda AWS SAM pour créer et déployer des fonctions Lambda, consultez [Getting started with AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-getting-started.html) dans le Guide du *AWS Serverless Application Model développeur*.
Vous pouvez également créer une fonction Lambda AWS SAM à l'aide d'une archive de fichiers .zip existante. Pour créer une fonction Lambda à l'aide de AWS SAM, vous pouvez enregistrer votre fichier .zip dans un compartiment Amazon S3 ou dans un dossier local sur votre machine de génération. Pour savoir comment charger un fichier dans un compartiment Amazon S3 à l'aide du AWS CLI, consultez la section [Déplacer des objets](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) dans le *guide de AWS CLI l'utilisateur*.
Dans votre AWS SAM modèle, la `AWS::Serverless::Function` ressource spécifie votre fonction Lambda. Dans cette ressource, définissez les propriétés suivantes pour créer une fonction à l’aide d’une archive de fichiers .zip :
+ `PackageType` : défini sur `Zip`
+ `CodeUri`- défini sur l'URI Amazon S3, le chemin d'accès au dossier local ou à l'[FunctionCode](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-function-functioncode.html)objet du code de fonction
+ `Runtime` : défini sur votre exécution choisie
Ainsi AWS SAM, si votre fichier .zip est supérieur à 50 Mo, vous n'avez pas besoin de le télécharger au préalable dans un compartiment Amazon S3. AWS SAM peut télécharger des packages .zip jusqu'à la taille maximale autorisée de 250 Mo (décompressés) à partir d'un emplacement sur votre machine de compilation locale.
Pour en savoir plus sur le déploiement de fonctions à l'aide d'un fichier .zip dans AWS SAM, consultez [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)le *manuel du AWS SAM développeur*.
### Création et mise à jour de fonctions avec des fichiers .zip à l'aide de CloudFormation
Vous pouvez l'utiliser CloudFormation pour créer une fonction Lambda à l'aide d'une archive de fichiers .zip. Pour créer une fonction Lambda à partir d’un fichier .zip, vous devez d’abord charger votre fichier dans un compartiment Amazon S3. Pour savoir comment charger un fichier dans un compartiment Amazon S3 à l'aide du AWS CLI, consultez la section [Déplacer des objets](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) dans le *guide de AWS CLI l'utilisateur.*
Pour les environnements d'exécution Node.js et Python, vous pouvez également fournir du code source intégré dans votre CloudFormation modèle. CloudFormation crée ensuite un fichier .zip contenant votre code lorsque vous créez votre fonction.
**Utilisation d’un fichier .zip existant**
Dans votre CloudFormation modèle, la `AWS::Lambda::Function` ressource spécifie votre fonction Lambda. Dans cette ressource, définissez les propriétés suivantes pour créer une fonction à l’aide d’une archive de fichiers .zip :
+ `PackageType` : défini sur `Zip`
+ `Code` : saisissez le nom du compartiment Amazon S3 et le nom du fichier .zip dans les champs `S3Bucket` et `S3Key`
+ `Runtime` : défini sur votre exécution choisie
**Création d’un fichier .zip à partir du code en ligne**
Vous pouvez déclarer des fonctions simples écrites en Python ou en Node.js en ligne dans un CloudFormation modèle. Le code étant intégré dans YAML ou JSON, vous ne pouvez pas ajouter de dépendances externes à votre package de déploiement. Cela signifie que votre fonction doit utiliser la version du AWS SDK incluse dans le runtime. Les exigences du modèle, telles que l’obligation d’échapper certains caractères, rendent également plus difficile l’utilisation des fonctionnalités de vérification syntaxique et de complétion de code de votre IDE. Cela signifie que votre modèle peut nécessiter des tests supplémentaires. En raison de ces limitations, la déclaration de fonctions en ligne convient mieux à un code très simple qui ne change pas fréquemment.
Pour créer un fichier .zip à partir du code en ligne pour les exécutions Node.js et Python, définissez les propriétés suivantes dans la ressource `AWS::Lambda::Function` de votre modèle :
+ `PackageType` : défini sur `Zip`
+ `Code` : saisissez votre code de fonction dans le champ `ZipFile`
+ `Runtime` : défini sur votre exécution choisie
Le fichier .zip CloudFormation généré ne peut pas dépasser 4 Mo. Pour en savoir plus sur le déploiement de fonctions à l'aide d'un fichier .zip dans CloudFormation, consultez [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)le *Guide de l'CloudFormation utilisateur*.
# Déployer des fonctions Lambda en Python avec des images conteneurs
Il existe trois méthodes pour créer une image de conteneur pour une fonction Lambda Python :
+ [Utilisation d'une image AWS de base pour Python](#python-image-instructions)
Les [images de base AWS](images-create.md#runtimes-images-lp) sont préchargées avec une exécution du langage, un client d’interface d’exécution pour gérer l’interaction entre Lambda et votre code de fonction, et un émulateur d’interface d’exécution pour les tests locaux.
+ [Utilisation d'une image de base AWS uniquement pour le système d'exploitation](images-create.md#runtimes-images-provided)
[AWS Les images de base réservées](https://gallery.ecr.aws/lambda/provided) au système d'exploitation contiennent une distribution Amazon Linux et l'émulateur [d'interface d'exécution](https://github.com/aws/aws-lambda-runtime-interface-emulator/). Ces images sont couramment utilisées pour créer des images de conteneur pour les langages compilés, tels que [Go](go-image.md#go-image-provided) et [Rust](lambda-rust.md), et pour une langue ou une version linguistique pour laquelle Lambda ne fournit pas d’image de base, comme Node.js 19. Vous pouvez également utiliser des images de base uniquement pour le système d’exploitation pour implémenter un [environnement d’exécution personnalisé](runtimes-custom.md). Pour rendre l’image compatible avec Lambda, vous devez inclure le [client d’interface d’exécution pour Python](#python-image-clients) dans l’image.
+ [Utilisation d'une image non AWS basique](#python-image-clients)
Vous pouvez utiliser une autre image de base à partir d’un autre registre de conteneur, comme Alpine Linux ou Debian. Vous pouvez également utiliser une image personnalisée créée par votre organisation. Pour rendre l’image compatible avec Lambda, vous devez inclure le [client d’interface d’exécution pour Python](#python-image-clients) dans l’image.
**Astuce**
Pour réduire le temps nécessaire à l’activation des fonctions du conteneur Lambda, consultez [Utiliser des générations en plusieurs étapes](https://docs.docker.com/build/building/multi-stage/) (français non garanti) dans la documentation Docker. Pour créer des images de conteneur efficaces, suivez la section [Bonnes pratiques pour l’écriture de Dockerfiles](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/) (français non garanti).
Cette page explique comment créer, tester et déployer des images de conteneur pour Lambda.
**Topics**
+ [AWS images de base pour Python](#python-image-base)
+ [Utilisation d'une image AWS de base pour Python](#python-image-instructions)
+ [Utilisation d’une autre image de base avec le client d’interface d’exécution](#python-image-clients)
## AWS images de base pour Python
AWS fournit les images de base suivantes pour Python :
| Étiquettes | Environnement d’exécution | Système d’exploitation | Dockerfile | Obsolescence |
| --- | --- | --- | --- | --- |
| 3,14 | Python 3.14 | Amazon Linux 2023 | [Dockerfile pour Python 3.14 sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/python3.14/Dockerfile.python3.14) | 30 juin 2029 |
| 3.13 | Python 3.13 | Amazon Linux 2023 | [Dockerfile pour Python 3.13 sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/python3.13/Dockerfile.python3.13) | 30 juin 2029 |
| 3,12 | Python 3.12 | Amazon Linux 2023 | [Dockerfile pour Python 3.12 sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/python3.12/Dockerfile.python3.12) | 31 octobre 2028 |
| 3,11 | Python 3.11 | Amazon Linux 2 | [Dockerfile pour Python 3.11 sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/python3.11/Dockerfile.python3.11) | 30 juin 2027 |
| 3,10 | Python 3.10 | Amazon Linux 2 | [Dockerfile pour Python 3.10 sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/python3.10/Dockerfile.python3.10) | 31 octobre 2026 |
Référentiel Amazon ECR : [gallery.ecr. aws/lambda/python](https://gallery.ecr.aws/lambda/python)
Les images de base de Python 3.12 et versions ultérieures sont basées sur l’[image de conteneur minimale Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/minimal-container.html). Les images de base Python 3.8-3.11 sont basées sur l'image Amazon Linux 2. AL2023les images basées sur Amazon Linux offrent 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`.
AL2023les images basées sur un lien symbolique sont utilisées `microdnf` comme gestionnaire de packages au lieu de`yum`, qui est le gestionnaire de packages par défaut dans Amazon Linux 2. `dnf` `microdnf`est une implémentation autonome de. `dnf` Pour obtenir la liste des packages inclus dans les images AL2023 basées, reportez-vous aux colonnes **Conteneur minimal** de la section [Comparaison des packages installés sur les images de conteneur Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/al2023-container-image-types.html). Pour plus d'informations sur les différences entre Amazon Linux 2 AL2023 et Amazon, consultez [la section 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.
**Note**
Pour exécuter des images AL2023 basées localement, y compris avec AWS Serverless Application Model (AWS SAM), vous devez utiliser Docker version 20.10.10 ou ultérieure.
### Chemin de recherche des dépendances dans les images de base
Lorsque vous utilisez une instruction `import` dans votre code, l’exécution Python recherche les répertoires dans son chemin de recherche jusqu’à ce qu’elle trouve le module ou le package. Par défaut, l’exécution recherche d’abord dans le répertoire `{LAMBDA_TASK_ROOT}`. Si vous ajoutez une version d’une bibliothèque incluse dans l’exécution dans votre image, votre version aura la priorité sur la version incluse dans l’exécution.
Les autres étapes du chemin de recherche dépendent de la version de l’image de base Lambda pour Python que vous utilisez :
+ **Python 3.11 et versions ultérieures** : Les bibliothèques incluses dans l’exécution et les bibliothèques installées par pip sont installées dans le répertoire `/var/lang/lib/python3.11/site-packages`. Ce répertoire a la priorité sur `/var/runtime` dans le chemin de recherche. Vous pouvez remplacer le kit SDK en utilisant pip pour installer une version plus récente. Vous pouvez utiliser pip pour vérifier que le kit SDK inclus dans l’’exécution et ses dépendances sont compatibles avec tous les packages que vous installez.
+ **Python 3.8-3.10** : Les bibliothèques incluses dans l’exécution sont installées dans le répertoire `/var/runtime`. Les bibliothèques installées par PIP sont installées dans le répertoire `/var/lang/lib/python3.x/site-packages`. Le répertoire `/var/runtime` a la priorité sur `/var/lang/lib/python3.x/site-packages` dans le chemin de recherche.
Vous pouvez voir le chemin de recherche complet de votre fonction Lambda en ajoutant l’extrait de code suivant.
```
import sys
search_path = sys.path
print(search_path)
```
## Utilisation d'une image AWS de base pour Python
### Conditions préalables
Pour exécuter la procédure indiquée dans cette section, vous devez satisfaire aux exigences suivantes :
+ [AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+ [Docker](https://docs.docker.com/get-docker) (version minimale 25.0.0)
+ Le [plug-in buildx](https://github.com/docker/buildx/blob/master/README.md) Docker.
+ Python
### Création d’une image à partir d’une image de base
**Pour créer une image de conteneur à partir d'une image AWS de base pour Python**
1. Créez un répertoire pour le projet, puis passez à ce répertoire.
```
mkdir example
cd example
```
1. Créez un nouveau fichier appelé `lambda_function.py`. Vous pouvez ajouter l’exemple de code de fonction suivant au fichier pour le tester, ou utiliser le vôtre.
**Example Fonction Python**
```
import sys
def handler(event, context):
return 'Hello from AWS Lambda using Python' + sys.version + '!'
```
1. Créez un nouveau fichier appelé `requirements.txt`. Si vous utilisez l’exemple de code de fonction de l’étape précédente, vous pouvez laisser le fichier vide, car il n’y a pas de dépendances. Sinon, répertoriez chaque bibliothèque requise. Par exemple, voici à quoi votre fichier `requirements.txt` doit ressembler si votre fonction utilise AWS SDK pour Python (Boto3) :
**Example requirements.txt**
```
boto3
```
1. Créez un nouveau Dockerfile avec la configuration suivante :
+ Définir la propriété `FROM` sur l’[URI de l’image de base](https://gallery.ecr.aws/lambda/python/).
+ Utilisez la commande COPY pour copier le code de la fonction et les dépendances de l’environnement d’exécution dans `{LAMBDA_TASK_ROOT}`, une [variable d’environnement définie par Lambda](configuration-envvars.md#configuration-envvars-runtime).
+ Définir l’argument `CMD` pour le gestionnaire de la fonction Lambda.
Notez que l’exemple de Dockerfile n’inclut pas d’[instruction USER](https://docs.docker.com/reference/dockerfile/#user). Lorsque vous déployez une image de conteneur sur Lambda, Lambda définit automatiquement un utilisateur Linux par défaut disposant d’autorisations de moindre privilège. Ceci est différent du comportement standard de Docker qui est défini par défaut par l’utilisateur `root` lorsqu’aucune instruction `USER` n’est fournie.
**Example Dockerfile**
```
FROM public.ecr.aws/lambda/python:3.12
# Copy requirements.txt
COPY requirements.txt ${LAMBDA_TASK_ROOT}
# Install the specified packages
RUN pip install -r requirements.txt
# Copy function code
COPY lambda_function.py ${LAMBDA_TASK_ROOT}
# Set the CMD to your handler (could also be done as a parameter override outside of the Dockerfile)
CMD [ "lambda_function.handler" ]
```
1. Générez l’image Docker à l’aide de la commande [docker build](https://docs.docker.com/engine/reference/commandline/build/). L’exemple suivant nomme l’image `docker-image` et lui donne la [balise](https://docs.docker.com/engine/reference/commandline/build/#tag) `test`. Pour rendre votre image compatible avec Lambda, vous devez utiliser l’option `--provenance=false`.
```
docker buildx build --platform linux/amd64 --provenance=false -t docker-image:test .
```
**Note**
La commande spécifie l’option `--platform linux/amd64` pour garantir la compatibilité de votre conteneur avec l’environnement d’exécution Lambda, quelle que soit l’architecture de votre machine de génération. Si vous avez l'intention de créer une fonction Lambda à l'aide de l'architecture du jeu ARM64 d'instructions, veillez à modifier la commande pour utiliser l'`--platform linux/arm64`option à la place.
### (Facultatif) Testez l'image localement
1. Démarrez votre image Docker à l’aide de la commande **docker run**. Dans cet exemple, `docker-image` est le nom de l’image et `test` est la balise.
```
docker run --platform linux/amd64 -p 9000:8080 docker-image:test
```
Cette commande exécute l’image en tant que conteneur et crée un point de terminaison local à `localhost:9000/2015-03-31/functions/function/invocations`.
**Note**
Si vous avez créé l'image Docker pour l'architecture du jeu ARM64 d'instructions, veillez à utiliser l'`--platform linux/arm64`option au lieu de`--platform linux/amd64`.
1. À partir d’une nouvelle fenêtre de terminal, publiez un événement au point de terminaison local.
------
#### [ Linux/macOS ]
Sous Linux et macOS, exécutez la commande `curl` suivante :
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{}'
```
Cette commande invoque la fonction avec un événement vide et renvoie une réponse. Si vous utilisez votre propre code de fonction plutôt que l’exemple de code de fonction, vous pouvez invoquer la fonction avec une charge utile JSON. Exemple :
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{"payload":"hello world!"}'
```
------
#### [ PowerShell ]
Dans PowerShell, exécutez la `Invoke-WebRequest` commande suivante :
```
Invoke-WebRequest -Uri "http://localhost:9000/2015-03-31/functions/function/invocations" -Method Post -Body '{}' -ContentType "application/json"
```
Cette commande invoque la fonction avec un événement vide et renvoie une réponse. Si vous utilisez votre propre code de fonction plutôt que l’exemple de code de fonction, vous pouvez invoquer la fonction avec une charge utile JSON. Exemple :
```
Invoke-WebRequest -Uri "http://localhost:9000/2015-03-31/functions/function/invocations" -Method Post -Body '{"payload":"hello world!"}' -ContentType "application/json"
```
------
1. Obtenez l’ID du conteneur.
```
docker ps
```
1. Utilisez la commande [docker kill](https://docs.docker.com/engine/reference/commandline/kill/) pour arrêter le conteneur. Dans cette commande, remplacez `3766c4ab331c` par l’ID du conteneur de l’étape précédente.
```
docker kill 3766c4ab331c
```
### Déploiement de l’image
**Pour charger l’image sur Amazon RIE et créer la fonction Lambda**
1. Exécutez la [get-login-password](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/get-login-password.html)commande pour authentifier la CLI Docker auprès de votre registre Amazon ECR.
+ Définissez la `--region` valeur à l' Région AWS endroit où vous souhaitez créer le référentiel Amazon ECR.
+ `111122223333`Remplacez-le par votre Compte AWS identifiant.
```
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-east-1.amazonaws.com
```
1. Créez un référentiel dans Amazon ECR à l’aide de la commande [create-repository](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/create-repository.html).
```
aws ecr create-repository --repository-name hello-world --region us-east-1 --image-scanning-configuration scanOnPush=true --image-tag-mutability MUTABLE
```
**Note**
Le référentiel Amazon ECR doit être Région AWS identique à la fonction Lambda.
En cas de succès, vous obtenez une réponse comme celle-ci :
```
{
"repository": {
"repositoryArn": "arn:aws:ecr:us-east-1:111122223333:repository/hello-world",
"registryId": "111122223333",
"repositoryName": "hello-world",
"repositoryUri": "111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world",
"createdAt": "2023-03-09T10:39:01+00:00",
"imageTagMutability": "MUTABLE",
"imageScanningConfiguration": {
"scanOnPush": true
},
"encryptionConfiguration": {
"encryptionType": "AES256"
}
}
}
```
1. Copiez le `repositoryUri` à partir de la sortie de l’étape précédente.
1. Exécutez la commande [docker tag](https://docs.docker.com/engine/reference/commandline/tag/) pour étiqueter votre image locale dans votre référentiel Amazon ECR en tant que dernière version. Dans cette commande :
+ `docker-image:test` est le nom et la [balise](https://docs.docker.com/engine/reference/commandline/build/#tag) de votre image Docker. Il s’agit du nom et de la balise de l’image que vous avez spécifiés dans la commande `docker build`.
+ Remplacez `` par l’`repositoryUri` que vous avez copié. Assurez-vous d’inclure `:latest` à la fin de l’URI.
```
docker tag docker-image:test :latest
```
Exemple :
```
docker tag docker-image:test 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. Exécutez la commande [docker push](https://docs.docker.com/engine/reference/commandline/push/) pour déployer votre image locale dans le référentiel Amazon ECR. Assurez-vous d’inclure `:latest` à la fin de l’URI du référentiel.
```
docker push 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. [Créez un rôle d’exécution](lambda-intro-execution-role.md#permissions-executionrole-api) pour la fonction, si vous n’en avez pas déjà un. Vous aurez besoin de l’Amazon Resource Name (ARN) du rôle à l’étape suivante.
1. Créez la fonction Lambda. Pour `ImageUri`, indiquez l’URI du référentiel mentionné précédemment. Assurez-vous d’inclure `:latest` à la fin de l’URI.
```
aws lambda create-function \
--function-name hello-world \
--package-type Image \
--code ImageUri=111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--role arn:aws:iam::111122223333:role/lambda-ex
```
**Note**
Vous pouvez créer une fonction en utilisant une image d'un autre AWS compte, à condition que l'image se trouve dans la même région que la fonction Lambda. Pour de plus amples informations, veuillez consulter [Autorisations entre comptes Amazon ECR](images-create.md#configuration-images-xaccount-permissions).
1. Invoquer la fonction.
```
aws lambda invoke --function-name hello-world response.json
```
Vous devriez obtenir une réponse comme celle-ci :
```
{
"ExecutedVersion": "$LATEST",
"StatusCode": 200
}
```
1. Pour voir la sortie de la fonction, consultez le fichier `response.json`.
Pour mettre à jour le code de fonction, vous devez créer à nouveau l'image, télécharger la nouvelle image dans le référentiel Amazon ECR, puis utiliser la [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)commande pour déployer l'image sur la fonction Lambda.
Lambda résout l’étiquette d’image en hachage d’image spécifique. Cela signifie que si vous pointez la balise d’image qui a été utilisée pour déployer la fonction vers une nouvelle image dans Amazon ECR, Lambda ne met pas automatiquement à jour la fonction pour utiliser la nouvelle image.
Pour déployer la nouvelle image sur la même fonction Lambda, vous devez utiliser la [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)commande, même si la balise d'image dans Amazon ECR reste la même. Dans l’exemple suivant, l’option `--publish` crée une version de la fonction à l’aide de l’image du conteneur mise à jour.
```
aws lambda update-function-code \
--function-name hello-world \
--image-uri 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--publish
```
## Utilisation d’une autre image de base avec le client d’interface d’exécution
Si vous utilisez une [image de base uniquement pour le système d’exploitation](images-create.md#runtimes-images-provided) ou une autre image de base, vous devez inclure le client d’interface d’exécution dans votre image. Le client d’interface d’exécution étend le[API de runtime](runtimes-api.md), qui gère l’interaction entre Lambda et votre code de fonction.
Installez le [client d’interface d’exécution pour Python](https://pypi.org/project/awslambdaric) à l’aide du gestionnaire de packages pip :
```
pip install awslambdaric
```
Vous pouvez également télécharger le [client d'interface d'exécution Python](https://github.com/aws/aws-lambda-python-runtime-interface-client/) depuis GitHub.
L'exemple suivant montre comment créer une image de conteneur pour Python à l'aide d'une image non AWS basique. L’exemple Dockerfile utilise une image de base Python officielle. Le Dockerfile inclut le client d’interface d’exécution pour Python.
### Conditions préalables
Pour exécuter la procédure indiquée dans cette section, vous devez satisfaire aux exigences suivantes :
+ [AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+ [Docker](https://docs.docker.com/get-docker) (version minimale 25.0.0)
+ Le [plug-in buildx](https://github.com/docker/buildx/blob/master/README.md) Docker.
+ Python
### Création d’une image à partir d’une image de base alternative
**Pour créer une image de conteneur à partir d'une image non AWS basique**
1. Créez un répertoire pour le projet, puis passez à ce répertoire.
```
mkdir example
cd example
```
1. Créez un nouveau fichier appelé `lambda_function.py`. Vous pouvez ajouter l’exemple de code de fonction suivant au fichier pour le tester, ou utiliser le vôtre.
**Example Fonction Python**
```
import sys
def handler(event, context):
return 'Hello from AWS Lambda using Python' + sys.version + '!'
```
1. Créez un nouveau fichier appelé `requirements.txt`. Si vous utilisez l’exemple de code de fonction de l’étape précédente, vous pouvez laisser le fichier vide, car il n’y a pas de dépendances. Sinon, répertoriez chaque bibliothèque requise. Par exemple, voici à quoi votre fichier `requirements.txt` doit ressembler si votre fonction utilise AWS SDK pour Python (Boto3) :
**Example requirements.txt**
```
boto3
```
1. Créez un nouveau fichier Docker. Le Dockerfile suivant utilise une image de base Python officielle au lieu d’une [image de base AWS](images-create.md#runtimes-images-lp). Le Dockerfile inclut le [client d’interface d’exécution](https://pypi.org/project/awslambdaric), ce qui rend l’image compatible avec Lambda. L’exemple de fichier Docker suivant utilise une [génération en plusieurs étapes](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#use-multi-stage-builds).
+ Définissez la propriété `FROM` sur l’image de base.
+ Définissez le `ENTRYPOINT` sur le module que vous souhaitez que le conteneur Docker exécute lorsqu’il démarre. Dans ce cas, le module est le client d’interface d’exécution.
+ Définissez le `CMD` sur le gestionnaire de la fonction Lambda.
Notez que l’exemple de Dockerfile n’inclut pas d’[instruction USER](https://docs.docker.com/reference/dockerfile/#user). Lorsque vous déployez une image de conteneur sur Lambda, Lambda définit automatiquement un utilisateur Linux par défaut disposant d’autorisations de moindre privilège. Ceci est différent du comportement standard de Docker qui est défini par défaut par l’utilisateur `root` lorsqu’aucune instruction `USER` n’est fournie.
**Example Dockerfile**
```
# Define custom function directory
ARG FUNCTION_DIR="/function"
FROM python:3.12 AS build-image
# Include global arg in this stage of the build
ARG FUNCTION_DIR
# Copy function code
RUN mkdir -p ${FUNCTION_DIR}
COPY . ${FUNCTION_DIR}
# Install the function's dependencies
RUN pip install \
--target ${FUNCTION_DIR} \
awslambdaric
# Use a slim version of the base Python image to reduce the final image size
FROM python:3.12-slim
# Include global arg in this stage of the build
ARG FUNCTION_DIR
# Set working directory to function root directory
WORKDIR ${FUNCTION_DIR}
# Copy in the built dependencies
COPY --from=build-image ${FUNCTION_DIR} ${FUNCTION_DIR}
# Set runtime interface client as default command for the container runtime
ENTRYPOINT [ "/usr/local/bin/python", "-m", "awslambdaric" ]
# Pass the name of the function handler as an argument to the runtime
CMD [ "lambda_function.handler" ]
```
1. Générez l’image Docker à l’aide de la commande [docker build](https://docs.docker.com/engine/reference/commandline/build/). L’exemple suivant nomme l’image `docker-image` et lui donne la [balise](https://docs.docker.com/engine/reference/commandline/build/#tag) `test`. Pour rendre votre image compatible avec Lambda, vous devez utiliser l’option `--provenance=false`.
```
docker buildx build --platform linux/amd64 --provenance=false -t docker-image:test .
```
**Note**
La commande spécifie l’option `--platform linux/amd64` pour garantir la compatibilité de votre conteneur avec l’environnement d’exécution Lambda, quelle que soit l’architecture de votre machine de génération. Si vous avez l'intention de créer une fonction Lambda à l'aide de l'architecture du jeu ARM64 d'instructions, veillez à modifier la commande pour utiliser l'`--platform linux/arm64`option à la place.
### (Facultatif) Testez l’image localement
Utilisez l’[émulateur d’interface d’exécution](https://github.com/aws/aws-lambda-runtime-interface-emulator/) pour tester l’image localement. Vous pouvez [intégrer l’émulateur dans votre image](https://github.com/aws/aws-lambda-runtime-interface-emulator/?tab=readme-ov-file#build-rie-into-your-base-image) ou utiliser la procédure suivante pour l’installer sur votre machine locale.
**Pour installer et exécuter l’émulateur d’interface d’exécution sur votre ordinateur local**
1. Depuis le répertoire de votre projet, exécutez la commande suivante pour télécharger l'émulateur d'interface d'exécution (architecture x86-64) GitHub et l'installer sur votre machine locale.
------
#### [ Linux/macOS ]
```
mkdir -p ~/.aws-lambda-rie && \
curl -Lo ~/.aws-lambda-rie/aws-lambda-rie https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie && \
chmod +x ~/.aws-lambda-rie/aws-lambda-rie
```
Pour installer l'émulateur arm64, remplacez l'URL du GitHub référentiel dans la commande précédente par la suivante :
```
https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie-arm64
```
------
#### [ PowerShell ]
```
$dirPath = "$HOME\.aws-lambda-rie"
if (-not (Test-Path $dirPath)) {
New-Item -Path $dirPath -ItemType Directory
}
$downloadLink = "https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie"
$destinationPath = "$HOME\.aws-lambda-rie\aws-lambda-rie"
Invoke-WebRequest -Uri $downloadLink -OutFile $destinationPath
```
Pour installer l’émulateur arm64, remplacez `$downloadLink` par ce qui suit :
```
https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie-arm64
```
------
1. Démarrez votre image Docker à l’aide de la commande **docker run**. Notez ce qui suit :
+ `docker-image` est le nom de l’image et `test` est la balise.
+ `/usr/local/bin/python -m awslambdaric lambda_function.handler` est le `ENTRYPOINT` suivi du `CMD` depuis votre Dockerfile.
------
#### [ Linux/macOS ]
```
docker run --platform linux/amd64 -d -v ~/.aws-lambda-rie:/aws-lambda -p 9000:8080 \
--entrypoint /aws-lambda/aws-lambda-rie \
docker-image:test \
/usr/local/bin/python -m awslambdaric lambda_function.handler
```
------
#### [ PowerShell ]
```
docker run --platform linux/amd64 -d -v "$HOME\.aws-lambda-rie:/aws-lambda" -p 9000:8080 `
--entrypoint /aws-lambda/aws-lambda-rie `
docker-image:test `
/usr/local/bin/python -m awslambdaric lambda_function.handler
```
------
Cette commande exécute l’image en tant que conteneur et crée un point de terminaison local à `localhost:9000/2015-03-31/functions/function/invocations`.
**Note**
Si vous avez créé l'image Docker pour l'architecture du jeu ARM64 d'instructions, veillez à utiliser l'`--platform linux/arm64`option au lieu de`--platform linux/amd64`.
1. Publiez un événement au point de terminaison local.
------
#### [ Linux/macOS ]
Sous Linux et macOS, exécutez la commande `curl` suivante :
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{}'
```
Cette commande invoque la fonction avec un événement vide et renvoie une réponse. Si vous utilisez votre propre code de fonction plutôt que l’exemple de code de fonction, vous pouvez invoquer la fonction avec une charge utile JSON. Exemple :
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{"payload":"hello world!"}'
```
------
#### [ PowerShell ]
Dans PowerShell, exécutez la `Invoke-WebRequest` commande suivante :
```
Invoke-WebRequest -Uri "http://localhost:9000/2015-03-31/functions/function/invocations" -Method Post -Body '{}' -ContentType "application/json"
```
Cette commande invoque la fonction avec un événement vide et renvoie une réponse. Si vous utilisez votre propre code de fonction plutôt que l’exemple de code de fonction, vous pouvez invoquer la fonction avec une charge utile JSON. Exemple :
```
Invoke-WebRequest -Uri "http://localhost:9000/2015-03-31/functions/function/invocations" -Method Post -Body '{"payload":"hello world!"}' -ContentType "application/json"
```
------
1. Obtenez l’ID du conteneur.
```
docker ps
```
1. Utilisez la commande [docker kill](https://docs.docker.com/engine/reference/commandline/kill/) pour arrêter le conteneur. Dans cette commande, remplacez `3766c4ab331c` par l’ID du conteneur de l’étape précédente.
```
docker kill 3766c4ab331c
```
### Déploiement de l’image
**Pour charger l’image sur Amazon RIE et créer la fonction Lambda**
1. Exécutez la [get-login-password](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/get-login-password.html)commande pour authentifier la CLI Docker auprès de votre registre Amazon ECR.
+ Définissez la `--region` valeur à l' Région AWS endroit où vous souhaitez créer le référentiel Amazon ECR.
+ `111122223333`Remplacez-le par votre Compte AWS identifiant.
```
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-east-1.amazonaws.com
```
1. Créez un référentiel dans Amazon ECR à l’aide de la commande [create-repository](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/create-repository.html).
```
aws ecr create-repository --repository-name hello-world --region us-east-1 --image-scanning-configuration scanOnPush=true --image-tag-mutability MUTABLE
```
**Note**
Le référentiel Amazon ECR doit être Région AWS identique à la fonction Lambda.
En cas de succès, vous obtenez une réponse comme celle-ci :
```
{
"repository": {
"repositoryArn": "arn:aws:ecr:us-east-1:111122223333:repository/hello-world",
"registryId": "111122223333",
"repositoryName": "hello-world",
"repositoryUri": "111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world",
"createdAt": "2023-03-09T10:39:01+00:00",
"imageTagMutability": "MUTABLE",
"imageScanningConfiguration": {
"scanOnPush": true
},
"encryptionConfiguration": {
"encryptionType": "AES256"
}
}
}
```
1. Copiez le `repositoryUri` à partir de la sortie de l’étape précédente.
1. Exécutez la commande [docker tag](https://docs.docker.com/engine/reference/commandline/tag/) pour étiqueter votre image locale dans votre référentiel Amazon ECR en tant que dernière version. Dans cette commande :
+ `docker-image:test` est le nom et la [balise](https://docs.docker.com/engine/reference/commandline/build/#tag) de votre image Docker. Il s’agit du nom et de la balise de l’image que vous avez spécifiés dans la commande `docker build`.
+ Remplacez `` par l’`repositoryUri` que vous avez copié. Assurez-vous d’inclure `:latest` à la fin de l’URI.
```
docker tag docker-image:test :latest
```
Exemple :
```
docker tag docker-image:test 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. Exécutez la commande [docker push](https://docs.docker.com/engine/reference/commandline/push/) pour déployer votre image locale dans le référentiel Amazon ECR. Assurez-vous d’inclure `:latest` à la fin de l’URI du référentiel.
```
docker push 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. [Créez un rôle d’exécution](lambda-intro-execution-role.md#permissions-executionrole-api) pour la fonction, si vous n’en avez pas déjà un. Vous aurez besoin de l’Amazon Resource Name (ARN) du rôle à l’étape suivante.
1. Créez la fonction Lambda. Pour `ImageUri`, indiquez l’URI du référentiel mentionné précédemment. Assurez-vous d’inclure `:latest` à la fin de l’URI.
```
aws lambda create-function \
--function-name hello-world \
--package-type Image \
--code ImageUri=111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--role arn:aws:iam::111122223333:role/lambda-ex
```
**Note**
Vous pouvez créer une fonction en utilisant une image d'un autre AWS compte, à condition que l'image se trouve dans la même région que la fonction Lambda. Pour de plus amples informations, veuillez consulter [Autorisations entre comptes Amazon ECR](images-create.md#configuration-images-xaccount-permissions).
1. Invoquer la fonction.
```
aws lambda invoke --function-name hello-world response.json
```
Vous devriez obtenir une réponse comme celle-ci :
```
{
"ExecutedVersion": "$LATEST",
"StatusCode": 200
}
```
1. Pour voir la sortie de la fonction, consultez le fichier `response.json`.
Pour mettre à jour le code de fonction, vous devez créer à nouveau l'image, télécharger la nouvelle image dans le référentiel Amazon ECR, puis utiliser la [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)commande pour déployer l'image sur la fonction Lambda.
Lambda résout l’étiquette d’image en hachage d’image spécifique. Cela signifie que si vous pointez la balise d’image qui a été utilisée pour déployer la fonction vers une nouvelle image dans Amazon ECR, Lambda ne met pas automatiquement à jour la fonction pour utiliser la nouvelle image.
Pour déployer la nouvelle image sur la même fonction Lambda, vous devez utiliser la [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)commande, même si la balise d'image dans Amazon ECR reste la même. Dans l’exemple suivant, l’option `--publish` crée une version de la fonction à l’aide de l’image du conteneur mise à jour.
```
aws lambda update-function-code \
--function-name hello-world \
--image-uri 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--publish
```
Pour un exemple de création d’une image Python à partir d’une image de base Alpine, consultez [Prise en charge des images conteneurs pour Lambda](https://aws.amazon.com/blogs/aws/new-for-aws-lambda-container-image-support/) sur le blog AWS .
# Utilisation de couches pour les fonctions Lambda Python
Utilisez les [couches Lambda](chapter-layers.md) pour empaqueter le code et les dépendances que vous souhaitez réutiliser dans plusieurs fonctions. Les couches contiennent généralement des dépendances de bibliothèque, une [exécution personnalisée](runtimes-custom.md), ou des fichiers de configuration. La création d’une couche implique trois étapes générales :
1. Empaquetez le contenu de votre couche. Cela signifie créer une archive de fichiers .zip contenant les dépendances que vous souhaitez utiliser dans vos fonctions.
1. Créez la couche dans Lambda.
1. Ajoutez la couche à vos fonctions.
**Topics**
+ [Empaqueter le contenu de votre couche](#python-layers-package)
+ [Créer la couche dans Lambda](#publishing-layer)
+ [Ajouter la couche à votre fonction](#python-layer-adding)
+ [Exemple d’application](#python-layer-sample-app)
## Empaqueter le contenu de votre couche
Pour créer une couche, regroupez vos packages dans une archive (fichier .zip) répondant aux exigences suivantes :
+ Créez la couche à l’aide de la même version de Python que celle que vous prévoyez d’utiliser pour la fonction Lambda. Par exemple, si vous créez votre couche à l'aide de Python 3.14, utilisez le runtime Python 3.14 pour votre fonction.
+ Votre fichier .zip doit inclure un répertoire `python` au niveau racine.
+ Les packages de votre couche doivent être compatibles avec Linux. Les fonctions Lambda s’exécutent sur Amazon Linux.
Vous pouvez créer des couches contenant des bibliothèques Python tierces installées avec `pip` (comme `requests` ou `pandas`) ou vos propres modules et packages Python.
### Dépendances tierces
**Créer une couche à l’aide de packages pip**
1. Choisissez l’une des méthodes suivantes pour installer les packages `pip` dans le répertoire de niveau supérieur requis (`python/`) :
------
#### [ pip install ]
Pour les packages Python purs (comme requests ou boto3) :
```
pip install requests -t python/
```
Certains packages Python, tels que NumPy Pandas, incluent des composants C compilés. Si vous créez une couche avec ces packages sous macOS ou Windows, vous devrez peut-être utiliser cette commande pour installer un fichier wheel compatible avec Linux :
```
pip install numpy --platform manylinux2014_x86_64 --only-binary=:all: -t python/
```
Pour plus d’informations sur l’utilisation des packages Python contenant des composants compilés, consultez [Création de packages de déploiement .zip avec des bibliothèques natives](python-package.md#python-package-native-libraries).
------
#### [ requirements.txt ]
L’utilisation d’un fichier `requirements.txt` vous permet de gérer les versions des packages et de garantir des installations cohérentes.
**Example requirements.txt**
```
requests==2.31.0
boto3==1.37.34
numpy==1.26.4
```
Si votre fichier `requirements.txt` contient uniquement des packages Python purs (comme requests ou boto3) :
```
pip install -r requirements.txt -t python/
```
Certains packages Python, tels que NumPy Pandas, incluent des composants C compilés. Si vous créez une couche avec ces packages sous macOS ou Windows, vous devrez peut-être utiliser cette commande pour installer un fichier wheel compatible avec Linux :
```
pip install -r requirements.txt --platform manylinux2014_x86_64 --only-binary=:all: -t python/
```
Pour plus d’informations sur l’utilisation des packages Python contenant des composants compilés, consultez [Création de packages de déploiement .zip avec des bibliothèques natives](python-package.md#python-package-native-libraries).
------
1. Compressez le contenu du répertoire `python` dans un fichier .zip.
------
#### [ Linux/macOS ]
```
zip -r layer.zip python/
```
------
#### [ PowerShell ]
```
Compress-Archive -Path .\python -DestinationPath .\layer.zip
```
------
La structure de répertoire de votre fichier .zip devrait se présenter comme suit :
```
python/ # Required top-level directory
└── requests/
└── boto3/
└── numpy/
└── (dependencies of the other packages)
```
**Note**
Si vous utilisez un environnement virtuel Python (venv) pour installer les packages, la structure de votre répertoire sera différente (par exemple, `python/lib/python3.x/site-packages`). Tant que votre fichier .zip inclut le répertoire `python` au niveau racine, Lambda peut localiser et importer vos packages.
### Modules Python personnalisés
**Créer une couche à l’aide de votre propre code**
1. Créez le répertoire de niveau supérieur requis pour votre couche :
```
mkdir python
```
1. Créez vos modules Python dans le répertoire `python`. L’exemple de module suivant valide les commandes en confirmant qu’elles contiennent les informations requises.
**Example module personnalisé : validator.py**
```
import json
def validate_order(order_data):
"""Validates an order and returns formatted data."""
required_fields = ['product_id', 'quantity']
# Check required fields
missing_fields = [field for field in required_fields if field not in order_data]
if missing_fields:
raise ValueError(f"Missing required fields: {', '.join(missing_fields)}")
# Validate quantity
quantity = order_data['quantity']
if not isinstance(quantity, int) or quantity < 1:
raise ValueError("Quantity must be a positive integer")
# Format and return the validated data
return {
'product_id': str(order_data['product_id']),
'quantity': quantity,
'shipping_priority': order_data.get('priority', 'standard')
}
def format_response(status_code, body):
"""Formats the API response."""
return {
'statusCode': status_code,
'body': json.dumps(body)
}
```
1. Compressez le contenu du répertoire `python` dans un fichier .zip.
------
#### [ Linux/macOS ]
```
zip -r layer.zip python/
```
------
#### [ PowerShell ]
```
Compress-Archive -Path .\python -DestinationPath .\layer.zip
```
------
La structure de répertoire de votre fichier .zip devrait se présenter comme suit :
```
python/ # Required top-level directory
└── validator.py
```
1. Dans votre fonction, importez et utilisez les modules comme vous le feriez avec n’importe quel package Python. Exemple :
```
from validator import validate_order, format_response
import json
def lambda_handler(event, context):
try:
# Parse the order data from the event body
order_data = json.loads(event.get('body', '{}'))
# Validate and format the order
validated_order = validate_order(order_data)
return format_response(200, {
'message': 'Order validated successfully',
'order': validated_order
})
except ValueError as e:
return format_response(400, {
'error': str(e)
})
except Exception as e:
return format_response(500, {
'error': 'Internal server error'
})
```
Vous pouvez utiliser l’[événement de test](testing-functions.md#invoke-with-event) suivant afin d’invoquer la fonction :
```
{
"body": "{\"product_id\": \"ABC123\", \"quantity\": 2, \"priority\": \"express\"}"
}
```
Réponse attendue :
```
{
"statusCode": 200,
"body": "{\"message\": \"Order validated successfully\", \"order\": {\"product_id\": \"ABC123\", \"quantity\": 2, \"shipping_priority\": \"express\"}}"
}
```
## Créer la couche dans Lambda
Vous pouvez publier votre couche à l'aide de la console Lambda AWS CLI ou de la console Lambda.
------
#### [ AWS CLI ]
Exécutez la [publish-layer-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-layer-version.html) AWS CLI commande pour créer la couche Lambda :
```
aws lambda publish-layer-version --layer-name my-layer --zip-file fileb://layer.zip --compatible-runtimes python3.14
```
Le paramètre [compatible runtimes](https://docs.aws.amazon.com/lambda/latest/api/API_PublishLayerVersion.html#lambda-PublishLayerVersion-request-CompatibleRuntimes) est facultatif. Lorsqu’il est spécifié, Lambda utilise ce paramètre pour filtrer les couches dans la console Lambda.
------
#### [ Console ]
**Pour créer une couche (console)**
1. Ouvrez la [page Couches](https://console.aws.amazon.com/lambda/home#/layers) de la console Lambda.
1. Sélectionnez **Créer un calque**.
1. Choisissez **Charger un fichier .zip**, puis chargez l’archive .zip que vous avez créée précédemment.
1. (Facultatif) Pour **Exécutions compatibles**, choisissez l’environnement d’exécution Python qui correspond à la version de Python que vous avez utilisée pour créer votre couche.
1. Choisissez **Créer**.
------
## Ajouter la couche à votre fonction
------
#### [ AWS CLI ]
Pour associer la couche à votre fonction, exécutez la [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html) AWS CLI commande. Utilisez l’ARN de la couche pour le paramètre `--layers`. L’ARN doit spécifier la version (par exemple, `arn:aws:lambda:us-east-1:123456789012:layer:my-layer:1`). Pour de plus amples informations, veuillez consulter [Couches et versions de couches](chapter-layers.md#lambda-layer-versions).
```
aws lambda update-function-configuration --function-name my-function --cli-binary-format raw-in-base64-out --layers "arn:aws:lambda:us-east-1:123456789012:layer:my-layer:1"
```
L'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la 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 AWS CLI prises en charge](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*.
------
#### [ Console ]
**Ajouter une couche à une fonction**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez la fonction.
1. Faites défiler jusqu’à la section **Couches**, puis choisissez **Ajouter une couche**.
1. Sous **Choisir une couche**, sélectionnez **Couches personnalisées**, puis choisissez votre couche.
**Note**
Si vous n’avez pas ajouté d’[environnement d’exécution compatible](https://docs.aws.amazon.com/lambda/latest/api/API_PublishLayerVersion.html#lambda-PublishLayerVersion-request-CompatibleRuntimes) lors de la création de la couche, celle-ci ne sera pas répertoriée ici. Vous pouvez spécifier l’ARN de la couche à la place.
1. Choisissez **Ajouter**.
------
## Exemple d’application
Pour d'autres exemples d'utilisation des couches Lambda, consultez l'exemple d'application [layer-python](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/layer-python) dans le référentiel du AWS Lambda Developer Guide. GitHub Cette application inclut deux couches contenant des bibliothèques Python. Après avoir créé les couches, vous pouvez déployer et invoquer les fonctions correspondantes pour vérifier que les couches fonctionnent comme prévu.
# Utilisation de l’objet de contexte Lambda pour récupérer les informations de la fonction Python
Lorsque Lambda exécute votre fonction, il transmet un objet contexte au [gestionnaire](python-handler.md). Cet objet fournit des méthodes et des propriétés fournissant des informations sur l’appel, la fonction et l’environnement d’exécution. Pour en savoir plus sur la façon dont l’objet de contexte est transmis au gestionnaire de fonctions, consultez [Définition du gestionnaire de fonction Lambda en Python](python-handler.md).
**Méthodes de contexte**
+ `get_remaining_time_in_millis` – Renvoie le nombre de millisecondes restant avant l’expiration de l’exécution.
**Propriétés du contexte**
+ `function_name` – Nom de la fonction Lambda.
+ `function_version` – [Version](configuration-versions.md) de la fonction.
+ `invoked_function_arn` – Amazon Resource Name (ARN) utilisé pour appeler la fonction. Indique si l’appelant a spécifié un numéro de version ou un alias.
+ `memory_limit_in_mb` – Quantité de mémoire allouée à la fonction.
+ `aws_request_id` – Identifiant de la demande d’invocation.
+ `log_group_name` – Groupe de journaux pour la fonction.
+ `log_stream_name` – Flux de journal de l’instance de fonction.
+ `identity` – (applications mobiles) Informations sur l’identité Amazon Cognito qui a autorisé la demande.
+ `cognito_identity_id` – Identité Amazon Cognito authentifiée.
+ `cognito_identity_pool_id` – Groupe d’identités Amazon Cognito ayant autorisé l’invocation.
+ `client_context` – (applications mobiles) Contexte client fourni à Lambda par l’application client.
+ `client.installation_id`
+ `client.app_title`
+ `client.app_version_name`
+ `client.app_version_code`
+ `client.app_package_name`
+ `custom` – `dict` de valeurs personnalisées définies par l’application client mobile.
+ `env` – `dict` d’informations d’environnement fournies par le kit SDK AWS.
Powertools pour Lambda (Python) fournit une définition d’interface pour l’objet de contexte Lambda. Vous pouvez utiliser la définition de l’interface pour les indications de type ou pour examiner plus en détail la structure de l’objet de contexte Lambda. Pour la définition de l’interface, consultez [lambda\$1context.py](https://github.com/aws-powertools/powertools-lambda-python/blob/develop/aws_lambda_powertools/utilities/typing/lambda_context.py) dans le référentiel *powertools-lambda-python* sur GitHub.
L’exemple suivant montre une fonction de gestionnaire qui consigne les informations de contexte.
**Example handler.py**
```
import time
def lambda_handler(event, context):
print("Lambda function ARN:", context.invoked_function_arn)
print("CloudWatch log stream name:", context.log_stream_name)
print("CloudWatch log group name:", context.log_group_name)
print("Lambda Request ID:", context.aws_request_id)
print("Lambda function memory limits in MB:", context.memory_limit_in_mb)
# We have added a 1 second delay so you can see the time remaining in get_remaining_time_in_millis.
time.sleep(1)
print("Lambda time remaining in MS:", context.get_remaining_time_in_millis())
```
En plus des options ci-dessus, vous pouvez également utiliser le kit SDK AWS X-Ray pour [Instrumentation du code Python dans AWS Lambda](python-tracing.md) afin d’identifier les chemins de code critiques, suivre leurs performances et capturer les données pour l’analyse.
# Journalisation et surveillance des fonctions Lambda Python
AWS Lambda surveille automatiquement les fonctions Lambda et envoie des entrées de journal à Amazon. CloudWatch Votre fonction Lambda est fournie avec un groupe de CloudWatch journaux Logs et un flux de journaux pour chaque instance de votre fonction. L’environnement d’exécution Lambda envoie des détails sur chaque invocation et d’autres sorties provenant du code de votre fonction au flux de journaux. Pour plus d'informations sur CloudWatch les journaux, consultez[Envoi automatique des journaux de la fonction Lambda à CloudWatch Logs](monitoring-cloudwatchlogs.md).
Pour produire des journaux à partir de votre code de fonction, vous pouvez utiliser le module intégré [https://docs.python.org/3/library/logging.html](https://docs.python.org/3/library/logging.html). Pour des entrées plus détaillées, vous pouvez utiliser n’importe quelle bibliothèque de journalisation qui écrit dans `stdout` ou `stderr`.
## Impression dans le journal
Pour envoyer une sortie de base aux journaux, vous pouvez utiliser une méthode `print` dans votre fonction. L'exemple suivant enregistre les valeurs du groupe et du flux de CloudWatch journaux Logs, ainsi que l'objet de l'événement.
Notez que si votre fonction génère des journaux à l'aide d'`print`instructions Python, Lambda ne peut envoyer les résultats de journal à CloudWatch Logs qu'au format texte brut. Pour capturer des journaux au format JSON structuré, vous devez utiliser une bibliothèque de journalisation prise en charge. Pour plus d’informations, consultez [Utilisation des contrôles de journalisation avancés de Lambda avec Python](#python-logging-advanced).
**Example lambda\$1function.py**
```
import os
def lambda_handler(event, context):
print('## ENVIRONMENT VARIABLES')
print(os.environ['AWS_LAMBDA_LOG_GROUP_NAME'])
print(os.environ['AWS_LAMBDA_LOG_STREAM_NAME'])
print('## EVENT')
print(event)
```
**Example sortie de journal**
```
START RequestId: 8f507cfc-xmpl-4697-b07a-ac58fc914c95 Version: $LATEST
## ENVIRONMENT VARIABLES
/aws/lambda/my-function
2025/08/31/[$LATEST]3893xmpl7fac4485b47bb75b671a283c
## EVENT
{'key': 'value'}
END RequestId: 8f507cfc-xmpl-4697-b07a-ac58fc914c95
REPORT RequestId: 8f507cfc-xmpl-4697-b07a-ac58fc914c95 Duration: 15.74 ms Billed Duration: 147 ms Memory Size: 128 MB Max Memory Used: 56 MB Init Duration: 130.49 ms
XRAY TraceId: 1-5e34a614-10bdxmplf1fb44f07bc535a1 SegmentId: 07f5xmpl2d1f6f85 Sampled: true
```
L’environnement d’exécution Python enregistre les lignes `START`, `END` et `REPORT` pour chaque invocation. La ligne `REPORT` comprend les données suivantes :
**Champs de données de la ligne REPORT**
+ **RequestId**— L'identifiant de demande unique pour l'invocation.
+ **Duration** – Temps que la méthode de gestion du gestionnaire de votre fonction a consacré au traitement de l’événement.
+ **Billed Duration** : temps facturé pour l’invocation.
+ **Memory Size** – Quantité de mémoire allouée à la fonction.
+ **Max Memory Used** – Quantité de mémoire utilisée par la fonction. Lorsque les appels partagent un environnement d’exécution, Lambda indique la mémoire maximale utilisée pour toutes les invocations. Ce comportement peut entraîner une valeur signalée plus élevée que prévu.
+ **Init Duration** : pour la première requête servie, temps qu’il a pris à l’exécution charger la fonction et exécuter le code en dehors de la méthode du gestionnaire.
+ **XRAY TraceId** — Pour les demandes suivies, l'[ID de AWS X-Ray trace.](services-xray.md)
+ **SegmentId**— Pour les demandes tracées, l'identifiant du segment X-Ray.
+ **Sampled** : pour les demandes suivies, résultat de l’échantillonnage.
## Utilisation d’une bibliothèque de journalisation
Pour des journaux plus détaillés, utilisez le module de [journalisation](https://docs.python.org/3/library/logging.html) de la bibliothèque standard, ou de toute bibliothèque de journalisation tierce qui écrit à `stdout` ou `stderr`.
Pour les environnements d’exécution Python pris en charge, vous pouvez choisir si les journaux créés à l’aide du module `logging` standard sont capturés en texte brut ou en JSON. Pour en savoir plus, veuillez consulter la section [Utilisation des contrôles de journalisation avancés de Lambda avec Python](#python-logging-advanced).
Actuellement, le format de journal par défaut pour tous les environnements d’exécution Python est le texte brut. L'exemple suivant montre comment les sorties de journal créées à l'aide du `logging` module standard sont capturées en texte brut dans CloudWatch Logs.
```
import os
import logging
logger = logging.getLogger()
logger.setLevel("INFO")
def lambda_handler(event, context):
logger.info('## ENVIRONMENT VARIABLES')
logger.info(os.environ['AWS_LAMBDA_LOG_GROUP_NAME'])
logger.info(os.environ['AWS_LAMBDA_LOG_STREAM_NAME'])
logger.info('## EVENT')
logger.info(event)
```
La sortie de `logger` inclut le niveau de journal, l’horodatage et l’ID de demande.
```
START RequestId: 1c8df7d3-xmpl-46da-9778-518e6eca8125 Version: $LATEST
[INFO] 2025-08-31T22:12:58.534Z 1c8df7d3-xmpl-46da-9778-518e6eca8125 ## ENVIRONMENT VARIABLES
[INFO] 2025-08-31T22:12:58.534Z 1c8df7d3-xmpl-46da-9778-518e6eca8125 /aws/lambda/my-function
[INFO] 2025-08-31T22:12:58.534Z 1c8df7d3-xmpl-46da-9778-518e6eca8125 2025/01/31/[$LATEST]1bbe51xmplb34a2788dbaa7433b0aa4d
[INFO] 2025-08-31T22:12:58.535Z 1c8df7d3-xmpl-46da-9778-518e6eca8125 ## EVENT
[INFO] 2025-08-31T22:12:58.535Z 1c8df7d3-xmpl-46da-9778-518e6eca8125 {'key': 'value'}
END RequestId: 1c8df7d3-xmpl-46da-9778-518e6eca8125
REPORT RequestId: 1c8df7d3-xmpl-46da-9778-518e6eca8125 Duration: 2.75 ms Billed Duration: 117 ms Memory Size: 128 MB Max Memory Used: 56 MB Init Duration: 113.51 ms
XRAY TraceId: 1-5e34a66a-474xmpl7c2534a87870b4370 SegmentId: 073cxmpl3e442861 Sampled: true
```
**Note**
Lorsque le format de journal de votre fonction est défini sur du texte brut, le paramètre de niveau de journal par défaut pour les environnements d’exécution Python est WARN. Cela signifie que Lambda envoie uniquement des sorties de journal de niveau WARN ou inférieur à CloudWatch Logs. Pour modifier le niveau de journalisation par défaut, utilisez la méthode Python `logging` `setLevel()` comme indiqué dans cet exemple de code. Si vous définissez le format de journal de votre fonction sur JSON, nous vous recommandons de configurer le niveau de journalisation de votre fonction à l’aide de Lambda Advanced Logging Controls et non en définissant le niveau de journalisation dans le code. Pour en savoir plus, consultez [Utilisation du filtrage au niveau du journal avec Python](#python-logging-levels)
## Utilisation des contrôles de journalisation avancés de Lambda avec Python
Pour mieux contrôler la manière dont les journaux de vos fonctions sont capturés, traités et consommés, vous pouvez configurer les options de journalisation suivantes pour les environnements d’exécution Lambda Python pris en charge :
+ **Format de journal** : choisissez entre le format texte brut et le format JSON structuré pour les journaux de votre fonction
+ **Niveau de journalisation** : pour les journaux au format JSON, choisissez le niveau de détail des journaux que Lambda envoie à Amazon CloudWatch, par exemple ERROR, DEBUG ou INFO
+ **Groupe de journaux** : choisissez le groupe de CloudWatch journaux auquel votre fonction envoie les journaux
Pour plus d’informations sur ces options de journalisation et pour savoir comment configurer votre fonction pour les utiliser, consultez [Configuration de commandes de journalisation avancées pour votre fonction Lambda](monitoring-logs.md#monitoring-cloudwatchlogs-advanced).
Pour en savoir plus sur l’utilisation du format de journal et les options de niveau de journal avec vos fonctions Python Lambda, consultez les instructions des sections suivantes.
### Utilisation de journaux JSON structurés avec Python
Si vous sélectionnez JSON pour le format de journal de votre fonction, Lambda enverra les journaux produits par la bibliothèque de journalisation standard Python au CloudWatch format JSON structuré. Chaque objet de journal JSON contient au moins quatre paires clé-valeur avec les clés suivantes :
+ `"timestamp"` - heure à laquelle le message de journal a été généré
+ `"level"` - niveau de journalisation attribué au message
+ `"message"` - contenu du message de journal
+ `"requestId"` - identifiant unique de la demande pour l’invocation de la fonction
La bibliothèque Python `logging` peut également ajouter des paires clé-valeur supplémentaires, comme `"logger"`, dans cet objet JSON.
Les exemples présentés dans les sections suivantes montrent comment les sorties de journal générées à l'aide de la `logging` bibliothèque Python sont capturées dans CloudWatch Logs lorsque vous configurez le format de journal de votre fonction au format JSON.
Notez que si vous utilisez la méthode `print` pour produire des sorties de journal de base comme décrit dans [Impression dans le journal](#python-logging-output), Lambda capture ces sorties sous forme de texte brut, même si vous définissez le format de journalisation de votre fonction sur JSON.
#### Sorties JSON standard à l’aide de la bibliothèque de journalisation Python
Les exemples d'extrait de code et de sortie de journal suivants montrent comment les sorties de journal standard générées à l'aide de la `logging` bibliothèque Python sont capturées dans CloudWatch Logs lorsque le format de journal de votre fonction est défini sur JSON.
**Example Code de journalisation Python**
```
import logging
logger = logging.getLogger()
def lambda_handler(event, context):
logger.info("Inside the handler function")
```
**Example Enregistrement de journaux JSON**
```
{
"timestamp":"2025-10-27T19:17:45.586Z",
"level":"INFO",
"message":"Inside the handler function",
"logger": "root",
"requestId":"79b4f56e-95b1-4643-9700-2807f4e68189"
}
```
#### Enregistrement de paramètres supplémentaires au format JSON
Lorsque le journal de votre fonction est au format JSON, vous pouvez également journaliser des paramètres supplémentaires avec la bibliothèque `logging` Python standard en utilisant le mot-clé `extra` pour transmettre un dictionnaire Python à la sortie du journal.
**Example Code de journalisation Python**
```
import logging
def lambda_handler(event, context):
logging.info(
"extra parameters example",
extra={"a":"b", "b": [3]},
)
```
**Example Enregistrement de journaux JSON**
```
{
"timestamp": "2025-11-02T15:26:28Z",
"level": "INFO",
"message": "extra parameters example",
"logger": "root",
"requestId": "3dbd5759-65f6-45f8-8d7d-5bdc79a3bd01",
"a": "b",
"b": [
3
]
}
```
#### Exceptions de journalisation au format JSON
L’extrait de code suivant montre comment les exceptions Python sont capturées dans la sortie du journal de votre fonction lorsque vous définissez le format de journal sur JSON. Notez que les sorties de journal générées en utilisant `logging.exception` sont affectées au niveau de journal ERROR.
**Example Code de journalisation Python**
```
import logging
def lambda_handler(event, context):
try:
raise Exception("exception")
except:
logging.exception("msg")
```
**Example Enregistrement de journaux JSON**
```
{
"timestamp": "2025-11-02T16:18:57Z",
"level": "ERROR",
"message": "msg",
"logger": "root",
"stackTrace": [
" File \"/var/task/lambda_function.py\", line 15, in lambda_handler\n raise Exception(\"exception\")\n"
],
"errorType": "Exception",
"errorMessage": "exception",
"requestId": "3f9d155c-0f09-46b7-bdf1-e91dab220855",
"location": "/var/task/lambda_function.py:lambda_handler:17"
}
```
#### Journaux structurés JSON avec d’autres outils de journalisation
Si votre code utilise déjà une autre bibliothèque de journalisation, telle que Powertools for AWS Lambda, pour produire des journaux structurés en JSON, vous n'avez pas besoin d'apporter de modifications. AWS Lambda ne double code aucun journal déjà codé au format JSON. Même si vous configurez votre fonction pour utiliser le format de journal JSON, vos sorties de journalisation apparaissent CloudWatch dans la structure JSON que vous définissez.
L'exemple suivant montre comment les sorties de journal générées à l'aide du AWS Lambda package Powertools for sont capturées dans CloudWatch Logs. Le format de cette sortie de journal est le même, que la configuration de journalisation de votre fonction soit définie sur JSON ou TEXT. Pour plus d'informations sur l'utilisation de Powertools pour AWS Lambda, consultez [Utilisation de Powertools pour AWS Lambda (Python) et AWS SAM pour la journalisation structurée](#python-logging-sam) et [Utilisation de Powertools pour AWS Lambda (Python) et AWS CDK pour la journalisation structurée](#python-logging-powertools-cdk)
**Example Extrait de code de journalisation en Python (à l'aide de Powertools pour) AWS Lambda**
```
from aws_lambda_powertools import Logger
logger = Logger()
def lambda_handler(event, context):
logger.info("Inside the handler function")
```
**Example Enregistrement de journal JSON (à l'aide de Powertools pour AWS Lambda)**
```
{
"level": "INFO",
"location": "lambda_handler:7",
"message": "Inside the handler function",
"timestamp": "2025-10-31 22:38:21,010+0000",
"service": "service_undefined",
"xray_trace_id": "1-654181dc-65c15d6b0fecbdd1531ecb30"
}
```
### Utilisation du filtrage au niveau du journal avec Python
En configurant le filtrage au niveau des journaux, vous pouvez choisir de n'envoyer que les journaux ayant un certain niveau de journalisation ou un niveau inférieur à CloudWatch Logs. Pour savoir comment configurer le filtrage de niveau journal de votre fonction, consultez [Filtrage au niveau du journal](monitoring-cloudwatchlogs-log-level.md).
AWS Lambda Pour filtrer les journaux de votre application en fonction de leur niveau de journalisation, votre fonction doit utiliser des journaux au format JSON. Vous pouvez effectuer cette opération de deux façons :
+ Créez des sorties de journal à l’aide de la bibliothèque Python `logging` standard et configurez votre fonction pour utiliser le format de journal JSON. AWS Lambda filtre ensuite les sorties de votre journal à l’aide de la paire clé-valeur « niveau » de l’objet JSON décrit dans [Utilisation de journaux JSON structurés avec Python](#python-logging-JSON). Pour savoir comment configurer le format de journal de votre fonction, consultez [Configuration de commandes de journalisation avancées pour votre fonction Lambda](monitoring-logs.md#monitoring-cloudwatchlogs-advanced).
+ Utilisez une autre bibliothèque ou méthode de journalisation pour créer des journaux structurés JSON dans votre code qui incluent une paire clé-valeur « niveau » définissant le niveau de sortie du journal. Par exemple, vous pouvez utiliser Powertools pour générer des sorties AWS Lambda de journal structurées JSON à partir de votre code.
Vous pouvez également utiliser une instruction print pour générer un objet JSON contenant un identifiant de niveau de journalisation. L'instruction d'impression suivante produit une sortie au format JSON dans laquelle le niveau de journalisation est défini sur INFO. AWS Lambda enverra l'objet JSON à CloudWatch Logs si le niveau de journalisation de votre fonction est défini sur INFO, DEBUG ou TRACE.
```
print('{"msg":"My log message", "level":"info"}')
```
Pour que Lambda puisse filtrer les journaux de votre fonction, vous devez également inclure une paire `"timestamp"` clé-valeur dans la sortie de votre journal JSON. L’heure doit être spécifiée dans un format d’horodatage [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) valide. Si vous ne fournissez pas d’horodatage valide, Lambda attribuera au journal le niveau INFO et ajoutera un horodatage pour vous.
## Affichage des journaux dans la console Lambda
Vous pouvez utiliser la console Lambda pour afficher la sortie du journal après avoir invoqué une fonction Lambda.
Si votre code peut être testé à partir de l’éditeur **Code** intégré, vous trouverez les journaux dans les **résultats d’exécution**. Lorsque vous utilisez la fonctionnalité de test de console pour invoquer une fonction, vous trouverez **Sortie du journal** dans la section **Détails**.
## Afficher les journaux dans CloudWatch la console
Vous pouvez utiliser la CloudWatch console Amazon pour consulter les journaux de toutes les invocations de fonctions Lambda.
**Pour afficher les journaux sur la CloudWatch console**
1. Ouvrez la [page Groupes de journaux](https://console.aws.amazon.com/cloudwatch/home?#logs:) sur la CloudWatch console.
1. Choisissez le groupe de journaux pour votre fonction (***your-function-name*/aws/lambda/**).
1. Choisissez un flux de journaux.
Chaque flux de journal correspond à une [instance de votre fonction](lambda-runtime-environment.md). Un flux de journal apparaît lorsque vous mettez à jour votre fonction Lambda et lorsque des instances supplémentaires sont créées pour gérer les appels simultanés. Pour trouver les journaux d'un appel spécifique, nous vous recommandons d'instrumenter votre fonction avec. AWS X-Ray X-Ray enregistre des détails sur la demande et le flux de journaux dans le suivi.
## Afficher les journaux avec AWS CLI
AWS CLI Il s'agit d'un outil open source qui vous permet d'interagir avec les AWS services à l'aide de commandes dans votre interface de ligne de commande. Pour effectuer les étapes de cette section, vous devez disposer de la [version 2 de l’AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
Vous pouvez utiliser [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) pour récupérer les journaux d’une invocation à l’aide de l’option de commande `--log-type`. La réponse inclut un champ `LogResult` qui contient jusqu’à 4 Ko de journaux codés en base64 provenant de l’invocation.
**Example récupérer un ID de journal**
L’exemple suivant montre comment récupérer un *ID de journal* à partir du champ `LogResult` d’une fonction nommée `my-function`.
```
aws lambda invoke --function-name my-function out --log-type Tail
```
Vous devriez voir la sortie suivante:
```
{
"StatusCode": 200,
"LogResult": "U1RBUlQgUmVxdWVzdElkOiA4N2QwNDRiOC1mMTU0LTExZTgtOGNkYS0yOTc0YzVlNGZiMjEgVmVyc2lvb...",
"ExecutedVersion": "$LATEST"
}
```
**Example décoder les journaux**
Dans la même invite de commandes, utilisez l’utilitaire `base64` pour décoder les journaux. L’exemple suivant montre comment récupérer les journaux encodés en base64 pour `my-function`.
```
aws lambda invoke --function-name my-function out --log-type Tail \
--query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode
```
L'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la 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 AWS CLI prises en charge](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 voir la sortie suivante :
```
START RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Version: $LATEST
"AWS_SESSION_TOKEN": "AgoJb3JpZ2luX2VjELj...", "_X_AMZN_TRACE_ID": "Root=1-5d02e5ca-f5792818b6fe8368e5b51d50;Parent=191db58857df8395;Sampled=0"",ask/lib:/opt/lib",
END RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8
REPORT RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Duration: 79.67 ms Billed Duration: 80 ms Memory Size: 128 MB Max Memory Used: 73 MB
```
L’utilitaire `base64` est disponible sous Linux, macOS et [Ubuntu sous Windows](https://docs.microsoft.com/en-us/windows/wsl/install-win10). Les utilisateurs de macOS auront peut-être besoin d’utiliser `base64 -D`.
**Example Script get-logs.sh**
Dans la même invite de commandes, utilisez le script suivant pour télécharger les cinq derniers événements de journalisation. Le script utilise `sed` pour supprimer les guillemets du fichier de sortie et attend 15 secondes pour permettre la mise à disposition des journaux. La sortie comprend la réponse de Lambda, ainsi que la sortie de la commande `get-log-events`.
Copiez le contenu de l’exemple de code suivant et enregistrez-le dans votre répertoire de projet Lambda sous `get-logs.sh`.
L'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la 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 AWS CLI prises en charge](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*.
```
#!/bin/bash
aws lambda invoke --function-name my-function --cli-binary-format raw-in-base64-out --payload '{"key": "value"}' out
sed -i'' -e 's/"//g' out
sleep 15
aws logs get-log-events --log-group-name /aws/lambda/my-function --log-stream-name stream1 --limit 5
```
**Example macOS et Linux (uniquement)**
Dans la même invite de commandes, les utilisateurs macOS et Linux peuvent avoir besoin d’exécuter la commande suivante pour s’assurer que le script est exécutable.
```
chmod -R 755 get-logs.sh
```
**Example récupérer les cinq derniers événements de journal**
Dans la même invite de commande, exécutez le script suivant pour obtenir les cinq derniers événements de journalisation.
```
./get-logs.sh
```
Vous devriez voir la sortie suivante:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
{
"events": [
{
"timestamp": 1559763003171,
"message": "START RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf Version: $LATEST\n",
"ingestionTime": 1559763003309
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tENVIRONMENT VARIABLES\r{\r \"AWS_LAMBDA_FUNCTION_VERSION\": \"$LATEST\",\r ...",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tEVENT\r{\r \"key\": \"value\"\r}\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "END RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "REPORT RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\tDuration: 26.73 ms\tBilled Duration: 27 ms \tMemory Size: 128 MB\tMax Memory Used: 75 MB\t\n",
"ingestionTime": 1559763018353
}
],
"nextForwardToken": "f/34783877304859518393868359594929986069206639495374241795",
"nextBackwardToken": "b/34783877303811383369537420289090800615709599058929582080"
}
```
## Suppression de journaux
Les groupes de journaux ne sont pas supprimés automatiquement quand vous supprimez une fonction. Pour éviter de stocker des journaux indéfiniment, supprimez le groupe de journaux ou [configurez une période de conservation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention) à l’issue de laquelle les journaux sont supprimés automatiquement.
## Utilisation d’autres outils et bibliothèques de journalisation
[Powertools for AWS Lambda (Python)](https://docs.aws.amazon.com/powertools/python/) est une boîte à outils destinée aux développeurs qui permet de mettre en œuvre les meilleures pratiques sans serveur et d'accroître la rapidité des développeurs. L’[utilitaire Logger](https://docs.aws.amazon.com/powertools/python/latest/core/logger/) fournit un enregistreur optimisé pour Lambda qui inclut des informations supplémentaires sur le contexte de fonction pour toutes vos fonctions avec une sortie structurée en JSON. Utilisez cet utilitaire pour effectuer les opérations suivantes :
+ Capturer les champs clés du contexte Lambda, démarrer à froid et structurer la sortie de la journalisation sous forme de JSON
+ Journaliser les événements d’invocation Lambda lorsque cela est demandé (désactivé par défaut)
+ Imprimer tous les journaux uniquement pour un pourcentage d’invocations via l’échantillonnage des journaux (désactivé par défaut)
+ Ajouter des clés supplémentaires au journal structuré à tout moment
+ Utiliser un formateur de journaux personnalisé (Apportez votre propre formateur) pour produire des journaux dans une structure compatible avec le RFC de journalisation de votre organisation
## Utilisation de Powertools pour AWS Lambda (Python) et AWS SAM pour la journalisation structurée
Suivez les étapes ci-dessous pour télécharger, créer et déployer un exemple d’application Hello World Python avec des modules [ Powertools for Python](https://docs.aws.amazon.com/powertools/python/latest/) (français non garanti) intégrés à l’aide d’ AWS SAM. Cette application met en œuvre un backend API de base et utilise Powertools pour émettre des journaux, des métriques et des traces. Elle se compose d’un point de terminaison Amazon API Gateway et d’une fonction Lambda. Lorsque vous envoyez une requête GET au point de terminaison API Gateway, la fonction Lambda appelle, envoie des journaux et des métriques au format métrique intégré à CloudWatch, et envoie des traces à. AWS X-Ray La fonction renvoie un message `hello world`.
**Conditions préalables**
Pour exécuter la procédure indiquée dans cette section, vous devez satisfaire aux exigences suivantes :
+ Python 3.9
+ [AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+ [AWS SAM CLI version 1.75 ou ultérieure](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html). Si vous disposez d'une ancienne version de la AWS SAM CLI, reportez-vous [à la section Mise à niveau de la AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/manage-sam-cli-versions.html#manage-sam-cli-versions-upgrade).
**Déployer un exemple d' AWS SAM application**
1. Initialisez l’application à l’aide du modèle Hello World Python.
```
sam init --app-template hello-world-powertools-python --name sam-app --package-type Zip --runtime python3.9 --no-tracing
```
1. Créez l’application.
```
cd sam-app && sam build
```
1. Déployez l’application.
```
sam deploy --guided
```
1. Suivez les invites à l’écran. Appuyez sur `Enter` pour accepter les options par défaut fournies dans l’expérience interactive.
**Note**
Car l'**autorisation n'a HelloWorldFunction peut-être pas été définie, est-ce que ça va ?** , assurez-vous de participer`y`.
1. Obtenez l’URL de l’application déployée :
```
aws cloudformation describe-stacks --stack-name sam-app --query 'Stacks[0].Outputs[?OutputKey==`HelloWorldApi`].OutputValue' --output text
```
1. Invoquez le point de terminaison de l’API :
```
curl GET
```
En cas de succès, vous obtiendrez cette réponse :
```
{"message":"hello world"}
```
1. Pour obtenir les journaux de la fonction, exécutez [sam logs](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-logs.html). Pour en savoir plus, consultez [Utilisation des journaux](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-logging.html) dans le *Guide du développeur AWS Serverless Application Model *.
```
sam logs --stack-name sam-app
```
La sortie du journal se présente comme suit :
```
2025/02/03/[$LATEST]ea9a64ec87294bf6bbc9026c05a01e04 2025-02-03T14:59:50.371000 INIT_START Runtime Version: python:3.9.v16 Runtime Version ARN: arn:aws:lambda:us-east-1::runtime:07a48df201798d627f2b950f03bb227aab4a655a1d019c3296406f95937e2525
2025/02/03/[$LATEST]ea9a64ec87294bf6bbc9026c05a01e04 2025-02-03T14:59:51.112000 START RequestId: d455cfc4-7704-46df-901b-2a5cce9405be Version: $LATEST
2025/02/03/[$LATEST]ea9a64ec87294bf6bbc9026c05a01e04 2025-02-03T14:59:51.114000 {
"level": "INFO",
"location": "hello:23",
"message": "Hello world API - HTTP 200",
"timestamp": "2025-02-03 14:59:51,113+0000",
"service": "PowertoolsHelloWorld",
"cold_start": true,
"function_name": "sam-app-HelloWorldFunction-YBg8yfYtOc9j",
"function_memory_size": "128",
"function_arn": "arn:aws:lambda:us-east-1:111122223333:function:sam-app-HelloWorldFunction-YBg8yfYtOc9j",
"function_request_id": "d455cfc4-7704-46df-901b-2a5cce9405be",
"correlation_id": "e73f8aef-5e07-436e-a30b-63e4b23f0047",
"xray_trace_id": "1-63dd2166-434a12c22e1307ff2114f299"
}
2025/02/03/[$LATEST]ea9a64ec87294bf6bbc9026c05a01e04 2025-02-03T14:59:51.126000 {
"_aws": {
"Timestamp": 1675436391126,
"CloudWatchMetrics": [
{
"Namespace": "Powertools",
"Dimensions": [
[
"function_name",
"service"
]
],
"Metrics": [
{
"Name": "ColdStart",
"Unit": "Count"
}
]
}
]
},
"function_name": "sam-app-HelloWorldFunction-YBg8yfYtOc9j",
"service": "PowertoolsHelloWorld",
"ColdStart": [
1.0
]
}
2025/02/03/[$LATEST]ea9a64ec87294bf6bbc9026c05a01e04 2025-02-03T14:59:51.126000 {
"_aws": {
"Timestamp": 1675436391126,
"CloudWatchMetrics": [
{
"Namespace": "Powertools",
"Dimensions": [
[
"service"
]
],
"Metrics": [
{
"Name": "HelloWorldInvocations",
"Unit": "Count"
}
]
}
]
},
"service": "PowertoolsHelloWorld",
"HelloWorldInvocations": [
1.0
]
}
2025/02/03/[$LATEST]ea9a64ec87294bf6bbc9026c05a01e04 2025-02-03T14:59:51.128000 END RequestId: d455cfc4-7704-46df-901b-2a5cce9405be
2025/02/03/[$LATEST]ea9a64ec87294bf6bbc9026c05a01e04 2025-02-03T14:59:51.128000 REPORT RequestId: d455cfc4-7704-46df-901b-2a5cce9405be Duration: 16.33 ms Billed Duration: 756 ms Memory Size: 128 MB Max Memory Used: 64 MB Init Duration: 739.46 ms
XRAY TraceId: 1-63dd2166-434a12c22e1307ff2114f299 SegmentId: 3c5d18d735a1ced0 Sampled: true
```
1. Il s’agit d’un point de terminaison d’API public accessible par Internet. Nous vous recommandons de supprimer le point de terminaison après un test.
```
sam delete
```
### Gestion de la conservation des journaux
Les groupes de journaux ne sont pas supprimés automatiquement quand vous supprimez une fonction. Pour éviter de stocker les journaux indéfiniment, supprimez le groupe de journaux ou configurez une période de conservation après laquelle les journaux CloudWatch sont automatiquement supprimés. Pour configurer la conservation des journaux, ajoutez ce qui suit à votre AWS SAM modèle :
```
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
# Omitting other properties
LogGroup:
Type: AWS::Logs::LogGroup
Properties:
LogGroupName: !Sub "/aws/lambda/${HelloWorldFunction}"
RetentionInDays: 7
```
## Utilisation de Powertools pour AWS Lambda (Python) et AWS CDK pour la journalisation structurée
Suivez les étapes ci-dessous pour télécharger, créer et déployer un exemple d'application Hello World Python avec des modules [Powertools pour AWS Lambda (Python)](https://docs.aws.amazon.com/powertools/python/latest/) intégrés à l'aide du AWS CDK. Cette application met en œuvre un backend API de base et utilise Powertools pour émettre des journaux, des métriques et des traces. Elle se compose d’un point de terminaison Amazon API Gateway et d’une fonction Lambda. Lorsque vous envoyez une requête GET au point de terminaison API Gateway, la fonction Lambda appelle, envoie des journaux et des métriques au format métrique intégré à CloudWatch, et envoie des traces à. AWS X-Ray La fonction renvoie un message hello world.
**Conditions préalables**
Pour exécuter la procédure indiquée dans cette section, vous devez satisfaire aux exigences suivantes :
+ Python 3.9
+ [AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+ [AWS CDK version 2](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_prerequisites)
+ [AWS SAM CLI version 1.75 ou ultérieure](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html). Si vous disposez d'une ancienne version de la AWS SAM CLI, reportez-vous [à la section Mise à niveau de la AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/manage-sam-cli-versions.html#manage-sam-cli-versions-upgrade).
**Déployer un exemple d' AWS CDK application**
1. Créez un répertoire de projets pour votre nouvelle application.
```
mkdir hello-world
cd hello-world
```
1. Initialisez l’application.
```
cdk init app --language python
```
1. Installez les dépendances de Python.
```
pip install -r requirements.txt
```
1. Créez un répertoire **lambda\$1function** dans le dossier racine.
```
mkdir lambda_function
cd lambda_function
```
1. Créez un fichier **app.py** et ajoutez-y le code suivant. Il s’agit du code de la fonction Lambda.
```
from aws_lambda_powertools.event_handler import APIGatewayRestResolver
from aws_lambda_powertools.utilities.typing import LambdaContext
from aws_lambda_powertools.logging import correlation_paths
from aws_lambda_powertools import Logger
from aws_lambda_powertools import Tracer
from aws_lambda_powertools import Metrics
from aws_lambda_powertools.metrics import MetricUnit
app = APIGatewayRestResolver()
tracer = Tracer()
logger = Logger()
metrics = Metrics(namespace="PowertoolsSample")
@app.get("/hello")
@tracer.capture_method
def hello():
# adding custom metrics
# See: https://docs.aws.amazon.com/powertools/python/latest//latest/core/metrics/
metrics.add_metric(name="HelloWorldInvocations", unit=MetricUnit.Count, value=1)
# structured log
# See: https://docs.aws.amazon.com/powertools/python/latest//latest/core/logger/
logger.info("Hello world API - HTTP 200")
return {"message": "hello world"}
# Enrich logging with contextual information from Lambda
@logger.inject_lambda_context(correlation_id_path=correlation_paths.API_GATEWAY_REST)
# Adding tracer
# See: https://docs.aws.amazon.com/powertools/python/latest//latest/core/tracer/
@tracer.capture_lambda_handler
# ensures metrics are flushed upon request completion/failure and capturing ColdStart metric
@metrics.log_metrics(capture_cold_start_metric=True)
def lambda_handler(event: dict, context: LambdaContext) -> dict:
return app.resolve(event, context)
```
1. Ouvrez le répertoire **hello\$1world**. Vous devriez voir un fichier nommé **hello\$1world\$1stack.py**.
```
cd ..
cd hello_world
```
1. Ouvrez **hello\$1world\$1stack.py** et ajoutez le code suivant au fichier. Il contient le [constructeur Lambda](https://docs.aws.amazon.com/cdk/api/v1/python/aws_cdk.aws_lambda.html), qui crée la fonction Lambda, configure les variables d'environnement pour Powertools et fixe la durée de conservation des journaux à une semaine, et le [constructeur ApiGatewayv 1](https://docs.aws.amazon.com/cdk/api/v1/python/aws_cdk.aws_apigateway.html), qui crée l'API REST.
```
from aws_cdk import (
Stack,
aws_apigateway as apigwv1,
aws_lambda as lambda_,
CfnOutput,
Duration
)
from constructs import Construct
class HelloWorldStack(Stack):
def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
super().__init__(scope, construct_id, **kwargs)
# Powertools Lambda Layer
powertools_layer = lambda_.LayerVersion.from_layer_version_arn(
self,
id="lambda-powertools",
# Using AWS Lambda Powertools via Lambda Layer
# This imports the Powertools layer which provides observability features for Lambda functions
# For available versions, see: https://docs.aws.amazon.com/powertools/python/latest/#lambda-layer
)
function = lambda_.Function(self,
'sample-app-lambda',
runtime=lambda_.Runtime.PYTHON_3_9,
layers=[powertools_layer],
code = lambda_.Code.from_asset("./lambda_function/"),
handler="app.lambda_handler",
memory_size=128,
timeout=Duration.seconds(3),
architecture=lambda_.Architecture.X86_64,
environment={
"POWERTOOLS_SERVICE_NAME": "PowertoolsHelloWorld",
"POWERTOOLS_METRICS_NAMESPACE": "PowertoolsSample",
"LOG_LEVEL": "INFO"
}
)
apigw = apigwv1.RestApi(self, "PowertoolsAPI", deploy_options=apigwv1.StageOptions(stage_name="dev"))
hello_api = apigw.root.add_resource("hello")
hello_api.add_method("GET", apigwv1.LambdaIntegration(function, proxy=True))
CfnOutput(self, "apiUrl", value=f"{apigw.url}hello")
```
1. Déployez votre application.
```
cd ..
cdk deploy
```
1. Obtenez l’URL de l’application déployée :
```
aws cloudformation describe-stacks --stack-name HelloWorldStack --query 'Stacks[0].Outputs[?OutputKey==`apiUrl`].OutputValue' --output text
```
1. Invoquez le point de terminaison de l’API :
```
curl GET
```
En cas de succès, vous obtiendrez cette réponse :
```
{"message":"hello world"}
```
1. Pour obtenir les journaux de la fonction, exécutez [sam logs](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-logs.html). Pour en savoir plus, consultez [Utilisation des journaux](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-logging.html) dans le *Guide du développeur AWS Serverless Application Model *.
```
sam logs --stack-name HelloWorldStack
```
La sortie du journal se présente comme suit :
```
2025/02/03/[$LATEST]ea9a64ec87294bf6bbc9026c05a01e04 2025-02-03T14:59:50.371000 INIT_START Runtime Version: python:3.9.v16 Runtime Version ARN: arn:aws:lambda:us-east-1::runtime:07a48df201798d627f2b950f03bb227aab4a655a1d019c3296406f95937e2525
2025/02/03/[$LATEST]ea9a64ec87294bf6bbc9026c05a01e04 2025-02-03T14:59:51.112000 START RequestId: d455cfc4-7704-46df-901b-2a5cce9405be Version: $LATEST
2025/02/03/[$LATEST]ea9a64ec87294bf6bbc9026c05a01e04 2025-02-03T14:59:51.114000 {
"level": "INFO",
"location": "hello:23",
"message": "Hello world API - HTTP 200",
"timestamp": "2025-02-03 14:59:51,113+0000",
"service": "PowertoolsHelloWorld",
"cold_start": true,
"function_name": "sam-app-HelloWorldFunction-YBg8yfYtOc9j",
"function_memory_size": "128",
"function_arn": "arn:aws:lambda:us-east-1:111122223333:function:sam-app-HelloWorldFunction-YBg8yfYtOc9j",
"function_request_id": "d455cfc4-7704-46df-901b-2a5cce9405be",
"correlation_id": "e73f8aef-5e07-436e-a30b-63e4b23f0047",
"xray_trace_id": "1-63dd2166-434a12c22e1307ff2114f299"
}
2025/02/03/[$LATEST]ea9a64ec87294bf6bbc9026c05a01e04 2025-02-03T14:59:51.126000 {
"_aws": {
"Timestamp": 1675436391126,
"CloudWatchMetrics": [
{
"Namespace": "Powertools",
"Dimensions": [
[
"function_name",
"service"
]
],
"Metrics": [
{
"Name": "ColdStart",
"Unit": "Count"
}
]
}
]
},
"function_name": "sam-app-HelloWorldFunction-YBg8yfYtOc9j",
"service": "PowertoolsHelloWorld",
"ColdStart": [
1.0
]
}
2025/02/03/[$LATEST]ea9a64ec87294bf6bbc9026c05a01e04 2025-02-03T14:59:51.126000 {
"_aws": {
"Timestamp": 1675436391126,
"CloudWatchMetrics": [
{
"Namespace": "Powertools",
"Dimensions": [
[
"service"
]
],
"Metrics": [
{
"Name": "HelloWorldInvocations",
"Unit": "Count"
}
]
}
]
},
"service": "PowertoolsHelloWorld",
"HelloWorldInvocations": [
1.0
]
}
2025/02/03/[$LATEST]ea9a64ec87294bf6bbc9026c05a01e04 2025-02-03T14:59:51.128000 END RequestId: d455cfc4-7704-46df-901b-2a5cce9405be
2025/02/03/[$LATEST]ea9a64ec87294bf6bbc9026c05a01e04 2025-02-03T14:59:51.128000 REPORT RequestId: d455cfc4-7704-46df-901b-2a5cce9405be Duration: 16.33 ms Billed Duration: 756 ms Memory Size: 128 MB Max Memory Used: 64 MB Init Duration: 739.46 ms
XRAY TraceId: 1-63dd2166-434a12c22e1307ff2114f299 SegmentId: 3c5d18d735a1ced0 Sampled: true
```
1. Il s’agit d’un point de terminaison d’API public accessible par Internet. Nous vous recommandons de supprimer le point de terminaison après un test.
```
cdk destroy
```
# Test de la fonction AWS Lambda dans Python
**Note**
Consultez le chapitre [Test des fonctions](testing-guide.md) pour une présentation complète des techniques et des bonnes pratiques pour tester les solutions sans serveur.
Le test des fonctions sans serveur utilise les types et techniques de tests traditionnels, mais vous devez également envisager de tester les applications sans serveur dans leur ensemble. Les tests basés sur le cloud fourniront la mesure la **plus précise** de la qualité de vos fonctions et de vos applications sans serveur.
Une architecture d’application sans serveur comprend des services gérés qui fournissent des fonctionnalités d’applications critiques par le biais d’appels d’API. C’est pourquoi votre cycle de développement doit inclure des tests automatisés qui vérifient la fonctionnalité lorsque votre fonction et vos services interagissent.
Si vous ne créez pas de tests basés sur le cloud, vous pouvez rencontrer des problèmes en raison des différences entre votre environnement local et l’environnement déployé. Votre processus d’intégration continue doit exécuter des tests sur une série de ressources allouées dans le cloud avant de promouvoir votre code vers l’environnement de déploiement suivant, comme l’assurance qualité, la mise en place ou la production.
Poursuivez la lecture de ce petit guide pour en savoir plus sur les stratégies de test pour les applications sans serveur, ou rendez-vous sur le [référentiel Serverless Test Samples](https://github.com/aws-samples/serverless-test-samples) pour vous plonger dans des exemples pratiques, spécifiques au langage et à l’exécution que vous avez choisis.
![\[illustration showing the relationship between types of tests\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/test-type-illustration2.png)
Pour les tests sans serveur, vous écrirez toujours des tests *unitaires*, *d’intégration* et de *bout en bout*.
+ **Tests unitaires** : tests exécutés sur un bloc de code isolé. Par exemple, la vérification de la logique métier permettant de calculer les frais de livraison en fonction d’un article et d’une destination donnés.
+ **Tests d’intégration** : tests impliquant au moins deux composants ou services qui interagissent, généralement dans un environnement cloud. Par exemple, la vérification d’une fonction traite les événements d’une file d’attente.
+ **Tests de bout en bout** : tests qui vérifient le comportement de l’ensemble d’une application. Il s'agit par exemple de s'assurer que l'infrastructure est correctement mise en place et que les événements circulent entre les services comme prévu pour enregistrer la commande d'un client.
## Test de vos applications sans serveur
Vous utiliserez généralement une combinaison d'approches pour tester le code de votre application sans serveur, notamment des tests dans le cloud, des tests avec des simulations et, occasionnellement, des tests avec des émulateurs.
### Tests dans le cloud
Les tests dans le cloud sont utiles pour toutes les phases des tests, y compris les tests unitaires, les tests d'intégration et les tests de bout en bout. Vous exécutez des tests sur du code déployé dans le cloud et interagissez avec des services basés sur le cloud. Cette approche fournit la mesure la **plus précise** de la qualité de votre code.
Un moyen pratique de déboguer votre fonction Lambda dans le cloud est de passer par la console avec un événement de test. Un *événement de test* est une entrée JSON pour votre fonction. Si votre fonction ne nécessite pas d’entrée, l’événement peut être un document JSON vide `({})`. La console fournit des exemples d'événements pour diverses intégrations de services. Après avoir créé un événement dans la console, vous pouvez le partager avec votre équipe pour faciliter les tests et les rendre plus cohérents.
**Note**
[Tester une fonction dans la console](testing-functions.md) est un moyen rapide de démarrer, mais l'automatisation de vos cycles de test garantit la qualité des applications et la rapidité du développement.
### Outils de test
Il existe des outils et des techniques permettant d'accélérer les boucles de rétroaction du développement. Par exemple, [AWS SAM Accelerate](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/accelerate.html) et le [mode de surveillance AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-deploy-watch) réduisent tous deux le temps nécessaire à la mise à jour des environnements cloud.
[Moto](https://pypi.org/project/moto/) est une bibliothèque Python qui permet de simuler des services et des ressources AWS. Vous pouvez ainsi tester vos fonctions avec peu ou pas de modifications à l'aide de décorateurs pour intercepter et simuler des réponses.
La fonctionnalité de validation de [Powertools pour AWS Lambda (Python)](https://docs.powertools.aws.dev/lambda-python/latest/utilities/validation/) fournit des décorateurs qui vous permettent de valider les événements d'entrée et les réponses de sortie de vos fonctions Python.
Pour plus d'informations, consultez l'article de blog [Unit Testing Lambda with Python and Mock AWS Services](https://aws.amazon.com/blogs/devops/unit-testing-aws-lambda-with-python-and-mock-aws-services/).
Pour réduire le temps de latence liés aux itérations de déploiement dans le cloud, consultez [AWS Serverless Application Model (AWS SAM)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/using-sam-cli-sync.html) et le mode de surveillance [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-deploy-watch). Ces outils surveillent les modifications apportées à votre infrastructure et à votre code. Ils réagissent à ces modifications en créant et en déployant automatiquement des mises à jour incrémentielles dans votre environnement cloud.
Des exemples utilisant ces outils sont disponibles dans le référentiel de code [Python Test Samples](https://github.com/aws-samples/serverless-test-samples/tree/main/python-test-samples).
# Instrumentation du code Python dans AWS Lambda
Lambda s'intègre pour vous aider AWS X-Ray à suivre, à déboguer et à optimiser les applications Lambda. Vous pouvez utiliser X-Ray pour suivre une demande lorsque celle-ci parcourt les ressources de votre application, qui peuvent inclure des fonctions Lambda et d’autres services AWS .
Pour envoyer des données de traçage à X-Ray, vous pouvez utiliser l’une des trois bibliothèques SDK suivantes :
+ [AWS Distro for OpenTelemetry (ADOT)](https://aws.amazon.com/otel) — Une distribution sécurisée, prête pour la production et AWS prise en charge du SDK (). OpenTelemetry OTel
+ [Kit SDK AWS X-Ray pour Python](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-python.html) – Un kit SDK permettant de générer et d’envoyer des données de suivi à X-Ray.
+ [Powertools for AWS Lambda (Python)](https://docs.aws.amazon.com/powertools/python/latest/) — Une boîte à outils pour les développeurs permettant de mettre en œuvre les meilleures pratiques sans serveur et d'accroître la rapidité des développeurs.
Chacune d'entre elles SDKs propose des moyens d'envoyer vos données de télémétrie au service X-Ray. Vous pouvez ensuite utiliser X-Ray pour afficher, filtrer et avoir un aperçu des métriques de performance de votre application, afin d’identifier les problèmes et les occasions d’optimiser votre application.
**Important**
Les outils X-Ray et Powertools pour AWS Lambda SDKs font partie d'une solution d'instrumentation étroitement intégrée proposée par AWS. Les couches ADOT Lambda font partie d’une norme industrielle pour l’instrumentation de traçage qui collecte plus de données en général, mais qui peut ne pas convenir à tous les cas d’utilisation. Vous pouvez implémenter le end-to-end traçage dans X-Ray en utilisant l'une ou l'autre solution. Pour en savoir plus sur le choix entre les deux, consultez [Choosing between the AWS Distro for Open Telemetry and](https://docs.aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html#xray-instrumenting-choosing) X-Ray. SDKs
**Topics**
+ [Utilisation de Powertools pour AWS Lambda (Python) et AWS SAM pour le traçage](#python-tracing-sam)
+ [Utilisation de Powertools pour AWS Lambda (Python) et AWS CDK pour le traçage](#python-logging-cdk)
+ [Utilisation d’ADOT pour instrumenter vos fonctions python](#python-adot)
+ [Utilisation du kit SDK X-Ray pour instrumenter vos fonctions Python](#python-xray-sdk)
+ [Activation du suivi avec la console Lambda](#python-tracing-console)
+ [Activation du suivi avec l’API Lambda](#python-tracing-api)
+ [Activation du traçage avec CloudFormation](#python-tracing-cloudformation)
+ [Interprétation d’un suivi X-Ray](#python-tracing-interpretation)
+ [Stockage des dépendances d’exécution dans une couche (kit SDK X-Ray)](#python-tracing-layers)
## Utilisation de Powertools pour AWS Lambda (Python) et AWS SAM pour le traçage
Suivez les étapes ci-dessous pour télécharger, créer et déployer un exemple d'application Hello World Python avec des modules [Powertools pour AWS Lambda (Python)](https://docs.powertools.aws.dev/lambda-python) intégrés à l'aide du AWS SAM. Cette application met en œuvre un backend API de base et utilise Powertools pour émettre des journaux, des métriques et des traces. Elle se compose d’un point de terminaison Amazon API Gateway et d’une fonction Lambda. Lorsque vous envoyez une requête GET au point de terminaison API Gateway, la fonction Lambda appelle, envoie des journaux et des métriques au format métrique intégré à CloudWatch, et envoie des traces à. AWS X-Ray La fonction renvoie un message hello world.
**Conditions préalables**
Pour exécuter la procédure indiquée dans cette section, vous devez satisfaire aux exigences suivantes :
+ Python 3.11
+ [AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+ [AWS SAM CLI version 1.75 ou ultérieure](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html). Si vous disposez d'une ancienne version de la AWS SAM CLI, reportez-vous [à la section Mise à niveau de la AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/manage-sam-cli-versions.html#manage-sam-cli-versions-upgrade).
**Déployer un exemple d' AWS SAM application**
1. Initialisez l’application à l’aide du modèle Hello World Python.
```
sam init --app-template hello-world-powertools-python --name sam-app --package-type Zip --runtime python3.11 --no-tracing
```
1. Créez l’application.
```
cd sam-app && sam build
```
1. Déployez l’application.
```
sam deploy --guided
```
1. Suivez les invites à l’écran. Appuyez sur `Enter` pour accepter les options par défaut fournies dans l’expérience interactive.
**Note**
Car l'**autorisation n'a HelloWorldFunction peut-être pas été définie, est-ce que ça va ?** , assurez-vous de participer`y`.
1. Obtenez l’URL de l’application déployée :
```
aws cloudformation describe-stacks --stack-name sam-app --query 'Stacks[0].Outputs[?OutputKey==`HelloWorldApi`].OutputValue' --output text
```
1. Invoquez le point de terminaison de l’API :
```
curl -X GET
```
En cas de succès, vous obtiendrez cette réponse :
```
{"message":"hello world"}
```
1. Pour obtenir les traces de la fonction, exécutez [sam traces](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-traces.html).
```
sam traces
```
La sortie de la trace ressemble à ceci :
```
New XRay Service Graph
Start time: 2023-02-03 14:59:50+00:00
End time: 2023-02-03 14:59:50+00:00
Reference Id: 0 - (Root) AWS::Lambda - sam-app-HelloWorldFunction-YBg8yfYtOc9j - Edges: [1]
Summary_statistics:
- total requests: 1
- ok count(2XX): 1
- error count(4XX): 0
- fault count(5XX): 0
- total response time: 0.924
Reference Id: 1 - AWS::Lambda::Function - sam-app-HelloWorldFunction-YBg8yfYtOc9j - Edges: []
Summary_statistics:
- total requests: 1
- ok count(2XX): 1
- error count(4XX): 0
- fault count(5XX): 0
- total response time: 0.016
Reference Id: 2 - client - sam-app-HelloWorldFunction-YBg8yfYtOc9j - Edges: [0]
Summary_statistics:
- total requests: 0
- ok count(2XX): 0
- error count(4XX): 0
- fault count(5XX): 0
- total response time: 0
XRay Event [revision 1] at (2023-02-03T14:59:50.204000) with id (1-63dd2166-434a12c22e1307ff2114f299) and duration (0.924s)
- 0.924s - sam-app-HelloWorldFunction-YBg8yfYtOc9j [HTTP: 200]
- 0.016s - sam-app-HelloWorldFunction-YBg8yfYtOc9j
- 0.739s - Initialization
- 0.016s - Invocation
- 0.013s - ## lambda_handler
- 0.000s - ## app.hello
- 0.000s - Overhead
```
1. Il s’agit d’un point de terminaison d’API public accessible par Internet. Nous vous recommandons de supprimer le point de terminaison après un test.
```
sam delete
```
X-Ray ne trace pas toutes les requêtes vers votre application. X-Ray applique un algorithme d’échantillonnage pour s’assurer que le suivi est efficace, tout en fournissant un échantillon représentatif de toutes les demandes. Le taux d’échantillonnage est 1 demande par seconde et 5 % de demandes supplémentaires. Vous ne pouvez pas configurer ce taux d’échantillonnage X-Ray pour vos fonctions.
## Utilisation de Powertools pour AWS Lambda (Python) et AWS CDK pour le traçage
Suivez les étapes ci-dessous pour télécharger, créer et déployer un exemple d'application Hello World Python avec des modules [Powertools pour AWS Lambda (Python)](https://docs.powertools.aws.dev/lambda-python) intégrés à l'aide du AWS CDK. Cette application met en œuvre un backend API de base et utilise Powertools pour émettre des journaux, des métriques et des traces. Elle se compose d’un point de terminaison Amazon API Gateway et d’une fonction Lambda. Lorsque vous envoyez une requête GET au point de terminaison API Gateway, la fonction Lambda appelle, envoie des journaux et des métriques au format métrique intégré à CloudWatch, et envoie des traces à. AWS X-Ray La fonction renvoie un message hello world.
**Conditions préalables**
Pour exécuter la procédure indiquée dans cette section, vous devez satisfaire aux exigences suivantes :
+ Python 3.11
+ [AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+ [AWS CDK version 2](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_prerequisites)
+ [AWS SAM CLI version 1.75 ou ultérieure](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html). Si vous disposez d'une ancienne version de la AWS SAM CLI, reportez-vous [à la section Mise à niveau de la AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/manage-sam-cli-versions.html#manage-sam-cli-versions-upgrade).
**Déployer un exemple d' AWS CDK application**
1. Créez un répertoire de projets pour votre nouvelle application.
```
mkdir hello-world
cd hello-world
```
1. Initialisez l’application.
```
cdk init app --language python
```
1. Installez les dépendances de Python.
```
pip install -r requirements.txt
```
1. Créez un répertoire **lambda\$1function** dans le dossier racine.
```
mkdir lambda_function
cd lambda_function
```
1. Créez un fichier **app.py** et ajoutez-y le code suivant. Il s’agit du code de la fonction Lambda.
```
from aws_lambda_powertools.event_handler import APIGatewayRestResolver
from aws_lambda_powertools.utilities.typing import LambdaContext
from aws_lambda_powertools.logging import correlation_paths
from aws_lambda_powertools import Logger
from aws_lambda_powertools import Tracer
from aws_lambda_powertools import Metrics
from aws_lambda_powertools.metrics import MetricUnit
app = APIGatewayRestResolver()
tracer = Tracer()
logger = Logger()
metrics = Metrics(namespace="PowertoolsSample")
@app.get("/hello")
@tracer.capture_method
def hello():
# adding custom metrics
# See: https://docs.powertools.aws.dev/lambda-python/latest/core/metrics/
metrics.add_metric(name="HelloWorldInvocations", unit=MetricUnit.Count, value=1)
# structured log
# See: https://docs.powertools.aws.dev/lambda-python/latest/core/logger/
logger.info("Hello world API - HTTP 200")
return {"message": "hello world"}
# Enrich logging with contextual information from Lambda
@logger.inject_lambda_context(correlation_id_path=correlation_paths.API_GATEWAY_REST)
# Adding tracer
# See: https://docs.powertools.aws.dev/lambda-python/latest/core/tracer/
@tracer.capture_lambda_handler
# ensures metrics are flushed upon request completion/failure and capturing ColdStart metric
@metrics.log_metrics(capture_cold_start_metric=True)
def lambda_handler(event: dict, context: LambdaContext) -> dict:
return app.resolve(event, context)
```
1. Ouvrez le répertoire **hello\$1world**. Vous devriez voir un fichier nommé **hello\$1world\$1stack.py**.
```
cd ..
cd hello_world
```
1. Ouvrez **hello\$1world\$1stack.py** et ajoutez le code suivant au fichier. Il contient le [constructeur Lambda](https://docs.aws.amazon.com/cdk/api/v1/python/aws_cdk.aws_lambda.html), qui crée la fonction Lambda, configure les variables d'environnement pour Powertools et fixe la durée de conservation des journaux à une semaine, et le [constructeur ApiGatewayv 1](https://docs.aws.amazon.com/cdk/api/v1/python/aws_cdk.aws_apigateway.html), qui crée l'API REST.
```
from aws_cdk import (
Stack,
aws_apigateway as apigwv1,
aws_lambda as lambda_,
CfnOutput,
Duration
)
from constructs import Construct
class HelloWorldStack(Stack):
def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
super().__init__(scope, construct_id, **kwargs)
# Powertools Lambda Layer
powertools_layer = lambda_.LayerVersion.from_layer_version_arn(
self,
id="lambda-powertools",
# At the moment we wrote this example, the aws_lambda_python_alpha CDK constructor is in Alpha, o we use layer to make the example simpler
# See https://docs.aws.amazon.com/cdk/api/v2/python/aws_cdk.aws_lambda_python_alpha/README.html
# Check all Powertools layers versions here: https://docs.powertools.aws.dev/lambda-python/latest/#lambda-layer
layer_version_arn=f"arn:aws:lambda:{self.region}:017000801446:layer:AWSLambdaPowertoolsPythonV2:21"
)
function = lambda_.Function(self,
'sample-app-lambda',
runtime=lambda_.Runtime.PYTHON_3_11,
layers=[powertools_layer],
code = lambda_.Code.from_asset("./lambda_function/"),
handler="app.lambda_handler",
memory_size=128,
timeout=Duration.seconds(3),
architecture=lambda_.Architecture.X86_64,
environment={
"POWERTOOLS_SERVICE_NAME": "PowertoolsHelloWorld",
"POWERTOOLS_METRICS_NAMESPACE": "PowertoolsSample",
"LOG_LEVEL": "INFO"
}
)
apigw = apigwv1.RestApi(self, "PowertoolsAPI", deploy_options=apigwv1.StageOptions(stage_name="dev"))
hello_api = apigw.root.add_resource("hello")
hello_api.add_method("GET", apigwv1.LambdaIntegration(function, proxy=True))
CfnOutput(self, "apiUrl", value=f"{apigw.url}hello")
```
1. Déployez votre application.
```
cd ..
cdk deploy
```
1. Obtenez l’URL de l’application déployée :
```
aws cloudformation describe-stacks --stack-name HelloWorldStack --query 'Stacks[0].Outputs[?OutputKey==`apiUrl`].OutputValue' --output text
```
1. Invoquez le point de terminaison de l’API :
```
curl -X GET
```
En cas de succès, vous obtiendrez cette réponse :
```
{"message":"hello world"}
```
1. Pour obtenir les traces de la fonction, exécutez [sam traces](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-traces.html).
```
sam traces
```
La sortie des traces ressemble à ceci :
```
New XRay Service Graph
Start time: 2023-02-03 14:59:50+00:00
End time: 2023-02-03 14:59:50+00:00
Reference Id: 0 - (Root) AWS::Lambda - sam-app-HelloWorldFunction-YBg8yfYtOc9j - Edges: [1]
Summary_statistics:
- total requests: 1
- ok count(2XX): 1
- error count(4XX): 0
- fault count(5XX): 0
- total response time: 0.924
Reference Id: 1 - AWS::Lambda::Function - sam-app-HelloWorldFunction-YBg8yfYtOc9j - Edges: []
Summary_statistics:
- total requests: 1
- ok count(2XX): 1
- error count(4XX): 0
- fault count(5XX): 0
- total response time: 0.016
Reference Id: 2 - client - sam-app-HelloWorldFunction-YBg8yfYtOc9j - Edges: [0]
Summary_statistics:
- total requests: 0
- ok count(2XX): 0
- error count(4XX): 0
- fault count(5XX): 0
- total response time: 0
XRay Event [revision 1] at (2023-02-03T14:59:50.204000) with id (1-63dd2166-434a12c22e1307ff2114f299) and duration (0.924s)
- 0.924s - sam-app-HelloWorldFunction-YBg8yfYtOc9j [HTTP: 200]
- 0.016s - sam-app-HelloWorldFunction-YBg8yfYtOc9j
- 0.739s - Initialization
- 0.016s - Invocation
- 0.013s - ## lambda_handler
- 0.000s - ## app.hello
- 0.000s - Overhead
```
1. Il s’agit d’un point de terminaison d’API public accessible par Internet. Nous vous recommandons de supprimer le point de terminaison après un test.
```
cdk destroy
```
## Utilisation d’ADOT pour instrumenter vos fonctions python
ADOT fournit des couches [Lambda](chapter-layers.md) entièrement gérées qui regroupent tout ce dont vous avez besoin pour collecter des données de télémétrie à l'aide du SDK. OTel En consommant cette couche, vous pouvez instrumenter vos fonctions Lambda sans avoir à modifier le code de fonction. Vous pouvez également configurer votre couche pour effectuer une initialisation personnalisée de OTel. Pour de plus amples informations, veuillez consulter [Configuration personnalisée pour ADOT Collector sur Lambda](https://aws-otel.github.io/docs/getting-started/lambda#custom-configuration-for-the-adot-collector-on-lambda) dans la documentation ADOT.
Pour les exécutions python, vous pouvez ajouter le**AWS couche Lambda gérée pour ADOT Python**pour instrumenter automatiquement vos fonctions. Cette couche fonctionne à la fois pour les architectures arm64 et x86\$164. Pour obtenir des instructions détaillées sur la façon d'ajouter cette couche, consultez [AWS Distro for OpenTelemetry Lambda Support for](https://aws-otel.github.io/docs/getting-started/lambda/lambda-python) Python dans la documentation ADOT.
## Utilisation du kit SDK X-Ray pour instrumenter vos fonctions Python
Pour enregistrer des détails sur les appels effectués par votre fonction Lambda à d’autres ressources de votre application, vous pouvez également utiliser le Kit SDK AWS X-Ray pour Python. Pour obtenir ce kit SDK, ajoutez le package `aws-xray-sdk` aux dépendances de votre application.
**Example [requirements.txt](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-python/function/requirements.txt)**
```
jsonpickle==1.3
aws-xray-sdk==2.4.3
```
Dans votre code de fonction, vous pouvez instrumenter les clients du AWS SDK en appliquant un correctif à la `boto3` bibliothèque avec le `aws_xray_sdk.core` module.
**Example [function — Suivi d'un AWS client SDK](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-python/function/lambda_function.py)**
```
import boto3
from aws_xray_sdk.core import xray_recorder
from aws_xray_sdk.core import patch_all
logger = logging.getLogger()
logger.setLevel(logging.INFO)
patch_all()
client = boto3.client('lambda')
client.get_account_settings()
def lambda_handler(event, context):
logger.info('## ENVIRONMENT VARIABLES\r' + jsonpickle.encode(dict(**os.environ)))
...
```
Une fois que vous avez ajouté les bonnes dépendances et effectué les modifications de code nécessaires, activez le suivi dans la configuration de votre fonction via la console Lambda ou l’API.
## Activation du suivi avec la console Lambda
Pour activer/désactiver le traçage actif sur votre fonction Lambda avec la console, procédez comme suit :
**Pour activer le traçage actif**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Choisissez **Configuration**, puis choisissez **Outils de surveillance et d’opérations**.
1. Dans **Outils de surveillance supplémentaires**, choisissez **Modifier**.
1. Sous **Signaux CloudWatch d'application et AWS X-Ray** sélectionnez **Activer les traces** de **service Lambda**.
1. Choisissez **Enregistrer**.
## Activation du suivi avec l’API Lambda
Configurez le suivi sur votre fonction Lambda avec le AWS SDK AWS CLI or, utilisez les opérations d'API suivantes :
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)
L'exemple de AWS CLI commande suivant permet d'activer le suivi actif sur une fonction nommée **my-function**.
```
aws lambda update-function-configuration --function-name my-function \
--tracing-config Mode=Active
```
Le mode de suivi fait partie de la configuration spécifique de la version lorsque vous publiez une version de votre fonction. Vous ne pouvez pas modifier le mode de suivi sur une version publiée.
## Activation du traçage avec CloudFormation
Pour activer le suivi d'une `AWS::Lambda::Function` ressource dans un CloudFormation modèle, utilisez la `TracingConfig` propriété.
**Example [function-inline.yml](https://github.com/awsdocs/aws-lambda-developer-guide/blob/master/templates/function-inline.yml) – Configuration du suivi**
```
Resources:
function:
Type: [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)
Properties:
TracingConfig:
Mode: Active
...
```
Pour une `AWS::Serverless::Function` ressource AWS Serverless Application Model (AWS SAM), utilisez la `Tracing` propriété.
**Example [template.yml](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs/template.yml) – Configuration du suivi**
```
Resources:
function:
Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
Properties:
Tracing: Active
...
```
## Interprétation d’un suivi X-Ray
Votre fonction a besoin d’une autorisation pour charger des données de suivi vers X-Ray. Lorsque vous activez le suivi actif dans la console Lambda, Lambda ajoute les autorisations requises au [rôle d’exécution](lambda-intro-execution-role.md) de votre fonction. Dans le cas contraire, ajoutez la [AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess)politique au rôle d'exécution.
Une fois que vous avez configuré le suivi actif, vous pouvez observer des demandes spécifiques via votre application. Le [ graphique de services X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html#xray-concepts-servicegraph) affiche des informations sur votre application et tous ses composants. L’exemple suivant montre une application dotée de deux fonctions. La fonction principale traite les événements et renvoie parfois des erreurs. La deuxième fonction située en haut traite les erreurs qui apparaissent dans le groupe de journaux de la première et utilise le AWS SDK pour appeler X-Ray, Amazon Simple Storage Service (Amazon S3) et Amazon Logs. CloudWatch
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sample-errorprocessor-servicemap.png)
X-Ray ne trace pas toutes les requêtes vers votre application. X-Ray applique un algorithme d’échantillonnage pour s’assurer que le suivi est efficace, tout en fournissant un échantillon représentatif de toutes les demandes. Le taux d’échantillonnage est 1 demande par seconde et 5 % de demandes supplémentaires. Vous ne pouvez pas configurer ce taux d’échantillonnage X-Ray pour vos fonctions.
Dans X-Ray, un *suivi* enregistre des informations sur une demande traitée par un ou plusieurs *services*. Lambda enregistre deux segments par suivi, ce qui a pour effet de créer deux nœuds sur le graphique du service. L’image suivante met en évidence ces deux nœuds :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/xray-servicemap-function.png)
Le premier nœud sur la gauche représente le service Lambda qui reçoit la demande d’invocation. Le deuxième nœud représente votre fonction Lambda spécifique. L’exemple suivant illustre une trace avec ces deux segments. Les deux sont nommés **my-function**, mais l’un a pour origine `AWS::Lambda` et l’autre a pour origine `AWS::Lambda::Function`. Si le segment `AWS::Lambda` affiche une erreur, cela signifie que le service Lambda a rencontré un problème. Si le segment `AWS::Lambda::Function` affiche une erreur, cela signifie que votre fonction a rencontré un problème.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/V2_sandbox_images/my-function-2-v1.png)
Cet exemple développe le segment `AWS::Lambda::Function` pour afficher ses trois sous-segments.
**Note**
AWS met actuellement en œuvre des modifications du service Lambda. En raison de ces modifications, vous pouvez constater des différences mineures entre la structure et le contenu des messages du journal système et des segments de suivi émis par les différentes fonctions Lambda de votre Compte AWS.
L’exemple de suivi présenté ici illustre le segment de fonction à l’ancienne. Les différences entre les segments à l’ancienne et de style moderne sont décrites dans les paragraphes suivants.
Ces modifications seront mises en œuvre au cours des prochaines semaines, et toutes les fonctions, Régions AWS sauf en Chine et dans les GovCloud régions, seront transférées pour utiliser le nouveau format des messages de journal et des segments de trace.
Le segment de fonction à l’ancienne contient les sous-segments suivants :
+ **Initialization (Initialisation)** : représente le temps passé à charger votre fonction et à exécuter le [code d’initialisation](foundation-progmodel.md). Ce sous-segment apparaît pour le premier événement traité par chaque instance de votre fonction.
+ **Invocation** – Représente le temps passé à exécuter votre code de gestionnaire.
+ **Overhead (Travail supplémentaire)** – Représente le temps que le fichier d’exécution Lambda passe à se préparer à gérer l’événement suivant.
Le segment de fonction de style moderne ne contient pas de sous-segment `Invocation`. À la place, les sous-segments du client sont directement rattachés au segment de fonction. Pour plus d’informations sur la structure des segments de fonction à l’ancienne et de style moderne, consultez [Comprendre les suivis X-Ray](services-xray.md#services-xray-traces).
Vous pouvez également utiliser des clients HTTP, enregistrer des requêtes SQL et créer des sous-segments personnalisés avec des annotations et des métadonnées. Pour plus d’informations, consultez [Kit SDK AWS X-Ray pour Python](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-python.html) dans le *AWS X-Ray Guide du développeur*.
**Tarification**
Vous pouvez utiliser le X-Ray Tracing gratuitement chaque mois jusqu'à une certaine limite dans le cadre du niveau AWS gratuit. Au-delà de ce seuil, X-Ray facture le stockage et la récupération du suivi. Pour en savoir plus, consultez [Pricing AWS X-Ray](https://aws.amazon.com/xray/pricing/) (Tarification).
## Stockage des dépendances d’exécution dans une couche (kit SDK X-Ray)
Si vous utilisez le SDK X-Ray pour instrumenter le code de fonction des clients du AWS SDK, votre package de déploiement peut devenir très volumineux. Pour éviter de charger des dépendances d’environnement d’exécution chaque fois que vous mettez à jour votre code de fonction, empaquetez le kit SDK X-Ray dans une [couche Lambda](chapter-layers.md).
L'exemple suivant montre une ressource `AWS::Serverless::LayerVersion` qui stocke le Kit SDK AWS X-Ray pour Python.
**Example [template.yml](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-python/template.yml) : couche de dépendances**
```
Resources:
function:
Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
Properties:
CodeUri: function/.
Tracing: Active
Layers:
- !Ref libs
...
libs:
Type: [AWS::Serverless::LayerVersion](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-layerversion.html)
Properties:
LayerName: blank-python-lib
Description: Dependencies for the blank-python sample app.
ContentUri: package/.
CompatibleRuntimes:
- python3.11
```
Avec cette configuration, vous ne mettez à jour les fichiers de couche de bibliothèque que si vous modifiez vos dépendances d’exécution. Étant donné que le package de déploiement de la fonction contient uniquement votre code, cela peut contribuer à réduire les temps de chargement.
La création d’une couche de dépendances nécessite des modifications de génération pour créer l’archive des couches avant le déploiement. Pour un exemple fonctionnel, consultez l’exemple d’application [blank-python](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-python).