Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Hinweis
Ab dem 1. Juni 2024 können neu erstellte App Service-Apps einen eindeutigen Standardhostnamen mit der Namenskonvention <app-name>-<random-hash>.<region>.azurewebsites.net erstellen. Vorhandene App-Namen bleiben unverändert. Zum Beispiel:
myapp-ds27dh7271aah175.westus-01.azurewebsites.net
Weitere Informationen finden Sie unter Eindeutiger Standardhostname für App Service-Ressourcen.
Wenn Sie Ihre Web-App, Web-App unter Linux, Ihr mobiles Back-End oder Ihre API-App in Azure App Service bereitstellen, können Sie einen separaten Bereitstellungsslot anstelle des Standardproduktionsslots verwenden. Dieser Ansatz ist verfügbar, wenn die Ausführung in der App Service-Planebene Standard, Premium oder App Service (isoliert) erfolgt. 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 sie 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 des Slots erst nach einer Anlaufzeit in den Produktionsslot verschoben werden. Durch diesen Ansatz werden Downtimes vermieden, wenn Sie Ihre App bereitstellen. Die Datenverkehrsumleitung ist nahtlos. Aufgrund von Swap-Vorgängen werden keine Anforderungen verworfen. 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. Wenn Ihre App beispielsweise mehr als fünf Slots enthält, können Sie sie nicht auf die Standardebene skalieren. Die Standardebene unterstützt nur fünf Bereitstellungsslots.
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 Slotvorgang durchzuführen, finden Sie unter Ressourcenanbietervorgänge. Suchen Sie beispielsweise 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.
Klicken Sie im linken Bereich auf Bereitstellung>Bereitstellungsslots>Hinzufügen.
Hinweis
Wenn sich die App noch nicht in der Ebene Standard, Premium oder App Service (isoliert) befindet, wählen Sie Upgrade aus. Wechseln Sie zur Registerkarte Skalieren Ihrer App, 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.
Nachdem Sie die Einstellungen eingegeben haben, wählen Sie 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 anzeigen, wird der App-Name als <app-name>/<slot-name> angezeigt. Der App-Typ entspricht App Service (Slot). 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. Visual Studio kann das Profil importieren, um Inhalte im Slot bereitzustellen.
Die URL des Slot hat das Format http://sitename-slotname.azurewebsites.net. Um die URL-Länge innerhalb der erforderlichen DNS-Grenzwerte zu halten, wird der Websitename bei 40 Zeichen abgeschnitten. Der Websitename und der Slotname müssen zusammen kürzer als 59 Zeichen sein.
Was geschieht bei einem Austausch?
Schritte bei einem Austausch
Wenn Sie zwei Slots austauschen, führt App Service die folgenden Schritte aus, um sicherzustellen, dass im Zielslot keine Downtimes auftreten:
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 stellt diese Aktion das Ende der ersten Phase dar. Der Tauschvorgang wird angehalten. Sie können überprüfen, ob der Quellslot ordnungsgemäß mit den Einstellungen des Zielslots 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
Ihre vorherigen Produktionsinstanzen werden nach diesem Tauschvorgang in die Stagingphase verschoben. Diese Instanzen werden im letzten Schritt des Tauschvorgangs wiederverwendet. 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. Einige Konfigurationselemente folgen bei einem Tausch dem Inhalt (nicht slotspezifisch). Andere Konfigurationselemente bleiben nach einem Tausch (slotspezifisch) im selben Slot. 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
Um Einstellungen tauschbar zu machen, fügen Sie die App-Einstellung WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS in jedem Slot der App hinzu und legen 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. Diese Außerkraftsetzungs-App-Einstellung wirkt sich nicht auf sie aus.
Bestimmte App-Einstellungen, die für nicht ausgetauschte Einstellungen gelten, werden ebenfalls nicht ausgetauscht. Da die Diagnoseeinstellungen 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.
Um eine App-Einstellung oder Verbindungszeichenfolge so zu konfigurieren, dass sie in einem bestimmten Slot bleibt, der nicht getauscht wird, wechseln Sie zur Seite Einstellungen>Umgebungsvariablen für diesen Slot. Aktivieren Sie nach dem Hinzufügen oder Bearbeiten einer Einstellung das Kontrollkästchen Bereitstellungssloteinstellung. Wenn Sie diese Option auswählen, 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. Weitere Informationen zum Slottausch finden Sie unter Was passiert während eines Tauschs?.
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 geändert werden sollen.
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. Anschließend können Sie die Slots sofort austauschen, indem Sie auf Austauschen klicken.
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.
Wenn Sie fertig sind, wählen Sie 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.
Wenn Phase 1 abgeschlossen ist, werden Sie über das Dialogfeld darüber benachrichtigt. 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.
Wenn Sie fertig sind, wählen Sie 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. Klicken Sie auf Bereitstellung>Bereitstellungsslots><Gewünschter Quellslot>.
Wählen Sie im linken Bereich Einstellungen>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 Tausch erfolgt nach kurzer Zeit. Das Update zeigt sich anhand der URL Ihres Zielslots.
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 Initialisierungsaktionen angeben. Der Austausch mit dem Zielslot erfolgt dann erst nach Abschluss dieser benutzerdefinierten Aufwärmphase. Hier finden Sie ein web.config-Beispielfragment.
<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 mithilfe der folgenden 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. z. B.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 Konfigurationselement <applicationInitialization> ist Teil jeder App-Startseite, während die 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 Web-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.
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 oder bis die Cookies gelöscht werden an diesen Slot angeheftet. 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, weisen das Cookie x-ms-routing-name=staging auf. 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. Diese Option ist hilfreich, wenn Sie es den Benutzenden 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. Diese Konfiguration 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 Bereitstellung>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 bereitgestellten Anwendung angibt. Beispiel:v1,1.0.0.1oder2019-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 für den Produktionsslot einstellen. Sie müssen über einen Slot namens staging verfügen.
{
"$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. Sie können sie wiederholt ausführen und denselben Zustand der Slots erzeugen. 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 unter D:\home\LogFiles\eventlog.xml angezeigt. 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 eines Websiteaktualisierungsvorgangs kann der folgende Fehler auftreten: Der Slot kann nicht geändert werden, weil seine Konfigurationseinstellungen für den Austausch vorbereitet wurden. Dieser Fehler kann auftreten, wenn Phase 1 des Austauschs mit Vorschau (Austausch mit mehreren Phasen) abgeschlossen ist, Phase 2 jedoch noch nicht ausgeführt wurde. Er kann auch auftreten, wenn 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 Vorschau (Austausch mit mehreren Phasen).
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. Die Neustarts treten auf, da nach einem Tausch die Konfiguration der Hostnamenbindung nicht mehr synchronisiert wird. Diese Situation selbst verursacht keine Neustarts. Bestimmte zugrunde liegende Speicherereignisse (z. B. Speichervolumefailover) 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).