Blazor på Azure: var du ska hosta det, och inställningarna som besparar dig en dålig måndag

Att lägga upp en Blazor-applikation på Azure tar en eftermiddag. Att få den att bete sig väl i produktion kräver lite mer kunskap: vilken tjänst som passar vilken typ av Blazor-app, och en handfull inställningar som avgör om användarna kopplas bort, loggas ut eller får se ett fel efter varje release.

Det korta svaret: en fristående WebAssembly-applikation hör hemma i Azure Static Web Apps. En Blazor Web App med rendering på servern eller Interactive Server hör hemma i Azure App Service. Container Apps är ett bra val för team som redan arbetar med containrar, och Kubernetes är mer än de flesta affärsapplikationer behöver.

Vilken tjänst för vilken Blazor-applikation

Tjänst	Passar	Bra att veta
Azure Static Web Apps	Fristående Blazor WebAssembly	Levereras via ett globalt nät, har en gratisplan och ett valfritt API via Azure Functions
Azure App Service	Blazor Web App: statisk rendering, Interactive Server, Auto	Det enklaste valet för de flesta affärsapplikationer, driftsättningsplatser från Standard-nivån och uppåt
Azure Container Apps	Blazor Web App i en container	För team som redan använder containrar, session affinity bara i läget med en revision
Azure Kubernetes Service	Stora plattformar med många tjänster	Sällan värt driftarbetet för en enda affärsapplikation

Vilket renderingsläge varje skärm ska använda beskriver vi i Blazor Server vs WebAssembly vs Auto. Hostingen följer av det valet, inte tvärtom.

Tre inställningar som Blazor Server behöver på App Service

Interactive Server håller en ständig anslutning mellan webbläsaren och servern. På App Service avgör tre saker om anslutningen fungerar väl:

1. WebSockets på. Blazor fungerar bäst över WebSockets, med lägre fördröjning och bättre tillförlitlighet. Utan dem faller det tillbaka på ett långsammare sätt att överföra.
2. Session affinity på. När applikationen körs på mer än en instans måste varje användare alltid prata med samma, eftersom skärmens tillstånd finns där. App Service kallar det ARR affinity.
3. Azure SignalR Service när användarna är många. Den är inte nödvändig, men tar över anslutningarna när antalet samtidiga användare växer till tusentals.

Inställningen nästan alla missar: delade nycklar

ASP.NET Core skyddar inloggningscookies och formulär med nycklar. På App Service delas nycklarna automatiskt mellan alla instanser på en driftsättningsplats. Men separata platser, som staging och produktion, delar dem inte. Efter ett platsbyte kan användare loggas ut, och formulär de hade öppna kan misslyckas.

Lösningen är att förvara nycklarna utanför applikationen, i Blob Storage, skyddade med Key Vault:

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

Samma sak gäller containrar: en container som startar om förlorar sina nycklar om de inte ligger på en delad volym eller i en extern lagring.

Releaser utan överraskningar

• Driftsättningsplatser. Den nya versionen driftsätts till en stagingplats, värms upp, kontrolleras och byts sedan till produktion. App Service byter utan att tappa anrop.
• Användare av Interactive Server ser en återanslutning. Ett byte eller en omstart avslutar de aktiva anslutningarna. Blazor återansluter automatiskt, men det användaren skrivit och inte sparat kan gå förlorat. Släpp utanför arbetstid, eller låt långa formulär spara under tiden.
• Automatiserad pipeline. GitHub Actions eller Azure DevOps bygger, testar och driftsätter vid varje ändring på huvudgrenen, så att ingen publicerar från sin egen laptop.

Övervakning från första dagen

Varje Blazor-applikation på Azure bör skicka fel, långsamma anrop och anrop till andra system till Application Insights, med larm som når en människa. Hur du sätter upp det och håller nere kostnaden beskriver vi i artikeln om Application Insights för .NET-applikationer. Och gå igenom checklistan för säkerhet i Blazor före den första releasen.

Innan du väljer

1. Är applikationen fristående WebAssembly eller en Blazor Web App med rendering på servern?
2. Hur många användare arbetar samtidigt vid topparna?
3. Bygger och driver ditt team redan containrar?
4. Hur ofta släpper ni nya versioner, och klarar användarna en återanslutning under arbetstid?
5. Vem bevakar applikationen efter driftsättningen, och vart går larmen?

Så arbetar vi

Vi flyttar Blazor- och .NET-applikationer till Azure och sätter upp dem ordentligt: rätt tjänst, WebSockets och session affinity, delade nycklar, driftsättningsplatser, en automatiserad pipeline och övervakning. Vi börjar med din applikation som den är i dag och den enklaste uppsättning som bär den. Mer om vårt arbete med Azure, och första steget är ett kostnadsfritt samtal på 30 minuter.

Källor

• 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