Serverless – AWS Lambda (Część 1)

Zaczynamy już bardziej technicznej. Pobawimy się funkcjami i zobaczymy co i jak nam daje. Ze względu na to, że chcę to zrobić dla każdego, przeważnie będą po dwie części per dostawca Serverless. To znaczy minimum dwie. Gdzie pierwsza zawsze będzie organizacyjna/konfiguracyjna/wprowadzająca. Druga i kolejne już bardziej wchodzące w to co możemy zrobić. Zaczynamy od pierwszej dostępnej chmury i FaaS – czyli AWS Lambda.

Mała adnotacja, przez pewne rzeczy będę was przeprowadzał, ale przez pewne po prostu odwołam do tutoriali lub dokumentacji. Na przykład jak założyć konto na AWS czy Auzre… to każdy potrafi a jak jest z tym problem, to pewnie dokumentacja szybciej i sprawniej pomoże niż ja.

Przy wszystkich opisach, domyślnym językiem będzie C# chyba, że nie jest on dostępny, wtedy JavaScript.

Przygotowanie środowiska

Pierwszym krokiem rozpoczęcia zabawy z AWS jest założenie konta na AWS. Tutaj będzie potrzebne podanie danych karty kredytowej/płatniczej. Nie ma co się obawiać… do póki mądrze korzystamy z chmury nic się nam nie stanie. Warto ustawić sobie powiadomienia, że coś się dzieje jak i (w miarę możliwości ograniczyć wszystkie opcje). Chyba z tego co wiem (proszę poprawcie mnie) w AWS nie ma możliwości ustawienia limitów płatności. Więc alert jest najlepszą naszą opcją.

Po założeniu konta, warto zapoznać się trochę z portalem, po prostu poklikać co i jak. Na przykład górne prawy róg umożliwia nam zmianę regiony w jakim operujemy. To ma znaczenie, jeżeli stawiamy bazę w stanach a stronę w Europie. Nagle się okazuje, że przesył danych może nam zjeść niejedno ograniczenie.

Po zapoznaniu się z UI i posiadaniu konta AWS należy doinstalować (jak nie ma) dotenet core. Jeżeli macie mac i korzystacie z boxen to zapraszam po instrukcję tutaj.

Jesteśmy prawie gotowi do zaczęcia zabawy, jeszcze pozostaje jedna mała rzecz. Swojego czasu dotnet korzystał z yeomana by tworzyć szablony projektów. Teraz korzysta on z rozszerzenia narzędzia dotnet new. Amazon poszedł nam trochę na rękę i stworzył specjalne szablony którymi możemy rozszerzyć opce dostępne przy dotnet new, wystarczy, że zainstalujemy paczkę:

dotnet new -i Amazon.Lambda.Templates::*

I od tej pory będziemy mieli dostępne szablony rozpoczynające się od lambda.:

dotnet new -all

Poniżej lista aktualnie dostępnych szablonów

Templates                            Short Name                    Language      Tags
------------------------------------------------------------------------------------------------------
Lambda Detect Image Labels           lambda.DetectImageLabels      [C#]          AWS/Lambda/Function
Lambda Empty Function                lambda.EmptyFunction          [C#]          AWS/Lambda/Function
Lambda Simple DynamoDB Function      lambda.DynamoDB               [C#]          AWS/Lambda/Function
Lambda Simple Kinesis Function       lambda.Kinesis                [C#]          AWS/Lambda/Function
Lambda Simple S3 Function            lambda.S3                     [C#]          AWS/Lambda/Function
Lambda ASP.NET Core Web API          lambda.AspNetCoreWebAPI       [C#]          AWS/Lambda/Serverless
Lambda DynamoDB Blog API             lambda.DynamoDBBlogAPI        [C#]          AWS/Lambda/Serverless
Lambda Empty Serverless              lambda.EmptyServerless        [C#]          AWS/Lambda/Serverless

Pierwsza aplikacja

W celu stworzenia aplikacji wystarczy, że z konsoli odpalimy:

dotnet new lambda.EmptyFunction

To stworzy nam dwa projekty – testowy i źródłowy. Przy czym zrobi coś jeszcze, doda nam paczkę Amazon.Lambda.Tools do DotNetCliToolReference w pliku projektu.

Teraz, niestety musimy wejść do katalogu src/NAME i wykonać:

dotnet restore

Nie uda nam się tego zrobić (albo mi się nie udaje) z poziomu w którym stworzyliśmy EmptyFunction. To co zrobi dotnet restore to zainstaluje wszystkie paczki wymienione w projekcie.

Lambda Tools

Znalezienie Lambda Tools w pliku projektu jest znaczące, gdyż ta paczka udostępnia narzędzia kontekstowe dotnet lambda:

> dotnet lambda help

Commands to deploy and manage AWS Lambda functions:
deploy-function         Command to deploy the project to AWS Lambda
invoke-function         Command to invoke a function in Lambda with an optional input
list-functions          Command to list all your Lambda functions
delete-function         Command to delete an AWS Lambda function
get-function-config     Command to get the current runtime configuration for a Lambda function
update-function-config  Command to update the runtime configuration for a Lambda function

Commands to deploy and manage AWS Serverless applications using AWS CloudFormation:
deploy-serverless       Command to deploy an AWS Serverless applicati
list-serverless         Command to list all your AWS Serverless applications
delete-serverless       Command to delete an AWS Serverless application

Other Commands:
package                 Command to package a Lambda project into a zip file ready for deployment

To get help on individual commands execute:
dotnet lambda help <command>

To właśnie dzięki Amazon.Lambda.Tools będziemy mogli z deployować naszą funkcję.

Konfiguracja AWS

Mając projekt warto skonfigurować sobie tak AWS by można było bez problemowo deployować naszą aplikację. W tym celu otwieramy plik aws-lambda-tools-defaults.json i modyfikujemy jego region na wartość która nas interesuje:

{
  "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" : "eu-central-1",
  "configuration" : "Release",
  "framework" : "netcoreapp1.0",
  "function-runtime":"dotnetcore1.0",
  "function-memory-size" : 256,
  "function-timeout" : 30,
  "function-handler" : "t1::t1.Function::FunctionHandler"
}

Ja ustawiłem wartość region na eu-central-1 (łatwo dowiedzieć się o region przy zmianie go z poziomu UI, zarówno URL jak i jego fragment ulegają zmianie, albo po prostu kliknąć tutaj).

To też możemy zrobić w trakcie tworzenia projektu za pomocą parametrów:

dotnet new lambda.EmptyFunction --profile default --region eu-central-1

Do tego co żeśmy zrobili musimy ustawić kilka zmiennych środowiskowych:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN

Wszystkie trzy klucze można pobrać z Your Security Credentials, sekcja Access Keys. To nam pozwoli ustawić AWS_ACCESS_KEY_ID i AWS_SECRET_ACCESS_KEY. Zaś AWS_SESSION_TOKEN jest opcjonalny – w sensie, jak nie mamy tych dwóch pierwszych to jest nam potrzebny AWS_SESSION_TOKEN.

Deployowanie rozwiązania

Mając już tak przygotowane środowisko, wykonujemy polecenie:

dotnet lambda deploy-function NAME

To powinno wywołać kilka rzeczy, po pierwsze musimy stworzyć IAM Role, co to takiego? W skrócie użytkownik funkcji. Dłużej wersji się nie podejmę.

Po podaniu nazwy roli, trzeba wybrać opcję IAM Policy czyli coś co nam powie jakie to ma prawa. Ja wybieram opcję AWSLambdaRole. Nie znam się zbytnio na tym i mam to w todo by to poznać trochę. Po tym już nasza funkcja będzie z deployowana. I można z niej już korzystać.

Wywołanie funkcji

Funkcje w ten sposób z deployowaną możemy wykonać za pomocą komendy:

dotnet lambda invoke-function NAME --payload "nasz funkcja działa"

Co powinno nam zwrócić:

Payload:
"NASZ FUNKCJA DZIAŁA"

Log Tail:
START RequestId: f01a303e-2eac-11e7-9c76-a724452939df Version: $LATEST
END RequestId: f01a303e-2eac-11e7-9c76-a724452939df
REPORT RequestId: f01a303e-2eac-11e7-9c76-a724452939df        Duration: 827.38 ms        Billed Duration: 900 ms         Memory Size: 256 MB        Max Memory Used: 45 MB

Przeglądanie funkcji

Nasza funkcja jest dostępna też z poziomu UI, możemy podejrzeć jej historię wykonań na przykład z poziomu portalu. W tym celu w services wyszukujemy Lambda i klikamy na link.

Następnie mamy dostęp do wszystkich funkcji, w tym przypadku powinna być jedna:

Ogólnie tutaj możemy kilka rzeczy dokonfigurować jak i za pomocą monitoring tab przejrzeć historię działania funkcji. Jednak to pozostawię na kiedy indziej.

To co warto zawsze robić po skończonej zabawie

Warto zawsze pamiętać o kasowaniu funkcji, jeżeli jej nie potrzebujemy. NA WSZELKI wypadek. Po co mamy ją mieć i po co ktoś przypadkiem może nam zrobić psikusa? :)

dotnet lambda delete-function t1

Podsumowanie

To tyle na dzisiaj, jak widać nie jest to ciężkie jednak jest trochę rzeczy do rozpoznania i do wyklinania zanim uda nam się wgrać naszą funkcję. To co stoi u mnie na przeszkodzie tutaj to brak wiedzy na temat AWS – IAM Role, Policy etc. To trochę drażni, bo ma się odczucie działania po omacku.

W całości ani razu nie wspomniałem też o AWS Toolkit for Visual Studio. Zrobię o tym osobny wpis. Jednak ogólnie robi on to samo co nasze szablony dla dotnet core z tą różnicą, iż jest to dla Visual Studio.

To co jest trochę smutne to, brak możliwości podejrzenia kodu naszej funkcji z poziomy przeglądarki. Osobiście myślałem, że coś przegapiłem, ale opcji po prostu nie znalazłem.