A legjobb módszer az egyoldalas alkalmazás (SPA) tárolására a Microsoft Azure-ban

Hagyományos Azure App Service vs. Azure V2 függvények proxyval vs. Azure Storage statikus webhely (előnézet)

Gyakran statikus webhelyeket (például a vállalati weboldalunkat a https://www.media-lesson.com) vagy egyoldalas alkalmazásokat kell telepítenem, és mindig keresem a költségek és a telepítéshez szükséges idő javításának lehetőségeit.

A Microsoft nemrégiben jelentette be az Azure Storage statikus webhely-tárhelyének nyilvános előnézetét, és újabb lehetőséget adott az egyoldalas alkalmazás (SPA) tárolására az Azure-on.

Közvetlenül azelőtt, hogy a Microsoft hozzáadta a proxyk támogatását az Azure Functions Runtime 2.0.11776-alfa-ban május 14-én, biztosítva ezzel egy statikus webhely hostolását az Azure Storage-ban, és a forgalom továbbítását az Azure Function proxy útvonalon keresztül.

Mindkét új lehetőség hozzáadja a (statikus) webhely hagyományos tárolási módját az Azure App Service-ben. Még több lehetőség van webhelyek tárolására az Azure-ban, például Konténerek, Docker, Kubernetes, Virtuális gépek stb. használatával, de továbbra is a hangsúlyt fektettem az egyoldalas alkalmazások egyszerű és költséghatékony telepítésére.

Mivel pedig a hostolási lehetőségeket értékeltük, érdemes összehasonlítani a kézi és automatikus telepítést a Visual Studio Team Services (VSTS) segítségével az említett szolgáltatásokra.

Tehát válaszoljunk ezekre a kérdésekre, hogy eldöntsük, mely szolgáltatást használjuk az egyoldalas alkalmazás tárolásakor:

  1. Mennyi erőfeszítést igényel egy alkalmazás kézi és automatikus telepítése?
  2. Mennyi konfiguráció szükséges?
  3. Hogyan méretezhető?
  4. Hogyan működik?
  5. Mennyibe kerül?

Test App

Tehát kezdje el ezt a kísérletet egy egyszerű, a Angular alapú SPA létrehozásával, amely a Szögletes CLI-t használja tesztalkalmazásként a három különféle szolgáltatás telepítéséhez és teszteléséhez: új testapp - útvonaltervezés. Felhívjuk figyelmét, hogy közvetlenül az útválasztási funkciót hozzáadom az alkalmazáshoz a --routing paraméter használatával. Ezt fontos szempontnak tartom, amikor megvizsgálom a tárhely lehetőségeit, mivel az útválasztás konfigurációs kihívást jelenthet bizonyos környezetben, például az App Service szolgáltatásban, mivel a webszervert úgy kell konfigurálnunk, hogy az ügyfélprogramunk útvonalkezelést tegyen lehetővé a szerveroldal helyett.

A routing teljes teszteléséhez szükségünk van néhány mintára. Ezért a CLI használatával adhatunk hozzá egy otthoni és egy kb. Komponenst alkalmazásunkhoz: ng generálunk otthoni komponenst és ng generálhatunk kb. Ezután két útvonalat kell tartalmaznunk az app-routing.module.ts-ben a két elem közötti navigáláshoz:

Végül néhány navigációs gomb lehetővé teszi a felhasználó számára, hogy navigáljon az app.component.html oldal két összetevője között:

Építsük fel alkalmazásunkat helyben a kézi üzembe helyezés előkészítése céljából, az ng build --prod használatával, amely megadja nekünk ezt a kis építési mellékletek mappát:

Természetesen azt is meg akarjuk szüntetni az automatikus telepítést, mint a folyamatos telepítési folyamat részét. Ezért tegyük át alkalmazásunkat egy VSTS-lerakatra, és állítsuk be a build definíciót a következő 3 feladat segítségével:

npm telepítés

npm épít

Közzéteszi az építkezés tárgyát a távolságtól kb

Azure App Service

Az Azure App Service egy PaaS (Platform as a Service) szolgáltatás, amely a webtartalom az Azure-on történő tárolásának klasszikus módja. Az alkalmazás-szolgáltatás használatával gondoskodnunk kell a szolgáltatás konfigurálásáról és kézzel történő méretezéséről. Ennek teszteléséhez hozzunk létre egy új alkalmazás szolgáltatást az Azure portálon. Az S1 szintet választom erre a tesztre, mivel ez a termelési alkalmazások belépési szintje.

Az útválasztás konfigurálása

Mivel ez a PaaS ajánlat, mivel a fejlesztők gondoskodnak az alapul szolgáló webszerver konfigurációjáról (Windows esetén IIS). Ez azt jelenti, hogy lehetővé tegyük az útválasztást a Szögletes alkalmazásunkban, és el kell látnunk egy web.config fájlt, amely a webkiszolgálónak tartalmaz utasításokat a szögletes alkalmazás irányításának kezeléséről vagy az ASP.Net Core 2.1 alkalmazás belsejében történő üzemeltetésről, a bekapcsolt SpaServices köztes szoftverrel. Itt egy egyszerű webes konfiguráció mintája, amelynek SPA-útvonala van:

Kézi telepítés

A kézi telepítéshez csak az FTP-t használjuk feltölteni dist könyvtárunk és a web.config tartalmát az alkalmazásszolgáltatás wwwroot mappájába. Az FTP-hitelesítő adatok letölthetők az Azure-portálon az alkalmazás-szolgáltatás áttekintő lapján, a „Közzétételi profil beszerzése” linkre kattintva.

Folyamatos telepítés a Visual Studio Team Services használatával

A kiadásdefiníció beállítása a VSTS-ben az alkalmazás alkalmazásba történő telepítéséhez meglehetősen egyenesen előre, mivel csak egy feladatra van szükségünk egy üres kiadásdefinícióra:

Az FTP-szolgáltatás végpontjának konfigurálásához kattintson a „Kezelés” elemre, és adjon hozzá egy új általános végpontot a kézi telepítéshez használt hitelesítő adatokkal.

Az Azure Functions

Ebben a változatban az Azure Storage-t olcsó áruházként fogjuk használni statikus fájljainkhoz és egy Azure Function App-t proxykkel, hogy a SPA-t kiszolgáljuk a felhasználónak. Ez lehetővé teszi számunkra, hogy automatikusan méretezzük (ha a fogyasztási tervet használjuk), kombináljuk a SPA-t más funkciókkal (például API-hívások) egy domain alatt, és kiszolgáló nélküli módon kezeljük alkalmazásunkat.

Tehát létre kell hoznunk egy Funkcióalkalmazást és egy Tárfiókot (amelyeket automatikusan létrehozunk egy Funkcióalkalmazás létrehozásakor). Ezután létre kell hoznunk egy „web” elnevezésű blob-tárolót a tárfiókban, ahol a fájlokat később telepítjük.

Az útválasztási varázslat most úgy történik, ahogy a proxykat úgy konfiguráljuk, hogy továbbítsuk a kérést a függvény alkalmazásunkból a tárfiókba. Ezért 2 proxire van szükségünk:

Az első, amely továbbítja a kéréseket az alap URL-hez, az index.html-re

a második pedig más statikus eszközök, például javascript fájlok vagy stíluslapok iránti kérelmek továbbítására a tárfiókban található helyükre.

Kézi telepítés

A kézi telepítéshez kattintson a „Konténerek” elemre az Azure portálon lévő tárfiókban, és válassza ki az éppen létrehozott „webes” tárolót. Töltsük fel a fájlokat a helyi összeállításból.

Folyamatos telepítés a Visual Studio Team Services használatával

Ennek teszteléséhez létre kell hoznunk egy második kiadási definíciót a VSTS-ben az üres folyamatsablonnal, és hozzá kell adnunk az AzureBlob File Copy feladatot:

Azure Storage

Ez a legújabb lehetőség, amely nemrégiben nyilvános előnézetbe került. Az ötlet az, hogy a tárolót használja a SPA gazdagépe számára, mivel valódi webszerverre nincs szükség csupán statikus fájlok kiszolgálásához, amelyek ezt a variációt a „kiszolgáló nélküli” szóhoz igazítják. Tehát hozzunk létre egy új tárfiókot (általános célú v2), majd kapcsoljuk be a statikus webhely funkciót:

Ez minden konfiguráció, amire szükségünk van. A tároló automatikusan skálázódik, és az útválasztás szintén működik. Az elsődleges végpont a mi SPA-címünk. Szép!

Kézi telepítés

A kézi telepítéshez kattintson a „Konténerek” elemre az Azure portálon lévő tárfiókban, és válassza a „$ web” tárolót (amely automatikusan létrejön, ha engedélyezi a statikus webhelyet). Töltsük fel a fájlokat a helyi összeállításból:

És ez az!

Folyamatos telepítés a Visual Studio Team Services használatával

Ennek teszteléséhez létre kell hoznunk egy harmadik kiadási meghatározást a VSTS-ben az üres folyamatsablonnal, és hozzá kell adnunk az AzureBlob fájlmásolás feladatát:

Ügyeljen arra, hogy a 2. verziót válassza (előnézet), különben a telepítési hiba sikertelen, mert a tároló nevében a „$” karakter korábban nem volt megengedett.

Teljesítmény

Ha szeretne képet kapni a teljesítményről, futtasson néhány artillery.io terhelési tesztet a 3 telepítésünkön. Itt vannak az eredményeim 1000, 10 000 és 100 000 kérés tüzelésével:

Az Azure Storage használata és a webkiszolgáló-összetevő elkerülése drasztikus teljesítmény-előnyt jelent, míg a Funkciók és az App Service összehasonlítható sebességgel futnak. Ennek van értelme, mivel mindkettő ugyanazt az alapul szolgáló infrastruktúrát használja. Kicsit meglepett, hogy a Function alkalmazás még lassabban fut, mint az App Service.

Ez még furcsábbnak találom, ha összehasonlítjuk a teljes futási időt a 100 000 kérelem teszt kitöltéséhez. Ez körülbelül 46 másodpercet vett igénybe az Azure Storage használatához, és 14 perc és 27 másodpercig tartott az App Service számára, és még 17 perc és 2 másodpercig tartott a Function alkalmazás számára. Arra számítottam, hogy a Function alkalmazás idővel felgyorsul, mivel arra számítottam, hogy az automatikusan vízszintesen skálázódik. Ami nem látszik működni ebben a forgatókönyvben.

Tehát egyértelmű nyertesünk van ebben a tudományágban: A tárolás nagyon gyors!

kiadások

A költségek megfelelő megszerzése bonyolult, mivel mindegyikük eltérő számlázási modellekkel rendelkezik. Íme a számviteli példa a nyugat-európai régióban a napi 100 000 kérelem havi költségeire (ami nem vagyok 100% -ban biztos, hogy teljes és pontos!):

App Service

1x S1 példány Nyugat-Európában, Windows futtatva (1 mag, 1,75 GB RAM, 50 GB tárhely) = 61,56 € / hónap

Funkcióalkalmazás (+ tárhely)

Gyógyfürdőnk 5 fájlból áll * 100 000 kérelem / nap * 31 = havonta összesen 15 500 000 kérelem. Alkalmazásunk teljes mérete megközelítőleg 0,33 MB, ami havi összesen 0,98 TB kimenő forgalmat tesz ki. A minimális végrehajtási idő 100 ms (ez elég lenne a proxy célunkhoz), mert 10 kérést / végrehajtási másodperc képes kezelni.

1x Function App 1.550.000 végrehajtással, havonta 1 s végrehajtási idővel (mindegyik kevesebb, mint 128 MB memória) a proxykon átmenő kérelmek kezeléséhez = 0,17 € / hó

1x általános célú V2 blokkblob-tárolófiók LRS redundáns és forró hozzáférési szinttel. 1 GB kapacitás (valójában csak kb. 300 kb-re van szükség, de ez a legkisebb elérhető méret), 100 írási művelet, 100 listázási művelet, 15 500 000 olvasási művelet és 0,98 TB adat visszakeresés = 5,64 € / hó

Összesen: 5,81 € / hó.

Tárolás

A tároláshoz ugyanazt a számítást vesszük, mint a fentiek:

1x általános célú V2 blokkblob-tárolófiók LRS redundáns és forró hozzáférési szinttel. 1 GB kapacitás (valójában csak kb. 300 kb-re van szükség, de ez a legkisebb elérhető méret), 100 írási művelet, 100 listázási művelet, 15 500 000 olvasási művelet és 0,98 TB adat visszakeresés = 5,64 € / hó

Következtetés

  • A SPA tárolása a tiszta tárolóban messze a legolcsóbb és leghatékonyabb módja az Azure-ban való futtatásnak
  • A SPA tárolása a Proxykkel ellátott Function App alkalmazásban minimális többletköltséggel jár, de hatalmas teljesítménycsökkenés. Ez a furcsa, amit vízszintesen kell méreteznem. Minden bizonnyal további kutatást fogok végezni itt ...
  • A SPA tárolása az App Service szolgáltatásban további konfigurációs erőfeszítéseket igényel az útválasztás támogatásához (bonyolultabbá válik, ha például Web API-kkal kombinálják)

A tárolóban lévő SPA tárolásának nem kell lelkiismeretesnek lennie a fejlesztési, tesztelési és átmeneti helyzetekben, mivel gyorsan beállíthatók, és a legtöbb esetben még ingyen ezekre a forgatókönyvekre. Még nem találtam hátrányokat, ezért belemerülök egy kicsit mélyebben, és megnézem, vajon felhasználhatjuk-e a gyártásban.

Nyugodtan küldjön visszajelzést.