Blazor auf Azure: wo hosten, und welche Einstellungen Ihnen einen schlechten Montag ersparen

Eine Blazor-Anwendung auf Azure zu bringen dauert einen Nachmittag. Damit sie sich in Produktion ordentlich verhält, braucht es etwas mehr Wissen: welcher Dienst zu welcher Art von Blazor-App passt, und eine Handvoll Einstellungen, die entscheiden, ob Nutzer nach jedem Release getrennt, abgemeldet oder mit einem Fehler begrüßt werden.

Die kurze Antwort: Eine eigenständige WebAssembly-Anwendung gehört zu Azure Static Web Apps. Eine Blazor Web App mit serverseitigem Rendern oder Interactive Server gehört zu Azure App Service. Container Apps ist eine gute Wahl für Teams, die schon mit Containern arbeiten, und Kubernetes ist mehr, als die meisten Geschäftsanwendungen brauchen.

Welcher Dienst für welche Blazor-Anwendung

Dienst	Passt zu	Gut zu wissen
Azure Static Web Apps	Eigenständiges Blazor WebAssembly	Auslieferung über ein globales Netz, kostenloser Plan, optionale API über Azure Functions
Azure App Service	Blazor Web App: statisches Rendern, Interactive Server, Auto	Die einfachste Wahl für die meisten Geschäftsanwendungen, Deployment Slots ab dem Standard-Tarif
Azure Container Apps	Blazor Web App im Container	Für Teams, die schon Container nutzen, Session Affinity nur im Single-Revision-Modus
Azure Kubernetes Service	Große Plattformen mit vielen Diensten	Lohnt den Betriebsaufwand für eine einzelne Geschäftsanwendung selten

Welchen Render-Modus welcher Bildschirm nutzen sollte, steht im Artikel Blazor Server vs WebAssembly vs Auto. Das Hosting folgt aus dieser Wahl, nicht umgekehrt.

Drei Einstellungen, die Blazor Server auf App Service braucht

Interactive Server hält eine ständige Verbindung zwischen Browser und Server. Auf App Service entscheiden drei Dinge, ob diese Verbindung gut funktioniert:

1. WebSockets an. Blazor arbeitet am besten über WebSockets, mit geringerer Latenz und höherer Zuverlässigkeit. Ohne sie weicht es auf einen langsameren Transport aus.
2. Session Affinity an. Läuft die Anwendung auf mehr als einer Instanz, muss jeder Nutzer immer mit derselben sprechen, weil der Zustand seines Bildschirms dort liegt. App Service nennt das ARR Affinity.
3. Azure SignalR Service bei vielen Nutzern. Er ist nicht zwingend, übernimmt aber die Verbindungen, wenn die Zahl gleichzeitiger Nutzer in die Tausende geht.

Die Einstellung, die fast alle übersehen: gemeinsame Schlüssel

ASP.NET Core schützt Anmelde-Cookies und Formulare mit Schlüsseln. Auf App Service werden diese Schlüssel automatisch zwischen allen Instanzen eines Deployment Slots geteilt. Getrennte Slots wie Staging und Produktion teilen sie aber nicht. Nach einem Slot-Swap können Nutzer abgemeldet werden, und offene Formulare können fehlschlagen.

Die Lösung: die Schlüssel außerhalb der Anwendung speichern, in Blob Storage, geschützt mit Key Vault:

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

Dasselbe gilt für Container: Ein Container, der neu startet, verliert seine Schlüssel, wenn sie nicht auf einem gemeinsamen Volume oder in einem externen Speicher liegen.

Releases ohne Überraschungen

• Deployment Slots. Die neue Version wird in einen Staging-Slot ausgeliefert, aufgewärmt, geprüft und dann in die Produktion getauscht. App Service tauscht, ohne Anfragen zu verlieren.
• Nutzer von Interactive Server sehen eine Neuverbindung. Ein Swap oder Neustart beendet die Live-Verbindungen. Blazor verbindet sich automatisch neu, aber was der Nutzer eingegeben und nicht gespeichert hat, kann verloren gehen. Releasen Sie außerhalb der Arbeitszeit, oder lassen Sie lange Formulare zwischendurch speichern.
• Automatisierte Pipeline. GitHub Actions oder Azure DevOps bauen, testen und deployen bei jeder Änderung am Hauptzweig, sodass niemand vom eigenen Laptop veröffentlicht.

Monitoring vom ersten Tag an

Jede Blazor-Anwendung auf Azure sollte Fehler, langsame Anfragen und Aufrufe anderer Systeme an Application Insights senden, mit Alarmen, die einen Menschen erreichen. Wie man das einrichtet und die Rechnung klein hält, steht im Artikel über Application Insights für .NET-Anwendungen. Und vor dem ersten Release gehen Sie die Blazor-Sicherheits-Checkliste durch.

Vor der Wahl

1. Ist die Anwendung eigenständiges WebAssembly oder eine Blazor Web App mit serverseitigem Rendern?
2. Wie viele Nutzer arbeiten zur Spitzenzeit gleichzeitig?
3. Baut und betreibt Ihr Team bereits Container?
4. Wie oft releasen Sie, und können Nutzer eine Neuverbindung während der Arbeitszeit hinnehmen?
5. Wer beobachtet die Anwendung nach dem Go-live, und wohin gehen die Alarme?

Wie wir arbeiten

Wir bringen Blazor- und .NET-Anwendungen nach Azure und richten sie richtig ein: der passende Dienst, WebSockets und Session Affinity, gemeinsame Schlüssel, Deployment Slots, eine automatisierte Pipeline und Monitoring. Wir beginnen mit Ihrer Anwendung, wie sie heute ist, und dem einfachsten Aufbau, der sie trägt. Mehr über unsere Arbeit mit Azure, und der erste Schritt ist ein kostenloses 30-minütiges Gespräch.

Quellen

• 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