Bereitstellungsslots und Austausch

Deployment-Slots sind aktive, separate Umgebungen für eine App Service-Web-App. Jeder Slot verfügt über einen eigenen Hostnamen (z. B. myapp-staging.azurewebsites.net). Die Slots nutzen denselben App Service-Plan und dieselben Ressourcen wie der Produktions-Slot, werden aber unabhängig ausgeführt. Sie ermöglichen Blue-Green-Deployments — Sie validieren ein neues Release in einem Staging-Slot und tauschen es anschließend ohne Ausfallzeit in die Produktion. Slots sind ab der Standard-Ebene verfügbar.

Fügen Sie Ihrer Web-App über das Azure-Portal oder die CLI einen neuen Deployment-Slot hinzu. Jeder Slot erhält eine eigene URL, Anwendungseinstellungen und Verbindungszeichenfolgen. Auf der Standard-Ebene können Sie bis zu 5 Slots und auf der Premium-Ebene bis zu 20 Slots erstellen. Häufige Slot-Namen sind staging, canary, hotfix und integration. Sie spiegeln die verschiedenen Phasen der Release-Pipeline wider.

Vor dem Tausch ist es wichtig, den Staging-Slot aufzuwärmen, damit die neue Version vollständig initialisiert ist. Eine nicht aufgewärmte App Service-Instanz verarbeitet die ersten Anforderungen langsam, während die Laufzeitumgebung initialisiert wird. Das ist in der Produktion nicht akzeptabel. Aktivieren Sie Auto Swap oder senden Sie manuell HTTP-Aufwärmanforderungen an den Staging-Slot. App Service unterstützt außerdem eine applicationInitialization-Konfiguration, mit der Sie Aufwärmpfade definieren können. Diese müssen den Statuscode 200 zurückgeben, bevor der Slot als bereit gilt.

Ein Tausch vertauscht den Staging- und den Produktions-Slot atomar. Während eines Tauschs leitet App Service den Datenverkehr zunächst an die Staging-Instanzen mit dem neuen Code weiter und wartet, bis diese initialisiert sind. Anschließend wird der gesamte Produktionsdatenverkehr an die neuen Instanzen umgeleitet, während die bisherigen Produktionsinstanzen zum neuen Staging-Slot werden. Dadurch ist ein Rollback ganz einfach — tauschen Sie die Slots einfach erneut, um die Änderung rückgängig zu machen.

Anwendungseinstellungen können als slotgebunden (slotspezifisch) oder nicht slotgebunden (austauschbar) markiert werden. Nicht slotgebundene Einstellungen werden beim Tausch mit dem Deployment-Slot verschoben — die Verbindungszeichenfolge Ihrer Staging-Datenbank folgt also dem Code in die Produktion. Slotgebundene Einstellungen bleiben unabhängig von Tauschvorgängen beim jeweiligen Slot — die Produktion behält also immer ihre Verbindungszeichenfolge zur Produktionsdatenbank. Markieren Sie Einstellungen über das Kontrollkästchen 'deployment slot setting' oder die CLI als slotgebunden.

App Service unterstützt die Datenverkehrsaufteilung — dabei wird ein Prozentsatz des Produktionsdatenverkehrs an einen Nicht-Produktions-Slot weitergeleitet, ohne einen vollständigen Tausch durchzuführen. Dies ermöglicht Canary-Releases, bei denen Sie den Datenverkehr schrittweise von 5 % über 10 % auf 50 % umleiten, während Sie Vertrauen in das neue Release gewinnen und die Fehlerraten bei jedem Schritt überwachen. Benutzer, die im Canary-Slot landen, erhalten ein Sticky-Cookie, das sie für eine konsistente Sitzung bei derselben Version hält.

Auto Swap tauscht einen Staging-Slot automatisch in die Produktion, sobald neuer Code dort bereitgestellt wurde. Diese Funktion eignet sich ideal für CI/CD-Pipelines, bei denen jedes erfolgreiche Deployment sofort live gehen soll. Auto Swap wartet, bis die HTTP-Anforderungen des Staging-Slots den Statuscode 200 zurückgeben, bevor der Tausch abgeschlossen wird. Aktivieren Sie die Funktion pro Slot im Portal oder über die CLI — verwenden Sie sie jedoch mit Vorsicht, da zwischen Deployment und Produktion keine manuelle Genehmigungsstufe vorhanden ist.

Beachten Sie für Deployment-Slots die folgenden bewährten Vorgehensweisen: Validieren Sie immer im Staging, bevor Sie in die Produktion tauschen. Verwenden Sie slotgebundene Einstellungen, um die Verbindungen der Produktionsdatenbank von Staging zu isolieren. Führen Sie nach dem Deployment Smoke-Tests anhand der URL des Staging-Slots aus. Konfigurieren Sie Health-Check-Pfade, damit App Service den Tausch nicht abschließt, wenn die neue Version fehlerhaft ist. Und versehen Sie Ihre Deployments mit Tags, damit Sie nachvollziehen können, welcher Commit in welchem Slot aktiv ist.

In einer typischen CI/CD-Pipeline kompiliert und testet die Build-Phase den Code, die Deployment-Phase stellt das Artefakt im Staging-Slot bereit, eine Integrationstest-Phase führt automatisierte Tests anhand der Staging-URL aus, und die Tausch-Phase tauscht den Staging-Slot in die Produktion — optional nach einer manuellen Genehmigung. Dieses Muster wird sowohl in Azure Pipelines als auch in GitHub Actions nativ mit der App Service-Deploy-Aktion unterstützt.

Überwachen Sie während und nach einem Slot-Tausch wichtige Metriken in Azure Monitor, um zu bestätigen, dass die neue Version fehlerfrei ist. Achten Sie auf Anstiege bei HTTP-5xx-Fehlern, der durchschnittlichen Antwortzeit und der CPU-/Speicherauslastung. Richten Sie Metrikalarme ein, die ausgelöst werden, wenn die Fehlerraten einen Schwellenwert überschreiten — so erhalten Sie ein Signal, um schnell zurückzutauschen. Die intelligente Erkennung von Application Insights kann Sie nach einem Deployment automatisch auf Anomalien hinweisen.

Deployment-Slots sind der Verwaltung vollständig getrennt stehender App Service-Apps für Staging und Produktion vorzuziehen, da Slots denselben Plan verwenden (keine zusätzlichen Kosten verursachen), einen Tausch mit einem Klick und Rollback ermöglichen, die Datenverkehrsaufteilung unterstützen und unter derselben App Service-Ressource verwaltet werden. Verwenden Sie separate Apps nur, wenn Staging grundlegend andere Plan-SKUs, Isolationsanforderungen oder eine vollständig getrennte Abrechnung benötigt.

Testen Sie Ihr Verständnis der Konzepte aus Microsoft Azure Fundamentals (AZ-900), die in dieser Lektion behandelt wurden.

In dieser Lektion haben Sie gelernt: Deployment-Slots stellen isolierte Umgebungen für Blue-Green-Deployments bereit. Slotgebundene Einstellungen halten umgebungsspezifische Konfigurationen (z. B. Datenbank-URLs) an den Slot gebunden und nicht an den Code. Die Datenverkehrsaufteilung ermöglicht Canary-Releases, indem ein Prozentsatz des Produktionsdatenverkehrs an eine neue Version weitergeleitet wird. Als Nächstes beschäftigen wir uns mit der automatischen Skalierung und benutzerdefinierten Domänen.