Carichi di lavoro .NET su AWS Lambda

Il servizio AWS Lambda offre una serie di runtime popolari su cui eseguire il codice. In relazione ai runtime .NET, AWS mantiene il runtime aggiornato e dotato delle patch necessarie in base alle ultime versioni disponibili da Microsoft. Come sviluppatore non devi fare nulla in merito alla gestione del runtime che utilizzerà il tuo codice, se non specificare la versione che desideri utilizzare nel tuo file .csproj.

Al momento, AWS offre runtime gestiti solo per le versioni LTS (Long Term Support) di runtime .NET, ossia .NET 3.1 e .NET 6. I runtime gestiti .NET sono disponibili per entrambe le architetture x86_64 e arm64 e vengono eseguiti su Amazon Linux 2. Se desideri utilizzare una versione di .NET diversa da quelle offerte da AWS, puoi creare il tuo runtime personalizzato o un'immagine di container adatta alle tue esigenze.

Se sei interessato a uscire dal contesto .NET, è bene sapere che il servizio Lambda offre runtime gestiti anche per altri linguaggi: Node.js, Python, Ruby, Java e Go. Per i dettagli completi sull'elenco dei runtime gestiti e sulle versioni dei linguaggi supportati, consulta questa pagina sui runtime disponibili.

I runtime personalizzati sono runtime creati e raggruppati dall'utente. Ci sono diversi motivi per scegliere questa opzione. Il più comune è che si desidera utilizzare una versione .NET che non è offerta come runtime gestito dal servizio Lambda. Un altro motivo, meno comune, è quello di avere un controllo preciso sulle versioni secondarie e sulle patch del runtime.

La creazione di un runtime personalizzato richiede pochissimo sforzo da parte tua. Tutto quello che devi fare è passare:

--self-contained true al comando di compilazione.

Questo può essere fatto direttamente con dotnet build. Puoi farlo anche tramite il file aws-lambda-tools-defaults.json con il seguente parametro:

"msbuild-parameters": "--self-contained true"

Questo è tutto, un semplice flag del compilatore quando si raggruppa la funzione Lambda .NET. Il pacchetto da distribuire ora conterrà il tuo codice e i file richiesti dal runtime .NET che hai scelto.

Ora spetta a te applicare le patch e aggiornare il runtime come ritieni opportuno. L'aggiornamento del runtime richiede la ridistribuzione della funzione, poiché il codice della funzione e il runtime sono impacchettati insieme.

Il pacchetto distribuito è notevolmente più grande rispetto al runtime gestito perché contiene tutti i file di runtime necessari. Ciò influisce negativamente sui tempi di avvio a freddo (ne parleremo più avanti). Per ridurre queste dimensioni, prendi in considerazione l'utilizzo delle funzionalità di compilazione .NET Trimming e ReadyToRun. Ti consigliamo di leggere la documentazione su queste funzionalità prima di utilizzarle.

È possibile creare un runtime personalizzato con qualsiasi versione .NET eseguita su Linux. Un caso d'uso comune consiste nel distribuire funzioni con le versioni "correnti" o di anteprima di .NET.

Quando si utilizzano runtime personalizzati, è possibile avvalersi di un'ampia varietà di linguaggi offerti dalla community. Oppure si può costruire il proprio runtime personalizzato, come hanno fatto altri per eseguire linguaggi come Erlang e COBOL.

È necessario installare gli strumenti richiesti per proseguire; consulta il modulo 3 per maggiori dettagli su come eseguire questa operazione.

Se non vuoi approfondirlo adesso, ecco un breve promemoria.

Installa i modelli di funzione Lambda .NET:

dotnet new -i Amazon.Lambda.Templates

Installa gli strumenti .NET per distribuire e gestire le funzioni Lambda:

dotnet tool install -g Amazon.Lambda.Tools

Ora che hai installato i modelli, puoi creare una nuova funzione

Dalla linea di comando esegui:

dotnet new lambda.EmptyFunction -n HelloEmptyFunction

In questo modo verrà creata una nuova directory chiamata HelloEmptyFunction. Al suo interno ci sono altre due directory: src e test. Come suggeriscono i nomi, la directory src contiene il codice per la funzione, mentre la directory test contiene i test di unità per la funzione. Navigando in queste directory, scoprirai che ognuna contiene un'altra directory al suo interno. All'interno di queste sottodirectory ci sono i file di codice per la funzione e i file di test di unità.

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

Diamo prima un'occhiata al file 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);
    }
}

Utilizza gli strumenti lambda dotnet per richiamare la funzione dalla shell (interprete di comandi) di tua scelta:

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

Per semplici funzioni Lambda come quelle precedenti, non esiste un JSON su cui fare l'escape, ma quando si desidera passare un JSON che deve essere deserializzato, l'escape del payload varierà a seconda della shell (interprete di comandi) che si sta utilizzando.

Verrà visualizzato un output simile al seguente:

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

L'output "Payload:" è la risposta della funzione Lambda.

Nota: la coda del log contiene informazioni utili sull'invocazione della funzione Lambda, ad esempio, per quanto tempo è stata eseguita e quanta memoria è stata utilizzata. Per una funzione semplice come questa, 244,83 ms potrebbero sembrare molti, ma questa è stata la prima volta che la funzione è stata richiamata, il che significa che è necessario eseguire più lavoro. Le invocazioni successive sarebbero state più rapide. Per ulteriori informazioni, consulta la sezione sugli avvii a freddo.

Facciamo una piccola modifica al codice per aggiungere alcune delle nostre istruzioni log.

Aggiungi quanto segue sopra l'istruzione return nel metodo FunctionHandler:

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

Implementa nuovamente utilizzando:

dotnet lambda deploy-function HelloEmptyFunction

Questa volta non ci saranno domande sul ruolo o sulle autorizzazioni.

Dopo che la funzione è stata implementata, puoi richiamarla nuovamente.

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

Questa volta, l'output conterrà un'istruzione di log aggiuntiva.

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

Qui, alla riga 6, troverai l'istruzione log. I log delle funzioni Lambda vengono scritti anche nei file di log CloudWatch (a condizione che tu abbia fornito le autorizzazioni alla funzione Lambda).

Un altro modo per richiamare la funzione è attraverso la console AWS.

Accedi alla console AWS e seleziona la funzione Lambda che desideri richiamare.

Fai clic sulla scheda Test.

Scorri verso il basso fino alla sezione JSON evento e inserisci "Richiama una funzione Lambda", incluse le virgolette.

Quindi fai clic sul pulsante Test.

L'output che vedrai sarà simile a questo.

Nota: sarà visibile anche l'output del log.

Come in precedenza, crea una nuova funzione utilizzando il seguente comando:

dotnet new lambda.EmptyFunction -n HelloPersonFunction

Accedi al file Function.cs in HelloPersonFunction/src/HelloPersonFunction.

Cambia il codice del metodo FunctionHandler in questo modo:

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

Nella parte inferiore del file, aggiungi una nuova classe:

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

Questo è lo stesso comando che hai usato qualche minuto fa:

dotnet lambda deploy-function HelloPersonFunction

Ora la tua funzione Lambda può accettare un payload JSON. Tuttavia, il modo in cui lo richiami dipende dalla shell (interprete di comandi) che stai usando a causa del modo in cui viene eseguito l'escape del JSON in ogni shell (interprete di comandi).

Se stai usando PowerShell o bash, usa:

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

Se invece stai usando il prompt dei comandi di Windows, usa:

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

Questo è un semplice esempio. Ma, ovviamente, il JSON può essere complesso quanto necessario.

Un altro modo per richiamare la funzione è attraverso la console AWS.

Accedi alla console AWS e seleziona la funzione Lambda che desideri richiamare.

Fai clic sulla scheda Test.

Scorri verso il basso fino alla sezione JSON evento e inserisci:

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

Quindi fai clic sul pulsante Test.

L'output che vedrai sarà simile a questo.

Gli esempi precedenti sono stati abbastanza semplici e la funzione Lambda non ha utilizzato nessun altro servizio AWS. Si tratta comunque di un ottimo modo per iniziare e acquisire familiarità con il servizio AWS Lambda, scrivere funzioni Lambda, implementare pacchetti compilati e richiamare le funzioni.

Nella prossima sezione, vedrai come implementare una funzione Lambda che risponde alle richieste HTTP.

Dalla linea di comando, esegui il comando seguente:

dotnet new serverless.AspNetCoreWebAPI -n HelloAspNetCoreWebAPI

Questo crea una nuova directory chiamata HelloAspNetCoreWebAPI. Al suo interno ci sono altre due directory, src e test. Come suggeriscono i nomi, la directory src contiene il codice per la funzione, mentre la directory test contiene i test di unità per la funzione. Navigando in queste directory, scoprirai che ognuna contiene un'altra directory al suo interno. All'interno di queste sottodirectory ci sono i file di codice per la funzione e i file di test di unità.

├───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

L'implementazione di una funzione basata su un modello serverless.* è un po' più complicata rispetto all'implementazione di una funzione basata su un modello lambda.*.

Prima di tentare di implementare la funzione serverless, è necessario un bucket S3. Questo verrà utilizzato dagli strumenti di implementazione per archiviare uno stack CloudFormation.

Puoi usare un bucket S3 esistente o, se non ne hai uno, segui le istruzioni riportate di seguito.

Se stai usando la regione us-east-1, usa il seguente comando per creare il bucket:

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

O se utilizzi una regione diversa

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

Ho creato un bucket in us-east-1, chiamato lambda-course-2022.

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

Ora che disponi di un bucket S3, puoi eseguire il comando di implementazione:

dotnet lambda deploy-serverless

Ti verrà richiesto di inserire un nome per lo stack CloudFormation.

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

Digita AspNetCoreWebAPI

Ti verrà quindi chiesto il nome del bucket S3. Usa il nome del bucket che hai creato in precedenza o un bucket esistente che desideri utilizzare a questo scopo.

Dopo averlo inserito, inizia il processo di creazione e implementazione.

Ciò richiederà più tempo rispetto agli esempi che utilizzano i modelli di progetto lambda.* perché c'è più infrastruttura da creare e cablare.

L'output verrà suddiviso in due sezioni distinte.

La sezione superiore sarà simile a quella che hai visto durante l'implementazione delle funzioni in precedenza, una pubblicazione e uno zip del progetto, ma questa volta l'artefatto viene caricato su 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%

Successivamente, viene creato lo stack CloudFormation e vengono implementate tutte le risorse necessarie.

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/

In basso c'è l'URL pubblico che da usare per richiamare l'API.

Tentando di aprire quell'URL nel tuo browser, o Fiddler/Postman, ecc., vedrai una risposta del tipo "Benvenuto nell'esecuzione di ASP.NET Core su AWS Lambda".

Quindi prova ad aprire https://xxxxxxxx.execute-api.us-east-1.amazonaws.com/Prod/api/values. In questo modo richiamerai il metodo GET del controller dei valori, proprio come in una normale applicazione API Web.

Nota: quando si utilizza un Gateway API, il gateway impone il proprio timeout di 29 secondi. Se la funzione Lambda funziona più a lungo, non riceverai una risposta.

Se sei interessato, ci sono alcuni modi per esaminare le risorse che sono state create.

Per esaminare le risorse AWS create, puoi utilizzare:

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

Questo ti fornirà dettagli su ogni risorsa dello stack.

Se vuoi un output più succinto, usa:

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

Un altro modo è aprire la console AWS e accedere al servizio Lambda. Sulla sinistra dello schermo, seleziona Applicazione (anziché funzioni).

Vedrai l'applicazione che hai creato. Selezionala, quindi scorri fino alla fine della pagina che si apre. Vedrai tutte le risorse che sono state create qui.

Hai completato la visione degli esempi di funzioni Lambda, il primo era un semplice Hello World che richiedeva una stringa, il secondo era anch'esso molto semplice ma richiedeva un oggetto JSON e il terzo era un po' più complesso, ma comunque molto facile da creare e implementare.

Con questi esempi, puoi creare e implementare le tue funzioni Lambda. E, magari, potresti aver capito qualcosa su come vengono richiamate le funzioni Lambda .NET. Questo è l'argomento della prossima sezione.

Se tutto ciò di cui hai bisogno è una funzione Lambda che risponda a una semplice richiesta HTTP, dovresti prendere in considerazione l'utilizzo degli URL della funzione Lambda.

Consentono di assegnare un endpoint HTTPS a una funzione Lambda. Dopodiché si richiama la funzione Lambda effettuando una richiesta all'endpoint HTTPS. Per ulteriori informazioni, consulta questo post del blog e questi documenti.

Per eliminare le funzioni Lambda, esegui:

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

Nota: i comandi precedenti non eliminano il ruolo che hai creato.

Per eliminare la funzione Lambda che agisce da host per l'applicazione Web API e tutte le risorse associate, esegui:

dotnet lambda delete-serverless AspNetCoreWebAPI

Ciò che rende molto semplice per un servizio AWS richiamare una funzione Lambda .NET è che questi servizi emettono JSON e, come discusso in precedenza, la funzione Lambda .NET accetta input JSON. Gli eventi generati da diversi servizi producono tutti JSON di forma diversa, ma i pacchetti NuGet degli eventi AWS Lambda includono tutti i tipi di oggetti pertinenti necessari per serializzare nuovamente il JSON in un oggetto su cui lavorare.

Vedi https://www.nuget.org/packages?packagetype=&sortby=relevance&q=Amazon.Lambda&prerel=True per un elenco dei pacchetti Lambda disponibili, dovrai cercare all'interno di questi risultati il tipo di evento che ti interessa.

Ad esempio, se desideri attivare una funzione Lambda in risposta a una modifica di file su un bucket S3, devi creare una funzione Lambda che accetti un oggetto di tipo S3Event. Quindi aggiungi il pacchetto Amazon.Lambda.S3Events al tuo progetto. Quindi cambia il metodo del gestore delle funzioni in:

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

Questo è tutto ciò di cui hai bisogno per gestire l'evento S3, puoi esaminare programmaticamente l'evento, vedere quale azione è stata eseguita sul file, in quale bucket si trovava, ecc. Amazon.Lambda.S3Events ti consente di lavorare con l'evento, non con S3 stesso, se desideri interagire con il servizio S3, devi aggiungere anche il pacchetto AWSSDK.S3 NuGet al tuo progetto. Un modulo successivo approfondirà l'argomento dei servizi AWS che richiamano le funzioni Lambda.

Lo stesso schema segue per altri tipi di eventi, aggiungi il pacchetto NuGet, modifica il parametro nel gestore della funzione e quindi puoi lavorare con l'oggetto evento.

Ecco alcuni dei pacchetti comuni che potresti usare per gestire gli eventi di altri servizi -

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

Non sei limitato all'utilizzo di tipi di eventi definiti da AWS quando richiami una funzione Lambda. Puoi creare tu stesso qualsiasi tipo di evento, ricorda che la funzione Lambda può accettare qualsiasi JSON che invii

Ricorderai che esistono due grandi categorie di modelli di progetto Lambda, quelle che iniziano con "lambda." e quelli che iniziano con "serverless.".

Nel caso dei modelli "lambda.", c'è un attributo assembly nella parte superiore del file Function.cs, che si occupa della deserializzazione dell'evento in entrata nel tipo .NET del gestore di funzioni. Nel file .csproj, c'è un riferimento al pacchetto Amazon.Lambda.Serialization.SystemTextJson.

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

Non devi fare nient'altro.

Per i modelli "serverless.", funziona in modo leggermente diverso.

Il gestore della funzione è specificato nel file serverless.template. Se stai implementando un'applicazione Serverless.AspNetCoreWebAPI, cerca il valore in Resources.AspNetCoreFunction.Properties.Handler. Il gestore per questo tipo di progetto terminerà nel modulo: Assembly::Namespace.LambdaEntryPoint::FunctionHandlerAsync.

La classe LambdaEntryPoint sarà nel tuo progetto ed eredita da una classe che ha un metodo FunctionHandlerAsync.

Il gestore di funzioni può essere impostato per gestire quattro diversi tipi di eventi: una REST API Gateway API, un payload API HTTP Gateway API versione 1.0, un payload API HTTP Gateway API versione 2.0 e un Application Load Balancer.

Modificando la classe da cui eredita LambdaEntryPoint, puoi cambiare il tipo di evento JSON gestito dal gestore della funzione.

Anche se sembra che la funzione Lambda stia rispondendo a una richiesta HTTP che la invii, con JSON che definisci, non è così. In realtà, la tua richiesta HTTP viene gestita da un gateway o da un sistema di bilanciamento del carico, che quindi crea un evento JSON che viene inviato al tuo gestore di funzioni. Questo evento JSON conterrà i dati originariamente inclusi nella richiesta HTTP, fino all'indirizzo IP di origine e alle intestazioni della richiesta.