Einrichten von Stagingumgebungen in Azure App Service
Hinweis
Ab dem 1. Juni 2024 haben alle neu erstellten App Service-Apps die Möglichkeit, einen eindeutigen Standardhostnamen mit der Namenskonvention <app-name>-<random-hash>.<region>.azurewebsites.net zu erstellen. Vorhandene App-Namen bleiben unverändert.
Beispiel: myapp-ds27dh7271aah175.westus-01.azurewebsites.net
Ausführlichere Informationen finden Sie unter Eindeutiger Standardhostname für App Service-Ressourcen.
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.
Navigieren Sie im Azure-Portal zur Verwaltungsseite Ihrer App.
Wählen Sie im linken Bereich Bereitstellungsslots>Slot hinzufügen aus.
Hinweis
Wenn sich die Anwendung noch nicht im Tarif Standard, Premium oder Isoliert befindet, wählen Sie Upgrade aus und wechseln Sie zur Registerkarte Skalierung in Ihrer Anwendung, bevor Sie fortfahren.
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 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:
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.
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 benutzerdefinierte Anwendungsinitiierung für jede Instanz des Quellslots aus.
Ohne Angabe von
applicationInitializationlö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 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.
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:
- 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
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. 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?.
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.
Um einen ausstehenden Austausch abzubrechen, wählen Sie stattdessen Tausch abbrechen und dann unten Tausch 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.
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 nicht-produktiven 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/statuscheckoder 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.
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.
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.
Nachdem die Einstellung gespeichert wurde, wird der angegebene Prozentsatz der Clients nach dem Zufallsprinzip auf den nicht produktiven Slot umgeleitet.
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
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.
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, welchebuildVersionder Slot enthalten soll. Wenn dietargetBuildVersionnicht mit der aktuellenbuildVersionübereinstimmt, wird der Tauschvorgang ausgelöst, indem der Slot mit der angegebenenbuildVersiongesucht 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:
- Abbrechen des Austauschvorgangs, wodurch die Website wieder in den alten Zustand zurückversetzt wird
- 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).