Einrichten von Stagingumgebungen in Azure App Service

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 Ihrer Anwendung auf einem nicht produktiven Slot hat die folgenden 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.

Dieses Video zeigt Ihnen die Einrichtung von Stagingumgebungen in Azure App Service.

Die Schritte im Video werden auch in den folgenden Abschnitten beschrieben.

Voraussetzungen

Informationen zu den Berechtigungen, die Sie benötigen, um den gewünschten Slot-Vorgang durchzuführen, finden Sie unter Vorgänge des Ressourcenanbieters (suchen Sie z. B. nach Slot).

Hinzufügen eines Slots

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

az webapp deployment slot create --name <app-name> --resource-group <group-name> --slot <slot-name>

New-AzWebAppSlot -ResourceGroupName <group-name> -Name <app-name> -Slot <slot-name> -AppServicePlan <plan-name>

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 Slot hat das Format http://sitename-slotname.azurewebsites.net. Um die Länge der URL innerhalb der erforderlichen DNS-Grenzen zu halten, wird der Name der Website auf 40 Zeichen gekürzt, und der kombinierte Name der Website und des Slots muss weniger als 59 Zeichen lang sein.

Was geschieht bei einem Austausch?

Schritte bei einem Austausch

Wenn Sie zwei Slots austauschen (in der Regel von einem Stagingslot als Quelle in einen Produktionsslot als Ziel), werden in App Service folgende Schritte ausgeführt, um Downtime im Zielslot zu verhindern:

1. 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)

   Wenn eine der Einstellungen auf den Quell-Slot angewendet wird, löst die Änderung einen Neustart aller Instanzen im Quell-Slot aus. 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.

2. 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.

3. 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.

4. Wenn Automatisch tauschen mit benutzerdefinierter Aufwärmphase aktiviert ist, löst App Service die benutzerdefinierte Anwendungsinitiierung für jede Instanz des Quellslots aus.

   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.

5. 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).

6. 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 gegen 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.

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:

• Sprachstapel und Version, 32/64 Bit
• App-Einstellungen (können so konfiguriert werden, dass sie beim Slot verbleiben)
• Verbindungszeichenfolgen (können so konfiguriert werden, dass sie beim Slot verbleiben)
• Eingebundene Speicherkonten (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:

• Allgemeine Einstellungen, die unter Einstellungen, die ausgetauscht werden, nicht erwähnt wurden
• 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 und zugehörige Einstellungen
• Einstellungen, die mit dem Suffix „_EXTENSION_VERSION“ enden
• Von Dienstconnector erstellte Einstellungen

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. Wenn Sie dieses Kontrollkästchen aktivieren, wird App Service mitgeteilt, dass die Einstellung nicht ausgetauscht werden kann.

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?.

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>"

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.

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production --action preview

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production --action swap

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production --action reset

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>" -SwapWithPreviewAction ApplySlotConfig

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>" -SwapWithPreviewAction CompleteSlotSwap

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>" -SwapWithPreviewAction ResetSlotSwap

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

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

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.

az webapp deployment slot auto-swap --name <app-name> --resource-group <group-name> --slot <source-slot-name>

az webapp deployment slot auto-swap --name <app-name> --resource-group <group-name> --slot <source-slot-name> --disable

Set-AzWebAppSlot -ResourceGroupName "<group-name>" -Name "<app-name>" -Slot "<source-slot-name>" -AutoSwapSlotName "production"

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 /.

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.

az monitor activity-log list --resource-group <group-name> --query "[?contains(operationName.value,'Microsoft.Web/sites/slots/slotsswap/action')]"

Get-AzLog -ResourceGroup <group-name> -StartTime 2023-07-07 | where{$_.OperationName -eq 'Swap Web App Slots'}

Automatisches Weiterleiten von Produktionsdatenverkehr

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.

az webapp traffic-routing set --resource-group <group-name> --name <app-name> --distribution <slot-name>=15

Add-AzWebAppTrafficRouting -ResourceGroupName "<group-name>" -WebAppName "<app-name>" -RoutingRule @{ActionHostName='<app-name>-<slot-name>.azurewebsites.net';ReroutePercentage='15';Name='<slot-name>'}

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.

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 sich Benutzer für Ihre Beta-Anwendung anmelden können, setzen Sie denselben Abfrageparameter auf den Namen des nicht produktiven Slots. 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

az webapp deployment slot delete --name <app-name> --resource-group <group-name> --slot <slot-name>

Remove-AzWebAppSlot -ResourceGroupName "<group-name>" -Name "<app-name>" -Slot "<slot-name>"

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. Um Slots mit Hilfe von Ressource Manager-Vorlagen zu tauschen, 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 installierten Anwendung angibt. 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 die targetBuildVersion nicht mit der aktuellen buildVersion übereinstimmt, wird der Tauschvorgang ausgelöst, indem der Slot mit der angegebenen buildVersion gesucht wird.

Beispiel einer Resource Manager-Vorlage

Mit der folgenden Ressource Manager-Vorlage tauschen Sie zwei Slots, indem Sie die buildVersion des Slots staging aktualisieren und die targetBuildVersion auf dem Produktionsslot einstellen. Es wird angenommen, dass Sie einen Slot namens 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. Ohne eine Änderung der Vorlage lösen nachfolgende Durchläufe derselben Vorlage keinen Slot-Tausch aus, da sich die Slots bereits im gewünschten Zustand befinden.

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 Tauschvorgang wartet 90 Sekunden lang auf jede HTTP-Anforderung und versucht es bis zu fünf Mal erneut. 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 einer Standortaktualisierung kann der folgende Fehler auftreten: „Der Steckplatz kann nicht geändert werden, weil die Konfigurationseinstellungen für den Austausch vorbereitet wurden“. Dies kann auftreten, wenn entweder ein Austausch mit der Vorschauphase (Mehrphasenaustausch) der Phase 1 abgeschlossen wurde, doch Phase 2 noch nicht ausgeführt wurde oder ein Austausch fehlgeschlagen ist. Es gibt zwei Möglichkeiten, dieses Problem zu beheben:

  1. Abbrechen des Austauschvorgangs, wodurch die Website wieder in den alten Zustand zurückversetzt wird
  2. Abschließen des Austauschvorgangs, wodurch die Website auf den gewünschten neuen Zustand aktualisiert wird

  Informationen zum Abbrechen oder Abschließen des Austauschvorgangs finden Sie unter Austausch mit der Vorschauphase (Mehrphasenaustausch).

• 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 nicht-produktive Slots