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 C\$1
Vous pouvez exécuter votre application .NET dans Lambda à l'aide du moteur d'exécution .NET 8 géré, d'un environnement d'exécution personnalisé ou d'une image de conteneur. Une fois le code de votre application compilé, vous pouvez le déployer dans Lambda sous la forme d'un fichier .zip ou d'une image de conteneur. Lambda fournit les exécutions suivantes pour les langages .NET :
| Name | Identifiant | Système d’exploitation | Date d’obsolescence | Créer la fonction de blocage | Mettre à jour la fonction de blocage |
| --- | --- | --- | --- | --- | --- |
| .NET 10 | `dotnet10` | Amazon Linux 2023 | 14 novembre 2028 | 14 déc. 2028 | 15 janvier 2029 |
| .NET 9 (conteneur uniquement) | `dotnet9` | Amazon Linux 2023 | 10 novembre 2026 | Non planifié | Non planifié |
| .NET 8 | `dotnet8` | Amazon Linux 2023 | 10 novembre 2026 | 10 déc. 2026 | 11 janvier 2027 |
## Configuration de votre environnement de développement .NET
Pour développer et créer vos fonctions Lambda, vous pouvez utiliser n'importe quel environnement de développement intégré .NET couramment disponible (IDEs), notamment Microsoft Visual Studio, Visual Studio Code et JetBrains Rider. Pour simplifier votre expérience de développement, AWS fournit un ensemble de modèles de projets .NET, ainsi que l'interface de ligne de `Amazon.Lambda.Tools` commande (CLI).
Exécutez les commandes CLI .NET suivantes pour installer ces modèles de projet et ces outils de ligne de commande.
### Installation des modèles de projet .NET
Pour installer les modèles de projet, exécutez la commande suivante :
```
dotnet new install Amazon.Lambda.Templates
```
### Installation et mise à jour des outils CLI
Exécutez les commandes suivantes pour installer, mettre à jour ou désinstaller la CLI `Amazon.Lambda.Tools`.
Pour installer les outils de ligne de commande :
```
dotnet tool install -g Amazon.Lambda.Tools
```
Pour mettre à jour les outils de ligne de commande :
```
dotnet tool update -g Amazon.Lambda.Tools
```
Pour désinstaller les outils de ligne de commande :
```
dotnet tool uninstall -g Amazon.Lambda.Tools
```
# Définition du gestionnaire de fonction Lambda dans C\$1
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 C\$1 pour travailler avec l’environnement d’exécution géré .NET, notamment des options pour la configuration du projet, les conventions de dénomination et les pratiques exemplaires. Cette page inclut également un exemple de fonction Lambda C\$1 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 (S3). Pour plus d’informations sur le déploiement de votre fonction après l’avoir écrite, consultez [Créez et déployez des fonctions Lambda C\$1 à l’aide des archives de fichiers .zip](csharp-package.md) ou [Déployer des fonctions Lambda .NET avec des images conteneurs](csharp-image.md).
**Topics**
+ [
## Configuration de votre projet de gestionnaire C\$1
](#csharp-handler-setup)
+ [
## Exemple de fonction Lambda C\$1
](#csharp-example-code)
+ [
## Gestionnaires de bibliothèques de classes
](#csharp-class-library-handlers)
+ [
## Gestionnaires d'assemblages exécutables
](#csharp-executable-assembly-handlers)
+ [
## Signatures de gestionnaire valides pour les fonctions C\$1
](#csharp-handler-signatures)
+ [
## Convention de nommage du gestionnaire
](#csharp-handler-naming)
+ [
## Sérialisation dans les fonctions Lambda C\$1
](#csharp-handler-serializer)
+ [
## Fonctions basées sur des fichiers
](#csharp-file-based-functions)
+ [
## Accès et utilisation de l’objet de contexte Lambda
](#csharp-example-context)
+ [
## Utilisation de la SDK pour .NET v3 dans votre gestionnaire
](#csharp-example-sdk-usage)
+ [
## Accès aux variables d’environnement
](#csharp-example-envvars)
+ [
## Utilisation de l'état global
](#csharp-handler-state)
+ [
## Simplifiez le code de la fonction à l'aide du cadre d'annotations Lambda
](#csharp-handler-annotations)
+ [
## Pratiques exemplaires de codage pour les fonctions Lambda C\$1
](#csharp-best-practices)
## Configuration de votre projet de gestionnaire C\$1
Lorsque vous utilisez des fonctions Lambda en C\$1, le processus consiste à écrire votre code, puis à le déployer sur Lambda. Il existe deux modèles de déploiement différents pour les fonctions Lambda dans .NET : l’approche de la bibliothèque de classes et l’approche de l’assemblage exécutable.
Dans l’approche de bibliothèque de classes, vous empaquetez le code de votre fonction sous forme d’assemblage .NET (`.dll`) et le déployez sur Lambda avec l’environnement d'exécution géré .NET (`dotnet8`). Pour le nom du gestionnaire, Lambda attend une chaîne au format `AssemblyName::Namespace.Classname::Methodname`. Pendant la phase d'initialisation de la fonction, la classe de votre fonction est initialisée et tout code contenu dans le constructeur est exécuté.
Dans l’approche d’assemblage exécutable, vous utilisez la [fonctionnalité d’instructions de haut niveau](https://learn.microsoft.com/en-us/dotnet/csharp/tutorials/top-level-statements) qui a été introduite pour la première fois avec C\$1 9. Cette approche génère un assemblage exécutable que Lambda exécute chaque fois qu'il reçoit une commande d'invocation pour votre fonction. Dans cette approche, vous utilisez également l’environnement d’exécution géré .NET (`dotnet8`). Pour le nom de gestionnaire, vous fournissez à Lambda le nom de l’assemblage exécutable à exécuter.
L’exemple principal de cette page illustre l’approche de bibliothèque de classes. Vous pouvez initialiser votre projet Lambda C\$1 de différentes manières, mais la méthode la plus simple consiste à utiliser la CLI .NET avec `Amazon.Lambda.Tools` CLI. Configurez `Amazon.Lambda.Tools` CLI en suivant les étapes décrites dans [Configuration de votre environnement de développement .NET](lambda-csharp.md#csharp-dev-env). Ensuite, initialisez votre projet avec la commande suivante :
```
dotnet new lambda.EmptyFunction --name ExampleCS
```
Cette commande génère la structure de fichiers suivante :
```
/project-root
└ src
└ ExampleCS
└ Function.cs (contains main handler)
└ Readme.md
└ aws-lambda-tools-defaults.json
└ ExampleCS.csproj
└ test
└ ExampleCS.Tests
└ FunctionTest.cs (contains main handler)
└ ExampleCS.Tests.csproj
```
Dans cette structure de fichiers, la logique du gestionnaire principal de votre fonction réside dans le fichier `Function.cs`.
## Exemple de fonction Lambda C\$1
L’exemple de code de fonction Lambda C\$1 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 `Function.cs`**
```
using System;
using System.Text;
using System.Threading.Tasks;
using Amazon.Lambda.Core;
using Amazon.S3;
using Amazon.S3.Model;
// Assembly attribute to enable Lambda function logging
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace ExampleLambda;
public class Order
{
public string OrderId { get; set; } = string.Empty;
public double Amount { get; set; }
public string Item { get; set; } = string.Empty;
}
public class OrderHandler
{
private static readonly AmazonS3Client s3Client = new();
public async Task HandleRequest(Order order, ILambdaContext context)
{
try
{
string? bucketName = Environment.GetEnvironmentVariable("RECEIPT_BUCKET");
if (string.IsNullOrWhiteSpace(bucketName))
{
throw new ArgumentException("RECEIPT_BUCKET environment variable is not set");
}
string receiptContent = $"OrderID: {order.OrderId}\nAmount: ${order.Amount:F2}\nItem: {order.Item}";
string key = $"receipts/{order.OrderId}.txt";
await UploadReceiptToS3(bucketName, key, receiptContent);
context.Logger.LogInformation($"Successfully processed order {order.OrderId} and stored receipt in S3 bucket {bucketName}");
return "Success";
}
catch (Exception ex)
{
context.Logger.LogError($"Failed to process order: {ex.Message}");
throw;
}
}
private async Task UploadReceiptToS3(string bucketName, string key, string receiptContent)
{
try
{
var putRequest = new PutObjectRequest
{
BucketName = bucketName,
Key = key,
ContentBody = receiptContent,
ContentType = "text/plain"
};
await s3Client.PutObjectAsync(putRequest);
}
catch (AmazonS3Exception ex)
{
throw new Exception($"Failed to upload receipt to S3: {ex.Message}", ex);
}
}
}
```
Ce fichier `Function.cs` comprend les sections suivantes :
+ Instructions `using` : utilisez ces instructions pour importer les classes C\$1 que votre fonction Lambda nécessite.
+ `[assembly: LambdaSerializer(...)]` : `LambdaSerializer` est un attribut d’assemblage qui indique à Lambda de convertir automatiquement les données utiles des événements JSON en objets C\$1 avant de les transmettre à votre fonction.
+ `namespace ExampleLambda` : définit l’espace de noms. En C\$1, il n’est pas nécessaire que le nom de l’espace de noms corresponde au nom du fichier.
+ `public class Order {...}` : définit la forme de l’événement d’entrée attendu.
+ `public class OrderHandler {...}` : définit votre classe C\$1. Vous y définirez la méthode du gestionnaire principal ainsi que toutes autres méthodes auxiliaires.
+ `private static readonly AmazonS3Client s3Client = new();` : initialise un client Amazon S3 avec la chaîne de fournisseur d’informations d’identification par défaut, en dehors de la méthode du gestionnaire principal. Cela oblige Lambda à exécuter ce code pendant la [phase d’initialisation](lambda-runtime-environment.md#runtimes-lifecycle-ib).
+ `public async ... HandleRequest (Order order, ILambdaContext context)` : il s’agit de la **méthode de gestion principale**, qui contient la logique principale de votre application.
+ `private async Task UploadReceiptToS3(...) {}` : il s’agit d’une méthode auxiliaire référencée par la méthode de gestion principale `handleRequest`.
Comme cette fonction nécessite un client SDK Amazon S3, vous devez l’ajouter aux dépendances de votre projet. Vous pouvez également le faire en accédant à `src/ExampleCS` et en exécutant la commande suivante :
```
dotnet add package AWSSDK.S3
```
### Ajouter des informations de métadonnées au aws-lambda-tools-defaults fichier .json
Par défaut, le fichier `aws-lambda-tools-defaults.json` généré ne contient aucune information `profile` ou `region` relative à votre fonction. Mettez également à jour la chaîne `function-handler` avec la bonne valeur (`ExampleCS::ExampleLambda.OrderHandler::HandleRequest`). Vous pouvez effectuer cette mise à jour manuellement et ajouter les métadonnées nécessaires pour utiliser un profil d’identification et une région spécifiques pour votre fonction. Par exemple, votre fichier `aws-lambda-tools-defaults.json` doit ressembler à ceci :
```
{
"Information": [
"This file provides default values for the deployment wizard inside Visual Studio and the AWS Lambda commands added to the .NET Core CLI.",
"To learn more about the Lambda commands with the .NET Core CLI execute the following command at the command line in the project root directory.",
"dotnet lambda help",
"All the command line options for the Lambda command can be specified in this file."
],
"profile": "default",
"region": "us-east-1",
"configuration": "Release",
"function-architecture": "x86_64",
"function-runtime": "dotnet8",
"function-memory-size": 512,
"function-timeout": 30,
"function-handler": "ExampleCS::ExampleLambda.OrderHandler::HandleRequest"
}
```
Pour que cette fonction fonctionne correctement, son [rôle d’exécution](lambda-intro-execution-role.md) doit autoriser l’action `s3:PutObject`. Assurez-vous également de définir la variable d’environnement `RECEIPT_BUCKET`. Après une invocation réussie, le compartiment Amazon S3 doit contenir un fichier de reçu.
## Gestionnaires de bibliothèques de classes
L’[exemple de code](#csharp-example-code) principal de cette page illustre un gestionnaire de bibliothèques de classes. La structure des gestionnaires de bibliothèques de classes est la suivante :
```
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace NAMESPACE;
...
public class CLASSNAME {
public async Task METHODNAME (...) {
...
}
}
```
Lorsque vous créez une fonction Lambda, vous devez fournir à Lambda des informations sur le gestionnaire de votre fonction sous la forme d’une chaîne dans le [champ Gestionnaire](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-Handler). Cette chaîne indique à Lambda quelle méthode de votre code doit être exécutée lorsque votre fonction est invoquée. En C\$1, pour les gestionnaires de bibliothèques de classes, le format de la chaîne du gestionnaire est `ASSEMBLY::TYPE::METHOD`, où :
+ `ASSEMBLY` est le nom du fichier d'assemblage .NET de votre application. Si vous utilisez la CLI `Amazon.Lambda.Tools` pour créer votre application et que vous ne définissez pas le nom de l’assemblage à l’aide de la propriété `AssemblyName` dans le fichier `.csproj`, alors `ASSEMBLY` est simplement le nom de votre fichier `.csproj`.
+ `TYPE` est le nom complet du type de gestionnaire, à savoir `NAMESPACE.CLASSNAME`.
+ `METHOD` est le nom de la méthode de gestionnaire principale de fonction dans votre code, à savoir `METHODNAME`.
Dans l’exemple de code principal illustré sur cette page, si l’assemblage est nommé `ExampleCS`, alors la chaîne du gestionnaire complète est `ExampleCS::ExampleLambda.OrderHandler::HandleRequest`.
## Gestionnaires d'assemblages exécutables
Vous pouvez également définir des fonctions Lambda en C\$1 sous forme d’assemblage exécutable. Les gestionnaires d’assemblages exécutables utilisent la fonctionnalité d’instructions de haut niveau de C\$1, dans laquelle le compilateur génère la méthode `Main()` et y insère le code de votre fonction. Lors de l'utilisation d'assemblages exécutables, l'exécution Lambda doit être amorcée. Pour ce faire, utilisez la méthode `LambdaBootstrapBuilder.Create` dans votre code. Les entrées de cette méthode sont la fonction principale du gestionnaire ainsi que le sérialiseur Lambda à utiliser. Voici un exemple de gestionnaire d’assemblages exécutables en C\$1 :
```
namespace GetProductHandler;
IDatabaseRepository repo = new DatabaseRepository();
await LambdaBootstrapBuilder.Create(Handler, new DefaultLambdaJsonSerializer())
.Build()
.RunAsync();
async Task Handler(APIGatewayProxyRequest apigProxyEvent, ILambdaContext context)
{
var id = apigProxyEvent.PathParameters["id"];
var databaseRecord = await this.repo.GetById(id);
return new APIGatewayProxyResponse
{
StatusCode = (int)HttpStatusCode.OK,
Body = JsonSerializer.Serialize(databaseRecord)
};
};
```
Dans le [champ Gestionnaire](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-Handler) pour les gestionnaires d’assemblages exécutables, la chaîne du gestionnaire qui indique à Lambda comment exécuter votre code est le nom de l’assemblage. Dans cet exemple, il s’agit de `GetProductHandler`.
## Signatures de gestionnaire valides pour les fonctions C\$1
En C\$1, les signatures de gestionnaire Lambda valides prennent entre 0 et 2 arguments. Généralement, la signature de votre gestionnaire comporte deux arguments, comme indiqué dans l’exemple principal :
```
public async Task HandleRequest(Order order, ILambdaContext context)
```
Lorsque vous fournissez deux arguments, le premier argument doit être l'entrée de l'événement et le second doit être l'objet de contexte Lambda. Les deux arguments sont facultatifs. Par exemple, les signatures de gestionnaire Lambda suivantes sont également valides en C\$1 :
+ `public async Task HandleRequest()`
+ `public async Task HandleRequest(Order order)`
+ `public async Task HandleRequest(ILambdaContext context)`
Outre la syntaxe de base de la signature du gestionnaire, il existe un certain nombre de restrictions supplémentaires :
+ Vous ne pouvez pas utiliser le mot clé `unsafe` dans la signature du gestionnaire. Cependant, vous pouvez utiliser le contexte `unsafe` dans la méthode du gestionnaire et ses dépendances. Pour de plus amples informations, veuillez consulter[dangereux (référence C\$1)](https://msdn.microsoft.com/en-us/library/chfa2zb8.aspx)sur le site Web de documentation de Microsoft.
+ Le gestionnaire ne doit pas utiliser le mot clé `params`, ni utiliser `ArgIterator` comme paramètre d’entrée ou de retour. Ces mots clés prennent en charge un nombre variable de paramètres. Le nombre maximum d’arguments que votre gestionnaire peut accepter est de deux.
+ Le gestionnaire ne peut pas être une méthode générique. En d’autres termes, il ne peut pas utiliser de paramètres de type générique, comme ``.
+ Lambda ne prend pas en charge les gestionnaires asynchrones contenant `async void` dans la signature.
## Convention de nommage du gestionnaire
Les gestionnaires Lambda en C\$1 ne sont pas soumis à des restrictions de dénomination strictes. Toutefois, vous devez vous assurer que vous fournissez la bonne chaîne de gestionnaire à Lambda lorsque vous déployez votre fonction. La bonne chaîne de gestionnaire varie selon que vous déployez un [gestionnaire de bibliothèques de classes](#csharp-class-library-handlers) ou un [gestionnaire d’assemblages exécutables](#csharp-executable-assembly-handlers).
Bien que vous puissiez utiliser n'importe quel nom pour votre gestionnaire, les noms de fonctions en C\$1 sont généralement disponibles. PascalCase De plus, même si le nom du fichier ne doit pas nécessairement correspondre au nom de la classe ou au nom du gestionnaire, il est généralement recommandé d’utiliser un nom de fichier comme `OrderHandler.cs` si le nom de votre classe est `OrderHandler`. Dans cet exemple, vous pouvez modifier le nom de fichier de `Function.cs` à `OrderHandler.cs`.
## Sérialisation dans les fonctions Lambda C\$1
JSON est le format d’entrée le plus courant et standard pour les fonctions Lambda. Dans cet exemple, la fonction exige une entrée similaire à l’exemple suivant :
```
{
"orderId": "12345",
"amount": 199.99,
"item": "Wireless Headphones"
}
```
En C\$1, vous pouvez définir la forme de l’événement d’entrée attendu dans une classe. Dans cet exemple, nous définissons la classe `Order` pour modéliser cette entrée :
```
public class Order
{
public string OrderId { get; set; } = string.Empty;
public double Amount { get; set; }
public string Item { get; set; } = string.Empty;
}
```
Si votre fonction Lambda utilise des types d'entrée ou de sortie autres qu'un objet `Stream`, vous devez ajouter une bibliothèque de sérialisation à votre application. Cela vous permet de convertir l’entrée JSON en une instance de la classe que vous avez définie. Il existe deux méthodes de sérialisation pour les fonctions C\$1 dans Lambda : la sérialisation basée sur la réflexion et la sérialisation générée par la source.
### Sérialisation basée sur la réflexion
AWS fournit des bibliothèques prédéfinies que vous pouvez rapidement ajouter à votre application. Ces bibliothèques implémentent la sérialisation à l’aide de la [réflexion](https://learn.microsoft.com/en-us/dotnet/csharp/advanced-topics/reflection-and-attributes/). Utilisez l’un des packages suivants pour implémenter la sérialisation basée sur la réflexion :
+ `Amazon.Lambda.Serialization.SystemTextJson` : dans le backend, ce package utilise `System.Text.Json` pour effectuer des tâches de sérialisation.
+ `Amazon.Lambda.Serialization.Json` : dans le backend, ce package utilise `Newtonsoft.Json` pour effectuer des tâches de sérialisation.
Vous pouvez également créer votre propre bibliothèque de sérialisation en implémentant l'interface `ILambdaSerializer`, disponible dans la bibliothèque `Amazon.Lambda.Core`. Cette interface définit deux méthodes :
+ `T Deserialize(Stream requestStream);`
Vous implémentez cette méthode afin de désérialiser la charge utile de la demande à partir de l'API `Invoke` dans l'objet qui est transféré à votre gestionnaire de fonction Lambda.
+ `T Serialize(T response, Stream responseStream);`
Vous implémentez cette méthode pour sérialiser le résultat renvoyé à partir de votre gestionnaire de fonction Lambda dans la charge utile de la réponse renvoyée par l'opération d'API `Invoke`.
L’exemple principal de cette page utilise la sérialisation basée sur la réflexion. La sérialisation basée sur la réflexion fonctionne immédiatement AWS Lambda et ne nécessite aucune configuration supplémentaire, ce qui en fait un bon choix pour des raisons de simplicité. Toutefois, elle nécessite une utilisation plus importante de la mémoire de la fonction. Vous pourriez également constater des latences de fonction plus élevées en raison de la réflexion dans l’environnement d’exécution.
### Sérialisation générée par la source
Avec la sérialisation générée par la source, le code de sérialisation est généré au moment de la compilation. Cela supprime le besoin de réflexion et peut améliorer les performances de votre fonction. Pour utiliser la sérialisation générée par la source dans votre fonction, vous devez procéder comme suit :
+ Créez une nouvelle classe partielle qui hérite de `JsonSerializerContext`, en ajoutant des attributs `JsonSerializable` pour tous les types qui nécessitent une sérialisation ou une désérialisation.
+ Configurez le `LambdaSerializer` afin d'utiliser un `SourceGeneratorLambdaJsonSerializer`.
+ Mettez à jour toute sérialisation ou désérialisation manuelle dans le code de votre application afin d’utiliser la classe nouvellement créée.
L’exemple suivant montre comment vous pouvez modifier l’exemple principal de cette page, qui utilise la sérialisation basée sur la réflexion, pour utiliser plutôt la sérialisation générée par la source.
```
using System.Text.Json;
using System.Text.Json.Serialization;
...
public class Order
{
public string OrderId { get; set; } = string.Empty;
public double Amount { get; set; }
public string Item { get; set; } = string.Empty;
}
[JsonSerializable(typeof(Order))]
public partial class OrderJsonContext : JsonSerializerContext {}
public class OrderHandler
{
...
public async Task HandleRequest(string input, ILambdaContext context)
{
var order = JsonSerializer.Deserialize(input, OrderJsonContext.Default.Order);
...
}
}
```
La sérialisation générée par la source nécessite davantage de configuration que la sérialisation basée sur la réflexion. Cependant, les fonctions utilisant la sérialisation générée par la source ont tendance à utiliser moins de mémoire et à offrir de meilleures performances en raison de la génération du code au moment de la compilation. Pour éliminer les [démarrages à froid](lambda-runtime-environment.md#cold-start-latency) des fonctions, envisagez de passer à la sérialisation générée par la source.
**Note**
Si vous souhaitez utiliser la [ahead-of-time compilation native (AOT)](dotnet-native-aot.md) avec Lambda, vous devez utiliser la sérialisation générée par la source.
## Fonctions basées sur des fichiers
Introduites dans .NET 10, les applications basées sur des fichiers vous permettent de créer des applications .NET à partir d'un seul `.cs` fichier, sans structure de `.csproj` fichier ou de répertoire. Lambda prend en charge les fonctions basées sur des fichiers, à commencer par .NET 10. Ils offrent un moyen simple et léger de créer des fonctions Lambda en C\$1.
Le moyen le plus rapide de commencer à créer une fonction Lambda basée sur un fichier C\$1 consiste à utiliser le package. `Amazon.Lambda.Templates` Pour installer le paquet, exécutez la commande suivante :
```
dotnet new install Amazon.Lambda.Templates
```
Ensuite, créez un exemple de fonction Lambda basée sur un fichier C\$1 :
```
dotnet new lambda.FileBased -n MyLambdaFunction
```
Les fonctions basées sur des fichiers utilisent des gestionnaires d'[assemblages exécutables](#csharp-executable-assembly-handlers). Vous devez donc inclure le `Amazon.Lambda.RuntimeSupport` NuGet package et utiliser la `LambdaBootstrapBuilder.Create` méthode pour enregistrer la fonction de gestionnaire .NET pour le type d'événement et démarrer le client d'exécution .NET Lambda.
Les fonctions basées sur des fichiers utilisent .NET Native AOT par défaut, ce qui nécessite une sérialisation générée par la source. Vous pouvez désactiver l'AOT natif en le spécifiant `#:property PublishAot=false` dans votre fichier source. Pour plus d'informations sur l'utilisation de l'AOT natif dans Lambda, consultez. [Compilation du code de fonction Lambda .NET dans un format d’exécution natif](dotnet-native-aot.md)
## Accès et utilisation de l’objet de contexte Lambda
L’[objet de contexte](csharp-context.md) Lambda contient des informations sur l’invocation, la fonction et l’environnement d’exécution. Dans cet exemple, l’objet de contexte est de type `Amazon.Lambda.Core.ILambdaContext`, et constitue le deuxième argument de la fonction de gestion principale.
```
public async Task HandleRequest(Order order, ILambdaContext context) {
...
}
```
L’objet de contexte est une entrée facultative. Pour plus d’informations sur les signatures de gestionnaire acceptées valides, consultez [Signatures de gestionnaire valides pour les fonctions C\$1](#csharp-handler-signatures).
L'objet de contexte est utile pour générer des journaux de fonctions pour Amazon CloudWatch. Vous pouvez utiliser la méthode `context.getLogger()` pour obtenir un objet `LambdaLogger` pour l’enregistrement. Dans cet exemple, nous pouvons utiliser l’enregistreur pour enregistrer un message d’erreur si le traitement échoue pour une raison quelconque :
```
context.Logger.LogError($"Failed to process order: {ex.Message}");
```
En dehors de la journalisation, vous pouvez également utiliser l’objet de contexte pour surveiller les fonctions. Pour plus d’informations sur la copie d’objets, consultez [Utilisation de l’objet de contexte Lambda pour récupérer les informations de la fonction C\$1](csharp-context.md).
## Utilisation de la SDK pour .NET v3 dans votre gestionnaire
Vous utiliserez souvent les fonctions Lambda pour interagir avec d'autres AWS ressources ou pour les mettre à jour. Le moyen le plus simple d'interagir avec ces ressources est d'utiliser la SDK pour .NET version 3.
**Note**
Le SDK pour .NET (v2) est obsolète. Nous vous recommandons de n'utiliser que la SDK pour .NET version 3.
Vous pouvez ajouter des dépendances du SDK à votre projet à l’aide de la commande `Amazon.Lambda.Tools` suivante :
```
dotnet add package
```
Par exemple, dans l’exemple principal sur cette page, nous devons utiliser l’API Amazon S3 pour charger un reçu sur S3. Nous pouvons importer le client du SDK Amazon S3 à l’aide de la commande suivante :
```
dotnet add package AWSSDK.S3
```
Cette commande ajoute la dépendance à votre projet. Vous devriez également voir une ligne similaire à la suivante dans le fichier `.csproj` de votre projet :
```
```
Importez ensuite les dépendances directement dans votre code C\$1 :
```
using Amazon.S3;
using Amazon.S3.Model;
```
L’exemple de code initialise ensuite un client Amazon S3 (en utilisant la [chaîne de fournisseur d’informations d’identification par défaut](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html)) comme suit :
```
private static readonly AmazonS3Client s3Client = new();
```
Dans cet exemple, nous avons initialisé notre client Amazon S3 en dehors de la fonction de gestionnaire principale pour éviter d’avoir à l’initialiser à chaque fois que nous invoquons notre fonction. Après avoir initialisé votre client SDK, vous pouvez l'utiliser pour interagir avec d'autres AWS services. L’exemple de code appelle l’API Amazon S3 `PutObject` comme suit :
```
var putRequest = new PutObjectRequest
{
BucketName = bucketName,
Key = key,
ContentBody = receiptContent,
ContentType = "text/plain"
};
await s3Client.PutObjectAsync(putRequest);
```
## Accès aux variables d’environnement
Dans le code de votre gestionnaire, vous pouvez référencer n’importe quelle [variable d’environnement](configuration-envvars.md) à l’aide de la méthode `System.Environment.GetEnvironmentVariable`. Dans cet exemple, nous référençons la variable d’environnement `RECEIPT_BUCKET` définie à l’aide des lignes de code suivantes :
```
string? bucketName = Environment.GetEnvironmentVariable("RECEIPT_BUCKET");
if (string.IsNullOrWhiteSpace(bucketName))
{
throw new ArgumentException("RECEIPT_BUCKET environment variable is not set");
}
```
## Utilisation de l'état global
Lambda exécute votre code statique et le constructeur de classe pendant la [phase d’initialisation](lambda-runtime-environment.md#runtimes-lifecycle-ib) avant d’invoquer votre fonction pour la première fois. Les ressources créées pendant l’initialisation restent en mémoire entre les invocations, ce qui vous évite d’avoir à les créer chaque fois que vous invoquez votre fonction.
Dans l’exemple de code, le code d’initialisation du client S3 se trouve en dehors de la méthode du gestionnaire principal. L’exécution initialise le client avant que la fonction exécute son premier événement, ce qui peut entraîner des délais de traitement plus longs. Les événements suivants sont beaucoup plus rapides, car Lambda n’a pas besoin d’initialiser à nouveau le client.
## Simplifiez le code de la fonction à l'aide du cadre d'annotations Lambda
Les [annotations Lambda](https://www.nuget.org/packages/Amazon.Lambda.Annotations) constituent un cadre pour .NET 8 qui simplifie l’écriture des fonctions Lambda en utilisant C\$1. Le cadre d’annotations utilise des [générateurs de source](https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/source-generators-overview) pour générer un code qui traduit le modèle de programmation Lambda en code simplifié. Grâce au cadre d'annotations, vous pouvez remplacer une grande partie du code d'une fonction Lambda écrite à l'aide du modèle de programmation habituel. Le code écrit à l'aide du cadre utilise des expressions plus simples qui vous permettent de vous concentrer sur votre logique commerciale. Consultez [Amazon.Lambda.Annotations](https://www.nuget.org/packages/Amazon.Lambda.Annotations) dans la documentation NuGet pour des exemples.
Pour un exemple d'application complète utilisant les annotations Lambda, consultez l'[ PhotoAssetManager](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/dotnetv3/cross-service/PhotoAssetManager)exemple dans le référentiel. `awsdocs/aws-doc-sdk-examples` GitHub Le fichier `Function.cs` principal dans le répertoire `PamApiAnnotations` utilise des annotations Lambda. À titre de comparaison, le répertoire `PamApi` contient des fichiers équivalents écrits à l’aide du modèle de programmation Lambda habituel.
### Injection de dépendances grâce au cadre d'annotations Lambda
Vous pouvez également utiliser le cadre d'annotations Lambda pour ajouter l'injection de dépendance à vos fonctions Lambda en utilisant une syntaxe que vous connaissez bien. Lorsque vous ajoutez un attribut `[LambdaStartup]` à un fichier `Startup.cs`, le cadre d'annotations Lambda génère le code nécessaire au moment de la compilation.
```
[LambdaStartup]
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
services.AddSingleton();
}
}
```
Votre fonction Lambda peut injecter des services en utilisant l'injection de constructeur ou en injectant dans des méthodes individuelles à l'aide de l'attribut `[FromServices]`.
```
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace GetProductHandler;
public class Function
{
private readonly IDatabaseRepository _repo;
public Function(IDatabaseRepository repo)
{
this._repo = repo;
}
[LambdaFunction]
[HttpApi(LambdaHttpMethod.Get, "/product/{id}")]
public async Task FunctionHandler([FromServices] IDatabaseRepository repository, string id)
{
return await this._repo.GetById(id);
}
}
```
## Pratiques exemplaires de codage pour les fonctions Lambda C\$1
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.
+ **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 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 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. Pour les fonctions créées dans .NET, évitez de télécharger l'intégralité de la bibliothèque du AWS SDK dans le cadre de votre package de déploiement. À la place, appuyez-vous de façon sélective sur les modules qui sélectionnent les composants du kit SDK dont vous avez besoin (par exemple, DynamoDB, modules du kit SDK Amazon S3 et bibliothèques principales Lambda).
**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 de code non documenté ni public APIs dans votre code** de fonction Lambda. Pour les AWS Lambda environnements d'exécution gérés, Lambda applique régulièrement des mises à jour de sécurité et fonctionnelles aux applications internes de Lambda. APIs Ces mises à jour internes de l'API peuvent être rétroincompatibles, ce qui peut entraîner des conséquences imprévues, telles que des échecs d'invocation si votre fonction dépend de ces mises à jour non publiques. APIs Consultez [la référence de l'API](https://docs.aws.amazon.com/lambda/latest/api/welcome.html) pour obtenir une liste des API accessibles au public APIs.
**É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/).
# Créez et déployez des fonctions Lambda C\$1 à l’aide des archives de fichiers .zip
Un package de déploiement .NET (archive de fichier .zip) contient l’assemblage compilé de votre fonction ainsi que toutes les dépendances de l’assemblage. Le package contient également un fichier `proj.deps.json`. Il indique à l’exécution .NET toutes les dépendances de votre fonction et un fichier `proj.runtimeconfig.json`, qui est utilisé pour configurer l’exécution.
Pour déployer des fonctions Lambda individuelles, vous pouvez utiliser la CLI .NET Lambda Global de `Amazon.Lambda.Tools`. L’utilisation de la commande `dotnet lambda deploy-function` crée automatiquement un package de déploiement .zip et le déploie sur Lambda. Cependant, nous vous recommandons d’utiliser des cadres tels que le AWS Serverless Application Model (AWS SAM) ou le AWS Cloud Development Kit (AWS CDK) pour déployer vos applications .NET sur AWS.
Les applications sans serveur comprennent généralement une combinaison de fonctions Lambda et d’autres Services AWS gérés qui fonctionnent ensemble pour exécuter une tâche commerciale particulière. AWS SAM et AWS CDK simplifient la création et le déploiement de fonctions Lambda avec d’autres Services AWS à grande échelle. La [spécification du modèle AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification.html) fournit une syntaxe simple et propre pour décrire les fonctions Lambda, les API, les autorisations, les configurations et les autres ressources AWS qui composent votre application sans serveur. Grâce au [AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/home.html), vous pouvez définir l’infrastructure cloud en tant que code pour vous aider à créer des applications fiables, évolutives et rentables dans le cloud à l’aide de langages de programmation et de cadres modernes tels que .NET. Le AWS CDK et le AWS SAM utilisent tous deux la CLI .NET Lambda Global pour empaqueter vos fonctions.
Bien qu’il soit possible d’utiliser des [couches Lambda](chapter-layers.md) avec des fonctions en C\$1 [à l’aide de la CLI .NET Core](csharp-package-cli.md#csharp-layers), nous vous le déconseillons. Les fonctions en C\$1 qui utilisent des couches chargent manuellement les assemblages partagés dans la mémoire pendant le [Phase d’initialisation](lambda-runtime-environment.md#runtimes-lifecycle-ib), ce qui peut augmenter les temps de démarrage à froid. Incluez plutôt tout le code partagé au moment de la compilation pour éviter d’affecter les performances du chargement des assemblages au moment de l’exécution.
Vous trouverez des instructions pour créer et déployer des fonctions Lambda .NET en utilisant le AWS SAM, le AWS CDK et la CLI .NET Lambda Global dans les sections suivantes.
**Topics**
+ [
# Utilisation de la CLI .NET Lambda Global
](csharp-package-cli.md)
+ [
# Déploiement de fonctions Lambda C\$1 à l’aide d’AWS SAM
](csharp-package-sam.md)
+ [
# Déploiement de fonctions Lambda C\$1 à l’aide d’AWS CDK
](csharp-package-cdk.md)
+ [
# Déployez des applications ASP.NET
](csharp-package-asp.md)
# Utilisation de la CLI .NET Lambda Global
La CLI .NET et l’extension .NET Lambda Global Tools (`Amazon.Lambda.Tools`) offrent un moyen multiplateforme de créer des applications Lambda basées sur .NET, de les empaqueter et de les déployer dans Lambda. Dans cette section, vous apprendrez à créer de nouveaux projets Lambda .NET à l’aide de la CLI .NET et des modèles Amazon Lambda, et à les empaqueter et les déployer en utilisant `Amazon.Lambda.Tools`
**Topics**
+ [
## Prérequis
](#csharp-package-cli-prerequisites)
+ [
## Création de projets .NET à l’aide de la CLI .NET
](#csharp-package-cli-create)
+ [
## Déploiement de projets .NET à l’aide de la CLI .NET
](#csharp-package-cli-deploy)
+ [
## Utilisation de couches Lambda avec l’interface de ligne de commande .NET
](#csharp-layers)
## Prérequis
**Kit SDK .NET 8**
Si vous ne l’avez pas encore fait, installez le kit SDK [.NET 8](https://dotnet.microsoft.com/en-us/download/dotnet/8.0) et l’environnement d’exécution.
**Modèles de projet .NET d’Amazon.Lambda.Templates AWS**
Pour générer votre code de fonction Lambda, utilisez le package NuGet [https://www.nuget.org/packages/Amazon.Lambda.Templates](https://www.nuget.org/packages/Amazon.Lambda.Templates). Pour installer ce package de modèle, exécutez la commande suivante :
```
dotnet new install Amazon.Lambda.Templates
```
**Outils globaux CLI .NET d’Amazon.Lambda.Tools AWS**
Pour créer vos fonctions Lambda, utilisez l’[https://www.nuget.org/packages/Amazon.Lambda.Tools](https://www.nuget.org/packages/Amazon.Lambda.Tools) [extension outils globaux .NET](https://aws.amazon.com/blogs/developer/net-core-global-tools-for-aws/). Pour installer Amazon.Lambda.Tools, exécutez la commande suivante :
```
dotnet tool install -g Amazon.Lambda.Tools
```
Pour en savoir plus sur l’extension CLI .NET Amazon.Lambda.Tools, consultez le référentiel [Extensions pour la CLI .NET AWS](https://github.com/aws/aws-extensions-for-dotnet-cli) dans GitHub.
## Création de projets .NET à l’aide de la CLI .NET
Dans la CLI .NET, utilisez la commande `dotnet new` pour créer des projets .NET à partir de la ligne de commande. Lambda propose des modèles supplémentaires à l’aide du package NuGet [https://www.nuget.org/packages/Amazon.Lambda.Templates](https://www.nuget.org/packages/Amazon.Lambda.Templates).
Après avoir installé ce package, exécutez la commande suivante pour obtenir la liste des modèles disponibles.
```
dotnet new list
```
Pour examiner les détails relatifs à un modèle, utilisez l’option `help`. Par exemple, pour obtenir des détails sur le modèle `lambda.EmptyFunction`, exécutez la commande suivante.
```
dotnet new lambda.EmptyFunction --help
```
Pour créer un modèle de base pour une fonction Lambda .NET, utilisez le modèle `lambda.EmptyFunction`. Celui-ci crée une fonction simple qui prend une chaîne comme entrée et la convertit en majuscules à l’aide de la méthode `ToUpper`. Ce modèle prend en charge les options suivantes :
+ `--name` – Nom de la fonction.
+ `--region` – Région AWS dans laquelle la fonction doit être créée.
+ `--profile` – Nom d’un profil dans votre fichier d’informations d’identification AWS SDK pour .NET. Pour en savoir plus sur les profils d’informations d’identification dans .NET, consultez la section [Configurer les informations d’identification AWS](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/net-dg-config-creds.html) dans le *Guide du développeur du kit SDK AWS pour .NET*.
Dans cet exemple, nous créons une nouvelle fonction vide nommée `myDotnetFunction` en utilisant le profil et les paramètres par défaut Région AWS :
```
dotnet new lambda.EmptyFunction --name myDotnetFunction
```
Cette commande crée les fichiers et répertoires suivants dans le répertoire de votre projet.
```
└── myDotnetFunction
├── src
│ └── myDotnetFunction
│ ├── Function.cs
│ ├── Readme.md
│ ├── aws-lambda-tools-defaults.json
│ └── myDotnetFunction.csproj
└── test
└── myDotnetFunction.Tests
├── FunctionTest.cs
└── myDotnetFunction.Tests.csproj
```
Sous le répertoire `src/myDotnetFunction`, examinez les fichiers suivants :
+ **aws-lambda-tools-defaults.json** : c’est ici que vous spécifiez les options de ligne de commande lors du déploiement de votre fonction Lambda. Exemples :
```
"profile" : "default",
"region" : "us-east-2",
"configuration" : "Release",
"function-architecture": "x86_64",
"function-runtime":"dotnet8",
"function-memory-size" : 256,
"function-timeout" : 30,
"function-handler" : "myDotnetFunction::myDotnetFunction.Function::FunctionHandler"
```
+ **Function.cs** : code de fonction de votre gestionnaire Lambda. Il s’agit d’un modèle C \$1 qui inclut la bibliothèque `Amazon.Lambda.Core` par défaut et un attribut `LambdaSerializer` par défaut. Pour plus d’informations sur les conditions de sérialisation et les options, consultez [Sérialisation dans les fonctions Lambda C\$1](csharp-handler.md#csharp-handler-serializer). Il inclut également un exemple de fonction que vous pouvez modifier pour appliquer votre code de fonction Lambda.
```
using Amazon.Lambda.Core;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace myDotnetFunction;
public class Function
{
///
/// A simple function that takes a string and does a ToUpper
///
///
///
public string FunctionHandler(string input, ILambdaContext context)
{
return input.ToUpper();
}
}
```
+ **myDotnetFunction.csproj** : un fichier [MSBuild](https://msdn.microsoft.com/en-us/library/dd393574.aspx) qui répertorie les fichiers et les assemblages qui composent votre application.
```
net8.0
enable
enable
true
Lambda
true
true
```
+ **Readme** : utilisez ce fichier pour documenter votre fonction Lambda.
Sous le répertoire `myfunction/test`, examinez les fichiers suivants :
+ **myDotnetFunction.Tests.csproj** : comme indiqué précédemment, il s’agit d’un fichier [MSBuild](https://msdn.microsoft.com/en-us/library/dd393574.aspx) qui répertorie les fichiers et les assemblages qui composent votre projet de test. Notez également qu’il comprend aussi la bibliothèque `Amazon.Lambda.Core`, ce qui vous permet d’intégrer de manière transparente tout modèle Lambda requis pour tester votre fonction.
```
...
...
```
+ **FunctionTest.cs** : le même fichier de modèle de code C\$1 que celui inclus dans le répertoire `src`. Modifiez ce fichier pour mettre en miroir le code de production de votre fonction, et testez-le avant de télécharger votre fonction Lambda sur un environnement de production.
```
using Xunit;
using Amazon.Lambda.Core;
using Amazon.Lambda.TestUtilities;
using MyFunction;
namespace MyFunction.Tests
{
public class FunctionTest
{
[Fact]
public void TestToUpperFunction()
{
// Invoke the lambda function and confirm the string was upper cased.
var function = new Function();
var context = new TestLambdaContext();
var upperCase = function.FunctionHandler("hello world", context);
Assert.Equal("HELLO WORLD", upperCase);
}
}
}
```
## Déploiement de projets .NET à l’aide de la CLI .NET
Pour créer votre package de déploiement et le déployer sur Lambda, utilisez les outils CLI `Amazon.Lambda.Tools`. Pour déployer votre fonction à partir des fichiers que vous avez créés dans les étapes précédentes, accédez d’abord au dossier contenant le fichier `.csproj` de votre fonction.
```
cd myDotnetFunction/src/myDotnetFunction
```
Pour déployer votre code sur Lambda sous la forme d’un package de déploiement .zip, exécutez la commande suivante. Choisissez le nom de votre fonction.
```
dotnet lambda deploy-function myDotnetFunction
```
Pendant le déploiement, l’assistant vous invite à sélectionner un [Définition des autorisations de fonction Lambda avec un rôle d’exécution](lambda-intro-execution-role.md). Pour cet exemple, sélectionnez le `lambda_basic_role`.
Une fois votre fonction déployée, vous pouvez la tester dans le cloud en utilisant la commande `dotnet lambda invoke-function`. Pour l’exemple de code dans le modèle `lambda.EmptyFunction`, vous pouvez tester votre fonction en transmettant une chaîne en utilisant l’option `--payload`.
```
dotnet lambda invoke-function myDotnetFunction --payload "Just checking if everything is OK"
```
Si votre fonction a été déployée avec succès, vous devriez obtenir une sortie similaire à celle qui suit.
```
dotnet lambda invoke-function myDotnetFunction --payload "Just checking if everything is OK"
Amazon Lambda Tools for .NET Core applications (5.8.0)
Project Home: https://github.com/aws/aws-extensions-for-dotnet-cli, https://github.com/aws/aws-lambda-dotnet
Payload:
"JUST CHECKING IF EVERYTHING IS OK"
Log Tail:
START RequestId: id Version: $LATEST
END RequestId: id
REPORT RequestId: id Duration: 0.99 ms Billed Duration: 1 ms Memory Size: 256 MB Max Memory Used: 12 MB
```
## Utilisation de couches Lambda avec l’interface de ligne de commande .NET
**Note**
Bien qu’il soit possible d’utiliser des [couches](chapter-layers.md) avec dans .NET, nous vous le déconseillons. Les fonctions en .NET qui utilisent des couches chargent manuellement les assemblages partagés dans la mémoire pendant la phase `Init`, ce qui peut augmenter les temps de démarrage à froid. Incluez plutôt tout le code partagé au moment de la compilation pour tirer parti des optimisations intégrées du compilateur .NET.
L’interface de ligne de commande .NET prend en charge les commandes qui vous aident à publier des couches et à déployer des fonctions C\$1 consommant des couches. Pour publier une couche dans un compartiment Amazon S3 spécifié, exécutez la commande suivante dans le même répertoire que votre fichier `.csproj` :
```
dotnet lambda publish-layer --layer-type runtime-package-store --s3-bucket
```
Ensuite, lorsque vous déployez votre fonction à l’aide de l’interface de ligne de commande .NET, spécifiez l’ARN de couche à consommer dans la commande suivante :
```
dotnet lambda deploy-function --function-layers arn:aws:lambda:us-east-1:123456789012:layer:layer-name:1
```
Pour un exemple complet de fonction Hello World, consultez l’exemple [blank-csharp-with-layer](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-csharp-with-layer).
# Déploiement de fonctions Lambda C\$1 à l’aide d’AWS SAM
L’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 commande AWS SAM (AWS SAM CLI) pour créer, empaqueter et déployer vos applications. Lorsque vous créez une fonction Lambda à partir d’un modèle AWS SAM, AWS SAM crée automatiquement un package de déploiement .zip ou une image de conteneur avec le code de votre fonction et toutes les dépendances que vous spécifiez. Ensuite, AWS SAM déploie votre fonction à l’aide d’une [pile CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacks.html). Pour en savoir plus sur l’utilisation d’AWS SAM pour créer et déployer des fonctions Lambda, veuillez consulter la rubrique [Premiers pas avec AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-getting-started.html) dans le *Guide du développeur AWS Serverless Application Model*.
Les étapes suivantes vous montrent comment télécharger, créer et déployer un exemple d’application Hello World en .NET à l’aide de AWS SAM. Cet exemple d’application utilise une fonction Lambda et un point de terminaison Amazon API Gateway pour implémenter une API backend de base. Lorsque vous envoyez une requête HTTP GET à votre point de terminaison API Gateway, API Gateway invoque votre fonction Lambda. La fonction renvoie un message « hello world », ainsi que l’adresse IP de l’instance de la fonction Lambda qui traite votre requête.
Lorsque vous créez et déployez votre application à l’aide de AWS SAM, en arrière-plan, la CLI AWS SAM utilise la commande `dotnet lambda package` pour empaqueter les différents paquets de code de la fonction Lambda.
## Prérequis
**Kit SDK .NET 8**
Installez l’environnement d’exécution et le kit SDK [.NET 8](https://dotnet.microsoft.com/en-us/download/dotnet/8.0).
**Version 1.39 ou ultérieure de la CLI AWS SAM**
Pour savoir comment installer la dernière version de la CLI AWS SAM, consultez la section [Installation de la CLI AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html).
## Déployer un exemple d’application AWS SAM
1. Initialisez l’application en utilisant le modèle Hello world .NET à l’aide de la commande suivante.
```
sam init --app-template hello-world --name sam-app \
--package-type Zip --runtime dotnet8
```
Cette commande crée les fichiers et répertoires suivants dans le répertoire de votre projet.
```
└── sam-app
├── README.md
├── events
│ └── event.json
├── omnisharp.json
├── samconfig.toml
├── src
│ └── HelloWorld
│ ├── Function.cs
│ ├── HelloWorld.csproj
│ └── aws-lambda-tools-defaults.json
├── template.yaml
└── test
└── HelloWorld.Test
├── FunctionTest.cs
└── HelloWorld.Tests.csproj
```
1. Accédez au répertoire contenant le `template.yaml file`. Ce fichier est un modèle qui définit les ressources AWS de votre application, notamment votre fonction Lambda et API Gateway.
```
cd sam-app
```
1. Pour créer la source de votre application, exécutez la commande suivante.
```
sam build
```
1. Pour déployer votre application sur AWS, exécutez la commande suivante.
```
sam deploy --guided
```
Cette commande permet d’empaqueter et de déployer votre application à l’aide de la série d’invites suivante. Pour accepter les options par défaut, appuyez sur Entrée.
**Note**
Pour **HelloWorldFunction peut ne pas avoir d’autorisation définie, est-ce correct ?**, assurez-vous de saisir `y`.
+ **Nom de la pile** : nom de la pile à déployer sur CloudFormation. Ce nom doit être propre à votre Compte AWS et à votre Région AWS.
+ **Région AWS** : la Région AWS dans laquelle vous souhaitez déployer votre application.
+ **Confirmer les modifications avant le déploiement** : sélectionnez oui pour examiner manuellement tous les ensembles de modifications avant que AWS SAM ne déploie les modifications de l’application. Si vous sélectionnez non, la CLI AWS SAM déploie automatiquement les modifications de l’application.
+ **Autoriser la création de rôles IAM par la CLI SAM** : de nombreux modèles AWS SAM, y compris celui de Hello world dans cet exemple, créent des rôles (IAM) Gestion des identités et des accès AWS pour donner à vos fonctions Lambda l’autorisation d’accéder à d’autres Services AWS. Sélectionnez Oui pour autoriser le déploiement d’une pile CloudFormation qui crée ou modifie des rôles IAM.
+ **Désactiver le retour en arrière** : par défaut, si AWS SAM rencontre une erreur lors de la création ou du déploiement de votre pile, il revient à la version précédente. Sélectionnez Non pour accepter cette valeur par défaut.
+ **HelloWorldFunction n’a peut-être pas d’autorisation définie, est-ce correct** : Saisissez `y`.
+ **Enregistrer les arguments dans samconfig.toml** : sélectionnez oui pour enregistrer vos choix de configuration. À l’avenir, vous pourrez à nouveau exécuter `sam deploy` sans paramètres pour déployer les modifications apportées à votre application.
1. Une fois le déploiement de votre application terminé, la CLI renvoie l’Amazon Resource Name (ARN) de la fonction Lambda Hello World et le rôle IAM créé pour cette fonction. Elle affiche également le point de terminaison de votre API Gateway. Pour tester votre application, ouvrez le point de terminaison dans un navigateur. Vous devriez voir une réponse similaire à la suivante.
```
{"message":"hello world","location":"34.244.135.203"}
```
1. Pour supprimer vos ressources, exécutez la commande suivante. Notez que le point de terminaison de l’API que vous avez créé est un point de terminaison public accessible via le réseau Internet. Nous vous recommandons de supprimer ce point de terminaison après les tests.
```
sam delete
```
## Étapes suivantes
Pour en savoir plus sur l’utilisation de AWS SAM pour créer et déployer des fonctions Lambda à l’aide de .NET, consultez les ressources suivantes :
+ Le [https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html)
+ [Création d’applications .NET sans serveur à l’aide de AWS Lambda et de la CLI SAM](https://aws.amazon.com/blogs/dotnet/building-serverless-net-applications-with-aws-lambda-and-the-sam-cli/)
# Déploiement de fonctions Lambda C\$1 à l’aide d’AWS CDK
Le AWS Cloud Development Kit (AWS CDK) est un cadre de développement logiciel libre permettant de définir une infrastructure cloud sous forme de code à l’aide de langages de programmation modernes et de cadres tels que .NET. Les projets AWS CDK sont exécutés pour générer des modèles CloudFormation qui sont ensuite utilisés pour déployer votre code.
Pour créer et déployer un exemple d’application Hello world .NET à l’aide de AWS CDK, suivez les instructions décrites dans les sections suivantes. L’exemple d’application implémente une API backend de base composée d’un point de terminaison API Gateway et d’une fonction Lambda. Lorsque vous envoyez une requête HTTP GET au point de terminaison, API Gateway invoque la fonction Lambda. La fonction renvoie un message Hello world, ainsi que l’adresse IP de l’instance Lambda qui traite votre requête.
## Prérequis
**Kit SDK .NET 8**
Installez l’environnement d’exécution et le kit SDK [.NET 8](https://dotnet.microsoft.com/en-us/download/dotnet/8.0).
**Version 2 de AWS CDK**
Pour savoir comment installer la dernière version de AWS CDK, consultez la section [Démarrer avec le AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html) dans le *Guide du développeur v2 de AWS Cloud Development Kit (AWS CDK)*.
## Déployer un exemple d’application AWS CDK
1. Créez un répertoire de projet pour l’application modèle et accédez à ce répertoire.
```
mkdir hello-world
cd hello-world
```
1. Initialisez une nouvelle application AWS CDK en exécutant la commande suivante.
```
cdk init app --language csharp
```
La commande crée les fichiers et répertoires suivants dans votre répertoire de projet.
```
├── README.md
├── cdk.json
└── src
├── HelloWorld
│ ├── GlobalSuppressions.cs
│ ├── HelloWorld.csproj
│ ├── HelloWorldStack.cs
│ └── Program.cs
└── HelloWorld.sln
```
1. Ouvrez le répertoire `src` et créez une nouvelle fonction Lambda à l’aide de la CLI .NET. Il s’agit de la fonction que vous allez déployer à l’aide de AWS CDK. Dans cet exemple, vous créez une fonction Hello world nommée `HelloWorldLambda` à l’aide du modèle `lambda.EmptyFunction`.
```
cd src
dotnet new lambda.EmptyFunction -n HelloWorldLambda
```
Après cette étape, la structure de votre répertoire à l’intérieur de votre répertoire de projet devrait ressembler à ce qui suit.
```
├── README.md
├── cdk.json
└── src
├── HelloWorld
│ ├── GlobalSuppressions.cs
│ ├── HelloWorld.csproj
│ ├── HelloWorldStack.cs
│ └── Program.cs
├── HelloWorld.sln
└── HelloWorldLambda
├── src
│ └── HelloWorldLambda
│ ├── Function.cs
│ ├── HelloWorldLambda.csproj
│ ├── Readme.md
│ └── aws-lambda-tools-defaults.json
└── test
└── HelloWorldLambda.Tests
├── FunctionTest.cs
└── HelloWorldLambda.Tests.csproj
```
1. Ouvrez le fichier `HelloWorldStack.cs` à partir du répertoire `src/HelloWorld`. Remplacez le contenu du fichier par le code suivant.
```
using Amazon.CDK;
using Amazon.CDK.AWS.Lambda;
using Amazon.CDK.AWS.Logs;
using Constructs;
namespace CdkTest
{
public class HelloWorldStack : Stack
{
internal HelloWorldStack(Construct scope, string id, IStackProps props = null) : base(scope, id, props)
{
var buildOption = new BundlingOptions()
{
Image = Runtime.DOTNET_8.BundlingImage,
User = "root",
OutputType = BundlingOutput.ARCHIVED,
Command = new string[]{
"/bin/sh",
"-c",
" dotnet tool install -g Amazon.Lambda.Tools"+
" && dotnet build"+
" && dotnet lambda package --output-package /asset-output/function.zip"
}
};
var helloWorldLambdaFunction = new Function(this, "HelloWorldFunction", new FunctionProps
{
Runtime = Runtime.DOTNET_8,
MemorySize = 1024,
LogRetention = RetentionDays.ONE_DAY,
Handler = "HelloWorldLambda::HelloWorldLambda.Function::FunctionHandler",
Code = Code.FromAsset("./src/HelloWorldLambda/src/HelloWorldLambda", new Amazon.CDK.AWS.S3.Assets.AssetOptions
{
Bundling = buildOption
}),
});
}
}
}
```
Il s’agit du code permettant de compiler et de regrouper le code de l’application, ainsi que de la définition de la fonction Lambda elle-même. L’objet `BundlingOptions` permet de créer un fichier zip, ainsi qu’un ensemble de commandes utilisées pour générer le contenu du fichier zip. Dans ce cas, la commande `dotnet lambda package` est utilisée pour compiler et générer le fichier zip.
1. Pour déployer votre application, exécutez la commande suivante.
```
cdk deploy
```
1. Invoquez votre fonction Lambda déployée à l’aide de la CLI .NET Lambda.
```
dotnet lambda invoke-function HelloWorldFunction -p "hello world"
```
1. Une fois les tests terminés, vous pouvez supprimer les ressources que vous avez créées, à moins que vous souhaitez les conserver. Exécutez la commande suivante pour supprimer vos ressources.
```
cdk destroy
```
## Étapes suivantes
Pour en savoir plus sur l’utilisation de AWS CDK pour créer et déployer des fonctions Lambda à l’aide de .NET, consultez les ressources suivantes :
+ [Utilisation de CDK AWS en C\$1](https://docs.aws.amazon.com/cdk/v2/guide/work-with-cdk-csharp.html)
+ [Créez, empaquetez et publiez des fonctions Lambda .NET C\$1 à l’aide de CDK AWS](https://aws.amazon.com/blogs/modernizing-with-aws/build-package-publish-dotnet-csharp-lambda-functions-aws-cdk/)
# Déployez des applications ASP.NET
Outre l’hébergement de fonctions événementielles, vous pouvez également utiliser .NET avec Lambda pour héberger des applications ASP.NET légères. Vous pouvez créer et déployer des applications ASP.NET à l’aide du package NuGet `Amazon.Lambda.AspNetCoreServer`. Dans cette section, vous apprendrez à déployer une API web ASP.NET sur Lambda à l’aide de l’outillage de la CLI .NET Lambda.
**Topics**
+ [
## Prérequis
](#csharp-package-asp-prerequisites)
+ [
## Déploiement d’une API Web ASP.NET sur Lambda
](#csharp-package-asp-deploy-api)
+ [
## Déploiement des API minimales ASP.NET sur Lambda
](#csharp-package-asp-deploy-minimal)
## Prérequis
**Kit SDK .NET 8**
Installez l’environnement d’exécution ASP.NET Core et le kit SDK [.NET 8](https://dotnet.microsoft.com/en-us/download/dotnet/8.0).
**Amazon.Lambda.Tools**
Pour créer vos fonctions Lambda, utilisez l’[https://www.nuget.org/packages/Amazon.Lambda.Tools](https://www.nuget.org/packages/Amazon.Lambda.Tools) [extension outils globaux .NET](https://aws.amazon.com/blogs/developer/net-core-global-tools-for-aws/). Pour installer Amazon.Lambda.Tools, exécutez la commande suivante :
```
dotnet tool install -g Amazon.Lambda.Tools
```
Pour en savoir plus sur l’extension CLI .NET Amazon.Lambda.Tools, consultez le référentiel [Extensions pour la CLI .NET AWS](https://github.com/aws/aws-extensions-for-dotnet-cli) dans GitHub.
**Amazon.Lambda.Templates**
Pour générer votre code de fonction Lambda, utilisez le package NuGet [https://www.nuget.org/packages/Amazon.Lambda.Templates](https://www.nuget.org/packages/Amazon.Lambda.Templates). Pour installer ce package de modèle, exécutez la commande suivante :
```
dotnet new --install Amazon.Lambda.Templates
```
## Déploiement d’une API Web ASP.NET sur Lambda
Pour déployer une API web à l’aide d’ASP.NET, vous pouvez utiliser les modèles Lambda .NET pour créer un nouveau projet d’API web. Utilisez la commande suivante pour initialiser un nouveau projet d’API web ASP.NET. Dans l’exemple de commande, nous nommons le projet `AspNetOnLambda`.
```
dotnet new serverless.AspNetCoreWebAPI -n AspNetOnLambda
```
Cette commande crée les fichiers et répertoires suivants dans le répertoire de votre projet.
```
.
└── AspNetOnLambda
├── src
│ └── AspNetOnLambda
│ ├── AspNetOnLambda.csproj
│ ├── Controllers
│ │ └── ValuesController.cs
│ ├── LambdaEntryPoint.cs
│ ├── LocalEntryPoint.cs
│ ├── Readme.md
│ ├── Startup.cs
│ ├── appsettings.Development.json
│ ├── appsettings.json
│ ├── aws-lambda-tools-defaults.json
│ └── serverless.template
└── test
└── AspNetOnLambda.Tests
├── AspNetOnLambda.Tests.csproj
├── SampleRequests
│ └── ValuesController-Get.json
├── ValuesControllerTests.cs
└── appsettings.json
```
Lorsque Lambda invoque votre fonction, le point d’entrée qu’elle utilise est le fichier `LambdaEntryPoint.cs`. Le fichier créé par le modèle Lambda .NET contient le code suivant.
```
namespace AspNetOnLambda;
public class LambdaEntryPoint : Amazon.Lambda.AspNetCoreServer.APIGatewayProxyFunction
{
protected override void Init(IWebHostBuilder builder)
{
builder
.UseStartup≪Startup≫();
}
protected override void Init(IHostBuilder builder)
{
}
}
```
Le point d’entrée utilisé par Lambda doit hériter de l’une des trois classes de base du package `Amazon.Lambda.AspNetCoreServer`. Ces trois classes de base sont les suivantes :
+ `APIGatewayProxyFunction`
+ `APIGatewayHttpApiV2ProxyFunction`
+ `ApplicationLoadBalancerFunction`
La classe par défaut utilisée lorsque vous créez votre fichier `LambdaEntryPoint.cs` à l’aide du modèle Lambda .NET fourni est `APIGatewayProxyFunction`. La classe de base que vous utilisez dans votre fonction dépend de la couche d’API qui se trouve devant votre fonction Lambda.
Chacune des trois classes de base contient une méthode publique appelée `FunctionHandlerAsync`. Le nom de cette méthode fera partie de la [chaîne du gestionnaire](csharp-handler.md#csharp-class-library-handlers) que Lambda utilise pour invoquer votre fonction. La méthode `FunctionHandlerAsync` transforme la charge utile de l’événement entrant dans le format ASP.NET correct et la réponse ASP.NET en une charge utile de réponse Lambda. Pour l’exemple de projet `AspNetOnLambda` affiché, la chaîne du gestionnaire serait la suivante.
```
AspNetOnLambda::AspNetOnLambda.LambdaEntryPoint::FunctionHandlerAsync
```
Pour déployer l’API sur Lambda, exécutez les commandes suivantes pour accéder au répertoire contenant votre fichier de code source et déployer votre fonction à l’aide de CloudFormation.
```
cd AspNetOnLambda/src/AspNetOnLambda
dotnet lambda deploy-serverless
```
**Astuce**
Lorsque vous déployez une API à l’aide de la commande `dotnet lambda deploy-serverless`, CloudFormation attribue à votre fonction Lambda un nom basé sur le nom de pile que vous avez spécifié lors du déploiement. Pour donner un nom personnalisé à votre fonction Lambda, modifiez le fichier `serverless.template` pour ajouter une propriété `FunctionName` à la ressource `AWS::Serverless::Function`. Pour en savoir plus, consultez [Type de nom](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-name.html) dans le *Guide de l’utilisateur CloudFormation*.
## Déploiement des API minimales ASP.NET sur Lambda
Pour déployer une API minimale ASP.NET sur Lambda, vous pouvez utiliser les modèles Lambda .NET pour créer un nouveau projet d’API minimale. Utilisez la commande suivante pour initialiser un nouveau projet d’API minimale. Dans cet exemple, nous nommons le projet `MinimalApiOnLambda`.
```
dotnet new serverless.AspNetCoreMinimalAPI -n MinimalApiOnLambda
```
La commande crée les fichiers et répertoires suivants dans le répertoire de votre projet.
```
└── MinimalApiOnLambda
└── src
└── MinimalApiOnLambda
├── Controllers
│ └── CalculatorController.cs
├── MinimalApiOnLambda.csproj
├── Program.cs
├── Readme.md
├── appsettings.Development.json
├── appsettings.json
├── aws-lambda-tools-defaults.json
└── serverless.template
```
Le fichier `Program.cs` contient le code suivant.
```
var builder = WebApplication.CreateBuilder(args);
// Add services to the container.
builder.Services.AddControllers();
// Add AWS Lambda support. When application is run in Lambda Kestrel is swapped out as the web server with Amazon.Lambda.AspNetCoreServer. This
// package will act as the webserver translating request and responses between the Lambda event source and ASP.NET Core.
builder.Services.AddAWSLambdaHosting(LambdaEventSource.RestApi);
var app = builder.Build();
app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();
app.MapGet("/", () => "Welcome to running ASP.NET Core Minimal API on AWS Lambda");
app.Run();
```
Pour configurer votre API minimale afin qu’elle s’exécute sur Lambda, vous devrez peut-être modifier ce code pour que les demandes et les réponses entre Lambda et ASP.NET Core soient correctement traduites. La fonction est configurée par défaut pour une source d’événements d’API REST. Pour une API HTTP ou un équilibreur de charge d’application, remplacez `(LambdaEventSource.RestApi)` par l’une des options suivantes :
+ `(LambdaEventSource.HttpAPi)`
+ `(LambdaEventSource.ApplicationLoadBalancer)`
Pour déployer votre API minimale sur Lambda, exécutez les commandes suivantes pour accéder au répertoire contenant votre fichier de code source et déployer votre fonction à l’aide de CloudFormation.
```
cd MinimalApiOnLambda/src/MinimalApiOnLambda
dotnet lambda deploy-serverless
```
# Utilisation de couches pour les fonctions Lambda .NET
Nous déconseillons d’utiliser des [couches](chapter-layers.md) pour gérer les dépendances des fonctions Lambda écrites en .NET. .NET étant un langage compilé, vos fonctions doivent toujours charger manuellement les assemblages partagés dans la mémoire pendant la phase d’[initialisation](lambda-runtime-environment.md#runtimes-lifecycle-ib), ce qui peut augmenter les temps de démarrage à froid. L’utilisation de couches complique non seulement le processus de déploiement, mais vous empêche également de tirer parti des optimisations du compilateur intégré.
Pour utiliser des dépendances externes avec vos gestionnaires .NET, incluez-les directement dans votre package de déploiement au moment de la compilation. Ce faisant, vous simplifiez le processus de déploiement et profitez des optimisations du compilateur .NET intégré. Pour un exemple d’importation et d’utilisation des dépendances comme les packages NuGet dans votre fonction, consultez [Définition du gestionnaire de fonction Lambda dans C\$1](csharp-handler.md).
# Déployer des fonctions Lambda .NET avec des images conteneurs
Il existe trois méthodes pour créer une image de conteneur pour une fonction Lambda .NET :
+ [Utilisation d'une image AWS de base pour .NET](#csharp-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 .NET](#csharp-image-clients) dans l’image.
+ [Utilisation d'une image non AWS basique](#csharp-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 .NET](#csharp-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 .NET
](#csharp-image-base)
+ [
## Utilisation d'une image AWS de base pour .NET
](#csharp-image-instructions)
+ [
## Utilisation d’une autre image de base avec le client d’interface d’exécution
](#csharp-image-clients)
## AWS images de base pour .NET
AWS fournit les images de base suivantes pour .NET :
| Étiquettes | Environnement d’exécution | Système d’exploitation | Dockerfile | Obsolescence |
| --- | --- | --- | --- | --- |
| 10 | .NET 10 | Amazon Linux 2023 | [Dockerfile pour .NET 10 sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/dotnet10/Dockerfile.dotnet10) | 14 novembre 2028 |
| 9 | .NET 9 | Amazon Linux 2023 | [Dockerfile pour .NET 9 sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/dotnet9/Dockerfile.dotnet9) | 10 novembre 2026 |
| 8 | .NET 8 | Amazon Linux 2023 | [Dockerfile pour .NET 8 sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/dotnet8/Dockerfile.dotnet8) | 10 novembre 2026 |
Référentiel Amazon ECR : [gallery.ecr. aws/lambda/dotnet](https://gallery.ecr.aws/lambda/dotnet)
## Utilisation d'une image AWS de base pour .NET
### Conditions préalables
Pour exécuter la procédure indiquée dans cette section, vous devez satisfaire aux exigences suivantes :
+ [SDK .NET](https://dotnet.microsoft.com/download) : les étapes suivantes utilisent l’image de base .NET 8. Assurez-vous que votre version de .NET correspond à la version de l’[image de base](https://gallery.ecr.aws/lambda/dotnet) que vous spécifiez dans votre Dockerfile.
+ [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.
### Création et déploiement d’une image à l’aide d’une image de base
Dans les étapes suivantes, vous utilisez [Amazon.Lambda.Templates](https://github.com/aws/aws-lambda-dotnet#dotnet-cli-templates) et [Amazon.Lambda.Tools](https://github.com/aws/aws-extensions-for-dotnet-cli#aws-lambda-amazonlambdatools) pour créer un projet .NET. Ensuite, vous créez une image Docker, vous chargez l’image sur Amazon ECR et vous la déployez vers une fonction Lambda.
1. Installez le package [Amazon.Lambda.Templates.](https://github.com/aws/aws-lambda-dotnet#dotnet-cli-templates) NuGet
```
dotnet new install Amazon.Lambda.Templates
```
1. Créez un projet .NET en utilisant le modèle `lambda.image.EmptyFunction`.
```
dotnet new lambda.image.EmptyFunction --name MyFunction --region us-east-1
```
Les fichiers de projet sont stockés dans le répertoire `MyFunction/src/MyFunction` :
+ **aws-lambda-tools-defaults.json** : Spécifie les options de ligne de commande pour déployer votre fonction Lambda.
+ **Function.cs** : code de fonction de votre gestionnaire Lambda. Il s’agit d’un modèle C\$1 qui inclut la bibliothèque `Amazon.Lambda.Core` par défaut et un attribut `LambdaSerializer` par défaut. Pour plus d’informations sur les conditions de sérialisation et les options, consultez [Sérialisation dans les fonctions Lambda C\$1](csharp-handler.md#csharp-handler-serializer). Vous pouvez utiliser le code fourni pour les tests ou le remplacer par le vôtre.
+ **MyFunction.csproj** : [fichier de projet](https://learn.microsoft.com/en-us/dotnet/core/project-sdk/overview#project-files) .NET répertoriant les fichiers et les assemblages composant votre application.
+ **Dockerfile** : vous pouvez utiliser le Dockerfile fourni pour les tests ou le remplacer par le vôtre. Si vous utilisez le vôtre, assurez-vous de :
+ Définir la propriété `FROM` sur l’[URI de l’image de base](https://gallery.ecr.aws/lambda/dotnet). L’image de base et `TargetFramework` dans le fichier `MyFunction.csproj` doivent tous deux utiliser la même version de .NET. Par exemple, pour utiliser .NET 9 :
+ Fichier Docker : `FROM public.ecr.aws/lambda/dotnet:9`
+ MyFunction.csproj : `net9.0`
+ Définir l’argument `CMD` pour le gestionnaire de la fonction Lambda. Il doit correspondre à `image-command` dans `aws-lambda-tools-defaults.json`.
1. Installer l’[outil global .NET](https://aws.amazon.com/blogs/developer/net-core-global-tools-for-aws/) d’Amazon.Lambda.Tools.
```
dotnet tool install -g Amazon.Lambda.Tools
```
Si Amazon.Lambda.Tools est déjà installé, assurez-vous que vous disposez de la dernière version.
```
dotnet tool update -g Amazon.Lambda.Tools
```
1. Changez le répertoire en `MyFunction/src/MyFunction`, si vous n’y êtes pas déjà.
```
cd src/MyFunction
```
1. Utilisez Amazon.Lambda.Tools pour créer l’image Docker, l’envoyer (push) vers un nouveau référentiel Amazon ECR, et déployer la fonction Lambda.
Pour `--function-role`, indiquez le nom du rôle, et non l’Amazon Resource Name (ARN), du [rôle d’exécution](lambda-intro-execution-role.md) de la fonction. Par exemple, `lambda-role`.
```
dotnet lambda deploy-function MyFunction --function-role lambda-role
```
Pour plus d'informations sur l'outil global .NET Amazon.Lambda.Tools, consultez le référentiel Extensions [AWS for .NET](https://github.com/aws/aws-extensions-for-dotnet-cli) CLI sur. GitHub
1. Invoquer la fonction.
```
dotnet lambda invoke-function MyFunction --payload "Testing the function"
```
Si tout réussit, vous verrez une réponse similaire à ce qui suit :
```
Payload:
{"Lower":"testing the function","Upper":"TESTING THE FUNCTION"}
Log Tail:
INIT_REPORT Init Duration: 9999.81 ms Phase: init Status: timeout
START RequestId: 12378346-f302-419b-b1f2-deaa1e8423ed Version: $LATEST
END RequestId: 12378346-f302-419b-b1f2-deaa1e8423ed
REPORT RequestId: 12378346-f302-419b-b1f2-deaa1e8423ed Duration: 3173.06 ms Billed Duration: 3174 ms Memory Size: 512 MB Max Memory Used: 24 MB
```
1. Supprimez la fonction Lambda.
```
dotnet lambda delete-function MyFunction
```
## 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.
L'exemple suivant montre comment créer une image de conteneur pour .NET à l'aide d'une image non AWS basique et comment ajouter le [fichier Amazon.Lambda. RuntimeSupport ](https://github.com/aws/aws-lambda-dotnet/blob/master/Libraries/src/Amazon.Lambda.RuntimeSupport/README.md#using-amazonlambdaruntimesupport-as-a-class-library)package, qui est le client d'interface d'exécution Lambda pour .NET. L’exemple de Dockerfile utilise l’image de base Microsoft .NET 8.
### Conditions préalables
Pour exécuter la procédure indiquée dans cette section, vous devez satisfaire aux exigences suivantes :
+ [SDK .NET](https://dotnet.microsoft.com/download) — Les étapes suivantes utilisent une image de base .NET 9. Assurez-vous que votre version de .NET correspond à la version de l’image de base que vous spécifiez dans votre Dockerfile.
+ [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.
### Création et déploiement d’une image à l’aide d’une image de base alternative
1. Installez le package [Amazon.Lambda.Templates.](https://github.com/aws/aws-lambda-dotnet#dotnet-cli-templates) NuGet
```
dotnet new install Amazon.Lambda.Templates
```
1. Créez un projet .NET en utilisant le modèle `lambda.CustomRuntimeFunction`. Ce modèle inclut l'[Amazon.Lambda. RuntimeSupport](https://github.com/aws/aws-lambda-dotnet/blob/master/Libraries/src/Amazon.Lambda.RuntimeSupport/README.md#using-amazonlambdaruntimesupport-as-a-class-library)colis.
```
dotnet new lambda.CustomRuntimeFunction --name MyFunction --region us-east-1
```
1. Accédez au répertoire `MyFunction/src/MyFunction`. C’est ici que les fichiers du projet sont stockés. Examinez les fichiers suivants :
+ **aws-lambda-tools-defaults.json** — Ce fichier vous permet de spécifier les options de ligne de commande lors du déploiement de votre fonction Lambda.
+ **Function.cs** : le code contient une classe avec une méthode `Main` qui initialise la bibliothèque `Amazon.Lambda.RuntimeSupport` en tant qu’amorce. La méthode `Main` est le point d’entrée du processus de la fonction. La méthode `Main` enveloppe le gestionnaire de fonctions dans un encapsuleur avec lequel l’amorce peut travailler. Pour plus d'informations, consultez la section [Utilisation d'Amazon.Lambda. RuntimeSupport en tant que bibliothèque de classes](https://github.com/aws/aws-lambda-dotnet/blob/master/Libraries/src/Amazon.Lambda.RuntimeSupport/README.md#using-amazonlambdaruntimesupport-as-a-class-library) dans le GitHub référentiel.
+ **MyFunction.csproj** : [fichier de projet](https://learn.microsoft.com/en-us/dotnet/core/project-sdk/overview#project-files) .NET répertoriant les fichiers et les assemblages composant votre application.
+ **Readme.md** : ce fichier contient plus d’informations sur l’exemple de fonction Lambda.
1. Ouvrez le fichier `aws-lambda-tools-defaults.json` et ajoutez les lignes suivantes :
```
"package-type": "image",
"docker-host-build-output-dir": "./bin/Release/lambda-publish"
```
+ **package-typee** : définit le package de déploiement en tant qu’image de conteneur.
+ **docker-host-build-output-dir** : définit le répertoire de sortie pour le processus de construction.
**Example aws-lambda-tools-defaults.json**
```
{
"Information": [
"This file provides default values for the deployment wizard inside Visual Studio and the AWS Lambda commands added to the .NET Core CLI.",
"To learn more about the Lambda commands with the .NET Core CLI execute the following command at the command line in the project root directory.",
"dotnet lambda help",
"All the command line options for the Lambda command can be specified in this file."
],
"profile": "",
"region": "us-east-1",
"configuration": "Release",
"function-runtime": "provided.al2023",
"function-memory-size": 256,
"function-timeout": 30,
"function-handler": "bootstrap",
"msbuild-parameters": "--self-contained true",
"package-type": "image",
"docker-host-build-output-dir": "./bin/Release/lambda-publish"
}
```
1. Créez un Dockerfile dans le référentiel `MyFunction/src/MyFunction`. L’exemple de Dockerfile suivant utilise une image de base Microsoft .NET au lieu d’une [image de base AWS](#csharp-image-base).
+ Définissez la propriété `FROM` pour l’identifiant de l’image de base. L’image de base et `TargetFramework` dans le fichier `MyFunction.csproj` doivent tous deux utiliser la même version de .NET.
+ Utilisez la commande `COPY` pour copier la fonction dans le répertoire `/var/task`.
+ 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 l’amorce, qui initialise la bibliothèque `Amazon.Lambda.RuntimeSupport`.
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**
```
# You can also pull these images from DockerHub amazon/aws-lambda-dotnet:8
FROM mcr.microsoft.com/dotnet/runtime:9.0
# Set the image's internal work directory
WORKDIR /var/task
# Copy function code to Lambda-defined environment variable
COPY "bin/Release/net9.0/linux-x64" .
# Set the entrypoint to the bootstrap
ENTRYPOINT ["/usr/bin/dotnet", "exec", "/var/task/bootstrap.dll"]
```
1. Installez l’[extension de l’outil global .NET](https://aws.amazon.com/blogs/developer/net-core-global-tools-for-aws/) d’Amazon.Lambda.Tools.
```
dotnet tool install -g Amazon.Lambda.Tools
```
Si Amazon.Lambda.Tools est déjà installé, assurez-vous que vous disposez de la dernière version.
```
dotnet tool update -g Amazon.Lambda.Tools
```
1. Utilisez Amazon.Lambda.Tools pour créer l’image Docker, l’envoyer (push) vers un nouveau référentiel Amazon ECR, et déployer la fonction Lambda.
Pour `--function-role`, indiquez le nom du rôle, et non l’Amazon Resource Name (ARN), du [rôle d’exécution](lambda-intro-execution-role.md) de la fonction. Par exemple, `lambda-role`.
```
dotnet lambda deploy-function MyFunction --function-role lambda-role
```
Pour plus d'informations sur l'extension .NET CLI Amazon.Lambda.Tools, consultez le référentiel [AWS Extensions for .NET](https://github.com/aws/aws-extensions-for-dotnet-cli) CLI sur. GitHub
1. Invoquer la fonction.
```
dotnet lambda invoke-function MyFunction --payload "Testing the function"
```
Si tout réussit, vous devez voir ce qui suit :
```
Payload:
"TESTING THE FUNCTION"
Log Tail:
START RequestId: id Version: $LATEST
END RequestId: id
REPORT RequestId: id Duration: 0.99 ms Billed Duration: 1 ms Memory Size: 256 MB Max Memory Used: 12 MB
```
1. Supprimez la fonction Lambda.
```
dotnet lambda delete-function MyFunction
```
# Compilation du code de fonction Lambda .NET dans un format d’exécution natif
.NET 8 prend en charge la compilation anticipée (AOT) native. Avec la compilation anticipée native, vous pouvez compiler le code de votre fonction Lambda dans un format d’environnement d’exécution natif, ce qui élimine la nécessité de compiler le code .NET au moment de l’exécution. La compilation anticipée native peut réduire le temps de démarrage à froid des fonctions Lambda que vous écrivez en .NET. Pour plus d’informations, consultez [Introducing the .NET 8 runtime for AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-the-net-8-runtime-for-aws-lambda/) sur le blog AWS Compute.
**Topics**
+ [
## Le fichier d’exécution Lambda
](#dotnet-native-aot-runtime)
+ [
## Prérequis
](#dotnet-native-aot-prerequisites)
+ [
## Prise en main
](#dotnet-native-aot-getting-started)
+ [
## Sérialisation
](#dotnet-native-aot-serialization)
+ [
## Réduction
](#dotnet-native-aot-trimming)
+ [
## Résolution des problèmes
](#dotnet-native-aot-troubleshooting)
## Le fichier d’exécution Lambda
Pour déployer une fonction Lambda créée avec une compilation AOT native, utilisez l’environnement d’exécution Lambda géré de .NET 8. Cet environnement d’exécution prend en charge l’utilisation des architectures x86\$164 et arm64.
Lorsque vous déployez une fonction Lambda .NET sans utiliser AOT, votre application est d’abord compilée en code de langage intermédiaire (IL). Au moment de l’environnement d’exécution, le compilateur JIT (just-in-time) de l’environnement d’exécution Lambda prend le code IL et le compile en code machine selon les besoins. Avec une fonction Lambda compilée à l’avance avec l’AOT native, vous compilez votre code en code machine lorsque vous déployez votre fonction, de sorte que vous ne dépendez pas de l’environnement d’exécution .NET ou du kit SDK dans l’environnement d’exécution Lambda pour compiler votre code avant qu’il ne s’exécute.
L’une des limites de l’AOT est que le code de votre application doit être compilé dans un environnement doté du même système d’exploitation Amazon Linux 2023 (AL2023) que celui utilisé par l’environnement d’exécution .NET 8. La CLI Lambda .NET fournit une fonctionnalité permettant de compiler votre application dans un conteneur Docker à l’aide d’une image AL2023.
Pour éviter d’éventuels problèmes de compatibilité entre architectures, nous vous recommandons vivement de compiler votre code dans un environnement doté de la même architecture de processeur que celle que vous avez configurée pour votre fonction. Pour en savoir plus sur les limites de la compilation entre architectures, consultez [Compilation croisée](https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/cross-compile) dans la documentation Microsoft .NET.
## Prérequis
**Docker**
Pour utiliser l’AOT native, votre code de fonction doit être compilé dans un environnement doté du même système d’exploitation AL2023 que l’environnement d’exécution .NET 8. Les commandes de la CLI .NET des sections suivantes utilisent Docker pour développer et construire des fonctions Lambda dans un environnement AL2023.
**Kit SDK .NET 8**
La compilation AOT native est une fonctionnalité de .NET 8. Vous devez installer le [kit SDK .NET 8](https://dotnet.microsoft.com/en-us/download/dotnet/8.0) sur votre machine de compilation, et pas seulement l’environnement d’exécution.
**Amazon.Lambda.Tools**
Pour créer vos fonctions Lambda, utilisez l’[https://www.nuget.org/packages/Amazon.Lambda.Tools](https://www.nuget.org/packages/Amazon.Lambda.Tools) [extension outils globaux .NET](https://aws.amazon.com/blogs/developer/net-core-global-tools-for-aws/). Pour installer Amazon.Lambda.Tools, exécutez la commande suivante :
```
dotnet tool install -g Amazon.Lambda.Tools
```
Pour en savoir plus sur l’extension CLI .NET Amazon.Lambda.Tools, consultez le référentiel [Extensions pour la CLI .NET AWS](https://github.com/aws/aws-extensions-for-dotnet-cli) dans GitHub.
**Amazon.Lambda.Templates**
Pour générer votre code de fonction Lambda, utilisez le package NuGet [https://www.nuget.org/packages/Amazon.Lambda.Templates](https://www.nuget.org/packages/Amazon.Lambda.Templates). Pour installer ce package de modèle, exécutez la commande suivante :
```
dotnet new install Amazon.Lambda.Templates
```
## Prise en main
La CLI globale .NET et le AWS Serverless Application Model (AWS SAM) fournissent tous deux des modèles de démarrage pour créer des applications à l’aide de la compilation anticipée native. Pour créer votre première fonction Lambda à l’aide de la compilation anticipée native, suivez les étapes décrites dans les instructions suivantes.
**Pour initialiser et déployer une fonction Lambda compilée à l’aide de la compilation anticipée native**
1. Initialisez un nouveau projet en utilisant le modèle de la compilation anticipée native, puis naviguez dans le répertoire contenant les fichiers créés `.cs` et `.csproj`. Dans cet exemple, nous allons nommer notre fonction `NativeAotSample`.
```
dotnet new lambda.NativeAOT -n NativeAotSample
cd ./NativeAotSample/src/NativeAotSample
```
Le fichier créé `Function.cs` par le modèle de la compilation anticipée native contient le code de fonction suivant.
```
using Amazon.Lambda.Core;
using Amazon.Lambda.RuntimeSupport;
using Amazon.Lambda.Serialization.SystemTextJson;
using System.Text.Json.Serialization;
namespace NativeAotSample;
public class Function
{
///
/// The main entry point for the Lambda function. The main function is called once during the Lambda init phase. It
/// initializes the .NET Lambda runtime client passing in the function handler to invoke for each Lambda event and
/// the JSON serializer to use for converting Lambda JSON format to the .NET types.
///
private static async Task Main()
{
Func handler = FunctionHandler;
await LambdaBootstrapBuilder.Create(handler, new SourceGeneratorLambdaJsonSerializer())
.Build()
.RunAsync();
}
///
/// A simple function that takes a string and does a ToUpper.
///
/// To use this handler to respond to an AWS event, reference the appropriate package from
/// https://github.com/aws/aws-lambda-dotnet#events
/// and change the string input parameter to the desired event type. When the event type
/// is changed, the handler type registered in the main method needs to be updated and the LambdaFunctionJsonSerializerContext
/// defined below will need the JsonSerializable updated. If the return type and event type are different then the
/// LambdaFunctionJsonSerializerContext must have two JsonSerializable attributes, one for each type.
///
// When using Native AOT extra testing with the deployed Lambda functions is required to ensure
// the libraries used in the Lambda function work correctly with Native AOT. If a runtime
// error occurs about missing types or methods the most likely solution will be to remove references to trim-unsafe
// code or configure trimming options. This sample defaults to partial TrimMode because currently the AWS
// SDK for .NET does not support trimming. This will result in a larger executable size, and still does not
// guarantee runtime trimming errors won't be hit.
///
///
///
///
public static string FunctionHandler(string input, ILambdaContext context)
{
return input.ToUpper();
}
}
///
/// This class is used to register the input event and return type for the FunctionHandler method with the System.Text.Json source generator.
/// There must be a JsonSerializable attribute for each type used as the input and return type or a runtime error will occur
/// from the JSON serializer unable to find the serialization information for unknown types.
///
[JsonSerializable(typeof(string))]
public partial class LambdaFunctionJsonSerializerContext : JsonSerializerContext
{
// By using this partial class derived from JsonSerializerContext, we can generate reflection free JSON Serializer code at compile time
// which can deserialize our class and properties. However, we must attribute this class to tell it what types to generate serialization code for.
// See https://docs.microsoft.com/en-us/dotnet/standard/serialization/system-text-json-source-generation
```
La compilation anticipée native permet de compiler votre application en un seul fichier binaire natif. Le point d’entrée de ce fichier binaire est la méthode `static Main`. Dans `static Main`, l’exécution Lambda est amorcée et la méthode `FunctionHandler` est configurée. Dans le cadre de l’amorçage de l’exécution, un sérialiseur généré par la source est configuré à l’aide de `new SourceGeneratorLambdaJsonSerializer()`
1. Pour déployer votre application sur Lambda, assurez-vous que Docker est en cours d’exécution dans votre environnement local et exécutez la commande suivante.
```
dotnet lambda deploy-function
```
En arrière plan, la CLI globale .NET télécharge une image Docker AL2023 et compile le code de votre application à l’intérieur d’un conteneur en cours d’exécution. Le fichier binaire compilé est renvoyé vers votre système de fichiers local avant d’être déployé sur Lambda.
1. Testez votre fonction en exécutant la commande suivante. Remplacez `` par le nom que vous avez choisi pour votre fonction dans l’assistant de déploiement.
```
dotnet lambda invoke-function --payload "hello world"
```
La réponse de la CLI comprend des détails sur les performances pour le démarrage à froid (durée d’initialisation) et la durée totale d’exécution de l’invocation de la fonction.
1. Pour supprimer les ressources AWS que vous avez créées en suivant les étapes précédentes, exécutez la commande suivante. Remplacez `` par le nom que vous avez choisi pour votre fonction dans l’assistant de déploiement. En supprimant les ressources AWS que vous n’utilisez plus, vous évitez que des frais inutiles soient facturés à votre Compte AWS.
```
dotnet lambda delete-function
```
## Sérialisation
Pour déployer des fonctions sur Lambda à l’aide de la compilation anticipée native, le code de votre fonction doit utiliser la [sérialisation générée par la source](https://learn.microsoft.com/en-us/dotnet/standard/serialization/system-text-json/source-generation-modes?pivots=dotnet-8-0). Au lieu d’utiliser la réflexion au moment de l’exécution pour rassembler les métadonnées nécessaires à l’accès aux propriétés des objets pour la sérialisation, les générateurs de sources génèrent des fichiers sources C\$1 qui sont compilés lorsque vous créez votre application. Pour configurer correctement le sérialiseur généré par la source, assurez-vous d’inclure tous les objets d’entrée et de sortie utilisés par votre fonction, ainsi que tous les types personnalisés. Par exemple, une fonction Lambda qui reçoit des événements d’API Gateway pour une API REST et renvoie un type de `Product` personnalisé inclurait un sérialiseur défini comme suit.
```
[JsonSerializable(typeof(APIGatewayProxyRequest))]
[JsonSerializable(typeof(APIGatewayProxyResponse))]
[JsonSerializable(typeof(Product))]
public partial class CustomSerializer : JsonSerializerContext
{
}
```
## Réduction
La compilation anticipée native permet de réduire le code de votre application dans le cadre de la compilation afin de s’assurer que le fichier binaire est aussi petit que possible. .NET 8 pour Lambda offre une meilleure prise en charge du découpage par rapport aux versions précédentes de .NET. La prise en charge a été ajoutée aux [bibliothèques d’environnement d’exécution Lambda](https://github.com/aws/aws-lambda-dotnet/pull/1596), au [kit SDK AWS .NET](https://github.com/aws/aws-sdk-net/pulls?q=is%3Apr+trimming), aux [annotations .NET Lambda](https://github.com/aws/aws-lambda-dotnet/pull/1610) et à .NET 8 lui-même.
Ces améliorations offrent la possibilité d’éliminer les avertissements de découpage au moment de la création, mais .NET ne sera jamais totalement sûr en matière de découpage. Cela signifie que certaines parties des bibliothèques sur lesquelles votre fonction repose peuvent être supprimées lors de l’étape de compilation. Vous pouvez gérer cela en le définissant `TrimmerRootAssemblies` dans le cadre de votre fichier `.csproj`, comme indiqué dans l’exemple suivant.
```
```
Notez que lorsque vous recevez un avertissement de découpage, l’ajout de la classe qui génère l’avertissement `TrimmerRootAssembly` risque de ne pas résoudre le problème. Un avertissement de découpage indique que la classe essaie d’accéder à une autre classe qui ne peut être déterminée avant l’exécution. Pour éviter les erreurs d’exécution, ajoutez cette deuxième classe à `TrimmerRootAssembly`.
Pour en savoir plus sur la gestion des avertissements de découpage, consultez [Introduction aux avertissements de découpage](https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/fixing-warnings) dans la documentation Microsoft .NET.
## Résolution des problèmes
**Error: Cross-OS native compilation is not supported. (Erreur : la compilation native entre systèmes d’exploitation n’est pas prise en charge).**
Votre version de l’outil global .NET Core Amazon.Lambda.Tools n’est pas à jour. Mettez à jour vers la dernière version et réessayez.
**Docker : l’image du système d’exploitation « linux » ne peut pas être utilisée sur cette plateforme.**
Docker sur votre système est configuré pour utiliser des conteneurs Windows. Passez aux conteneurs Linux pour exécuter l’environnement de création anticipée native.
Pour plus d’informations sur les erreurs courantes, consultez le référentiel [AWS NativeAOT for .NET](https://github.com/awslabs/dotnet-nativeaot-labs#common-errors) (français non garanti) sur GitHub.
# Utilisation de l’objet de contexte Lambda pour récupérer les informations de la fonction C\$1
Lorsque Lambda exécute votre fonction, il transmet un objet de contexte au [gestionnaire](csharp-handler.md). Cet objet fournit les propriétés avec des informations sur l'appel, la fonction et l'environnement d'exécution.
**Propriétés du contexte**
+ `FunctionName` – Nom de la fonction Lambda.
+ `FunctionVersion` – [Version](configuration-versions.md) de la fonction.
+ `InvokedFunctionArn` – Amazon Resource Name (ARN) utilisé pour appeler la fonction. Indique si l’appelant a spécifié un numéro de version ou un alias.
+ `MemoryLimitInMB` – Quantité de mémoire allouée à la fonction.
+ `AwsRequestId` – Identifiant de la demande d’invocation.
+ `LogGroupName` – Groupe de journaux pour la fonction.
+ `LogStreamName` – Flux de journal de l'instance de fonction.
+ `RemainingTime` (`TimeSpan`) – Nombre de millisecondes restant avant l'expiration de l'exécution.
+ `Identity` – (applications mobiles) Informations sur l'identité Amazon Cognito qui a autorisé la demande.
+ `ClientContext` – (applications mobiles) Contexte client fourni à Lambda par l'application client.
+ `Logger` L'[objet enregistreur d'événements](csharp-logging.md) pour la fonction.
Vous pouvez utiliser les informations contenues dans l'objet `ILambdaContext` pour générer des informations sur l'invocation de votre fonction à des fins de contrôle. Le code suivant montre comment ajouter des informations contextuelles à un cadre de journalisation structuré. Dans cet exemple, la fonction ajoute `AwsRequestId` aux sorties du journal. La fonction utilise également la propriété `RemainingTime` pour annuler une tâche en vol si le délai d'attente de la fonction Lambda est sur le point d'être atteint.
```
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace GetProductHandler;
public class Function
{
private readonly IDatabaseRepository _repo;
public Function()
{
this._repo = new DatabaseRepository();
}
public async Task FunctionHandler(APIGatewayProxyRequest request, ILambdaContext context)
{
Logger.AppendKey("AwsRequestId", context.AwsRequestId);
var id = request.PathParameters["id"];
using var cts = new CancellationTokenSource();
try
{
cts.CancelAfter(context.RemainingTime.Add(TimeSpan.FromSeconds(-1)));
var databaseRecord = await this._repo.GetById(id, cts.Token);
return new APIGatewayProxyResponse
{
StatusCode = (int)HttpStatusCode.OK,
Body = JsonSerializer.Serialize(databaseRecord)
};
}
catch (Exception ex)
{
return new APIGatewayProxyResponse
{
StatusCode = (int)HttpStatusCode.InternalServerError,
Body = JsonSerializer.Serialize(new { error = ex.Message })
};
}
finally
{
cts.Cancel();
}
}
}
```
# Journalisation et surveillance des fonctions Lambda C\$1
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).
**Topics**
+ [
## Création d’une fonction qui renvoie des journaux
](#csharp-logging-output)
+ [
## Utilisation des contrôles de journalisation avancés de Lambda avec .NET
](#csharp-logging-advanced)
+ [
## Outils de journalisation et bibliothèques supplémentaires
](#csharp-tools-libraries)
+ [
## Utilisation de Powertools pour AWS Lambda (.NET) et AWS SAM pour la journalisation structurée
](#dotnet-logging-sam)
+ [
## Affichage des journaux dans la console Lambda
](#csharp-logging-console)
+ [
## Afficher les journaux dans la CloudWatch console
](#csharp-logging-cwconsole)
+ [
## Afficher les journaux à l'aide de AWS Command Line Interface (AWS CLI)
](#csharp-logging-cli)
+ [
## Suppression de journaux
](#csharp-logging-delete)
## Création d’une fonction qui renvoie des journaux
Pour générer des journaux à partir de votre code de fonction, vous pouvez utiliser le [ILambdaLogger](https://github.com/aws/aws-lambda-dotnet/blob/master/Libraries/src/Amazon.Lambda.Core/ILambdaLogger.cs) sur l'objet de contexte, les méthodes de la [classe Console](https://docs.microsoft.com/en-us/dotnet/api/system.console) ou toute bibliothèque de journalisation qui écrit dans `stdout` ou`stderr`.
L’environnement d’exécution .NET enregistre les lignes `START`, `END` et `REPORT` pour chaque invocation. La ligne de rapport fournit les détails suivants.
**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 des contrôles de journalisation avancés de Lambda avec .NET
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 .NET pris en charge :
+ **Format de journal** : choisissez entre le format texte brut et le format JSON structuré pour les journaux de votre fonction
+ **Niveau du journal** : pour les journaux au format JSON, choisissez le niveau de détail des journaux auxquels Lambda envoie 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 utiliser le format de journal et les options de niveau de journal avec vos fonctions Lambda .NET, consultez les instructions des sections suivantes.
### Utilisation du format de journal JSON structuré avec .NET
Si vous sélectionnez JSON pour le format de journal de votre fonction, Lambda enverra les journaux en sortie à l'aide de [ILambdaLogger](https://github.com/aws/aws-lambda-dotnet/blob/master/Libraries/src/Amazon.Lambda.Core/ILambdaLogger.cs) sous forme de JSON structuré. Chaque objet de journal JSON contient au moins cinq 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
+ `"requestId"` - identifiant unique de la demande pour l’invocation de la fonction
+ `"traceId"` : la variable d’environnement `_X_AMZN_TRACE_ID`
+ `"message"` - contenu du message de journal
L’instance `ILambdaLogger` peut ajouter des paires clé-valeur supplémentaires, par exemple lors de la journalisation des exceptions. Vous pouvez également fournir vos propres paramètres supplémentaires, comme décrit dans la section [Paramètres de journal fournis par le client](#csharp-logging-advanced-JSON-user-supplied).
**Note**
Si votre code utilise déjà une autre bibliothèque de journalisation pour produire des journaux au format JSON, assurez-vous que le format de journal de votre fonction est défini sur du texte brut. Si vous définissez le format de journal sur JSON, les sorties de votre journal seront encodées deux fois.
L’exemple de commande de journalisation suivant montre comment écrire un message de journal de niveau `INFO`.
**Example Code de journalisation .NET**
```
context.Logger.LogInformation("Fetching cart from database");
```
Vous pouvez également utiliser une méthode de journal générique qui prend le niveau de journal comme argument, comme le montre l’exemple suivant.
```
context.Logger.Log(LogLevel.Information, "Fetching cart from database");
```
La sortie du journal par ces exemples d'extraits de code serait capturée dans CloudWatch Logs comme suit :
**Example Enregistrement de journaux JSON**
```
{
"timestamp": "2025-09-07T01:30:06.977Z",
"level": "Information",
"requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
"traceId": "1-6408af34-50f56f5b5677a7d763973804",
"message": "Fetching cart from database"
}
```
**Note**
Si vous configurez le format de journal de votre fonction pour utiliser du texte brut plutôt que du JSON, le niveau de journal capturé dans le message suit la convention de Microsoft qui consiste à utiliser une étiquette à quatre caractères. Par exemple, un niveau de journalisation `Debug` est représenté dans le message sous la forme `dbug`.
Lorsque vous configurez votre fonction pour utiliser des journaux au format JSON, le niveau de journal capturé dans le journal utilise l’étiquette complète, comme indiqué dans l’exemple d’enregistrement de journal JSON.
Si vous n’attribuez aucun niveau à la sortie de votre journal, Lambda lui attribuera automatiquement le niveau INFO.
#### Exceptions de journalisation au format JSON
Lorsque vous utilisez la journalisation JSON structurée avec `ILambdaLogger`, vous pouvez journaliser les exceptions dans votre code, comme indiqué dans l’exemple suivant.
**Example utilisation de la journalisation des exceptions**
```
try
{
connection.ExecuteQuery(query);
}
catch(Exception e)
{
context.Logger.LogWarning(e, "Error executing query");
}
```
Le format de journal généré par ce code est illustré dans l’exemple de JSON suivant. Notez que la propriété `message` du JSON est renseignée à l’aide de l’argument message fourni dans l’appel `LogWarning`, tandis que la propriété `errorMessage` provient de la propriété `Message` de l’exception elle-même.
**Example Enregistrement de journaux JSON**
```
{
"timestamp": "2025-09-07T01:30:06.977Z",
"level": "Warning",
"requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
"traceId": "1-6408af34-50f56f5b5677a7d763973804",
"message": "Error executing query",
"errorType": "System.Data.SqlClient.SqlException",
"errorMessage": "Connection closed",
"stackTrace": [""]
}
```
Si le format de journalisation de votre fonction est défini sur JSON, Lambda produit également des messages de journal au format JSON lorsque votre code génère une exception non détectée. L’exemple d’extrait de code et de message de journal suivants montre comment les exceptions non détectées sont journalisées.
**Example code d’exception**
```
throw new ApplicationException("Invalid data");
```
**Example Enregistrement de journaux JSON**
```
{
"timestamp": "2025-09-07T01:30:06.977Z",
"level": "Error",
"requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
"traceId": "1-6408af34-50f56f5b5677a7d763973804",
"message": "Invalid data",
"errorType": "System.ApplicationException",
"errorMessage": "Invalid data",
"stackTrace": [""]
}
```
#### Paramètres de journal fournis par le client
Avec les messages de journal au format JSON, vous pouvez fournir des paramètres de journal supplémentaires et les inclure dans le journal `message`. L’exemple d’extrait de code suivant montre une commande permettant d’ajouter deux paramètres fournis par l’utilisateur et étiquetés `retryAttempt` et `uri`. Dans l’exemple, la valeur de ces paramètres provient des arguments `retryAttempt` et `uriDestination` transmis à la commande de journalisation.
**Example Commande de journalisation JSON avec paramètres supplémentaires**
```
context.Logger.LogInformation("Starting retry {retryAttempt} to make GET request to {uri}", retryAttempt, uriDestination);
```
Le message du journal généré par cette commande est illustré dans l’exemple de fichier JSON suivant.
**Example Enregistrement de journaux JSON**
```
{
"timestamp": "2025-09-07T01:30:06.977Z",
"level": "Information",
"requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
"traceId": "1-6408af34-50f56f5b5677a7d763973804",
"message": "Starting retry 1 to make GET request to http://example.com/",
"retryAttempt": 1,
"uri": "http://example.com/"
}
```
**Astuce**
Vous pouvez également utiliser des propriétés de positionnement plutôt que des noms lorsque vous spécifiez des paramètres supplémentaires. Par exemple, dans l’exemple précédent, la commande peut également être écrite comme suit :
```
context.Logger.LogInformation("Starting retry {0} to make GET request to {1}", retryAttempt, uriDestination);
```
Notez que lorsque vous fournissez des paramètres de journalisation supplémentaires, Lambda les capture en tant que propriétés de premier niveau dans l’enregistrement de journal JSON. Cette approche diffère de certaines bibliothèques de journalisation .NET populaires `Serilog`, telles que celles qui capturent des paramètres supplémentaires dans un objet enfant distinct.
Si l’argument que vous fournissez pour un paramètre supplémentaire est un objet complexe, Lambda utilise par défaut la méthode `ToString()` pour fournir la valeur. Pour indiquer qu’un argument doit être sérialisé au format JSON, utilisez le préfixe `@` tel qu’illustré dans l’extrait de code suivant. Dans cet exemple, `User` est un objet doté de propriétés `FirstName` et `LastName`.
**Example Commande de journalisation JSON avec objet sérialisé JSON**
```
context.Logger.LogInformation("User {@user} logged in", User);
```
Le message du journal généré par cette commande est illustré dans l’exemple de fichier JSON suivant.
**Example Enregistrement de journaux JSON**
```
{
"timestamp": "2025-09-07T01:30:06.977Z",
"level": "Information",
"requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
"traceId": "1-6408af34-50f56f5b5677a7d763973804",
"message": "User {@user} logged in",
"user":
{
"FirstName": "John",
"LastName": "Doe"
}
}
```
Si l’argument d’un paramètre supplémentaire est un tableau ou implémente `IList` ou `IDictionary`, alors Lambda ajoute l’argument au message de journal JSON sous forme de tableau, comme indiqué dans l’exemple d’enregistrement de journal JSON suivant. Dans cet exemple, `{users}` prend un argument `IList` contenant des instances de la propriété `User` au même format que dans l’exemple précédent. Lambda le convertit cet `IList` en tableau, chaque valeur étant créée à l’aide de la méthode `ToString`.
**Example Enregistrement de journal JSON avec un argument `IList`**
```
{
"timestamp": "2025-09-07T01:30:06.977Z",
"level": "Information",
"requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
"traceId": "1-6408af34-50f56f5b5677a7d763973804",
"message": "{users} have joined the group",
"users":
[
"Rosalez, Alejandro",
"Stiles, John"
]
}
```
Vous pouvez également sérialiser la liste au format JSON en utilisant le préfixe `@` dans votre commande de journalisation. Dans l’exemple d’enregistrement de journal JSON suivant, la propriété `users` est sérialisée au format JSON.
**Example Enregistrement de journal JSON avec un argument sérialisé JSON `IList`**
```
{
"timestamp": "2025-09-07T01:30:06.977Z",
"level": "Information",
"requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
"traceId": "1-6408af34-50f56f5b5677a7d763973804",
"message": "{@users} have joined the group",
"users":
[
{
"FirstName": "Alejandro",
"LastName": "Rosalez"
},
{
"FirstName": "John",
"LastName": "Stiles"
}
]
}
```
### Utilisation du filtrage au niveau du journal avec .NET
En configurant le filtrage au niveau des journaux, vous pouvez choisir de n'envoyer que les journaux d'un certain niveau de détail ou 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 vos messages de journal par niveau de journal, vous pouvez soit utiliser des journaux au format JSON, soit utiliser les `Console` méthodes .NET pour générer des messages de journal. Pour créer des journaux au format JSON, [configurez le type de journal de votre fonction sur JSON](monitoring-cloudwatchlogs-logformat.md#monitoring-cloudwatchlogs-set-format) et utilisez l’instance `ILambdaLogger`.
Avec les journaux formatés en JSON, Lambda filtre les sorties de votre journal à l’aide de la paire clé-valeur « niveau » de l’objet JSON décrit dans [Utilisation du format de journal JSON structuré avec .NET](#csharp-logging-advanced-JSON).
Si vous utilisez les `Console` méthodes .NET pour écrire des messages dans CloudWatch Logs, Lambda applique les niveaux de journalisation à vos messages comme suit :
+ **Console. WriteLine **méthode - Lambda applique un niveau de journalisation de `INFO`
+ **Méthode Console.Error** : Lambda applique une journalisation de niveau `ERROR`
Lorsque vous configurez votre fonction pour utiliser le filtrage au niveau des journaux, vous devez sélectionner l'une des options suivantes pour le niveau de journaux que Lambda doit envoyer à Logs. CloudWatch Notez le mappage des niveaux de journalisation utilisés par Lambda avec les niveaux Microsoft standard utilisés par l’attribut .NET `ILambdaLogger`.
| Niveau du journal de Lambda | Niveau Microsoft équivalent | Utilisation standard |
| --- | --- | --- |
| TRACE (le plus détaillé) | Suivi | Les informations les plus précises utilisées pour tracer le chemin d’exécution de votre code |
| DEBUG | Débogage | Informations détaillées pour le débogage du système |
| INFO | Informations | Messages qui enregistrent le fonctionnement normal de votre fonction |
| WARN | Avertissement | Messages relatifs à des erreurs potentielles susceptibles d’entraîner un comportement inattendu si elles ne sont pas traitées |
| ERROR | Erreur | Messages concernant les problèmes qui empêchent le code de fonctionner comme prévu |
| FATAL (moindre détail) | Critique | Messages relatifs à des erreurs graves entraînant l’arrêt du fonctionnement de l’application |
Lambda envoie des journaux correspondant au niveau de détail sélectionné et inférieur à. CloudWatch Par exemple, si vous configurez un niveau de journalisation WARN, Lambda envoie des journaux correspondant aux niveaux WARN, ERROR et FATAL.
## Outils de journalisation et bibliothèques supplémentaires
[Powertools for AWS Lambda (.NET)](https://docs.aws.amazon.com/powertools/dotnet/) 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 Logging](https://docs.aws.amazon.com/powertools/dotnet/core/logging/) (français non garanti) 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 (.NET) 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 C\$1 avec des modules [Powertools pour AWS Lambda (.NET)](https://docs.powertools.aws.dev/lambda-dotnet) 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 :
+ .NET 8
+ [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 TypeScript modèle Hello World.
```
sam init --app-template hello-world-powertools-dotnet --name sam-app --package-type Zip --runtime dotnet6 --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 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/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:27.988000 INIT_START Runtime Version: dotnet:6.v13 Runtime Version ARN: arn:aws:lambda:ap-southeast-2::runtime:699f346a05dae24c58c45790bc4089f252bf17dae3997e79b17d939a288aa1ec
2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:28.229000 START RequestId: bed25b38-d012-42e7-ba28-f272535fb80e Version: $LATEST
2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:29.259000 2025-09-20T14:15:29.201Z bed25b38-d012-42e7-ba28-f272535fb80e info {"_aws":{"Timestamp":1676902528962,"CloudWatchMetrics":[{"Namespace":"sam-app-logging","Metrics":[{"Name":"ColdStart","Unit":"Count"}],"Dimensions":[["FunctionName"],["Service"]]}]},"FunctionName":"sam-app-HelloWorldFunction-haKIoVeose2p","Service":"PowertoolsHelloWorld","ColdStart":1}
2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:30.479000 2025-09-20T14:15:30.479Z bed25b38-d012-42e7-ba28-f272535fb80e info {"ColdStart":true,"XrayTraceId":"1-63f3807f-5dbcb9910c96f50742707542","CorrelationId":"d3d4de7f-4ccc-411a-a549-4d67b2fdc015","FunctionName":"sam-app-HelloWorldFunction-haKIoVeose2p","FunctionVersion":"$LATEST","FunctionMemorySize":256,"FunctionArn":"arn:aws:lambda:ap-southeast-2:123456789012:function:sam-app-HelloWorldFunction-haKIoVeose2p","FunctionRequestId":"bed25b38-d012-42e7-ba28-f272535fb80e","Timestamp":"2025-09-20T14:15:30.4602970Z","Level":"Information","Service":"PowertoolsHelloWorld","Name":"AWS.Lambda.Powertools.Logging.Logger","Message":"Hello world API - HTTP 200"}
2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:30.599000 2025-09-20T14:15:30.599Z bed25b38-d012-42e7-ba28-f272535fb80e info {"_aws":{"Timestamp":1676902528922,"CloudWatchMetrics":[{"Namespace":"sam-app-logging","Metrics":[{"Name":"ApiRequestCount","Unit":"Count"}],"Dimensions":[["Service"]]}]},"Service":"PowertoolsHelloWorld","ApiRequestCount":1}
2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:30.680000 END RequestId: bed25b38-d012-42e7-ba28-f272535fb80e
2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:30.680000 REPORT RequestId: bed25b38-d012-42e7-ba28-f272535fb80e Duration: 2450.99 ms Billed Duration: 2692 ms Memory Size: 256 MB Max Memory Used: 74 MB Init Duration: 240.05 ms
XRAY TraceId: 1-63f3807f-5dbcb9910c96f50742707542 SegmentId: 16b362cd5f52cba0
```
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
```
## 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 la CloudWatch 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 à l'aide de AWS Command Line Interface (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.
# Instrumentation du code C\$1 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 .NET](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-dotnet.html) – Un kit SDK permettant de générer et d’envoyer des données de suivi à X-Ray.
+ [Powertools for AWS Lambda (.NET)](https://docs.aws.amazon.com/powertools/dotnet/) — 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 (.NET) et AWS SAM pour le traçage
](#dotnet-tracing-sam)
+ [
## Utilisation du kit SDK X-Ray pour instrumenter vos fonctions .NET
](#dotnet-xray-sdk)
+ [
## Activation du suivi avec la console Lambda
](#dotnet-tracing-console)
+ [
## Activation du suivi avec l’API Lambda
](#dotnet-tracing-api)
+ [
## Activation du traçage avec CloudFormation
](#dotnet-tracing-cloudformation)
+ [
## Interprétation d’un suivi X-Ray
](#dotnet-tracing-interpretation)
## Utilisation de Powertools pour AWS Lambda (.NET) 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 C\$1 avec des modules [Powertools pour AWS Lambda (.NET)](https://docs.powertools.aws.dev/lambda-dotnet) 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 :
+ .NET 8
+ [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, consultez 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 TypeScript modèle Hello World.
```
sam init --app-template hello-world-powertools-dotnet --name sam-app --package-type Zip --runtime dotnet6 --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
```
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-20 23:05:16+08:00
End time: 2023-02-20 23:05:16+08:00
Reference Id: 0 - AWS::Lambda - sam-app-HelloWorldFunction-pNjujb7mEoew - Edges: [1]
Summary_statistics:
- total requests: 1
- ok count(2XX): 1
- error count(4XX): 0
- fault count(5XX): 0
- total response time: 2.814
Reference Id: 1 - AWS::Lambda::Function - sam-app-HelloWorldFunction-pNjujb7mEoew - Edges: []
Summary_statistics:
- total requests: 1
- ok count(2XX): 1
- error count(4XX): 0
- fault count(5XX): 0
- total response time: 2.429
Reference Id: 2 - (Root) AWS::ApiGateway::Stage - sam-app/Prod - Edges: [0]
Summary_statistics:
- total requests: 1
- ok count(2XX): 1
- error count(4XX): 0
- fault count(5XX): 0
- total response time: 2.839
Reference Id: 3 - client - sam-app/Prod - Edges: [2]
Summary_statistics:
- total requests: 0
- ok count(2XX): 0
- error count(4XX): 0
- fault count(5XX): 0
- total response time: 0
XRay Event [revision 3] at (2023-02-20T23:05:16.521000) with id (1-63f38c2c-270200bf1d292a442c8e8a00) and duration (2.877s)
- 2.839s - sam-app/Prod [HTTP: 200]
- 2.836s - Lambda [HTTP: 200]
- 2.814s - sam-app-HelloWorldFunction-pNjujb7mEoew [HTTP: 200]
- 2.429s - sam-app-HelloWorldFunction-pNjujb7mEoew
- 0.230s - Initialization
- 2.389s - Invocation
- 0.600s - ## FunctionHandler
- 0.517s - Get Calling IP
- 0.039s - 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 du kit SDK X-Ray pour instrumenter vos fonctions .NET
Vous pouvez instrumenter le code de gestionnaire pour enregistrer les métadonnées et suivre les appels en aval. Pour enregistrer les détails des appels que votre fonction effectue vers d'autres ressources et services, utilisez le Kit SDK AWS X-Ray pour .NET. Pour obtenir ce kit SDK, ajoutez les packages `AWSXRayRecorder` à votre fichier de projet.
```
net8.0
true
Lambda
```
Il existe une gamme de packages Nuget qui fournissent une instrumentation automatique pour les AWS SDKs requêtes Entity Framework et HTTP. Pour connaître l'ensemble des options de configuration, reportez-vous à [kit SDK AWS X-Ray pour .NET](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-dotnet.html) dans le *Guide du développeur AWS X-Ray *.
Une fois que vous avez ajouté les packages Nuget de votre choix, configurez l'auto-instrumentation. La meilleure pratique consiste à effectuer cette configuration en dehors de la fonction du gestionnaire de votre fonction. Cela vous permet de tirer parti de la réutilisation de l'environnement d'exécution afin d'améliorer les performances de votre fonction. Dans l'exemple de code suivant, la `RegisterXRayForAllServices` méthode est appelée dans le constructeur de fonctions pour ajouter de l'instrumentation à tous les appels du AWS SDK.
```
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace GetProductHandler;
public class Function
{
private readonly IDatabaseRepository _repo;
public Function()
{
// Add auto instrumentation for all AWS SDK calls
// It is important to call this method before initializing any SDK clients
AWSSDKHandler.RegisterXRayForAllServices();
this._repo = new DatabaseRepository();
}
public async Task FunctionHandler(APIGatewayProxyRequest request)
{
var id = request.PathParameters["id"];
var databaseRecord = await this._repo.GetById(id);
return new APIGatewayProxyResponse
{
StatusCode = (int)HttpStatusCode.OK,
Body = JsonSerializer.Serialize(databaseRecord)
};
}
}
```
## 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 active 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. Sinon, 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 .NET](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-dotnet.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).
# Test de fonction AWS Lambda en C\$1
**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
Pour accélérer votre cycle de développement, il existe un certain nombre d'outils et de techniques que vous pouvez utiliser pour tester vos fonctions. Par exemple, [Accélérer AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/using-sam-cli-sync.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 pour mettre à jour les environnements cloud.
La façon dont vous définissez votre code de fonction Lambda facilite l'ajout de tests d'unité. Lambda nécessite un constructeur public sans paramètre pour initialiser votre catégorie. L'introduction d'un deuxième constructeur interne vous permet de contrôler les dépendances utilisées par votre application.
```
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace GetProductHandler;
public class Function
{
private readonly IDatabaseRepository _repo;
public Function(): this(null)
{
}
internal Function(IDatabaseRepository repo)
{
this._repo = repo ?? new DatabaseRepository();
}
public async Task FunctionHandler(APIGatewayProxyRequest request)
{
var id = request.PathParameters["id"];
var databaseRecord = await this._repo.GetById(id);
return new APIGatewayProxyResponse
{
StatusCode = (int)HttpStatusCode.OK,
Body = JsonSerializer.Serialize(databaseRecord)
};
}
}
```
Pour écrire un test pour cette fonction, vous pouvez initialiser une nouvelle instance de votre catégorie `Function` et transmettre une implémentation simulée du `IDatabaseRepository`. Les exemples ci-dessous utilisent `XUnit`, `Moq`, et `FluentAssertions` pour écrire un test simple permettant de s'assurer que le `FunctionHandler` renvoie un code d'état 200.
```
using Xunit;
using Moq;
using FluentAssertions;
public class FunctionTests
{
[Fact]
public async Task TestLambdaHandler_WhenInputIsValid_ShouldReturn200StatusCode()
{
// Arrange
var mockDatabaseRepository = new Mock();
var functionUnderTest = new Function(mockDatabaseRepository.Object);
// Act
var response = await functionUnderTest.FunctionHandler(new APIGatewayProxyRequest());
// Assert
response.StatusCode.Should().Be(200);
}
}
```
Pour obtenir des exemples plus détaillés, y compris des exemples de tests asynchrones, consultez le [référentiel d'échantillons de tests .NET](https://github.com/aws-samples/serverless-test-samples/tree/main/dotnet-test-samples) dans GitHub.