Bevezetés az AWS kiszolgáló nélküli alkalmazásmodellbe

1. Áttekintés

Korábbi cikkünkben már megvalósítottunk egy teljes veremű kiszolgáló nélküli alkalmazást az AWS-en, API-átjárót használva a REST végpontokhoz, az AWS Lambda-t az üzleti logikához, valamint egy DynamoDB-t adatbázisként.

A telepítés azonban sok manuális lépésből áll, amelyek a növekvő bonyolultság és a környezetek számának függvényében elbizonytalanodhatnak.

Ebben az oktatóanyagban most megvitatjuk a AWS Serverless Application Model (SAM), amely sablon alapú leírást és kiszolgáló nélküli alkalmazások automatikus telepítését teszi lehetővé AWS-en.

Részletesen a következő témákat vesszük szemügyre:

  • A kiszolgáló nélküli alkalmazásmodell (SAM), valamint az alapul szolgáló CloudFormation alapjai
  • Kiszolgáló nélküli alkalmazás meghatározása a SAM sablon szintaxisa segítségével
  • Az alkalmazás automatikus telepítése a CloudFormation parancssori felület használatával

2. Alapismeretek

Amint azt korábban említettük, az AWS lehetővé teszi számunkra, hogy teljesen kiszolgáló nélküli alkalmazásokat valósítsunk meg az API Gateway, a Lambda függvények és a DynamoDB segítségével. Kétségtelen, hogy ez már számos előnyt kínál a teljesítmény, a költség és a méretezhetőség szempontjából.

Hátránya azonban, hogy sok kézi lépésre van szükségünk az AWS konzolban, például az egyes funkciók létrehozására, a kód feltöltésére, a DynamoDB tábla létrehozására, az IAM szerepkörök létrehozására, az API és az API struktúra létrehozására stb.

Bonyolult alkalmazásokhoz és több környezettel, például teszteléssel, előkészítéssel és gyártással ez az erőfeszítés gyorsan megsokszorozódik.

Itt jön szóba a CloudFormation az AWS-en általában, és a kifejezetten a kiszolgáló nélküli alkalmazásokhoz tartozó Serverless Application Model (SAM).

2.1. AWS CloudFormation

A CloudFormation egy AWS szolgáltatás az AWS infrastrukturális erőforrások automatikus kiépítéséhez. A felhasználó az összes szükséges erőforrást tervrajzként definiálja (sablonnak nevezi), az AWS pedig gondoskodik a kiépítésről és a konfigurációról.

A következő kifejezések és fogalmak elengedhetetlenek a CloudFormation és a SAM megértéséhez:

A sablon az alkalmazás leírása, hogyan kell felépíteni futás közben. Meghatározhatjuk a szükséges erőforrások halmazát, valamint az erőforrások konfigurálásának módját. A CloudFormation közös nyelvet biztosít a sablonok meghatározásához, támogatva a JSON és a YAML formátumát.

Az erőforrások a CloudFormation építőkövei. Erőforrás lehet bármi, például RestApi, RestApi szakasza, Batch Job, DynamoDB tábla, EC2 példány, hálózati interfész, IAM szerep és még sok más. A hivatalos dokumentáció jelenleg mintegy 300 erőforrástípust sorol fel a CloudFormationhoz.

A verem a sablon példányosítása. A CloudFormation gondoskodik a verem kiépítéséről és konfigurálásáról.

2.2. Szerver nélküli alkalmazásmodell (SAM)

Mint gyakran, a nagy teljesítményű eszközök használata nagyon összetetté és kezelhetetlenné válhat, ami a CloudFormation esetében is érvényes.

Ezért az Amazon bevezette a Serverless Application Model (SAM) szolgáltatást. A SAM azzal a követeléssel kezdte, hogy tiszta és egyértelmű szintaxist biztosítson a szerver nélküli alkalmazások meghatározásához. Jelenleg csak három erőforrástípusa van, ezek a Lambda függvények, a DynamoDB táblák és az API-k.

A SAM a CloudFormation sablon szintaxisán alapul, így az egyszerű SAM szintaxissal definiálhatjuk sablonunkat, és a CloudFormation tovább dolgozza fel ezt a sablont.

További részletek a hivatalos GitHub adattárban, valamint az AWS dokumentációban érhetők el.

3. Előfeltételek

A következő oktatóanyaghoz AWS-fiókra lesz szükségünk. Elegendő egy ingyenes szintű számla.

Emellett telepítenünk kell az AWS CLI-t.

Végül szükségünk van egy S3 vödörre a régiónkban, amelyet az AWS CLI segítségével lehet létrehozni a következő paranccsal:

$> aws s3 mb s3: // baeldung-sam-vödör

Míg az oktatóanyag használja baeldung-sam-vödör a következőkben vegye figyelembe, hogy a csoportneveknek egyedinek kell lenniük, ezért ki kell választania a nevét.

Bemutató alkalmazásként az AWS Lambda használata az API átjáróval kódot használjuk.

4. A sablon létrehozása

Ebben a szakaszban létrehozzuk a SAM sablonunkat.

Először megnézzük a teljes struktúrát, mielőtt meghatároznánk az egyes erőforrásokat.

4.1. A sablon felépítése

Először nézzük meg a sablonunk általános felépítését:

AWSTemplateFormatVersion: '2010-09-09' Átalakítás: 'AWS :: Serverless-2016-10-31' Leírás: Baeldung Serverless Application Model example Resources: PersonTable: Type: AWS :: Serverless :: SimpleTable Properties: # Itt adhatja meg a táblázat tulajdonságait StorePersonFunction: Típus: AWS :: Szerver nélküli :: Funkció tulajdonságai: # Itt adhatja meg a függvény tulajdonságait Itt adhatja meg az API tulajdonságokat

Mint láthatjuk, a sablon egy fejlécből és egy törzsből áll:

A fejléc meghatározza a CloudFormation sablon verzióját (AWSTemplateFormatVersion), valamint a SAM sablonunk verziója (Átalakítás). Megadhatjuk a Leírás.

A törzs erőforrások halmazából áll: minden erőforrásnak van neve, erőforrása típus, és egy sor Tulajdonságok.

A SAM specifikáció jelenleg három típust támogat: AWS :: Szerver nélküli :: Api, AWS :: Szerver nélküli :: Funkció továbbá AWS :: Szerver nélküli :: SimpleTable.

Amint a példaprogramunkat telepíteni akarjuk, meg kell határoznunk egyet SimpleTable, kettő Funkciók, valamint egy Api sablon-testünkben.

4.2. DynamoDB táblázat meghatározása

Határozzuk meg most a DynamoDB táblázatunkat:

AWSTemplateFormatVersion: '2010-09-09' Átalakítás: 'AWS :: Serverless-2016-10-31' Leírás: Baeldung Serverless Application Model example Resources: PersonTable: Type: AWS :: Serverless :: SimpleTable Properties: PrimaryKey: Name: id Típus: SzámtáblaNév: Személy

Csak két tulajdonságot kell meghatároznunk a sajátunk számára SimpleTable: a tábla neve, valamint egy elsődleges kulcs, amelyet meghívunk id és megvan a típusa Szám a mi esetünkben.

A támogatottak teljes listája SimpleTable tulajdonságok megtalálhatók a hivatalos specifikációban.

Megjegyzés: Mivel a táblához csak az elsődleges kulccsal szeretnénk hozzáférni, a AWS :: Szerver nélküli :: SimpleTable elegendő számunkra. Bonyolultabb követelmények esetén a natív CloudFormation típus AWS :: DynamoDB :: Táblázat használható helyette.

4.3. A lambda funkciók meghatározása

Ezután határozzuk meg a két funkciónkat:

AWSTemplateFormatVersion: '2010-09-09' Átalakítás: 'AWS :: Serverless-2016-10-31' Leírás: Baeldung Serverless alkalmazásmodell példa erőforrások: StorePersonFunction: Type: AWS :: Serverless :: Funkció tulajdonságai: Handler: com.baeldung .lambda.apigateway.APIDemoHandler :: handleRequest Futásideje: java8 Időtúllépés: 15 MemorySize: 512 CodeUri: ../target/aws-lambda-0.1.0-SNAPSHOT.jar Házirendek: DynamoDBCrudPolicy Környezet: Változók: TABLE_NAME:! Ref PersonTable Events StoreApi: Típus: Api Tulajdonságok: Elérési út: / személyek Módszer: PUT RestApiId: Hivatkozás: MyApi GetPersonByHTTPParamFunction: Típus: AWS :: Szerver nélküli :: Funkció tulajdonságai: Handler: com.baeldung.lambda.apigateway.APIDemoHandler :: handleGetByParam Runtime: : 15 MemorySize: 512 CodeUri: ../target/aws-lambda-0.1.0-SNAPSHOT.jar Házirendek: DynamoDBReadPolicy Környezet: Változók: TABLE_NAME:! Ref PersonTable Events: GetByPathApi: Type: Api Properties: Path: / persons / { id} Módszer: GET RestApiId: Ref: MyApi GetByQueryApi: Típus: Api Propertie s: Útvonal: / személyek Módszer: GET RestApiId: Ref: MyApi

Mint láthatjuk, minden függvénynek ugyanazok a tulajdonságai vannak:

Handler meghatározza a függvény logikáját. Mivel Java-t használunk, ez az osztály neve, beleértve a csomagot is, a metódus nevével kapcsolatban.

Futásidő meghatározza a függvény megvalósításának módját, ami esetünkben Java 8.

Időtúllépés meghatározza, hogy a kód végrehajtása mennyi ideig tarthat mielőtt az AWS befejezi a végrehajtást.

Memória méretmeghatározza a hozzárendelt memória méretét MB-ban. Fontos tudni, hogy az AWS a CPU erőforrásait arányosan rendeli hozzá Memória méret. Tehát CPU-intenzív funkció esetén szükség lehet növelésre Memória méret, még akkor is, ha a funkcióhoz nincs szükség annyi memóriára.

CodeUrimeghatározza a funkciókód helyét. Jelenleg a helyi munkaterületünk célmappájára hivatkozik. Amikor később feltöltjük függvényünket a CloudFormation használatával, kapunk egy frissített fájlt, hivatkozással egy S3 objektumra.

Házirendektartalmazhat egy AWS által kezelt IAM-házirendet vagy SAM-specifikus házirend-sablont. Használjuk a SAM-specifikus házirendeket DynamoDBCrudPolicy a StorePersonFunction és DynamoDBReadPolicy mert GetPersonByPathParamFunction és GetPersonByQueryParamFunction.

Környezetfutás közben meghatározza a környezeti tulajdonságokat. Környezeti változót használunk a DynamoDB tábla nevének megtartására.

Eseményektartalmazhat AWS eseményeket, amelyek képesek lesznek a funkció elindítására. Esetünkben definiálunk egy Esemény típusú Api. Az egyedülálló kombinációja pálya, egy HTTP Módszer, és a RestApiId összekapcsolja a függvényt az API egyik módszerével, amelyet a következő szakaszban definiálunk.

A támogatottak teljes listája Funkció tulajdonságok megtalálhatók a hivatalos specifikációban.

4.4. Az API meghatározása Swagger fájlként

A DynamoDB tábla és függvények meghatározása után meghatározhatjuk az API-t.

Az első lehetőség az API inline definiálása a Swagger formátum használatával:

AWSTemplateFormatVersion: '2010-09-09' Átalakítás: 'AWS :: Serverless-2016-10-31' Leírás: Baeldung Serverless alkalmazásmodell-példa erőforrások: MyApi: Type: AWS :: Serverless :: Api Tulajdonságok: StageName: test EndpointConfiguration: REGIONAL DefinitionBody: swagger: "2.0" info: title: "TestAPI" paths: / persons: get: parameters: - name: "id" in: "query" required: true type: "string" x-amazon-apigateway-request -validator: "A lekérdezési karakterlánc paramétereinek és a \ \ fejlécek érvényesítése" x-amazon-apigateway-integráció: uri: Fn :: Sub: arn: aws: apigateway: $ {AWS :: Region}: lambda: path / 2015-03- 31 / functions / $ {GetPersonByHTTPParamFunction.Arn} / invocations válaszok: {} httpMethod: "POST" típus: "aws_proxy" put: x-amazon-apigateway-integráció: uri: Fn :: Sub: arn: aws: apigateway: $ {AWS :: Region}: lambda: path / 2015-03-31 / functions / $ {StorePersonFunction.Arn} / invocations responses: {} httpMethod: "POST" típus: "aws_proxy" / persons / {id}: get: paraméterek: - név: "id" itt: "elérési út" szükséges: true type: "string" válaszok: {} xa mazon-apigateway-integráció: uri: Fn :: Sub: arn: aws: apigateway: $ {AWS :: Region}: lambda: path / 2015-03-31 / functions / $ {GetPersonByHTTPParamFunction.Arn} / invocations válaszok: { } httpMethod: "POST" típus: "aws_proxy" x-amazon-apigateway-request-validators: Ellenőrizze a lekérdezési karakterlánc paramétereit és fejléceit: validateRequestParameters: true validateRequestBody: hamis

A mi Api három tulajdonsággal rendelkezik: Művésznévmeghatározza az API szakaszát, EndpointConfigurationmeghatározza, hogy az API regionális vagy éloptimalizált-e, és DefinitionBody tartalmazza az API tényleges felépítését.

Ban,-ben DefinitionBody, három paramétert határozunk meg: a henceg verzió as “2.0”, a info: cím: mint „TestAPI”, valamint egy sor utak.

Mint láthatjuk, a utak képviselik az API struktúrát, amelyet korábban kézzel kellett definiálnunk. A utak Swagger-ben az AWS Console erőforrásaival egyenértékűek. Csak így, mindegyik pálya egy vagy több HTTP-ig lehet, amelyek egyenértékűek az AWS-konzolban szereplő módszerekkel.

Mindegyik módszernek lehet egy vagy több paramétere, valamint kérés-hitelesítő is.

A legizgalmasabb rész az attribútum x-amazon-apigateway-integráció, amely a Swagger AWS-specifikus kiterjesztése:

uri meghatározza, hogy melyik Lambda függvényt kell meghívni.

válaszokat adja meg a függvény által adott válaszok átalakításának szabályait. Mivel a Lambda Proxy Integrációt használjuk, nincs szükségünk külön szabályra.

típus meghatározza, hogy használni akarjuk a Lambda Proxy Integrációt, és ezáltal be kell állítanunk httpMethod nak nek „POST”, mivel erre számítanak a Lambda funkciói.

A támogatottak teljes listája Api tulajdonságok megtalálhatók a hivatalos specifikációban.

4.5. Implicit API definíció

A második lehetőség az API implicit meghatározása a Funkció erőforrásokon belül:

AWSTemplateFormatVersion: '2010-09-09' Átalakítás: 'AWS :: Serverless-2016-10-31' Leírás: Baeldung Serverless alkalmazásmodell-példa implicit API-definíciós globálisokkal: Api: EndpointConfiguration: REGIONAL Name: "TestAPI" Resources: StorePersonFunction: Típus: AWS :: Szerver nélküli :: Funkció tulajdonságai: Kezelő: com.baeldung.lambda.apigateway.APIDemoHandler :: handleRequest Futásidejű: java8 Időtúllépés: 15 MemorySize: 512 CodeUri: ../target/aws-lambda-0.1.0-SNAPSHOT .jar házirendek: - DynamoDBCrudPolicy: TableName:! Ref PersonTable Környezet: Változók: TABLE_NAME:! Ref PersonTable Events: StoreApi: Type: Api Properties: Path: / persons Metód: PUT GetPersonByHTTPParamFunction: Type: AWS :: Serverless :: Function Properties: Handler: com.baeldung.lambda.apigateway.APIDemoHandler :: handleGetByParam Futásidejű: java8 Időtúllépés: 15 MemorySize: 512 CodeUri: ../target/aws-lambda-0.1.0-SNAPSHOT.jar Házirendek: - DynamoDBReadPolicy: TableName:! PersonTable Környezet: Változók: TABLE_NAME:! Ref PersonTable E szellőzőnyílások: GetByPathApi: Típus: Api tulajdonságok: Útvonal: / persons / {id} Módszer: GET GetByQueryApi: Típus: Api Tulajdonságok: Útvonal: / fő Módszer: GET

Mint láthatjuk, a sablonunk most kissé eltér: Nincs AWS :: Szerver nélküli :: Api erőforrás.

A CloudFormation azonban a Események típusú attribútumok Api implicit definícióként, és egyébként is létrehoz egy API-t. Amint teszteljük az alkalmazásunkat, látni fogjuk, hogy ugyanúgy viselkedik, mint amikor az API-t kifejezetten a Swagger segítségével definiáljuk.

Emellett van egy Globálisok szakasz, ahol meghatározhatjuk API-junk nevét, valamint azt, hogy a végpontunk regionális legyen.

Csak egy korlátozás fordul elő: ha az API-t implicit módon definiáljuk, akkor nem tudjuk beállítani a szakasz nevét. Ezért hozza létre az AWS az úgynevezett színpadot Prod mindenesetre.

5. Telepítés és tesztelés

A sablon létrehozása után most folytathatjuk a telepítést és a tesztelést.

Ehhez feltöltöttük a funkció kódunkat az S3-ba, mielőtt elindítanánk a tényleges telepítést.

Végül bármely HTTP kliens segítségével tesztelhetjük az alkalmazásunkat.

5.1. Kód feltöltés az S3-ba

Első lépésként fel kell töltenünk a funkciókódot az S3-ra.

Ezt megtehetjük a CloudFormation hívásával az AWS CLI-n keresztül:

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

Ezzel a paranccsal elindítjuk a CloudFormation-t, hogy átvegye a funkciókódot CodeUri: és feltölteni az S3-ra. A CloudFormation létrehoz egy packaged-template.yml fájl, amelynek ugyanaz a tartalma, kivéve CodeUri: most az S3 objektumra mutat.

Vessünk egy pillantást a CLI kimenetre:

Feltöltés ide: 4b445c195c24d05d8a9eee4cd07f34d0 92702076 / 92702076.0 (100,00%) Sikeresen csomagolt műtermékeket és kimeneti sablont írt a packaged-template.yml fájlba. Hajtsa végre a következő parancsot a csomagolt aws cloudformation deploy --template-file c telepítéséhez: \ zz_workspace \ tutorials \ aws-lambda \ sam-templates \ packaged-template.yml --stack-name 

5.2. Telepítés

Most kiválthatjuk a tényleges telepítést:

$> aws cloudformation deploy --template-file ./sam-templates/packaged-template.yml --stack-name baeldung-sam-stack - képességek CAPABILITY_IAM

Mivel veremünknek IAM-szerepkörökre is szüksége van (mint például a függvények szerepei a DynamoDB táblánk eléréséhez), kifejezetten tudomásul kell vennünk, hogy –Képesség paraméter.

És a CLI kimenetnek a következőképpen kell kinéznie:

Várakozás a változáskészlet létrehozására .. Várakozás a verem létrehozásának / frissítésének befejezéséhez Sikeresen létrehozott / frissített verem - baeldung-sam-stack

5.3. Telepítés felülvizsgálata

A telepítés után áttekinthetjük az eredményt:

$> aws cloudformation írja le-stack-resources - stack-name baeldung-sam-stack

A CloudFormation felsorolja az összes erőforrást, amely a verem része.

5.4. Teszt

Végül bármely HTTP kliens segítségével tesztelhetjük az alkalmazásunkat.

Lássunk néhány mintát becsavar parancsokat használhatjuk ezekhez a tesztekhez.

StorePersonFunction:

$> curl -X PUT '//0skaqfgdw4.execute-api.eu-central-1.amazonaws.com/test/persons' \ -H 'tartalomtípus: application / json' \ -d '{"id": 1, "név": "John Doe"} '

GetPersonByPathParamFunction:

$> curl -X GET '//0skaqfgdw4.execute-api.eu-central-1.amazonaws.com/test/persons/1' \ -H 'tartalomtípus: alkalmazás / json'

GetPersonByQueryParamFunction:

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

5.5. Tisztítsd meg

Végül megtisztíthatjuk a verem és az összes benne található erőforrás eltávolításával:

aws cloudformation delete-stack - verem-név baeldung-sam-verem

6. Következtetés

Ebben a cikkben megvizsgáltuk az AWS Serverless Application Model (SAM) szolgáltatást, amely sablon alapú leírást és kiszolgáló nélküli alkalmazások automatikus telepítését teszi lehetővé AWS-en.

Részletesen a következő témákat vitattuk meg:

  • A kiszolgáló nélküli alkalmazásmodell (SAM) alapjai, valamint az alapul szolgáló CloudFormation
  • Kiszolgáló nélküli alkalmazás meghatározása a SAM sablon szintaxisa segítségével
  • Az alkalmazás automatikus telepítése a CloudFormation parancssori felület használatával

Szokás szerint a cikk összes kódja elérhető a GitHubon.