Bedste måde at være vært for en Single Page Application (SPA) i Microsoft Azure

Traditionel Azure App Service vs. Azure-funktioner V2 med proxys vs. Azure Storage Static Website (Preview)

Jeg har ofte brug for at installere statiske websteder (f.eks. Vores virksomhedswebsted https://www.media-lesson.com) eller applikationer på en enkelt side, og jeg leder altid efter måder at forbedre omkostninger og tid til implementering.

Microsoft har netop for nylig annonceret en offentlig forhåndsvisning af statisk webstedshosting til Azure Storage og tilføjet endnu en mulighed for at være vært for en enkelt sides applikation (SPA) på Azure.

Lige før Microsoft tilføjede back support til Proxies i Azure-funktionaliteten Runtime 2.0.11776-alpha den 14. maj, hvilket giver en måde at være vært for et statisk websted i Azure Storage og videresende trafik gennem en Azure Function-proxy-rute.

Begge nye indstillinger føjer til den traditionelle måde at være vært for (statisk) websted i en Azure App Service. Der er endnu flere muligheder for at være vært for websteder i Azure f.eks. ved hjælp af containere, Docker, Kubernetes, virtuelle maskiner osv., men jeg vil holde fokus på nemme og omkostningseffektive implementeringer af applikationer på en side.

Og da vi vurderer hostingindstillinger, er det også værd at sammenligne manuel og automatisk implementering ved hjælp af Visual Studio Team Services (VSTS) for de nævnte tjenester.

Så lad os svare på disse spørgsmål for at hjælpe med at beslutte, hvilken service der skal bruges, når du er vært for en enkelt sideprogram:

  1. Hvor meget kræver det at manuelt og automatisk implementere en app?
  2. Hvor meget konfiguration er der behov for?
  3. Hvordan skaleres det?
  4. Hvordan fungerer det?
  5. Hvor meget koster det?

Test-app

Så lad os starte dette eksperiment ved at oprette en simpel SPA baseret på Angular ved hjælp af Angular CLI som en testapp til implementering og test på de 3 forskellige tjenester: ng ny testapp --routering Bemærk, at jeg direkte tilføjer routingfunktionen til app ved hjælp af parameteren --routing. Jeg finder dette et vigtigt aspekt at teste, når man ser på hostingindstillinger, da routing kan være en konfigurationsudfordring i nogle miljøer som App Service, fordi vi er nødt til at konfigurere webserveren til at tillade rutehåndtering af vores klient-app i stedet for serversiden.

For fuldt ud at teste routing er vi også nødt til at have nogle prøveruter. Lad os derfor føje et hjem og en om-komponent til vores app ved hjælp af CLI: ng generere komponent hjem og ng generere komponent ca. Dernæst skal vi have to ruter i vores app-routing.module.ts for at tillade navigation mellem de to komponenter:

Endelig nogle navigationsknapper, der giver brugeren mulighed for at navigere mellem de to komponenter i vores app.component.html:

Lad os bygge vores app lokalt som forberedelse til manuel implementering ved hjælp af ng build - produkt, der giver os denne lille mappe med build-artefakter:

Selvfølgelig ønsker vi også at tørre automatisk distribution som en del af en kontinuerlig implementeringsproces. Lad os derfor skubbe vores app til et VSTS-lager og opsætte en build-definition med disse 3 opgaver:

npm installation

npm bygning

Publicer build-artefakt fra sti dist til app

Azure App Service

Azure App Service er et PaaS-tilbud (Platform as a Service) og den klassiske måde at være vært for webindhold på Azure. Ved hjælp af apptjeneste skal vi sørge for konfiguration og skalering af vores service manuelt. For at teste dette, lad os oprette en ny apptjeneste i Azure Portal. Jeg vælger S1-niveauet til denne test, da det er indgangsniveauet for produktionsapps.

Konfigurer routing

På grund af dets natur at være et PaaS-tilbud, skal udviklere tage sig af konfigurationen af ​​den underliggende webserver (i tilfælde af Windows er det IIS). Dette betyder at muliggøre routing i vores Angular-app, vi er nødt til at give en web.config-fil med instruktioner til webserveren, hvordan man håndterer routing eller vært for den kantede app inden i en ASP.Net Core 2.1-app med SpaServices mellemvaren aktiveret. Her en simpel prøve af en web.config med SPA-routing:

Manuel installation

Til manuel implementering lad os bare bruge FTP til at uploade indholdet af vores dist-mappe og web.config til mappen wwwroot i apptjenesten. FTP-legitimationsoplysningerne kan downloades i Azure-portalen i app-tjenestens oversigt-fane ved at klikke på “Hent offentliggør profil”.

Kontinuerlig implementering ved hjælp af Visual Studio Team Services

At indstille en frigørelsesdefinition i VSTS til at implementere app til apptjeneste er temmelig ligetil, da vi bare har brug for en tom release-definition med en opgave:

For at konfigurere et FTP-serviceendepunkt lad os klikke på "Administrer" og tilføje et nyt generisk slutpunkt med de samme legitimationsoplysninger, der bruges til manuel implementering.

Azurefunktioner

I denne variant vil vi bruge Azure Storage som en billig butik til vores statiske filer og en Azure Function-app med proxier til at betjene SPA til brugeren. Dette giver os mulighed for at skalere automatisk (når vi bruger forbrugsplanen), kombinere vores SPA med andre funktioner (f.eks. API-opkald) under et domæne og administrere vores app på en serverløs måde.

Så vi er nødt til at oprette en funktionsapp og en lagringskonto (automatisk oprettet, når du opretter en funktionsapp). Derefter skal vi oprette en klatebeholder med navnet "web" på lagringskontoen, hvor vi vil distribuere vores filer til senere.

Routingmagien sker nu på den måde, vi konfigurerer proxies til at videresende anmodning fra vores funktionsapp til lagringskontoen. Derfor har vi brug for 2 proxy:

Den første, der videresender anmodninger til basis-url'en til vores indeks.html

og en anden til at videresende anmodninger om andre statiske aktiver som javascript-filer eller stilark til deres placering på lagringskontoen.

Manuel installation

For manuelt at installere skal du klikke på “Containere” på lagringskontoen i Azure-portalen og vælge “web” -containeren, vi lige har oprettet. Lad os nu uploade filerne fra den lokale build.

Kontinuerlig implementering ved hjælp af Visual Studio Team Services

For at teste dette er vi nødt til at oprette en anden udgivelsesdefinition i VSTS med den tomme processkabelon og tilføje opgaven AzureBlob File Copy:

Azuropbevaring

Dette er den nyeste mulighed, der netop for nylig gik i offentlig forhåndsvisning. Ideen er at bruge lagerplads til at være vært for SPA, fordi en reel webserver ikke er nødvendig for at tjene bare statiske filer, der kvalificerer denne variant til buzzword “serverless”. Så lad os oprette en ny lagringskonto (generelt formål v2) og aktiver derefter den statiske webstedsfunktion:

Dette er al den konfiguration, vi har brug for. Opbevaring skaleres automatisk og routing fungerer også ud af kassen. Det primære slutpunkt er vores SPA's url. Pæn!

Manuel installation

For manuelt at installere skal du klikke på “Containere” i lagringskontoen i Azure-portalen og vælge beholderen “$ web” (som oprettes automatisk, når statisk webside aktiveres). Lad os nu uploade filerne fra den lokale build:

Og det er det!

Kontinuerlig implementering ved hjælp af Visual Studio Team Services

For at teste dette er vi nødt til at oprette en tredje udgivelsesdefinition i VSTS med den tomme processkabelon og tilføje opgaven AzureBlob File Copy:

Sørg for at vælge version 2. * (forhåndsvisning), ellers mislykkes installationsvælgen, fordi "$" -tegnet i beholdernavnet ikke tidligere var tilladt.

Ydeevne

For at få en idé om ydeevnen skal vi køre nogle artillery.io belastningstest på vores 3 implementeringer. Her er mine resultater, når jeg fyrer 1000, 10.000 og 100.000 anmodninger:

Der er en drastisk ydelsesfordel ved at bruge Azure Storage og at undgå webserverkomponenten, mens funktioner og appservice kører med en sammenlignelig hastighed. Dette giver mening, da begge deler den samme underliggende infrastruktur. Jeg er lidt overrasket over, at appen Funktion kører endnu langsommere end App-tjenesten.

Jeg finder dette endnu fremmed, når jeg sammenligner den samlede driftstid for at gennemføre testen på 100.000 anmodninger. Dette tog omkring 46 sekunder at afslutte til Azure Storage og 14 minutter og 27 sekunder for App Service og endda 17 minutter og 2 sekunder for funktionen app. Jeg ville have forventet, at Funktion-appen ville vinde hastighed over tid, da jeg forventede, at den skalerer horisontalt automatisk. Hvilket ikke ser ud til at fungere i dette scenarie.

Så vi har en klar vinder inden for denne disciplin: Opbevaring er virkelig hurtig!

Omkostninger

At få omkostningerne rigtigt er vanskeligt, da alle har forskellige faktureringsmodeller. Her er min eksempelberegning for månedlige omkostninger for 100.000 anmodninger / dag i Vesteuropa-regionen (som jeg ikke er 100% sikker på, at den er komplet og nøjagtig!):

App Service

1x S1-forekomst i Vesteuropa med Windows (1 kerne, 1,75 GB RAM, 50 GB opbevaring) = 61,56 € / måned

Funktionsapp (+ opbevaring)

Vores SPA består af 5 filer * 100.000 anmodninger / dag * 31 = 15.500.000 anmodninger pr. Måned i alt. Den samlede størrelse af vores app er cirka 0,33 MB, hvilket tegner sig for 0,98 TB udgående trafik pr. Måned i alt. Den mindste udførelsestid er 100 ms (hvilket ville være nok til vores proxy-formål), for vi kan håndtere 10 anmodninger / eksekvering sekund.

1x Funktionsapp med 1.550.000 henrettelser med en eksekveringstid på 1s hver pr. Måned (hver mindre end 128 MB hukommelse) til håndtering af anmodninger, der går gennem proxies = 0,17 € / måned

1x Storage Almindelig V2 Block Blob Storage-konto med LRS-redundans og hot access-niveau. Kapacitet 1 GB (vi har faktisk brug for bare 300kb, men det er den mindste tilgængelige størrelse), 100 skriveoperationer, 100 listefunktioner, 15.500.000 læseoperationer og 0,98 TB dataindhentning = 5,64 € / måned

I alt: 5,81 € / måned.

Opbevaring

For opbevaring tager vi bare den samme beregning end ovenfor:

1x Storage Almindelig V2 Block Blob Storage-konto med LRS-redundans og hot access-niveau. Kapacitet 1 GB (vi har faktisk brug for bare 300kb, men det er den mindste tilgængelige størrelse), 100 skriveoperationer, 100 listefunktioner, 15.500.000 læseoperationer og 0,98 TB dataindhentning = 5,64 € / måned

Konklusion

  • At være vært for et SPA i ren opbevaring er langt den billigste og mest performante måde at køre i Azure på
  • Hosting af en SPA i en funktionsapp med fuldmagt kommer til en minimal ekstraomkostning, men et massivt ydeevne. Denne slags mærkelig, som jeg skal skalere vandret. Jeg vil bestemt undersøge mere her ...
  • Hosting af en SPA i en apptjeneste kræver ekstra konfigurationsindsats for at understøtte routing (bliver mere kompliceret, når det kombineres med f.eks. Web API'er)

At være vært for en SPA i opbevaring bør være en no-brainer til dev, test og iscenesættelsessituationer, da det er hurtigt at opsætte og i de fleste tilfælde endda gratis for disse scenarier. Jeg fandt endnu ingen ulemper, så vil dykke lidt dybere og se, om vi også kan bruge det i produktionen.

Du er velkommen til at give feedback.