Charges de travail .NET sur AWS Lambda

Le service AWS Lambda fournit divers environnements d'exécution courants sur lesquels vous pouvez exécuter votre code. En ce qui concerne les environnements d'exécution .NET, AWS maintient le moteur d'exécution à jour et y apporte les correctifs nécessaires avec les dernières versions disponibles auprès de Microsoft. En tant que développeur, vous n'avez rien à faire en ce qui concerne la gestion du moteur d'exécution que votre code utilisera, si ce n'est de spécifier la version que vous souhaitez utiliser dans votre fichier .csproj habituel.

À l'heure actuelle, AWS propose uniquement des environnements d'exécution gérés pour les versions LTS (Long Term Support) de l'exécution .NET, à savoir .NET 3.1 et .NET 6 au moment de la rédaction de cet article. Les environnements d'exécution gérés .NET sont disponibles pour les architectures x86_64 et arm64 et s'exécutent sur Amazon Linux 2. Si vous souhaitez utiliser une version de .NET autre que celles proposées par AWS, vous pouvez créer votre propre environnement d'exécution personnalisé ou créer une image de conteneur adaptée à vos besoins.

Si vous souhaitez sortir du monde .NET, sachez que le service Lambda propose également des environnements d'exécution gérés pour d'autres langages : Node.js, Python, Ruby, Java et Go. Pour plus de détails sur la liste des temps d'exécution gérés et des versions des langues prises en charge, consultez cette page sur les exécutions disponibles.

Les environnements d'exécution personnalisés sont des environnements d'exécution que vous créez et regroupez vous-même. Il y a plusieurs raisons pour lesquelles vous feriez cela. La plus courante est que vous souhaitiez utiliser une version .NET qui n'est pas proposée en tant qu'exécutions gérées par le service Lambda. Une autre raison, moins courante, serait que vous souhaitiez avoir un contrôle précis sur les versions mineures et les correctifs d'exécution.

La création de l'environnement d'exécution personnalisé ne demande que très peu d'efforts de votre part. Il vous suffit de faire :

--self-contained true à la commande build.

Cela peut être fait directement avec dotnet build. Vous pouvez également le faire via le fichier aws-lambda-tools-defaults.json avec le paramètre suivant :

« msbuild-parameters » : « --self-contained true »

C'est la seule chose qu'il y ait, un simple indicateur de compilateur lors de la création d'une offre groupée de la fonction Lambda.NET. Le package à déployer contiendra désormais votre code, ainsi que les fichiers requis provenant du moteur d'exécution .NET que vous avez choisi.

C'est maintenant à vous de corriger et de mettre à jour l'exécution comme bon vous semble. La mise à jour du moteur d'exécution nécessite de redéployer la fonction, car le code de la fonction et le moteur d'exécution sont regroupés.

Le package déployé est nettement plus volumineux que l'exécution gérée car il contient tous les fichiers d'exécution nécessaires. Cela affecte négativement les temps de démarrage à froid (nous y reviendrons plus tard). Pour réduire cette taille, pensez à utiliser les fonctionnalités de compilation .NET Trimming et ReadyToRun. Veuillez toutefois lire la documentation relative à ces fonctionnalités avant de le faire.

Vous pouvez créer un environnement d'exécution personnalisé avec n'importe quelle version de .NET exécutée sous Linux. Un cas d'utilisation courant consiste à déployer des fonctions avec les versions « actuelles » ou préliminaires de .NET.

Lorsque vous utilisez des environnements d'exécution personnalisés, vous pouvez utiliser une très grande variété de langages proposés par la communauté. Vous pouvez même créer votre propre environnement d'exécution personnalisé, comme d'autres l'ont fait pour exécuter des langages tels que Erlang et COBOL.

Vous devez installer l'outillage requis pour suivre cette procédure. Veuillez consulter le module 3 pour plus de détails sur la procédure à suivre.

Si vous ne voulez pas vous lancer tout de suite, voici un petit rappel.

Installez les modèles de fonctions Lambda .NET :

dotnet new -i Amazon.Lambda.Templates

Installez les outils .NET pour déployer et gérer les fonctions Lambda :

dotnet tool install -g Amazon.Lambda.Tools

Maintenant que les modèles sont installés, vous pouvez créer une nouvelle fonction

À partir de la ligne de commande, exécutez :

dotnet new lambda.EmptyFunction -n HelloEmptyFunction

Cela crée un nouveau répertoire appelé HelloEmptyFunction. À l'intérieur se trouvent deux autres répertoires, src et test. Comme ses noms l'indiquent, le répertoire src contient le code de la fonction et le répertoire de test contient les tests unitaires de la fonction. Lorsque vous naviguez dans ces répertoires, vous constaterez qu'ils contiennent chacun un autre répertoire. À l'intérieur de ces sous-répertoires se trouvent les fichiers de code de la fonction et les fichiers de tests unitaires.

HelloEmptyFunction
    ├───src
    │   └───HelloEmptyFunction
    │           aws-lambda-tools-defaults.json // The default configuration file
    │           Function.cs // The code for the function
    │           HelloEmptyFunction.csproj // Standard C# project file
    │           Readme.md // A readme file
    │
    └───test
        └───HelloEmptyFunction.Tests
                FunctionTest.cs // The unit tests for the function
                HelloEmptyFunction.Tests.csproj // Standard C# project file

Jetons d'abord un coup d'œil au fichier Function.cs.

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 HelloEmptyFunction;

public class Function
{
    
    /// <summary>
    /// A simple function that takes a string and does a ToUpper
    /// </summary>
    /// <param name="input"></param>
    /// <param name="context"></param>
    /// <returns></returns>
    public string FunctionHandler(string input, ILambdaContext context)
    {
        return input.ToUpper();
    }
}

{
  "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": "",
  "configuration": "Release",
  "function-runtime": "dotnet6",
  "function-memory-size": 256,
  "function-timeout": 30,
  "function-handler": "HelloEmptyFunction::HelloEmptyFunction.Function::FunctionHandler"
}

using Xunit;
using Amazon.Lambda.Core;
using Amazon.Lambda.TestUtilities;

namespace HelloEmptyFunction.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);
    }
}

Vous pouvez utiliser l'outil dotnet lambda pour invoquer la fonction depuis le shell de votre choix :

dotnet lambda invoke-function HelloEmptyFunction --payload "Invoking a Lambda function"

Pour les fonctions Lambda simples comme celles ci-dessus, il n'y a pas de code JSON à échapper, mais lorsque vous souhaitez transmettre du JSON qui doit être désérialisé, la charge utile qui sort varie en fonction du shell que vous utilisez.

Vous verrez une sortie qui ressemble à ce qui suit :

Amazon Lambda Tools for .NET Core applications (5.4.1)
Project Home: https://github.com/aws/aws-extensions-for-dotnet-cli, https://github.com/aws/aws-lambda-dotnet

Payload:
"INVOKING A LAMBDA FUNCTION"

Log Tail:
START RequestId: 3d43c8be-8eca-48a1-9e51-96d9c84947b2 Version: $LATEST
END RequestId: 3d43c8be-8eca-48a1-9e51-96d9c84947b2
REPORT RequestId: 3d43c8be-8eca-48a1-9e51-96d9c84947b2  Duration: 244.83 ms      Billed Duration: 245 ms                                                                                                                  
Memory Size: 256 MB      Max Memory Used: 68 MB      Init Duration: 314.32 ms

La sortie « Payload : » est la réponse de la fonction Lambda.

Notez que le journal contient des informations utiles sur l'invocation de la fonction Lambda, comme sa durée d'exécution et la quantité de mémoire utilisée. Pour une fonction simple comme celle-ci, 244,83 ms peuvent sembler beaucoup, mais c'était la première fois que la fonction était invoquée, ce qui signifie que plus de travail devait être effectué et que les invocations suivantes auraient été plus rapides. Consultez la section sur les démarrages à froid pour plus d'informations.

Apportons une petite modification au code pour ajouter certaines de nos propres instructions de journal.

Ajoutez ce qui suit au-dessus de l'instruction de retour dans la méthode FunctionHandler :

context.Logger.LogInformation("Input: " + input);

Déployez à nouveau à l’aide de :

dotnet lambda deploy-function HelloEmptyFunction

Cette fois, il n'y aura aucune question sur le rôle ou les autorisations.

Une fois la fonction déployée, vous pouvez l'invoquer à nouveau.

dotnet lambda invoke-function HelloEmptyFunction --payload "Invoking a Lambda function" 

Cette fois, la sortie contiendra une instruction de journal supplémentaire.

Payload:
"INVOKING A LAMBDA FUNCTION"

Log Tail:
START RequestId: 7f77a371-c183-494f-bb44-883fe0c57471 Version: $LATEST
2022-06-03T15:36:20.238Z        7f77a371-c183-494f-bb44-883fe0c57471    info    Input: Invoking a Lambda function
END RequestId: 7f77a371-c183-494f-bb44-883fe0c57471
REPORT RequestId: 7f77a371-c183-494f-bb44-883fe0c57471  Duration: 457.22 ms     Billed Duration: 458 ms                                                                                                       
Memory Size: 256 MB      Max Memory Used: 62 MB  Init Duration: 262.12 ms

À la ligne 6, se trouve l'instruction du journal. Les journaux des fonctions Lambda sont également écrits dans les journaux CloudWatch (à condition que vous ayez autorisé la fonction Lambda à le faire).

Vous pouvez également invoquer la fonction à partir de la console AWS.

Connectez-vous à la console AWS et sélectionnez la fonction Lambda que vous souhaitez invoquer.

Cliquez sur l'onglet Test.

Faites défiler la page jusqu'à la section Event JSON et saisissez « Invoquer une fonction Lambda », y compris les guillemets.

Cliquez ensuite sur le bouton Test.

Vous verrez une sortie semblable à ce qui suit.

Notez que la sortie du journal est également visible.

Comme précédemment, créez une nouvelle fonction à l'aide de la commande suivante :

dotnet new lambda.EmptyFunction -n HelloPersonFunction

Accédez au fichier Function.cs dans HelloPersonFunction/src/HelloPersonFunction.

Modifiez le code de la méthode FunctionHandler pour qu'il ressemble à ceci :

public string FunctionHandler(Person input, ILambdaContext context)
{
    return $"Hello, {input.FirstName} {input.LastName}";
}

Au bas du fichier, ajoutez une nouvelle classe :

public class Person 
{
    public string FirstName { get; init; }
    public string LastName { get; init; }  
}

Il s'agit de la même commande que celle que vous avez utilisée il y a quelques minutes :

dotnet lambda deploy-function HelloPersonFunction

Votre fonction Lambda peut désormais prendre une charge utile JSON, mais la manière dont vous l'invoquez dépend du shell que vous utilisez en raison de la manière dont le JSON est échappé dans chaque shell.

Si vous utilisez PowerShell ou bash, utilisez :

dotnet lambda invoke-function HelloPersonFunction --payload '{ \"FirstName\": \"Alan\", \"LastName\": \"Adams\" }'

Mais si vous utilisez l'invite de commande Windows, utilisez :

dotnet lambda invoke-function HelloPersonFunction --payload "{ \"FirstName\": \"Alan\", \"LastName\": \"Adams\" }"

Il ne s'agit que d'un simple exemple. Mais, bien entendu, le JSON peut être aussi complexe que nécessaire.

Vous pouvez également invoquer la fonction à partir de la console AWS.

Connectez-vous à la console AWS et sélectionnez la fonction Lambda que vous souhaitez invoquer.

Cliquez sur l'onglet Test.

Faites défiler la page jusqu'à la section JSON de l'événement et saisissez :

{
  "FirstName": "Alan",
  "LastName": "Adams"
}

Cliquez ensuite sur le bouton Test.

Vous verrez une sortie semblable à ce qui suit.

Ces derniers exemples sont assez simples et la fonction Lambda n'a utilisé aucun autre service AWS, mais ils constituent un excellent moyen de démarrer et de se familiariser avec le service AWS Lambda, en écrivant des fonctions Lambda, en déployant des packages compilés et en invoquant les fonctions.

Dans la section suivante, vous allez voir comment déployer une fonction Lambda qui répond aux requêtes HTTP.

À partir de la ligne de commande, exécutez la commande suivante :

dotnet new serverless.AspNetCoreWebAPI -n HelloAspNetCoreWebAPI

Cela crée un nouveau répertoire appelé HelloAspNetCoreWebAPI. À l'intérieur se trouvent deux autres répertoires, src et test. Comme ses noms l'indiquent, le répertoire src contient le code de la fonction et le répertoire de test contient les tests unitaires de la fonction. Lorsque vous naviguez dans ces répertoires, vous constaterez qu'ils contiennent chacun un autre répertoire. À l'intérieur de ces sous-répertoires se trouvent les fichiers de code de la fonction et les fichiers de tests unitaires.

├───src
│   └───AspNetCoreWebAPI
│       │   appsettings.Development.json
│       │   appsettings.json
│       │   AspNetCoreWebAPI.csproj
│       │   aws-lambda-tools-defaults.json // basic Lambda function config, and points to serverless.template file for deployment
│       │   LambdaEntryPoint.cs // Contains the function handler method, this handles the incoming JSON payload
│       │   LocalEntryPoint.cs // Equivalent to Program.cs when running locally, starts Kestrel (only locally)
│       │   Readme.md  
│       │   serverless.template // CloudFormation template for deployment
│       │   Startup.cs // Familiar Startup.cs, can use dependency injection, read config, etc.
│       │
│       └───Controllers
│               ValuesController.cs // Familiar API controller
│
└───test
    └───AspNetCoreWebAPI.Tests
        │   appsettings.json
        │   AspNetCoreWebAPI.Tests.csproj
        │   ValuesControllerTests.cs // Unit test for ValuesController
        │
        └───SampleRequests
                ValuesController-Get.json // JSON representing an APIGatewayProxyRequest, used by the unit test

Le déploiement d'une fonction basée sur un modèle sans serveur.* est un peu plus complexe que le déploiement d'une fonction basée sur un modèle lambda.*.

Avant de tenter de déployer la fonction sans serveur, vous avez besoin d'un compartiment S3. Cela sera utilisé par les outils de déploiement pour stocker une pile CloudFormation.

Vous pouvez utiliser un compartiment S3 existant ou, si vous n'en avez pas, suivre les instructions ci-dessous.

Si vous utilisez la région us-east-1, vous pouvez utiliser la commande suivante pour créer le compartiment :

aws s3api create-bucket --bucket your-unique-bucket-name1234 

Ou si vous utilisez une autre région

aws s3api create-bucket --bucket your-unique-bucket-name1234 --create-bucket-configuration LocationConstraint=REGION

J'ai créé un compartiment dans us-east-1, nommé lambda-course-2022.

aws s3api create-bucket --bucket lambda-course-2022 

Maintenant que vous avez un S3, vous pouvez exécuter la commande de déploiement :

dotnet lambda deploy-serverless

Il vous sera demandé de saisir le nom de la pile CloudFormation.

Enter CloudFormation Stack Name: (CloudFormation stack name for an AWS Serverless application)

Tapez AspNetCoreWebAPI

Il vous sera ensuite demandé le nom du compartiment S3. Utilisez le nom du compartiment que vous avez créé précédemment ou un compartiment existant que vous souhaitez utiliser à cette fin.

Une fois que vous l'avez saisi, le processus de génération et de déploiement commence.

Cela prendra plus de temps que les exemples utilisant les modèles de projet lambda.* car il y a plus d'infrastructures à créer et à connecter.

La sortie sera divisée en deux sections distinctes.

La section supérieure sera similaire à celle que vous avez vue lors du déploiement des fonctions précédemment : une publication et un zip du projet, mais cette fois, l'artefact est téléchargé sur S3.

..snip
... zipping: AspNetCoreWebAPI.runtimeconfig.json
... zipping: aws-lambda-tools-defaults.json
Created publish archive (C:\Users\someuser\AppData\Local\Temp\AspNetCoreFunction-CodeUri-Or-ImageUri-637907144179228995.zip).
Lambda project successfully packaged: C:\Users\ someuser\AppData\Local\Temp\AspNetCoreFunction-CodeUri-Or-ImageUri-637907144179228995.zip
Uploading to S3. (Bucket: lambda-course-2022 Key: AspNetCoreWebAPI/AspNetCoreFunction-CodeUri-Or-ImageUri-637907144179228995-637907144208759417.zip)
... Progress: 100%

Ensuite, la pile CloudFormation est créée et toutes les ressources requises sont déployées.

Uploading to S3. (Bucket: lambda-course-2022 Key: AspNetCoreWebAPI/AspNetCoreWebAPI-serverless-637907144211067892.template)
... Progress: 100%
Found existing stack: False
CloudFormation change set created
... Waiting for change set to be reviewed
Created CloudFormation stack AspNetCoreWebAPI

Timestamp            Logical Resource Id                      Status
-------------------- ---------------------------------------- ---------------------------------------- 
6/10/2022 09:53 AM   AspNetCoreWebAPI                         CREATE_IN_PROGRESS
6/10/2022 09:53 AM   AspNetCoreFunctionRole                   CREATE_IN_PROGRESS
6/10/2022 09:53 AM   AspNetCoreFunctionRole                   CREATE_IN_PROGRESS
6/10/2022 09:54 AM   AspNetCoreFunctionRole                   CREATE_COMPLETE
6/10/2022 09:54 AM   AspNetCoreFunction                       CREATE_IN_PROGRESS
6/10/2022 09:54 AM   AspNetCoreFunction                       CREATE_IN_PROGRESS
6/10/2022 09:54 AM   AspNetCoreFunction                       CREATE_COMPLETE
6/10/2022 09:54 AM   ServerlessRestApi                        CREATE_IN_PROGRESS
6/10/2022 09:54 AM   ServerlessRestApi                        CREATE_IN_PROGRESS
6/10/2022 09:54 AM   ServerlessRestApi                        CREATE_COMPLETE
6/10/2022 09:54 AM   ServerlessRestApiDeploymentcfb7a37fc3    CREATE_IN_PROGRESS
6/10/2022 09:54 AM   AspNetCoreFunctionProxyResourcePermissionProd CREATE_IN_PROGRESS
6/10/2022 09:54 AM   AspNetCoreFunctionRootResourcePermissionProd CREATE_IN_PROGRESS
6/10/2022 09:54 AM   AspNetCoreFunctionProxyResourcePermissionProd CREATE_IN_PROGRESS
6/10/2022 09:54 AM   AspNetCoreFunctionRootResourcePermissionProd CREATE_IN_PROGRESS
6/10/2022 09:54 AM   ServerlessRestApiDeploymentcfb7a37fc3    CREATE_IN_PROGRESS
6/10/2022 09:54 AM   ServerlessRestApiDeploymentcfb7a37fc3    CREATE_COMPLETE
6/10/2022 09:54 AM   ServerlessRestApiProdStage               CREATE_IN_PROGRESS
6/10/2022 09:54 AM   ServerlessRestApiProdStage               CREATE_IN_PROGRESS
6/10/2022 09:54 AM   ServerlessRestApiProdStage               CREATE_COMPLETE
6/10/2022 09:54 AM   AspNetCoreFunctionProxyResourcePermissionProd CREATE_COMPLETE
6/10/2022 09:54 AM   AspNetCoreFunctionRootResourcePermissionProd CREATE_COMPLETE
6/10/2022 09:54 AM   AspNetCoreWebAPI                         CREATE_COMPLETE
Stack finished updating with status: CREATE_COMPLETE

Output Name                    Value
------------------------------ --------------------------------------------------
ApiURL                         https://xxxxxxxxx.execute-api.us-east-1.amazonaws.com/Prod/

Tout en bas se trouve l'URL publique que vous pouvez utiliser pour invoquer l'API.

En ouvrant cette URL dans votre navigateur, ou Fiddler/Postman, etc., vous verrez une réponse du type « Bienvenue dans l'exécution d'ASP.NET Core sur AWS Lambda ».

Essayez ensuite d'ouvrir https://xxxxxxxx.execute-api.us-east-1.amazonaws.com/Prod/api/values, vous invoquerez la méthode GET du contrôleur de valeurs, comme vous le feriez dans une application API Web normale.

Notez que lorsque vous utilisez un API Gateway, la passerelle impose son propre délai d'attente de 29 secondes. Si votre fonction Lambda s'exécute plus longtemps, vous ne recevrez pas de réponse.

Si cela vous intéresse, il existe plusieurs manières de consulter les ressources qui ont été créées.

Pour consulter les ressources AWS créées, vous pouvez utiliser :

aws cloudformation describe-stack-resources --stack-name AspNetCoreWebAPI

Cela vous donnera des détails sur chaque ressource de la pile.

Si vous souhaitez obtenir une sortie plus succincte, utilisez :

aws cloudformation describe-stack-resources --stack-name AspNetCoreWebAPI --query 'StackResources[].[{ResourceType:ResourceType, LogicalResourceId:LogicalResourceId, PhysicalResourceId:PhysicalResourceId}]'

Une autre méthode consiste à ouvrir la console AWS et à accéder au service Lambda. Sur la gauche de l'écran, sélectionnez Application (au lieu de fonctions).

Vous verrez l'application que vous avez créée. Sélectionnez-la, puis faites défiler la page qui s'ouvre vers le bas. Vous verrez toutes les ressources qui ont été créées ici.

Vous avez maintenant vu trois exemples de fonctions Lambda : le premier était un simple Hello World utilisant une chaîne, le second était également très simple mais utilisait un objet JSON, et le troisième était un peu plus complexe, tout en restant très facile à créer et à déployer.

Ces exemples vous permettent de créer et de déployer vos propres fonctions Lambda. Et vous en avez peut-être appris un peu plus sur la façon dont les fonctions Lambda .NET sont invoquées. C'est l'objet de la section suivante.

Si tout ce dont vous avez besoin est une fonction Lambda qui répond à une simple requête HTTP, vous devriez envisager d'utiliser les URL des fonctions Lambda.

Ils vous permettent d'attribuer un point de terminaison HTTPS à une fonction Lambda. Vous invoquez ensuite la fonction Lambda en envoyant une requête au point de terminaison HTTPS. Pour plus d'informations, lisez cet article de blog etces documents.

Pour supprimer les fonction Lambda, exécutez :

dotnet lambda delete-function HelloEmptyFunction  
dotnet lambda delete-function HelloPersonFunction

Notez que les commandes ci-dessus ne suppriment pas le rôle que vous avez créé.

Pour supprimer la fonction Lambda qui hébergeait l'application API Web et toutes les ressources associées, exécutez :

dotnet lambda delete-serverless AspNetCoreWebAPI

Ce qui permet à un service AWS d'invoquer très facilement une fonction Lambda .NET, c'est que ces services émettent du JSON et, comme indiqué ci-dessus, la fonction Lambda .NET accepte les entrées JSON. Les événements déclenchés par les différents services produisent tous un JSON de forme différente, mais les packages AWS Lambda Event NuGet incluent tous les types d'objets pertinents nécessaires pour sérialiser à nouveau le JSON en un objet avec lequel vous pouvez travailler.

Consultez https://www.nuget.org/packages?packagetype=&sortby=relevance&q=Amazon.Lambda&prerel=True pour une liste des packages Lambda disponibles. Vous devrez rechercher dans ces résultats le type d'événement qui vous intéresse.

Par exemple, si vous souhaitez déclencher une fonction Lambda en réponse à une modification de fichier sur un compartiment S3, vous devez créer une fonction Lambda qui accepte un objet de type S3Event. Vous ajoutez ensuite le package Amazon.Lambda.S3Events à votre projet. Modifiez ensuite la méthode du gestionnaire de fonctions en :

public async string FunctionHandler(S3Event s3Event, ILambdaContext context)
{
    ...
}

C'est tout ce dont vous avez besoin pour gérer l'événement S3, vous pouvez examiner l'événement par programmation, voir quelle action a été effectuée sur le fichier, dans quel compartiment il se trouvait, etc. L'Amazon.Lambda.S3Events vous permet de travailler avec l'événement, et non avec S3 lui-même. Si vous souhaitez interagir avec le service S3, vous devez également ajouter le package NuGet AWSSDK.S3 à votre projet. Un module ultérieur abordera le sujet des services AWS invoquant des fonctions Lambda.

Les autres types d'événements suivent le même schéma : ajoutez le package NuGet, modifiez le paramètre dans le gestionnaire de fonctions, puis vous pouvez travailler avec l'objet événement.

Voici quelques-uns des packages courants que vous pouvez utiliser pour gérer les événements provenant d'autres services –

https://www.nuget.org/packages/Amazon.Lambda.SNSEvents

https://www.nuget.org/packages/Amazon.Lambda.DynamoDBEvents

https://www.nuget.org/packages/Amazon.Lambda.CloudWatchEvents

https://www.nuget.org/packages/Amazon.Lambda.KinesisEvents

https://www.nuget.org/packages/Amazon.Lambda.APIGatewayEvents

Vous n'êtes pas limité à l'utilisation des types d'événements définis par AWS lorsque vous appelez une fonction Lambda. Vous pouvez créer vous-même n'importe quel type d'événement. N'oubliez pas que la fonction Lambda peut prendre n'importe quel JSON que vous lui envoyez

Vous vous souviendrez qu'il existe deux grandes catégories de modèles de projet Lambda, ceux qui commencent par « lambda ». et ceux qui commencent par « sans serveur ».

Dans le cas des modèles « lambda », il y a un attribut d'assemblage en haut du fichier Function.cs, qui prend en charge la désérialisation de l'événement entrant dans le type .NET de votre gestionnaire de fonctions. Le fichier .csproj contient une référence au package Amazon.Lambda.Serialization.SystemTextJson.

[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]

Vous n'avez rien d'autre à faire.

Pour les modèles « sans serveur », cela fonctionne un peu différemment.

Le gestionnaire de fonctions est spécifié dans le fichier serverless.template. Si vous déployez une application Serverless.AspNetCoreWebAPI, recherchez la valeur sous Resources.AspNetCoreFunction.Properties.Handler. Le gestionnaire pour ce type de projet se terminera sous la forme suivante : Assembly::Namespace.LambdaEntryPoint::FunctionHandlerAsync.

La classe LambdaEntryPoint fera partie de votre projet et hérite d'une classe dotée d'une méthode FunctionHandlerAsync.

Le gestionnaire de fonctions peut être configuré pour gérer quatre types d'événements différents : une API Gateway REST API, une charge utile API Gateway HTTP API version 1.0, une charge utile API Gateway HTTP API version 2.0 et un Application Load Balancer.

En modifiant la classe dont LambdaEntryPoint hérite, vous pouvez modifier le type d'événement JSON géré par le gestionnaire de fonctions.

Même s'il semble que la fonction Lambda répond à une requête HTTP que vous lui envoyez, avec le JSON que vous définissez, ce n'est pas le cas. En réalité, votre requête HTTP est gérée par une passerelle ou un équilibreur de charge, qui crée ensuite un événement JSON qui est envoyé à votre gestionnaire de fonctions. Cet événement JSON contiendra les données initialement incluses dans la requête HTTP, y compris l'adresse IP source et les en-têtes de demande.