streamalism.org

1. Oversigt

I vores forrige artikel har vi allerede implementeret en serverløs applikation med fuld stak på AWS ved hjælp af API Gateway til REST-slutpunkter, AWS Lambda til forretningslogik samt en DynamoDB som en database.

Imidlertid består implementeringen af ​​mange manuelle trin, som kan blive uhåndterlige med voksende kompleksitet og med antallet af miljøer.

I denne vejledning diskuterer vi nu, hvordan du bruger AWS Serverless Application Model (SAM), som muliggør en skabelonbaseret beskrivelse og automatisk implementering af serverløse applikationer på AWS.

I detaljer vil vi se på følgende emner:

• Grundlæggende om den serverløse applikationsmodel (SAM) såvel som for den underliggende CloudFormation
• Definition af en serverløs applikation ved hjælp af SAM-skabelonsyntaks
• Automatisk implementering af applikationen ved hjælp af CloudFormation CLI

2. Grundlæggende

Som tidligere omtalt giver AWS os mulighed for at implementere helt serverløse applikationer ved hjælp af API Gateway, Lambda-funktioner og DynamoDB. Det giver utvivlsomt allerede mange fordele for ydeevne, omkostninger og skalerbarhed.

Ulempen er imidlertid, at vi har brug for mange manuelle trin i AWS-konsollen i øjeblikket, som at oprette hver funktion, uploade kode, oprette DynamoDB-tabellen, oprette IAM-roller, oprette API- og API-struktur osv.

Til komplekse applikationer og i flere miljøer som test, iscenesættelse og produktion multipliceres denne indsats hurtigt.

Det er her CloudFormation til applikationer på AWS generelt og Serverless Application Model (SAM) specifikt til serverløse applikationer kommer i spil.

2.1. AWS CloudFormation

CloudFormation er en AWS-tjeneste til automatisk levering af AWS-infrastrukturressourcer. En bruger definerer alle nødvendige ressourcer i en plan (kaldet skabelon), og AWS tager sig af klargøringen og konfigurationen.

Følgende udtryk og koncepter er afgørende for forståelsen af ​​CloudFormation og SAM:

En skabelon er en beskrivelse af en applikation, hvordan det skal struktureres ved kørsel. Vi kan definere et sæt krævede ressourcer samt hvordan disse ressourcer skal konfigureres. CloudFormation giver et fælles sprog til definition af skabeloner, der understøtter JSON og YAML som et format.

Ressourcer er byggestenene i CloudFormation. En ressource kan være hvad som helst som en RestApi, en fase af en RestApi, et batchjob, en DynamoDB-tabel, en EC2-forekomst, en netværksgrænseflade, en IAM-rolle og mange flere. Den officielle dokumentation viser i øjeblikket omkring 300 ressourcetyper til CloudFormation.

En stak er instantiering af en skabelon. CloudFormation tager sig af klargøring og konfiguration af stakken.

2.2. Serverløs applikationsmodel (SAM)

Som så ofte kan brugen af ​​kraftfulde værktøjer blive meget kompleks og uhåndterlig, hvilket også er tilfældet for CloudFormation.

Derfor introducerede Amazon den serverløse applikationsmodel (SAM). SAM startede med påstanden om at give en ren og ligetil syntaks til definition af serverløse applikationer. I øjeblikket har den kun tre ressourcetyper, som er Lambda-funktioner, DynamoDB-tabeller og API'er.

SAM er baseret på CloudFormation-skabelonsyntaks, så vi kan definere vores skabelon ved hjælp af den enkle SAM-syntaks, og CloudFormation behandler skabelonen yderligere.

Flere detaljer er tilgængelige på det officielle GitHub-arkiv såvel som i AWS-dokumentationen.

3. Forudsætninger

Til den følgende vejledning har vi brug for en AWS-konto. En gratis tier-konto skal være tilstrækkelig.

Derudover er vi nødt til at have AWS CLI installeret.

Endelig har vi brug for en S3 Bucket i vores region, som kan oprettes via AWS CLI med følgende kommando:

$> aws s3 mb s3: // baeldung-sam-bucket

Mens tutorial bruger baeldung-sam-spand i det følgende skal du være opmærksom på, at spandnavne skal være unikke, så du skal vælge dit navn.

Som en demo-applikation bruger vi koden fra Brug af AWS Lambda med API Gateway.

4. Oprettelse af skabelonen

I dette afsnit opretter vi vores SAM-skabelon.

Vi kigger først på den overordnede struktur, inden vi definerer de enkelte ressourcer.

4.1. Skabelonens struktur

Lad os først se på den overordnede struktur for vores skabelon:

AWSTemplateFormatVersion: '2010-09-09' Transform: 'AWS :: Serverless-2016-10-31' Beskrivelse: Baeldung Serverless applikationsmodeleksempel Ressourcer: PersonTable: Type: AWS :: Serverless :: SimpleTable Properties: # Definer tabelegenskaber her StorePersonFunction: Type: AWS :: Serverless :: Funktionsegenskaber: # Definer funktionsegenskaber her GetPersonByHTTPParamFunction: Type: AWS :: Serverless :: Funktionsegenskaber: # Definer funktionsegenskaber her MyApi: Type: AWS :: Serverless :: Api Properties: # Definer API-egenskaber her

Som vi kan se, består skabelonen af ​​et overskrift og en krop:

Overskriften specificerer versionen af ​​CloudFormation-skabelonen (AWSTemplateFormatVersion) samt versionen af ​​vores SAM-skabelon (Transformer). Vi kan også specificere en Beskrivelse.

Kroppen består af et sæt ressourcer: hver ressource har et navn, en ressource Typeog et sæt af Ejendomme.

SAM-specifikationen understøtter i øjeblikket tre typer: AWS :: Serverløs :: Api, AWS :: Serverløs :: Funktion såvel som AWS :: Serverløs :: SimpleTable.

Da vi ønsker at implementere vores eksempelapplikation, skal vi definere en SimpleTable, to Funktioner, såvel som en Api i vores skabelon-krop.

4.2. DynamoDB tabel definition

Lad os definere vores DynamoDB-tabel nu:

AWSTemplateFormatVersion: '2010-09-09' Transform: 'AWS :: Serverless-2016-10-31' Beskrivelse: Baeldung Serverless applikationsmodeleksempel Ressourcer: PersonTable: Type: AWS :: Serverless :: SimpleTable Properties: PrimaryKey: Name: id Type: Nummertabel Navn: Person

Vi behøver kun at definere to egenskaber til vores SimpleTable: tabelnavnet samt en primær nøgle, der kaldes id og har typen Nummer i vores tilfælde.

En komplet liste over understøttede SimpleTable ejendomme kan findes i den officielle specifikation.

Bemærk: Da vi kun ønsker at få adgang til tabellen ved hjælp af den primære nøgle, er AWS :: Serverløs :: SimpleTable er tilstrækkelig for os. For mere komplekse krav, den oprindelige CloudFormation-type AWS :: DynamoDB :: Tabel kan bruges i stedet.

4.3. Definition af Lambda-funktionerne

Lad os derefter definere vores to funktioner:

AWSTemplateFormatVersion: '2009-09-09' Transform: 'AWS :: Serverless-2016-10-31' Beskrivelse: Baeldung Serverless applikationsmodeleksempel Ressourcer: StorePersonFunction: Type: AWS :: Serverless :: Funktionsegenskaber: Handler: com.baeldung .lambda.apigateway.APIDemoHandler :: handleRequest Runtime: java8 Timeout: 15 MemorySize: 512 CodeUri: ../target/aws-lambda-0.1.0-SNAPSHOT.jar Politikker: DynamoDBCrudPolicy Miljø: Variabler: TABLE_NAME:! Ref PersonTable Events: StoreApi: Type: Api Egenskaber: Sti: / persons Metode: PUT RestApiId: Ref: MyApi GetPersonByHTTPParamFunction: Type: AWS :: Serverless :: Funktionsegenskaber: Handler: com.baeldung.lambda.apigateway.APIDemoHandler :: handleGetByParam Runtime: java8 Timeout : 15 MemorySize: 512 CodeUri: ../target/aws-lambda-0.1.0-SNAPSHOT.jar Politikker: DynamoDBReadPolicy Miljø: Variabler: TABLE_NAME:! Ref PersonTable begivenheder: GetByPathApi: Type: Api egenskaber: Sti: / personer / { id} Metode: GET RestApiId: Ref: MyApi GetByQueryApi: Type: Api Propertie s: Sti: / personer Metode: FÅ RestApiId: Ref: MyApi

Som vi kan se, har hver funktion de samme egenskaber:

Handler definerer funktionens logik. Da vi bruger Java, er det klassens navn inklusive pakken i forbindelse med metodens navn.

Kørselstid definerer, hvordan funktionen blev implementeret, hvilket er Java 8 i vores tilfælde.

Tiden er gået definerer, hvor lang tid eksekveringen af ​​koden højst kan tage inden AWS afslutter eksekveringen.

MemorySizedefinerer størrelsen på den tildelte hukommelse i MB. Det er vigtigt at vide, at AWS tildeler CPU-ressourcer proportionalt til MemorySize. Så i tilfælde af en CPU-intensiv funktion kan det være nødvendigt at øge MemorySize, selvom funktionen ikke har brug for så meget hukommelse.

CodeUridefinerer placeringen af ​​funktionskoden. Den refererer i øjeblikket til målmappen i vores lokale arbejdsområde. Når vi uploader vores funktion senere ved hjælp af CloudFormation, får vi en opdateret fil med en henvisning til et S3-objekt.

Politikkerkan indeholde et sæt AWS-styrede IAM-politikker eller SAM-specifikke politikskabeloner. Vi bruger de SAM-specifikke politikker DynamoDBCrudPolitik til StorePersonFunction og DynamoDBReadPolicy til GetPersonByPathParamFunction og GetPersonByQueryParamFunction.

Miljødefinerer miljøegenskaber ved kørselstid. Vi bruger en miljøvariabel til at holde navnet på vores DynamoDB-tabel.

Begivenhederkan holde et sæt AWS-begivenheder, som skal være i stand til at udløse funktionen. I vores tilfælde definerer vi en Begivenhed af typen Api. Den unikke kombination af sti, en HTTP Metodeog en RestApiId linker funktionen til en metode i vores API, som vi definerer i næste afsnit.

En komplet liste over understøttede Fungere ejendomme kan findes i den officielle specifikation.

4.4. API-definition som swagger-fil

Efter at have defineret DynamoDB tabel og funktioner, kan vi nu definere API.

Den første mulighed er at definere vores API inline ved hjælp af Swagger-formatet:

AWSTemplateFormatVersion: '2010-09-09' Transform: 'AWS :: Serverless-2016-10-31' Beskrivelse: Baeldung Serverless applikationsmodeleksempel Ressourcer: MyApi: Type: AWS :: Serverless :: Api Properties: StageName: test EndpointConfiguration: REGIONAL DefinitionBody: swagger: "2.0" info: title: "TestAPI" stier: / persons: get: parameters: - name: "id" in: "query" required: true type: "string" x-amazon-apigateway-request -validator: "Valider forespørgselsstrengparametre og \ \ headers" x-amazon-apigateway-integration: uri: Fn :: Sub: arn: aws: apigateway: $ {AWS :: Region}: lambda: path / 2015-03- 31 / funktioner / $ {GetPersonByHTTPParamFunction.Arn} / invokations svar: {} httpMethod: "POST" type: "aws_proxy" put: x-amazon-apigateway-integration: uri: Fn :: Sub: arn: aws: apigateway: $ {AWS :: Region}: lambda: path / 2015-03-31 / functions / $ {StorePersonFunction.Arn} / invokations-svar: {} httpMethod: "POST" type: "aws_proxy" / persons / {id}: get: parametre: - navn: "id" i: "sti" krævet: sand type: "streng" svar: {} xa mazon-apigateway-integration: uri: Fn :: Sub: arn: aws: apigateway: $ {AWS :: Region}: lambda: sti / 2015-03-31 / funktioner / $ {GetPersonByHTTPParamFunction.Arn} / invokations svar: { } httpMethod: "POST" type: "aws_proxy" x-amazon-apigateway-request-validators: Validate query string parameters and headers: validateRequestParameters: true validateRequestBody: false

Vores Api har tre egenskaber: Kunstnernavndefinerer scenen i API'et, EndpointConfigurationdefinerer, om API'en er regional eller kantoptimeret, og Definition Body indeholder API'ens faktiske struktur.

I Definition Body, definerer vi tre parametre: swagger version som “2.0”, det info: titel: som “TestAPI”, samt et sæt af stier.

Som vi kan se, er stier repræsenterer API-strukturen, som vi skulle definere manuelt før. Det stier i Swagger svarer til ressourcerne i AWS-konsollen. Lige sådan hver sti kan have en eller flere HTTP-verb, der svarer til metoderne i AWS-konsollen.

Hver metode kan have en eller flere parametre samt en anmodningsvalidator.

Den mest spændende del er attributten x-amazon-apigateway-integration, som er en AWS-specifik udvidelse til Swagger:

uri angiver, hvilken Lambda-funktion der skal påberåbes.

svar angive regler for, hvordan man omdanner svarene, der returneres af funktionen. Da vi bruger Lambda Proxy Integration, behøver vi ingen specifik regel.

type definerer, at vi vil bruge Lambda Proxy Integration, og dermed er vi nødt til at indstille httpMetode til "STOLPE", da dette er, hvad Lambda-funktioner forventer.

En komplet liste over understøttede Api ejendomme kan findes i den officielle specifikation.

4.5. Implicit API-definition

En anden mulighed er at definere API'en implicit inden for funktionsressourcerne:

AWSTemplateFormatVersion: '2010-09-09' Transform: 'AWS :: Serverless-2016-10-31' Beskrivelse: Baeldung Serverless applikationsmodel Eksempel med implicit API-definition Globals: Api: EndpointConfiguration: REGIONALt navn: "TestAPI" Ressourcer: StorePersonFunction: Type: AWS :: Serverløs :: Funktionsegenskaber: Handler: com.baeldung.lambda.apigateway.APIDemoHandler :: handleRequest Runtime: java8 Timeout: 15 MemorySize: 512 CodeUri: ../target/aws-lambda-0.1.0-SNAPSHOT jar politik Handler: com.baeldung.lambda.apigateway.APIDemoHandler :: handleGetByParam Runtime: java8 Timeout: 15 MemorySize: 512 CodeUri: ../target/aws-lambda-0.1.0-SNAPSHOT.jar Politikker: - DynamoDBReadPolicy: TableName:! Ref. PersonTable-miljø: Variabler: TABLE_NAME:! Ref PersonTable E ventilationskanaler: GetByPathApi: Type: Api Egenskaber: Sti: / persons / {id} Metode: GET GetByQueryApi: Type: Api Egenskaber: Sti: / persons Metode: GET

Som vi kan se, er vores skabelon lidt anderledes nu: Der er ingen AWS :: Serverløs :: Api ressource længere.

Dog tager CloudFormation Begivenheder attributter af typen Api som en implicit definition og opretter alligevel en API. Så snart vi tester vores applikation, ser vi, at den opfører sig det samme som ved definition af API eksplicit ved hjælp af Swagger.

Derudover er der en Globale sektion, hvor vi kan definere navnet på vores API, såvel som at vores slutpunkt skal være regionalt.

Der opstår kun en begrænsning: når vi implicit definerer API'en, er vi ikke i stand til at indstille et scenenavn. Dette er grunden til, at AWS opretter en scene kaldet Prod under alle omstændigheder.

5. Implementering og test

Efter oprettelse af skabelonen kan vi nu fortsætte med implementering og test.

Til dette uploader vi vores funktionskode til S3, før vi udløser den faktiske implementering.

I sidste ende kan vi teste vores applikation ved hjælp af enhver HTTP-klient.

5.1. Kode upload til S3

I et første trin skal vi uploade funktionskoden til S3.

Vi kan gøre det ved at ringe til CloudFormation via AWS CLI:

$> aws cloudformation-pakke --template-fil ./sam-templates/template.yml --s3-bucket baeldung-sam-bucket --output-template-fil ./sam-templates/packaged-template.yml

Med denne kommando udløser vi CloudFormation for at tage den funktionskode, der er angivet i CodeUri: og at uploade det til S3. CloudFormation opretter en pakket-skabelon.yml fil, som har det samme indhold, bortset fra at CodeUri: peger nu på S3-objektet.

Lad os se på CLI-output:

Uploader til 4b445c195c24d05d8a9eee4cd07f34d0 92702076 / 92702076.0 (100,00%) Pakkede artefakter er vellykket og skrev outputskabelon til fil pakket-template.yml. Udfør følgende kommando for at distribuere den pakkede skabelon aws cloudformation deploy --template-file c: \ zz_workspace \ tutorials \ aws-lambda \ sam-templates \ packaged-template.yml - stack-name 

5.2. Implementering

Nu kan vi udløse den faktiske implementering:

$> aws cloudformation deploy --template-file ./sam-templates/packaged-template.yml - stack-name baeldung-sam-stack --capabilities CAPABILITY_IAM

Da vores stak også har brug for IAM-roller (som funktionernes roller for at få adgang til vores DynamoDB-tabel), skal vi udtrykkeligt anerkende det ved at specificere –Capabilities-parameter.

Og CLI-output skal se ud:

Venter på, at ændringssæt oprettes .. Venter på, at stak oprettes / opdateres til fuldføres Vellykket oprettet / opdateret stak - baeldung-sam-stack

5.3. Gennemgang af implementering

Efter implementeringen kan vi gennemgå resultatet:

$> aws cloudformation beskriver-stack-ressourcer - stack-navn baeldung-sam-stack

CloudFormation viser alle ressourcer, der er en del af vores stack.

5.4. Prøve

Endelig kan vi teste vores applikation ved hjælp af enhver HTTP-klient.

Lad os se nogle eksempler krøller kommandoer, vi kan bruge til disse tests.

StorePersonFunction:

$> curl -X PUT '//0skaqfgdw4.execute-api.eu-central-1.amazonaws.com/test/persons' \ -H 'content-type: application / json' \ -d '{"id": 1, "name": "John Doe"} '

GetPersonByPathParamFunction:

$> curl -X GET '//0skaqfgdw4.execute-api.eu-central-1.amazonaws.com/test/persons/1' \ -H 'content-type: application / json'

GetPersonByQueryParamFunction:

$> curl -X GET '//0skaqfgdw4.execute-api.eu-central-1.amazonaws.com/test/persons?id=1' \ -H 'content-type: application / json'

5.5. Ryd op

I sidste ende kan vi rydde op ved at fjerne stakken og alle inkluderede ressourcer:

aws cloudformation delete-stack - stack-name baeldung-sam-stack

6. Konklusion

I denne artikel har vi kigget på AWS Serverless Application Model (SAM), som muliggør en skabelonbaseret beskrivelse og automatisk implementering af serverløse applikationer på AWS.

I detaljer diskuterede vi følgende emner:

• Grundlæggende om den serverløse applikationsmodel (SAM) samt den underliggende CloudFormation
• Definition af en serverløs applikation ved hjælp af SAM-skabelonsyntaks
• Automatisk implementering af applikationen ved hjælp af CloudFormation CLI

Som sædvanlig er al koden til denne artikel tilgængelig på GitHub.