Blazor na Azureu: gdje ga hostati i postavke koje vam štede loš ponedjeljak

Postaviti Blazor aplikaciju na Azure pitanje je jednog popodneva. Da bi se u produkciji ponašala kako treba, treba znati malo više: koja usluga odgovara kojoj vrsti Blazor aplikacije i nekoliko postavki o kojima ovisi hoće li korisnike izbacivati, odjavljivati ili im nakon svake nove verzije pokazivati grešku.

Kratki odgovor: samostalna WebAssembly aplikacija ide na Azure Static Web Apps. Blazor Web App sa serverskim iscrtavanjem ili Interactive Serverom ide na Azure App Service. Container Apps je dobar izbor za timove koji već rade s kontejnerima, a Kubernetes je više nego što većini poslovnih aplikacija treba.

Koja usluga za koju Blazor aplikaciju

Usluga	Odgovara	Dobro je znati
Azure Static Web Apps	Samostalni Blazor WebAssembly	Poslužuje se s globalne mreže, ima besplatni plan i neobavezni API preko Azure Functions
Azure App Service	Blazor Web App: statično iscrtavanje, Interactive Server, Auto	Najjednostavniji izbor za većinu poslovnih aplikacija, deployment slotovi od Standard razine naviše
Azure Container Apps	Blazor Web App u kontejneru	Za timove koji već koriste kontejnere, session affinity samo u načinu s jednom revizijom
Azure Kubernetes Service	Velike platforme s puno servisa	Za jednu poslovnu aplikaciju rijetko vrijedi operativnog truda

Koji način rada treba koristiti koji ekran, opisujemo u članku Blazor Server vs WebAssembly vs Auto. Hosting slijedi iz tog izbora, a ne obrnuto.

Tri postavke koje Blazor Server treba na App Serviceu

Interactive Server drži stalnu vezu između preglednika i servera. Na App Serviceu o tri stvari ovisi radi li ta veza dobro:

1. Uključeni WebSockets. Blazor najbolje radi preko WebSocketsa, uz manje kašnjenje i veću pouzdanost. Bez njih prelazi na sporiji način prijenosa.
2. Uključen session affinity. Kad aplikacija radi na više od jedne instance, svaki korisnik mora stalno razgovarati s istom, jer stanje njegovog ekrana živi upravo na njoj. App Service to zove ARR affinity.
3. Azure SignalR Service kad je korisnika puno. Nije obavezan, ali preuzima veze kad broj istovremenih korisnika naraste na tisuće.

Postavka koju gotovo svi promaše: zajednički ključevi

ASP.NET Core ključevima štiti kolačiće prijave i forme. Na App Serviceu ti se ključevi automatski dijele između svih instanci jednog deployment slota. Ali odvojeni slotovi, poput stagea i produkcije, ne dijele ih. Nakon zamjene slotova korisnici mogu biti odjavljeni, a forme koje su imali otvorene mogu pasti.

Rješenje je ključeve držati izvan aplikacije, u Blob Storageu, zaštićene Key Vaultom:

builder.Services.AddDataProtection()
    .PersistKeysToAzureBlobStorage(new Uri(BlobStorageUri), new DefaultAzureCredential())
    .ProtectKeysWithAzureKeyVault(new Uri(KeyVaultURI), new DefaultAzureCredential());

Isto vrijedi za kontejnere: kontejner koji se ponovno pokrene gubi ključeve, osim ako se čuvaju na zajedničkom volumenu ili u vanjskom spremištu.

Isporuka bez iznenađenja

• Deployment slotovi. Nova verzija isporučuje se u staging slot, zagrije se, provjeri i onda zamijeni s produkcijom. App Service zamjenu radi bez odbačenih zahtjeva.
• Korisnici Interactive Servera vide ponovno spajanje. Zamjena ili restart prekida žive veze. Blazor se sam ponovno spaja, ali ono što je korisnik upisao na ekranu, a nije spremio, može se izgubiti. Isporučujte izvan radnog vremena ili neka duge forme spremaju usput.
• Automatizirani pipeline. GitHub Actions ili Azure DevOps grade, testiraju i isporučuju pri svakoj promjeni na glavnoj grani, pa nitko ne objavljuje sa svog laptopa.

Nadzor od prvog dana

Svaka Blazor aplikacija na Azureu trebala bi greške, spore zahtjeve i pozive prema drugim sustavima slati u Application Insights, uz alarme koji stižu do čovjeka. Kako to postaviti i kako da račun ne naraste, opisujemo u članku o Application Insightsu za .NET aplikacije. A prije prve isporuke prođite kontrolnu listu za sigurnost Blazor aplikacije.

Prije odluke

1. Je li aplikacija samostalni WebAssembly ili Blazor Web App sa serverskim iscrtavanjem?
2. Koliko će korisnika raditi istovremeno, u najvećoj gužvi?
3. Gradi li i vodi li vaš tim već kontejnere?
4. Koliko često isporučujete i mogu li korisnici podnijeti ponovno spajanje tijekom radnog vremena?
5. Tko će pratiti aplikaciju nakon puštanja u rad i kamo idu alarmi?

Kako mi radimo

Blazor i .NET aplikacije selimo u Azure i postavljamo kako treba: prava usluga, WebSockets i session affinity, zajednički ključevi, deployment slotovi, automatizirani pipeline i nadzor. Krećemo od vaše aplikacije kakva je danas i najjednostavnijeg postava koji će je nositi. Više o našem radu s Azureom, a prvi korak je besplatan razgovor od 30 minuta.

Izvori

• Host and deploy server-side Blazor apps, Microsoft Learn
• Host and deploy standalone Blazor WebAssembly with Azure Static Web Apps, Microsoft Learn
• Deploy a Blazor app on Azure Static Web Apps, Microsoft Learn
• Data Protection key management and lifetime, Microsoft Learn
• Session affinity in Azure Container Apps, Microsoft Learn
• Set up staging environments in Azure App Service, Microsoft Learn