.NET-Workloads in AWS Lambda

Der AWS-Lambda-Service bietet eine Vielzahl beliebter Laufzeiten, auf denen Sie Ihren Code ausführen können. In Bezug auf die .NET-Laufzeiten hält AWS die Laufzeit auf dem neuesten Stand und aktualisiert sie bei Bedarf mit den neuesten von Microsoft verfügbaren Versionen. Sie als Entwickler müssen in Bezug auf die Verwaltung der Laufzeit, die Ihr Code verwenden wird, nichts weiter tun, als die Version, die Sie verwenden möchten, in Ihrer vertrauten .csproj-Datei anzugeben.

Derzeit bietet AWS nur verwaltete Laufzeiten für Long Term Support (LTS)-Versionen der NET-Laufzeit an, d. h. .NET 3.1 und.NET 6. Die verwalteten.NET-Laufzeiten sind sowohl für x86_64- als auch für arm64-Architekturen verfügbar und werden in Amazon Linux 2 ausgeführt. Wenn Sie eine andere Version von .NET als die von AWS angebotenen verwenden möchten, können Sie Ihre eigene benutzerdefinierte Laufzeit erstellen oder ein Container-Image erstellen, das Ihren Anforderungen entspricht.

Wenn Sie daran interessiert sind, die .NET-Welt zu verlassen, ist es gut zu wissen, dass der Lambda-Service auch verwaltete Laufzeiten für andere Sprachen anbietet, wie Node.js, Python, Ruby, Java und Go. Vollständige Informationen zur Liste der verwalteten Laufzeiten und Versionen der unterstützten Sprachen finden Sie auf dieser Seite zu verfügbaren Laufzeiten.

Benutzerdefinierte Laufzeiten sind Laufzeiten, die Sie selbst erstellen und bündeln. Es gibt ein paar Gründe, warum Sie das tun würden. In den meisten Fällen möchten Sie eine Version von .NET verwenden, die vom Lambda-Service nicht als verwaltete Laufzeit angeboten wird. Ein weiterer, seltenerer Grund wäre, wenn Sie eine genaue Kontrolle über die Neben- und Patch-Versionen der Laufzeit haben möchten.

Das Erstellen der benutzerdefinierten Laufzeit ist von Ihrer Seite mit nur wenig Aufwand verbunden. Sie müssen dafür nur Folgendes tun:

--self-contained entspricht dem Build-Befehl.

Dies kann direkt mit dotnet build erfolgen. Sie können dies auch über die Datei aws-lambda-tools-defaults.json mit dem folgenden Parameter tun:

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

Das ist alles, ein einfaches Compiler-Flag beim Bündeln der Lambda-Funktion. Das bereitzustellende Paket enthält jetzt Ihren Code sowie die erforderlichen Dateien aus der ausgewählten .NET-Laufzeit.

Es liegt nun an Ihnen, die Laufzeit nach Belieben zu patchen und zu aktualisieren. Um die Laufzeit zu aktualisieren, müssen Sie die Funktion erneut bereitstellen, da der Funktionscode und die Laufzeit zusammen verpackt sind.

Das bereitgestellte Paket ist im Vergleich zur verwalteten Laufzeit deutlich größer, da es alle erforderlichen Laufzeitdateien enthält. Dies wirkt sich negativ auf die Kaltstartzeiten aus (dazu später mehr). Um diese Größe zu reduzieren, sollten Sie die .NET-Kompilierungsfunktionen Trimming und ReadyToRun verwenden. Bitte lesen Sie jedoch vorher die Dokumentation zu diesen Funktionen.

Sie können eine benutzerdefinierte Laufzeit mit jeder Version von .NET erstellen, die in Linux läuft. Ein häufiger Anwendungsfall ist die Bereitstellung von Funktionen mit den „aktuellen“ Versionen oder Vorschauversionen von.NET.

Wenn Sie benutzerdefinierte Laufzeiten verwenden, können Sie eine Vielzahl von Sprachen verwenden, die von der Community angeboten werden. Oder erstellen Sie sogar Ihre eigene benutzerdefinierte Laufzeit, wie es andere getan haben, um Sprachen wie Erlang und COBOL auszuführen.

Sie müssen hierfür die erforderlichen Tools installieren. Weitere Informationen dazu finden Sie in Modul 3.

Wenn Sie jetzt nicht dorthin springen möchten, finden Sie hier eine kurze Erinnerung.

Installieren Sie die .NET Lambda-Funktionsvorlagen:

dotnet new -i Amazon.Lambda.Templates

Installieren Sie das .NET-Tool für die Bereitstellung und Verwaltung von Lambda-Funktionen:

dotnet tool install -g Amazon.Lambda.Tools

Nachdem Sie die Vorlagen installiert haben, können Sie eine neue Funktion erstellen

Führen Sie in der Befehlszeile Folgendes aus:

dotnet new lambda.EmptyFunction -n HelloEmptyFunction

Dadurch wird ein neues Verzeichnis namens „HelloEmptyFunction“ erstellt. Darin befinden sich zwei weitere Verzeichnisse, src und test. Wie die Namen schon vermuten lassen, enthält das src-Verzeichnis den Code für die Funktion, und das test-Verzeichnis enthält die Modultests für die Funktion. Wenn Sie in diese Verzeichnisse navigieren, werden Sie feststellen, dass sie jeweils ein anderes Verzeichnis enthalten. In diesen Unterverzeichnissen befinden sich die Codedateien für die Funktion und die Modultestdateien.

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

Schauen wir uns zuerst die Datei Function.cs an.

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);
    }
}

Sie können das dotnet-Lambda-Tool verwenden, um die Funktion von der Shell Ihrer Wahl aus aufzurufen:

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

Bei einfachen Lambda-Funktionen wie die oben genannten ist kein JSON-Escaping erforderlich, aber wenn Sie ein deserialisiertes Element in JSON übergeben möchten, variiert das Escaping der Nutzlast je nach verwendeter Shell.

Sie werden eine Ausgabe sehen, die wie folgt aussieht:

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

Die Ausgabe „Payload:“ ist die Antwort der Lambda-Funktion.

Beachten Sie, dass der Log-Tail nützliche Informationen über den Lambda-Funktionsaufruf enthält, z. B. wie lange er ausgeführt wurde und wie viel Speicher verwendet wurde. Für eine einfache Funktion wie diese mögen 244,83 ms viel erscheinen, aber dies war das erste Mal, dass die Funktion aufgerufen wurde, was bedeutet, dass mehr Arbeit ausgeführt werden musste, nachfolgende Aufrufe wären schneller gewesen. Weitere Informationen finden Sie im Abschnitt über Kaltstarts.

Wir nehmen jetzt eine kleine Änderung am Code vor, um einige unserer eigenen Protokollanweisungen hinzuzufügen.

Fügen Sie über der Rückgabeanweisung in der FunctionHandler-Methode Folgendes hinzu:

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

Stellen Sie erneut bereit mit:

dotnet lambda deploy-function HelloEmptyFunction

Dieses Mal wird es keine Fragen zu Rollen oder Berechtigungen geben.

Nachdem die Funktion bereitgestellt wurde, können Sie sie erneut aufrufen.

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

Dieses Mal wird die Ausgabe eine zusätzliche Protokollanweisung enthalten.

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

Dort, in Zeile 6, befindet sich die Protokollanweisung. Lambda-Funktion-Protokolle werden auch in CloudWatch-Protokolle geschrieben (vorausgesetzt, Sie haben der Lambda-Funktion die entsprechenden Berechtigungen erteilt).

Eine andere Möglichkeit, die Funktion aufzurufen, ist die AWS-Konsole.

Melden Sie sich bei der AWS-Konsole an und wählen Sie die Lambda-Funktion aus, die Sie aufrufen möchten.

Klicken Sie auf die Registerkarte „Test“.

Scrollen Sie nach unten zum Abschnitt Event JSON und geben Sie „Invoking a Lambda function“ (Eine Lambda-Funktion aufrufen) ein, einschließlich der Anführungszeichen.

Klicken Sie dann auf die Schaltfläche „Test“ (Testen).

Sie werden eine Ausgabe ähnlich der folgenden sehen.

Beachten Sie, dass die Protokollausgabe ebenfalls sichtbar ist.

Erstellen Sie wie zuvor eine neue Funktion mit dem folgenden Befehl:

dotnet new lambda.EmptyFunction -n HelloPersonFunction

Navigieren Sie zur Datei Function.cs in HelloPersonFunction/src/HelloPersonFunction.

Ändern Sie den Code der FunctionHandler-Methode so, dass er wie folgt aussieht:

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

Fügen Sie am Ende der Datei eine neue Klasse hinzu:

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

Dies ist derselbe Befehl, den Sie vor ein paar Minuten verwendet haben:

dotnet lambda deploy-function HelloPersonFunction

Jetzt kann Ihre Lambda-Funktion eine JSON-Nutzlast annehmen, aber wie Sie sie aufrufen, hängt von der Shell ab, die Sie verwenden, da JSON in jeder Shell maskiert wird.

Wenn Sie PowerShell oder Bash verwenden, verwenden Sie Folgendes:

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

Wenn Sie jedoch die Windows-Eingabeaufforderung verwenden, verwenden Sie Folgendes:

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

Dies ist nur ein einfaches Beispiel. Aber natürlich kann JSON so komplex wie nötig sein.

Eine andere Möglichkeit, die Funktion aufzurufen, ist die AWS-Konsole.

Melden Sie sich bei der AWS-Konsole an und wählen Sie die Lambda-Funktion aus, die Sie aufrufen möchten.

Klicken Sie auf die Registerkarte „Test“.

Scrollen Sie nach unten zum Abschnitt „Event JSON“ (Ereignis-JSON) und geben Sie Folgendes ein:

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

Klicken Sie dann auf die Schaltfläche „Test“ (Testen).

Sie werden eine Ausgabe ähnlich der folgenden sehen.

Die letzten Beispiele waren ziemlich einfach, und die Lambda-Funktion hat keine anderen AWS-Services verwendet, aber sie sind eine gute Möglichkeit, um loszulegen und sich mit dem AWS-Lambda-Service vertraut zu machen, Lambda-Funktionen zu schreiben, kompilierte Pakete bereitzustellen und die Funktionen aufzurufen.

Im nächsten Abschnitt erfahren Sie, wie Sie eine Lambda-Funktion bereitstellen, die auf HTTP-Anfragen reagiert.

Führen Sie in der Befehlszeile den folgenden Befehl aus:

dotnet new serverless.AspNetCoreWebAPI -n HelloAspNetCoreWebAPI

Dadurch wird ein neues Verzeichnis namens HelloAspNetCoreWebAPI erstellt. Darin befinden sich zwei weitere Verzeichnisse, src und test. Wie die Namen schon vermuten lassen, enthält das src-Verzeichnis den Code für die Funktion, und das test-Verzeichnis enthält die Modultests für die Funktion. Wenn Sie in diese Verzeichnisse navigieren, werden Sie feststellen, dass sie jeweils ein anderes Verzeichnis enthalten. In diesen Unterverzeichnissen befinden sich die Codedateien für die Funktion und die Modultestdateien.

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

Die Bereitstellung einer Funktion, die auf einer serverless.*-Vorlage basiert, ist etwas aufwändiger als die Bereitstellung einer Funktion, die auf einer lambda.*-Vorlage basiert.

Bevor Sie versuchen, die Serverless-Funktion bereitzustellen, benötigen Sie einen S3-Bucket. Dieser wird von den Bereitstellungstools verwendet, um einen CloudFormation-Stack zu speichern.

Sie können einen vorhandenen S3-Bucket oder, falls Sie keinen haben, die folgenden Anweisungen verwenden.

Wenn Sie die Region us-east-1 verwenden, können Sie den folgenden Befehl verwenden, um den Bucket zu erstellen:

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

Wenn Sie eine andere Region verwenden

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

Ich habe in us-east-1 einen Bucket mit dem Namen lambda-course-2022 erstellt.

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

Jetzt, da Sie einen S3-Bucket haben, können Sie den Bereitstellungsbefehl ausführen:

dotnet lambda deploy-serverless

Sie werden aufgefordert, einen CloudFormation-Stack-Namen einzugeben.

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

Geben Sie AspNetCoreWebAPI ein

Sie werden dann nach dem S3-Bucket-Namen gefragt. Verwenden Sie den Namen des Buckets, den Sie zuvor erstellt haben, oder eines vorhandenen Buckets, den Sie für diesen Zweck verwenden möchten.

Nachdem Sie ihn eingegeben haben, beginnt der Erstellungs- und Bereitstellungsprozess.

Dies wird länger dauern als die Beispiele, die lambda.*-Projektvorlagen verwenden, da mehr Infrastruktur erstellt und angeschlossen werden muss.

Die Ausgabe wird in zwei verschiedene Abschnitte aufgeteilt.

Der obere Abschnitt wird dem ähneln, was Sie zuvor bei der Bereitstellung von Funktionen gesehen haben, eine Veröffentlichung und eine ZIP-Datei des Projekts, aber dieses Mal wird das Artefakt in S3 hochgeladen.

..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%

Danach wird der CloudFormation-Stack erstellt und alle erforderlichen Ressourcen werden bereitgestellt.

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/

Ganz unten befindet sich die öffentliche URL, mit der Sie die API aufrufen können.

Wenn Sie diese URL in Ihrem Browser oder Fiddler/Postman usw. öffnen, wird eine Antwort wie „Welcome to running ASP.NET Core on AWS Lambda“ (Willkommen beim Ausführen von ASP.NET Core auf AWS Lambda) angezeigt.

Versuchen Sie dann, https://xxxxxxxx.execute-api.us-east-1.amazonaws.com/Prod/api/values zu öffnen. Sie rufen die GET-Methode des Werte-Controllers auf, genau wie in einer normalen Web-API-Anwendung.

Beachten Sie, dass bei Verwendung eines API-Gateways das Gateway ein eigenes Timeout von 29 Sekunden festlegt. Wenn Ihre Lambda-Funktion länger läuft, erhalten Sie keine Antwort.

Wenn Sie interessiert sind, gibt es verschiedene Möglichkeiten, die erstellten Ressourcen zu überprüfen.

Um die erstellten AWS-Ressourcen zu überprüfen, können Sie Folgendes verwenden:

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

Dadurch erhalten Sie Details zu jeder Ressource im Stack.

Wenn Sie eine prägnantere Ausgabe wünschen, verwenden Sie Folgendes:

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

Eine andere Möglichkeit besteht darin, die AWS-Konsole zu öffnen und zum Lambda-Service zu navigieren. Wählen Sie auf der linken Seite des Bildschirms „Application“ (Anwendung) (statt „Functions“ [Funktionen]) aus.

Sie werden die Anwendung sehen, die Sie erstellt haben. Wählen Sie sie aus und scrollen Sie dann zum Ende der sich öffnenden Seite. Sie werden alle Ressourcen sehen, die hier erstellt wurden.

Sie haben jetzt drei Beispiele für Lambda-Funktionen gesehen, die erste war eine einfache „Hello World“, die eine Zeichenfolge benötigte, die zweite war ebenfalls sehr einfach, nahm aber ein JSON-Objekt, und die dritte war etwas komplexer, aber immer noch sehr einfach zu erstellen und bereitzustellen.

Mit diesen Beispielen können Sie Ihre eigenen Lambda-Funktionen erstellen und bereitstellen. Und vielleicht haben Sie ein wenig darüber erfahren, wie .NET-Lambda-Funktionen aufgerufen werden. Das ist das Thema des nächsten Abschnitts.

Wenn Sie lediglich eine Lambda-Funktion benötigen, die auf eine einfache HTTP-Anfrage reagiert, sollten Sie die Verwendung von Lambda-Funktions-URLs in Betracht ziehen.

Sie ermöglichen es Ihnen, einer Lambda-Funktion einen HTTPS-Endpunkt zuzuweisen. Anschließend rufen Sie die Lambda-Funktion auf, indem Sie eine Anfrage an den HTTPS-Endpunkt stellen. Weitere Informationen finden Sie in diesem Blog-Beitrag sowie in diesen Dokumentationen.

Wenn Sie die Lambda-Funktion löschen möchten, führen Sie Folgendes aus:

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

Beachten Sie, dass die obigen Befehle die von Ihnen erstellte Rolle nicht löschen.

Um die Lambda-Funktion, die die Web-API-Anwendung hostete, und alle zugehörigen Ressourcen zu löschen, führen Sie Folgendes aus:

dotnet lambda delete-serverless AspNetCoreWebAPI

Ein AWS-Service kann so einfach eine.NET-Lambda-Funktion aufrufen, da diese Services JSON ausgeben und die .NET-Lambda-Funktion, wie oben beschrieben, JSON-Eingaben akzeptiert. Die von verschiedenen Services ausgelösten Ereignisse erzeugen alle unterschiedlich geformtes JSON, aber die Ereignis-NuGet-Pakete von AWS Lambda enthalten alle relevanten Objekttypen, die erforderlich sind, um den JSON wieder in ein Objekt zu serialisieren, mit dem Sie arbeiten können.

Unter https://www.nuget.org/packages?packagetype=&sortby=relevance&q=Amazon.Lambda&prerel=True finden Sie eine Liste der verfügbaren Lambda-Pakete. Sie müssen in diesen Ergebnissen nach dem Ereignistyp suchen, an dem Sie interessiert sind.

Wenn Sie beispielsweise eine Lambda-Funktion als Reaktion auf eine Dateiänderung in einem S3-Bucket auslösen möchten, müssen Sie eine Lambda-Funktion erstellen, die ein Objekt vom Typ S3Event akzeptiert. Anschließend fügen Sie das Amazon.Lambda.S3Events-Paket zu Ihrem Projekt hinzu. Ändern Sie dann die Funktionshandler-Methode zu:

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

Das ist alles, was Sie benötigen, um das S3-Ereignis handhaben. Sie können das Ereignis programmgesteuert untersuchen, sehen, welche Aktion für die Datei ausgeführt wurde, in welchem Bucket sie sich befand usw. Mit Amazon.Lambda.S3Events können Sie mit dem Ereignis arbeiten, nicht mit S3 selbst. Wenn Sie mit dem S3-Service interagieren möchten, müssen Sie Ihrem Projekt auch das NuGet-Paket AWSSDK.S3 hinzufügen. Ein späteres Modul wird sich mit AWS-Services befassen, die Lambda-Funktionen aufrufen.

Das gleiche Muster gilt für andere Ereignistypen. Fügen Sie das NuGet-Paket hinzu und ändern Sie den Parameter in den Funktionshandler, um mit dem Ereignisobjekt zu arbeiten.

Hier sind einige der gängigen Pakete, die Sie verwenden könnten, um Ereignisse von anderen Services zu behandeln:

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

Sie sind nicht auf die Verwendung von AWS-definierten Ereignistypen beschränkt, wenn Sie eine Lambda-Funktion aufrufen. Sie können jede Art von Ereignis selbst erstellen. Denken Sie daran, dass die Lambda-Funktion jedes JSON annehmen kann, das Sie an sie senden

Sie werden sich erinnern, dass es zwei große Kategorien von Lambda-Projektvorlagen gibt: einmal die, die mit „Lambda“ beginnen, und dann solche, die mit „serverless“ beginnen.

Bei den „lambda.“-Vorlagen befindet sich oben in der Datei Function.cs ein Assembly-Attribut, das in Ihrem Funktionshandler für die Deserialisierung des eingehenden Ereignisses in den .NET-Typ sorgt. In der csproj-Datei gibt es einen Verweis auf das Amazon.Lambda.Serialization.SystemTextJson-Paket.

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

Sie müssen nichts weiter tun.

Bei den „serverless.“-Vorlagen sieht es etwas anders aus.

Der Funktionshandler ist in der Datei serverless.template angegeben. Wenn Sie eine serverless.AspNetCoreWebAPI-Anwendung bereitstellen, suchen Sie unter Resources.AspNetCoreFunction.Properties.Handler nach dem Wert. Der Handler für diesen Projekttyp hat das Format Assembly::Namespace.LambdaEntryPoint::FunctionHandlerAsync.

Die LambdaEntryPoint-Klasse befindet sich in Ihrem Projekt und erbt von einer Klasse, die über eine FunctionHandlerAsync-Methode verfügt.

Der Funktionshandler kann so eingestellt werden, dass er vier verschiedene Ereignistypen behandelt: eine API-Gateway-REST-API, eine API-Gateway-HTTP-API-Nutzlast Version 1.0, eine API-Gateway-HTTP-API-Nutzlast Version 2.0 und einen Application Load Balancer.

Indem Sie ändern, von welcher Klasse der LambdaEntryPoint erbt, können Sie ändern, welchen JSON-Ereignistyp der Funktionshandler verarbeitet.

Obwohl es so aussieht, als würde die Lambda-Funktion auf eine HTTP-Anfrage antworten, die Sie an sie senden, ist dies bei von Ihnen definiertem JSON nicht der Fall. In Wirklichkeit wird Ihre HTTP-Anfrage von einem Gateway oder Load Balancer verarbeitet, der dann ein JSON-Ereignis erstellt, das an Ihren Funktionshandler gesendet wird. Dieses JSON-Ereignis enthält die Daten, die ursprünglich in der HTTP-Anfrage enthalten waren, bis hin zur Quell-IP-Adresse und den Anforderungsheadern.