Einrichten von Stagingumgebungen in Azure App Service

Artikel
05/11/2023

Im Tarif Standard, Premium oder I des App Service-Plans können Sie für die Bereitstellung Ihrer Web-App, Ihrer Web-App unter Linux, Ihres mobilen Back-Ends oder Ihrer API-App in Azure App Service anstelle des Standardproduktionsslots einen separaten Bereitstellungsslot verwenden. Bereitstellungsslots sind aktive Apps mit eigenen Hostnamen. Elemente für App-Inhalte und -Konfigurationen können zwischen zwei Bereitstellungsslots, einschließlich des Produktionsslots, ausgetauscht werden.

Die Bereitstellung von Anwendungen in einem produktionsfremden Slot hat folgende Vorteile:

Sie können App-Änderungen in einem Stagingbereitstellungsslot überprüfen, bevor Sie die App in den Produktionsslot überführen.
Wenn Sie eine App zuerst in einem Slot bereitstellen und dann in den Produktionsslot überführen, ist sichergestellt, dass alle Instanzen erst nach einer Anlaufzeit in den Produktionsslot übernommen werden. Dadurch vermeiden Sie Ausfallzeiten bei der Bereitstellung der App. Die Umleitung des Datenverkehrs erfolgt übergangslos, und es gehen keine Anforderungen aufgrund des Tauschs verloren. Der gesamte Workflow kann durch Konfigurieren von Automatisch tauschen automatisiert werden, wenn keine Überprüfung vor dem Tausch erforderlich ist.
Nach der Überführung enthält der Slot mit der vorherigen Staging-App die vorherige Produktions-App. Wenn die in den Produktionsslot überführten Änderungen nicht Ihren Erwartungen entsprechen, können Sie den gleichen Tausch sofort noch einmal vornehmen, um Ihre „letzte als funktionierend bekannte Website“ zurückzuerhalten.

Jeder App Service-Plantarif unterstützt eine andere Anzahl von Bereitstellungsslots. Für die Nutzung von Bereitstellungsslots fallen keine zusätzlichen Gebühren an. Informationen zur unterstützten Slotanzahl in Ihrem App-Tarif finden Sie unter App Service-Grenzwerte.

Wenn Sie Ihre App auf einen anderen Tarif skalieren möchten, muss der Zieltarif die Anzahl von Slots unterstützen, die Ihre App bereits verwendet. Falls Ihre App also beispielsweise mehr als fünf Slots besitzt, können Sie sie nicht auf den Tarif Standard herunterskalieren, da der Tarif Standard nur fünf Bereitstellungsslots unterstützt.

Hinzufügen eines Slots

Die App muss im Tarif Standard, Premium oder I ausgeführt werden, um mehrere Bereitstellungsslots aktivieren zu können.

Suchen Sie im Azure-Portal die Option App Services, wählen Sie sie aus, und wählen Sie dann Ihre App aus.
Wählen Sie im linken Bereich Bereitstellungsslots>Slot hinzufügen aus.

Hinweis

Wenn die App nicht bereits im Tarif Standard, Premium oder I ausgeführt wird, wird eine Meldung angezeigt, in der auf die unterstützten Tarife für die Veröffentlichung in einer Stagingumgebung hingewiesen wird. An diesem Punkt können Sie Upgrade auswählen und zur Registerkarte Skalierung der App navigieren, bevor Sie den Vorgang fortsetzen.
Weisen Sie dem Slot im Dialogfeld Slot hinzufügen einen Namen zu, und wählen Sie aus, ob Sie die App-Konfiguration eines anderen Bereitstellungsslots klonen möchten. Wählen Sie Hinzufügen aus, um den Vorgang fortzusetzen.

Sie können die Konfiguration eines beliebigen bereits vorhandenen Slots klonen. Zu den Einstellungen, die geklont werden können, zählen App-Einstellungen, Verbindungszeichenfolgen, Sprachframework-Versionen, Websockets, die HTTP-Version und die Bitanzahl der Plattform.

Hinweis

Derzeit werden private Endpunkte nicht über Slots geklont.

Wählen Sie nach dem Hinzufügen des Slots Schließen aus, um das Dialogfeld zu schließen. Der neue Slot wird nun auf der Seite Bereitstellungsslots angezeigt. Datenverkehr % ist für den neuen Slot standardmäßig auf „0“ festgelegt, sodass der gesamte Kundendatenverkehr an den Produktionsslot weitergeleitet wird.
Wählen Sie den neuen Bereitstellungsslot aus, um die Ressourcenseite dieses Slots zu öffnen.

Der Stagingslot verfügt genau wie jede andere App Service-App über eine Verwaltungsseite. Sie können die Konfiguration des Slots ändern. Um Sie daran zu erinnern, dass Sie den Bereitstellungsslot sehen, wird der App-Name als <App-Name>/<Slotname> angezeigt, während der App-Typ App Service (Slot) lautet. Sie können den Slot auch als separate App in der Ressourcengruppe mit denselben Bezeichnungen sehen.
Wählen Sie auf der Ressourcenseite des Slots die App-URL aus. Der Bereitstellungsslot besitzt einen eigenen Hostnamen und ist außerdem eine Live-App. Informationen zum Beschränken des öffentlichen Zugriffs auf den Bereitstellungsslot finden Sie unter Statische Azure App Service-IP-Einschränkungen.

Der neue Bereitstellungsslot hat keinen Inhalt. Das gilt auch, wenn Sie die Einstellungen eines anderen Slots klonen. Sie können beispielsweise Git verwenden, um etwas in diesem Slot zu veröffentlichen. Die Bereitstellung im Slot kann aus einem anderen Repository-Branch oder aus einem anderen Repository erfolgen. Durch das Abrufen des Veröffentlichungsprofils aus Azure App Service können Sie erforderliche Informationen für die Bereitstellung im Slot erhalten. Das Profil kann von Visual Studio importiert werden, um Inhalte in dem Slot bereitzustellen.

Die URL des Slots weist folgendes Format auf: http://sitename-slotname.azurewebsites.net. Um die URL-Länge innerhalb der erforderlichen DNS-Grenzwerte zu halten, wird der Websitename bei 40 Zeichen und der Slotname bei 19 Zeichen abgeschnitten. Zusätzlich werden weitere 4 Zufallszeichen angefügt, um sicherzustellen, dass der resultierende Domänenname eindeutig ist.

Was geschieht bei einem Austausch?

Schritte bei einem Austausch

Wenn Sie zwei Slots austauschen (in der Regel, um aus einem Stagingslot einen Produktionsslot zu machen), werden folgende Schritte ausgeführt, um Downtime im Zielslot zu verhindern:

App Service wendet die folgenden Einstellungen aus dem Zielslot (also beispielsweise dem Produktionsslot) auf alle Instanzen des Quellslot an:
- Slotspezifische App-Einstellungen und Verbindungszeichenfolgen (sofern zutreffend)
- Einstellungen für Continuous Deployment (sofern aktiviert)
- Einstellungen für die App Service-Authentifizierung (sofern aktiviert)
In jedem dieser Fälle wird ein Neustart aller Instanzen im Quellslot ausgelöst. Beim Austauschen mit Vorschau ist dies das Ende der ersten Phase. Der Austauschvorgang wird angehalten, und Sie können sich vergewissern, dass der Quellslot mit den Einstellungen des Zielslots ordnungsgemäß funktioniert.
App Service wartet, bis jede Instanz im Quellslot neu gestartet wurde. Sollte eine Instanz nicht erfolgreich neu gestartet werden, werden sämtliche Änderungen am Quellslot zurückgesetzt, und der Austauschvorgang wird beendet.
Wenn lokaler Cache aktiviert ist, löst App Service die Initialisierung des lokalen Caches aus. Hierzu wird eine HTTP-Anforderung an den Anwendungsstamm („/“) in jeder Instanz des Quellslots gerichtet. Daraufhin wird gewartet, bis die einzelnen Instanzen eine HTTP-Antwort zurückgeben. Die Initialisierung des lokalen Caches hat einen weiteren Neustart der einzelnen Instanzen zur Folge.
Wenn Automatisch tauschen mit benutzerdefinierter Aufwärmphase aktiviert ist, löst App Service die Anwendungsinitiierung aus. Hierzu wird eine HTTP-Anforderung an den Anwendungsstamm („/“) in jeder Instanz des Quellslots gerichtet.

Ohne Angabe von applicationInitialization löst App Service eine HTTP-Anforderung an den Anwendungsstamm des Quellslots in jeder Instanz aus.

Wenn eine Instanz eine HTTP-Antwort zurückgibt, wird sie vorbereitet betrachtet.
Nach erfolgreicher Vorbereitung aller Instanzen im Quellslot vertauscht App Service die Routingregeln der beiden Slots, um die beiden Slots auszutauschen. Nach diesem Schritt befindet sich die App, die zuvor im Quellslot vorbereitet wurde, im Zielslot (also beispielsweise im Produktionsslot).
Nachdem der Quellslot nun die App vor dem Austausch enthält, die sich zuvor im Zielslot befand, führt App Service den gleichen Vorgang erneut aus (also Anwenden aller Einstellungen und Neustarten der Instanzen).

In jeder Phase des Austauschvorgangs finden sämtliche Vorgänge zur Initialisierung der ausgetauschten Apps im Quellslot statt. Der Zielslot bleibt während der gesamten Vorbereitung des Quellslots online – unabhängig davon, ob der Austausch erfolgreich ist. Wenn Sie einen Stagingslot und den Produktionsslot austauschen möchten, muss der Produktionsslot immer der Zielslot sein. So ist sichergestellt, dass Ihre Produktions-App durch den Austauschvorgang nicht beeinträchtigt wird.

Hinweis

Die Instanzen in Ihren früheren Produktionsinstanzen (diejenigen, die nach diesem Austauschvorgang in das Staging verlagert wurden) werden im letzten Schritt des Austauschprozesses schnell neu gestartet. Falls Ihre Anwendung zeitintensive Vorgänge umfasst, werden diese beim Neustart der Worker abgebrochen. Dies gilt auch für Funktions-Apps. Daher sollte Ihr Anwendungscode Fehlertoleranz vorsehen.

Welche Einstellungen werden ausgetauscht?

Wenn Sie die Konfiguration von einem anderen Bereitstellungsslot klonen, kann die geklonte Konfiguration bearbeitet werden. Bei einem Austausch werden einige Konfigurationselemente zusammen mit dem Inhalt überführt (nicht slotspezifisch), während andere Konfigurationselemente nach einem Austausch im gleichen Slot verbleiben (slotspezifisch). Im Anschluss sind die Einstellungen aufgeführt, die sich beim Austauschen der Slots ändert.

Einstellungen, die ausgetauscht werden:

Allgemeine Einstellungen (z. B. Framework-Version, 32/64-Bit-Angabe, WebSockets)
App-Einstellungen (können so konfiguriert werden, dass sie beim Slot verbleiben)
Verbindungszeichenfolgen (können so konfiguriert werden, dass sie beim Slot verbleiben)
Handlerzuordnungen
Öffentliche Zertifikate
WebJobs-Inhalte
Hybridverbindungen *
Dienstendpunkte*
Azure Content Delivery Network*
Pfadzuordnungen

Für mit einem Sternchen (*) gekennzeichnete Features ist eine Rückgängigmachung des Austauschs geplant.

Einstellungen, die nicht ausgetauscht werden:

Veröffentlichungsendpunkte
Benutzerdefinierte Domänennamen
Nicht öffentliche Zertifikate und TLS/SSL-Einstellungen
Skalierungseinstellungen
WebJobs-Planer
IP-Einschränkungen
Always On
Diagnoseeinstellungen
Ressourcenfreigabe zwischen verschiedenen Ursprüngen (Cross-Origin Resource Sharing, CORS)
Integration in ein virtuelles Netzwerk
Verwaltete Identitäten
Einstellungen, die mit dem Suffix „_EXTENSION_VERSION“ enden

Hinweis

Damit die genannten Einstellungen ausgetauscht werden können, fügen Sie die App-Einstellung WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS in jedem Slot der App hinzu, und legen Sie ihren Wert auf 0 oder false fest. Entweder sind alle diese Einstellungen austauschbar oder überhaupt keine. Sie können nicht einige Einstellungen als austauschbar definieren und andere nicht. Verwaltete Identitäten werden nie ausgetauscht und sind von dieser App-Einstellung zum Außerkraftsetzen nicht betroffen.

Bestimmte App-Einstellungen, die für nicht ausgetauschte Einstellungen gelten, werden ebenfalls nicht ausgetauscht. Da die Diagnoseprotokolleinstellungen beispielsweise nicht ausgetauscht werden, werden verwandte App-Einstellungen wie WEBSITE_HTTPLOGGING_RETENTION_DAYS und DIAGNOSTICS_AZUREBLOBRETENTIONDAYS ebenfalls nicht ausgetauscht, auch wenn Sie nicht als Sloteinstellungen angezeigt werden.

Wenn Sie eine App-Einstellung oder eine Verbindungszeichenfolge fest einem bestimmten Slot zuordnen möchten, sodass sie nicht ausgetauscht wird, navigieren Sie zurKonfigurationsseite für den entsprechenden Slot. Aktivieren Sie nach dem Hinzufügen oder Bearbeiten einer Einstellung das Kontrollkästchen Bereitstellungssloteinstellung. Ist dieses Kontrollkästchen aktiviert, wird die Einstellung nicht ausgetauscht.

Sloteinstellung

Austauschen von zwei Slots

Bereitstellungsslots können auf der Seite Bereitstellungsslots Ihrer App sowie auf der Seite Übersicht ausgetauscht werden. Technische Details zum Slotaustauch finden Sie unter Was geschieht bei einem Austausch?.

Wichtig

Vergewissern Sie sich vor der Überführung einer App aus einem Bereitstellungsslot in die Produktion, dass der Produktionsslot der Zielslot ist und dass alle Einstellungen im Quellslot exakt so konfiguriert sind, wie sie in der Produktion konfiguriert sein sollen.

So tauschen Sie Bereitstellungsslots aus:

Wählen Sie auf der Seite Bereitstellungsslots Ihrer App die Option Austauschen aus.

Im Dialogfeld Austauschen werden Einstellungen der ausgewählten Quell- und Zielslots angezeigt, die ausgetauscht werden.
Wählen Sie die gewünschten Slots für Quelle und Ziel aus. Bei dem Ziel handelt es sich in der Regel um einen Produktionsslot. Wählen Sie auch die Registerkarten Quelländerungen und Zieländerungen aus, und vergewissern Sie sich, dass die Konfigurationsänderungen Ihren Erwartungen entsprechen. Wählen Sie anschließend Austauschen aus, um die Slots umgehend auszutauschen.

Wenn Sie sich vor dem tatsächlichen Austausch ansehen möchten, wie der Zielslot mit den neuen Einstellungen funktioniert, wählen Sie nicht Austauschen aus, sondern führen Sie die Schritte unter Mit Vorschau austauschen aus.
Wählen Sie abschließend Schließen aus, um das Dialogfeld zu schließen.

Informationen zur Problembehandlung finden Sie bei Bedarf unter Behandeln von Problemen beim Austausch.

Mit Vorschau austauschen (Austausch mit mehreren Phasen)

Vergewissern Sie sich, dass die App mit den ausgetauschten Einstellungen funktioniert, bevor Sie einen Austausch mit dem Produktionsslot als Zielslot durchführen. Der Quellslot wird außerdem vor Abschluss des Austauschs vorbereitet, was für unternehmenskritische Anwendungen von Vorteil ist.

Bei einem Austausch mit Vorschau führt App Service den gleichen Austauschvorgang durch, pausiert jedoch nach dem ersten Schritt. Daraufhin können Sie das Ergebnis vor Abschluss des Austauschs im Stagingslot überprüfen.

Wenn Sie den Austausch abbrechen, wendet App Service erneut Konfigurationselemente auf den Quellslot an.

Hinweis

Der Austausch mit der Vorschau kann nicht verwendet werden, wenn für einen der Slots Websiteauthentifizierung aktiviert ist.

So führen Sie einen Austausch mit Vorschau durch:

Führen Sie die Schritte unter Überführen von Bereitstellungsslots aus, aktivieren Sie dabei jedoch das Kontrollkästchen Tausch mit Vorschau ausführen.

Das Dialogfeld zeigt, wie sich die Konfiguration im Quellslot ändert (Phase 1) und wie sich der Quell- und der Zielslot ändern (Phase 2).
Wenn Sie so weit sind, wählen Sie Austausch starten aus.

Nach Abschluss der ersten Phase wird im Dialogfeld eine entsprechende Benachrichtigung angezeigt. Navigieren Sie zu https://<app_name>-<source-slot-name>.azurewebsites.net, um sich eine Vorschau des Austauschs im Quellslot anzusehen.
Wenn Sie bereit sind, den ausstehenden Austausch abzuschließen, wählen Sie unter Austauschaktion die Option Austausch abschließen und anschließend Austausch abschließen aus.

Wenn Sie einen ausstehenden Austausch abbrechen möchten, wählen Sie stattdessen Austausch abbrechen aus.
Wählen Sie abschließend Schließen aus, um das Dialogfeld zu schließen.

Informationen zur Problembehandlung finden Sie bei Bedarf unter Behandeln von Problemen beim Austausch.

Informationen zum Automatisieren eines mehrstufigen Austauschs finden Sie unter Automatisieren mit PowerShell.

Ausführen eines Rollbacks für einen Austausch

Sollten nach einem Slotaustausch Fehler im Zielslot (etwa im Produktionsslot) auftreten, stellen Sie für die Slots den Zustand vor dem Austausch wieder her, indem Sie die beiden gleichen Slots sofort erneut austauschen.

Konfigurieren des automatischen Austauschs

Hinweis

Der automatische Austausch wird in Web-Apps unter Linux und in der Web-App für Container nicht unterstützt.

Das Feature „Automatisch tauschen“ ermöglicht die Optimierung von Azure DevOps-Szenarien, bei denen Ihre App kontinuierlich ohne Kaltstarts und ohne Downtime für App-Kunden bereitgestellt werden soll. Wenn automatisches Austauschen für die Überprüfung eines Slots in die Produktion aktiviert ist, gilt Folgendes: Sobald Sie Ihre Codeänderungen an diesen Slot pushen, überführt App Service die App automatisch in die Produktion, nachdem sie im Quellslot vorbereitet wurde.

Hinweis

Es empfiehlt sich, das Feature „Automatisch tauschen“ zunächst in einem produktionsfremden Zielslot zu testen, bevor Sie es für den Produktionsslot konfigurieren.

So konfigurieren Sie automatisches Austauschen:

Navigieren Sie zur Ressourcenseite Ihrer App. Wählen Sie Bereitstellungsslots><gewünschter Quellslot>>Konfiguration>Allgemeine Einstellungen aus.
Legen Sie Automatischer Tausch aktiviert auf Ein fest. Wählen Sie anschließend unter Bereitstellungsslot für automatischen Tausch den gewünschten Zielslot und danach auf der Befehlsleiste die Option Speichern aus.
Führen Sie einen Codepushvorgang an den Quellslot aus. Der automatische Austausch erfolgt nach kurzer Zeit, und die URL Ihres Zielslots spiegelt die Änderung wider.

Informationen zur Problembehandlung finden Sie bei Bedarf unter Behandeln von Problemen beim Austausch.

Angeben der benutzerdefinierten Aufwärmphase

Für einige Apps müssen vor dem Austausch unter Umständen benutzerdefinierte Vorbereitungsschritte ausgeführt werden. Mithilfe des Konfigurationselements applicationInitialization in „web.config“ können Sie benutzerdefinierte Initialisierungsaktionen angeben. Der Austausch mit dem Zielslot erfolgt dann erst nach Abschluss dieser benutzerdefinierten Aufwärmphase. Hier sehen Sie ein Beispielfragment aus „web.config“:

<system.webServer>
    <applicationInitialization>
        <add initializationPage="/" hostName="[app hostname]" />
        <add initializationPage="/Home/About" hostName="[app hostname]" />
    </applicationInitialization>
</system.webServer>

Weitere Informationen zum Anpassen des applicationInitialization-Elements finden Sie unter Häufigste Bereitstellungsfehler beim Slotaustausch und Vorgehensweise zu deren Behebung.

Sie können das Aufwärmverhalten ferner mithilfe folgender App-Einstellungen anpassen:

WEBSITE_SWAP_WARMUP_PING_PATH: Der über HTTP zu pingende Pfad, um Ihre Website vorzubereiten. Fügen Sie diese App-Einstellung durch Angeben eines benutzerdefinierten Pfads hinzu, der mit einem Schrägstrich als Wert beginnt. z. B. /statuscheck. Standardwert: /.
WEBSITE_SWAP_WARMUP_PING_STATUSES: Gültige HTTP-Antwortcodes für den Aufwärmvorgang. Fügen Sie diese App-Einstellung mit einer durch Trennzeichen getrennten Liste mit HTTP-Codes hinzu. Beispiel: 200,202. Ist der zurückgegebene Statuscode nicht in der Liste enthalten, werden die Vorbereitungs- und Austauschvorgänge beendet. Standardmäßig sind alle Antwortcodes gültig.
WEBSITE_WARMUP_PATH: Ein relativer Pfad auf der Site, der bei jedem Neustart der Site (nicht nur während des Slotaustausches) gepingt werden sollte. Beispielwerte sind /statuscheck oder der Stammpfad /.

Hinweis

Das <applicationInitialization>-Konfigurationselement ist Teil jeder App-Startseite, während die beiden App-Einstellungen für das Aufwärmverhalten nur für den Slotaustausch gelten.

Informationen zur Problembehandlung finden Sie bei Bedarf unter Behandeln von Problemen beim Austausch.

Überwachen eines Austauschs

Bei länger dauernden Austauschvorgängen können Sie sich anhand des Aktivitätsprotokolls über den Austauschvorgang informieren.

Wählen Sie im Portal auf der Ressourcenseite Ihrer App im linken Bereich die Option Aktivitätsprotokoll aus.

Ein Austauschvorgang wird in der Protokollabfrage als Swap Web App Slots angezeigt. Sie können die Abfrage erweitern und Untervorgänge oder Fehler auswählen, um die entsprechenden Details anzuzeigen.

Weiterleiten von Datenverkehr

Standardmäßig werden alle an die Produktions-URL Ihrer App (http://<app_name>.azurewebsites.net) gerichteten Clientanforderungen an den Produktionsslot weitergeleitet. Sie können einen Teil des Datenverkehrs an einen anderen Slot weiterleiten. Dieses Feature ist hilfreich, wenn Sie Benutzerfeedback zu einem neuen Update benötigen, das noch nicht für die Veröffentlichung in der Produktionsumgebung bereit ist.

Automatisches Weiterleiten von Produktionsdatenverkehr

So leiten Sie Produktionsdatenverkehr automatisch weiter:

Navigieren Sie zur Ressourcenseite Ihrer App, und wählen Sie Bereitstellungsslots aus.
Geben Sie in der Spalte Datenverkehr % des gewünschten Zielslots für die Weiterleitung durch einen Prozentwert (zwischen 0 und 100) an, welcher Anteil des gesamten Datenverkehrs weitergeleitet werden soll. Wählen Sie Speichern aus.

Nach dem Speichern der Einstellung wird der angegebene Prozentsatz von Clients nach dem Zufallsprinzip an den produktionsfremden Slot weitergeleitet.

Nachdem ein Client automatisch an einen bestimmten Slot weitergeleitet wurde, wird er für eine Stunde an diesen Slot angeheftet oder bis die Cookies gelöscht werden. Im Clientbrowser sehen Sie anhand des Cookies x-ms-routing-name in Ihren HTTP-Headern, mit welchem Slot Ihre Sitzung verknüpft ist. Anforderungen, die an den Stagingslot weitergeleitet werden, haben das Cookie x-ms-routing-name=staging. Anforderungen, die an den Produktionsslot weitergeleitet werden, haben das Cookie x-ms-routing-name=self.

Hinweis

Sie können auch den Befehl az webapp traffic-routing set in der Azure-Befehlszeilenschnittstelle verwenden, um die Prozentwerte für das Routing von CI/CD-Tools wie GitHub Actions, DevOps-Pipelines oder anderen Automatisierungssystemen festzulegen.

Manuelles Weiterleiten von Produktionsdatenverkehr

Neben dem automatischen Datenverkehrsrouting kann App Service Anforderungen auch an einen bestimmten Slot weiterleiten. Dies ist hilfreich, wenn Sie Ihren Benutzern ermöglichen möchten, Ihre Beta-App zu nutzen oder die Nutzung zu beenden. Zur manuellen Weiterleitung von Produktionsdatenverkehr wird der Abfrageparameter x-ms-routing-name verwendet.

Damit Benutzer die Nutzung Ihrer Beta-App beenden können, können Sie z. B. folgenden Link auf Ihrer Webseite bereitstellen:

<a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>

Die Zeichenfolge x-ms-routing-name=self gibt den Produktionsslot an. Wenn der Clientbrowser auf den Link zugreift, wird er zum Produktionsslot weitergeleitet. Jede nachfolgende Anforderung besitzt das Cookie x-ms-routing-name=self, das die Sitzung mit dem Produktionsslot verknüpft.

Damit Benutzer Ihre Beta-App nutzen können, müssen Sie den gleichen Abfrageparameter auf den Namen des produktionsfremden Slots festlegen. Hier sehen Sie ein Beispiel:

<webappname>.azurewebsites.net/?x-ms-routing-name=staging

Standardmäßig erhalten neue Slots eine Routingregel von 0%, die in grau dargestellt. Wenn Sie diesen Wert explizit auf 0% festlegen (als schwarzer Text dargestellt), können Ihre Benutzer manuell unter Verwendung des Abfrageparameters x-ms-routing-name auf den Stagingslot zugreifen. Sie werden jedoch nicht automatisch an den Slot weitergeleitet, da der Prozentsatz für die Weiterleitung auf „0“ festgelegt ist. Dies ist ein erweitertes Szenario, in dem Sie Ihren Stagingslot vor der Öffentlichkeit verbergen können, während Sie gleichzeitig zulassen, dass interne Teams Änderungen am Slot testen.

Löschen eines Slots

Suchen Sie nach Ihrer App, und wählen Sie sie aus. Wählen Sie Bereitstellungsslots><zu löschender Slot>>Übersicht aus. Der App-Typ lautet App Service (Slot) und soll Sie daran erinnern, dass Sie einen Bereitstellungsslot sehen. Stellen Sie vor dem Löschen eines Slots sicher, dass Sie den Slot beenden und den Datenverkehr im Slot auf 0 (Null) festlegen. Wählen Sie auf der Befehlsleiste die Option Löschen aus.

Löschen eines Bereitstellungsslots

Automatisieren mit PowerShell

Hinweis

Es wird empfohlen, das Azure Az PowerShell-Modul für die Interaktion mit Azure zu verwenden. Informationen zu den ersten Schritten finden Sie unter Installieren des Azure Az PowerShell-Moduls. Informationen zum Migrieren zum Az PowerShell-Modul finden Sie unter Migrieren von Azure PowerShell von AzureRM zum Az-Modul.

Azure PowerShell ist ein Modul, das Cmdlets für die Verwaltung von Azure über Windows PowerShell bietet, einschließlich Unterstützung der Verwaltung von Bereitstellungsslots für Azure App Service.

Informationen zum Installieren und Konfigurieren von Azure PowerShell sowie zur Authentifizierung von Azure PowerShell mit Ihrem Azure-Abonnement finden Sie unter Installieren und Konfigurieren von Microsoft Azure PowerShell.

Erstellen einer Web-App

New-AzWebApp -ResourceGroupName [resource group name] -Name [app name] -Location [location] -AppServicePlan [app service plan name]

Erstellen eines Slots

New-AzWebAppSlot -ResourceGroupName [resource group name] -Name [app name] -Slot [deployment slot name] -AppServicePlan [app service plan name]

Initiieren eines Austauschs mit Vorschau (Austausch mit mehreren Phasen) und Anwenden der Konfiguration des Zielslots auf den Quellslot

$ParametersObject = @{targetSlot  = "[slot name – e.g. "production"]"}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action applySlotConfig -Parameters $ParametersObject -ApiVersion 2015-07-01

Abbrechen eines ausstehenden Austauschs (Austausch mit Vorschau) und Wiederherstellen der Konfiguration des Quellslots

Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action resetSlotConfig -ApiVersion 2015-07-01

Überführen von Bereitstellungsslots

$ParametersObject = @{targetSlot  = "[slot name – e.g. "production"]"}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action slotsswap -Parameters $ParametersObject -ApiVersion 2015-07-01

Überwachen von Austauschereignissen im Aktivitätsprotokoll

Get-AzLog -ResourceGroup [resource group name] -StartTime 2018-03-07 -Caller SlotSwapJobProcessor

Löschen eines Slots

Remove-AzResource -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots –Name [app name]/[slot name] -ApiVersion 2015-07-01

Zum Ausführen eines Slot-Tauschs vom Produktionsslot benötigt die Identität (mindestens) Berechtigungen zum Ausführen des Microsoft.Web/sites/slotsswap/Action-Vorgangs. Weitere Informationen finden Sie unter Ressourcenanbietervorgänge.

Automatisieren mit Resource Manager-Vorlagen

Azure Resource Manager-Vorlagen sind deklarative JSON-Dateien, die zur Automatisierung der Bereitstellung und Konfiguration von Azure-Ressourcen verwendet werden. Zum Austauschen von Slots mithilfe von Resource Manager-Vorlagen legen Sie zwei Eigenschaften für die Ressourcen Microsoft.Web/sites/slots und Microsoft.Web/sites fest:

buildVersion: Dies ist eine Zeichenfolgeneigenschaft, die die aktuelle Version der im Slot bereitgestellten App darstellt. Beispiele: „v1“, „1.0.0.1“ oder „2019-09-20T11:53:25.2887393-07:00“.
targetBuildVersion: Dies ist eine Zeichenfolgeneigenschaft, die angibt, welche buildVersion der Slot enthalten soll. Wenn targetBuildVersion nicht mit der aktuellen buildVersion identisch ist, wird der Austauschvorgang dadurch ausgelöst, dass der Slot mit der angegebenen buildVersion ermittelt wird.

Beispiel einer Resource Manager-Vorlage

Mit der folgenden Resource Manager-Vorlage werden die buildVersion des Stagingslots aktualisiert und die targetBuildVersion für den Produktionsslot festgelegt. Dadurch werden die beiden Slots ausgetauscht. Die Vorlage geht davon aus, dass Sie bereits eine Web-App mit einem Slot mit dem Namen „staging“ erstellt haben.

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "my_site_name": {
            "defaultValue": "SwapAPIDemo",
            "type": "String"
        },
        "sites_buildVersion": {
            "defaultValue": "v1",
            "type": "String"
        }
    },
    "resources": [
        {
            "type": "Microsoft.Web/sites/slots",
            "apiVersion": "2018-02-01",
            "name": "[concat(parameters('my_site_name'), '/staging')]",
            "location": "East US",
            "kind": "app",
            "properties": {
                "buildVersion": "[parameters('sites_buildVersion')]"
            }
        },
        {
            "type": "Microsoft.Web/sites",
            "apiVersion": "2018-02-01",
            "name": "[parameters('my_site_name')]",
            "location": "East US",
            "kind": "app",
            "dependsOn": [
                "[resourceId('Microsoft.Web/sites/slots', parameters('my_site_name'), 'staging')]"
            ],
            "properties": {
                "targetBuildVersion": "[parameters('sites_buildVersion')]"
            }
        }        
    ]
}

Diese Resource Manager-Vorlage ist idempotent – das bedeutet, dass sie wiederholt ausgeführt werden kann und dabei denselben Zustand der Slots erzeugt. Nach der ersten Ausführung entspricht targetBuildVersion der aktuellen buildVersion, sodass kein Austausch ausgelöst wird.

Automatisieren mithilfe der Befehlszeilenschnittstelle

Informationen zu Befehlen der Azure CLI für Bereitstellungsslots finden Sie unter az webapp deployment slot.

Behandeln von Problemen beim Austausch

Sollte bei einem Slotaustausch ein Fehler auftreten, wird er in D:\home\LogFiles\eventlog.xml protokolliert. Darüber hinaus wird der Fehler auch im anwendungsspezifischen Fehlerprotokoll protokolliert.

Im Anschluss folgen einige allgemeine Austauschfehler:

Eine HTTP-Anforderung an den Anwendungsstamm ist zeitgesteuert. Der Austauschvorgang wartet bei jeder HTTP-Anforderung 90 Sekunden und führt bis zu fünf Wiederholungen durch. Sollte bei allen Wiederholungen ein Timeout auftreten, wird der Austauschvorgang beendet.
Die Initialisierung des lokalen Caches ist möglicherweise nicht erfolgreich, wenn die App-Inhalte das für den lokalen Cache angegebene Kontingent des lokalen Datenträgers übersteigen. Weitere Informationen finden Sie in der Übersicht über den lokalen Cache von Azure App Service.
Während der benutzerdefinierten Aufwärmphase werden die HTTP-Anforderungen intern (also nicht über die externe URL) ausgeführt. Sie sind möglicherweise nicht erfolgreich, wenn web.config bestimmte URL Rewrite-Regeln enthält. So können beispielsweise Regeln zur Umleitung von Domänennamen oder zur Erzwingung von HTTPS dazu führen, dass vorbereitende Anforderungen den App-Code nicht erreichen. Ändern Sie zur Umgehung dieses Problems Ihre Rewrite-Regeln, indem Sie die beiden folgenden Bedingungen hinzufügen:
```
<conditions>
  <add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
  <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
  ...
</conditions>
```
Auch ohne benutzerdefinierte Aufwärmphase können HTTP-Anforderungen durch die URL Rewrite-Regel blockiert werden. Ändern Sie zur Umgehung dieses Problems Ihre Rewrite-Regeln, indem Sie die folgende Bedingung hinzufügen:
```
<conditions>
  <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
  ...
</conditions>
```
Nach einem Slotaustausch kann es bei der App zu unerwarteten Neustarts kommen. Der Grund hierfür ist, dass die Konfiguration der Hostnamenbindung nach einem Austausch nicht mehr synchron ist, was als alleiniger Umstand aber nicht zu Neustarts führt. Bestimmte zugrunde liegende Speicherereignisse (z. B. Speichervolume-Failover) können diese Abweichungen erkennen und einen Neustart aller Workerprozesse erzwingen. Um diese Arten von Neustarts zu minimieren, legen Sie die App-Einstellung WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1auf Alle Slots fest. Diese App-Einstellung funktioniert allerdings nicht mit WCF-Apps (Windows Communication Foundation).

Nächste Schritte

Blockieren des Zugriffs auf produktionsfremde Slots

Einrichten von Stagingumgebungen in Azure App Service

Hinzufügen eines Slots

Was geschieht bei einem Austausch?

Schritte bei einem Austausch

Welche Einstellungen werden ausgetauscht?

Austauschen von zwei Slots

Mit Vorschau austauschen (Austausch mit mehreren Phasen)

Ausführen eines Rollbacks für einen Austausch

Konfigurieren des automatischen Austauschs

Angeben der benutzerdefinierten Aufwärmphase

Überwachen eines Austauschs

Weiterleiten von Datenverkehr

Automatisches Weiterleiten von Produktionsdatenverkehr

Manuelles Weiterleiten von Produktionsdatenverkehr

Löschen eines Slots

Automatisieren mit PowerShell

Erstellen einer Web-App

Erstellen eines Slots

Initiieren eines Austauschs mit Vorschau (Austausch mit mehreren Phasen) und Anwenden der Konfiguration des Zielslots auf den Quellslot

Abbrechen eines ausstehenden Austauschs (Austausch mit Vorschau) und Wiederherstellen der Konfiguration des Quellslots

Überführen von Bereitstellungsslots

Überwachen von Austauschereignissen im Aktivitätsprotokoll

Löschen eines Slots

Automatisieren mit Resource Manager-Vorlagen

Beispiel einer Resource Manager-Vorlage

Automatisieren mithilfe der Befehlszeilenschnittstelle

Behandeln von Problemen beim Austausch

Nächste Schritte

Zusätzliche Ressourcen

Zusätzliche Ressourcen