Blazor op Azure: waar u het host, en de instellingen die u een slechte maandag besparen

Een Blazor-applicatie op Azure zetten kost een middag. Zorgen dat ze zich in productie goed gedraagt, vraagt iets meer kennis: welke dienst bij welk soort Blazor-app past, en een handvol instellingen die bepalen of gebruikers na elke release worden losgekoppeld, uitgelogd of een foutmelding te zien krijgen.

Het korte antwoord: een zelfstandige WebAssembly-applicatie hoort bij Azure Static Web Apps. Een Blazor Web App met rendering op de server of Interactive Server hoort bij Azure App Service. Container Apps is een goede keuze voor teams die al met containers werken, en Kubernetes is meer dan de meeste bedrijfsapplicaties nodig hebben.

Welke dienst voor welke Blazor-applicatie

Dienst	Past bij	Goed om te weten
Azure Static Web Apps	Zelfstandige Blazor WebAssembly	Geleverd via een wereldwijd netwerk, heeft een gratis plan en een optionele API via Azure Functions
Azure App Service	Blazor Web App: statische rendering, Interactive Server, Auto	De eenvoudigste keuze voor de meeste bedrijfsapplicaties, deployment slots vanaf de Standard-laag
Azure Container Apps	Blazor Web App in een container	Voor teams die al containers gebruiken, session affinity alleen in single revision-modus
Azure Kubernetes Service	Grote platforms met veel services	Zelden de beheerlast waard voor één bedrijfsapplicatie

Welke rendermodus elk scherm moet gebruiken, leest u in Blazor Server vs WebAssembly vs Auto. De hosting volgt uit die keuze, niet andersom.

Drie instellingen die Blazor Server op App Service nodig heeft

Interactive Server houdt een vaste verbinding tussen browser en server. Op App Service bepalen drie dingen of die verbinding goed werkt:

1. WebSockets aan. Blazor werkt het best via WebSockets, met minder vertraging en meer betrouwbaarheid. Zonder valt het terug op een tragere manier van transport.
2. Session affinity aan. Draait de applicatie op meer dan één instantie, dan moet elke gebruiker steeds met dezelfde praten, omdat de status van zijn scherm daar staat. App Service noemt dit ARR affinity.
3. Azure SignalR Service bij veel gebruikers. Het is niet verplicht, maar het neemt de verbindingen over als het aantal gelijktijdige gebruikers in de duizenden loopt.

De instelling die bijna iedereen mist: gedeelde sleutels

ASP.NET Core beschermt inlogcookies en formulieren met sleutels. Op App Service worden die sleutels automatisch gedeeld tussen alle instanties van één deployment slot. Maar aparte slots, zoals staging en productie, delen ze niet. Na een slot swap kunnen gebruikers worden uitgelogd en kunnen openstaande formulieren mislukken.

De oplossing is de sleutels buiten de applicatie te bewaren, in Blob Storage, beschermd met Key Vault:

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

Hetzelfde geldt voor containers: een container die herstart, verliest zijn sleutels tenzij ze op een gedeeld volume of in een externe opslag staan.

Releasen zonder verrassingen

• Deployment slots. De nieuwe versie gaat naar een stagingslot, wordt opgewarmd, gecontroleerd en daarna naar productie geswapt. App Service swapt zonder verzoeken te laten vallen.
• Gebruikers van Interactive Server zien een herverbinding. Een swap of herstart beëindigt de live verbindingen. Blazor verbindt automatisch opnieuw, maar wat de gebruiker had ingevuld en niet opgeslagen, kan verloren gaan. Release buiten werktijd, of laat lange formulieren tussentijds opslaan.
• Geautomatiseerde pipeline. GitHub Actions of Azure DevOps bouwt, test en deployt bij elke wijziging in de hoofdbranch, zodat niemand vanaf zijn eigen laptop publiceert.

Monitoring vanaf dag één

Elke Blazor-applicatie op Azure moet fouten, trage verzoeken en aanroepen naar andere systemen naar Application Insights sturen, met meldingen die een mens bereiken. Hoe u dat inricht en de rekening laag houdt, leest u in het artikel over Application Insights voor .NET-applicaties. En loop vóór de eerste release de Blazor-beveiligingschecklist door.

Voordat u kiest

1. Is de applicatie zelfstandige WebAssembly, of een Blazor Web App met rendering op de server?
2. Hoeveel gebruikers werken er op het drukste moment tegelijk?
3. Bouwt en beheert uw team al containers?
4. Hoe vaak releaset u, en kunnen gebruikers een herverbinding tijdens werktijd verdragen?
5. Wie houdt de applicatie na de livegang in de gaten, en waar gaan de meldingen naartoe?

Hoe wij werken

Wij verhuizen Blazor- en .NET-applicaties naar Azure en richten ze goed in: de juiste dienst, WebSockets en session affinity, gedeelde sleutels, deployment slots, een geautomatiseerde pipeline en monitoring. Wij beginnen bij uw applicatie zoals die nu is en de eenvoudigste opzet die haar kan dragen. Meer over ons werk met Azure, en de eerste stap is een gratis gesprek van 30 minuten.

Bronnen

• 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