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.
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 Sie die Stufe "Standard", "Premium" oder "Isoliert" eines App Service-Plans ausführen. 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 überprüfen, bevor Sie den Slot in die Produktionsumgebung verschieben.
Sie können sicherstellen, dass alle Instanzen des Slots aufgewärmt sind, bevor Sie ihn in die Produktionsumgebung verschieben. 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.
Für die Nutzung von Bereitstellungsslots fallen keine zusätzlichen Gebühren an. Jeder App Service-Plantarif unterstützt eine andere Anzahl von Bereitstellungsslots. Informationen zur Anzahl der Slots, die die App-Ebene unterstützt, finden Sie unter App Service-Grenzwerte.
Um Ihre App auf eine andere Ebene zu skalieren, stellen Sie sicher, dass die Zielebene die Anzahl der Slots unterstützt, 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 Stufe "Standard" unterstützt nur fünf Bereitstellungsplätze.
Das folgende Video ergänzt die Schritte in diesem Artikel, indem veranschaulicht wird, wie Stagingumgebungen in Azure App Service eingerichtet werden.
Voraussetzungen
- Berechtigungen zum Ausführen der gewünschten Slot-Operation. Informationen zu den erforderlichen Berechtigungen finden Sie unter Ressourcenanbietervorgänge. Suchen Sie beispielsweise nach slot.
Hinzufügen eines Slots
Damit Sie mehrere Bereitstellungsplätze aktivieren können, muss die App auf der Stufe "Standard", "Premium" oder "Isoliert" ausgeführt werden.
Wechseln Sie im Azure-Portal zur Verwaltungsseite Ihrer App.
Wählen Sie im linken Menü Bereitstellung>Bereitstellungsplätze aus. Wählen Sie dann Hinzufügen aus.
Hinweis
Wenn sich die App noch nicht auf der Stufe "Standard", "Premium" oder "Isoliert" befindet, wählen Sie "Upgrade" aus. Wechseln Sie zur Registerkarte Skalieren Ihrer App, bevor Sie fortfahren.
Geben Sie im Dialogfeld " Steckplatz hinzufügen " dem Steckplatz einen Namen, und wählen Sie aus, ob eine App-Konfiguration von einem anderen Bereitstellungsplatz geklont werden soll. 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 jetzt auf der Seite "Bereitstellungsplätze" angezeigt. Standardmäßig ist traffic % für den neuen Steckplatz auf 0 festgelegt, wobei der gesamte Kundenverkehr an den Produktionsplatz weitergeleitet wird.
Wählen Sie den neuen Bereitstellungsplatz aus, um seine Ressourcenseite 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 und der Slot-Name in der URL 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 Steckplatzes die App-URL aus. Der Bereitstellungsslot besitzt einen eigenen Hostnamen und ist außerdem eine Live-App. Informationen zum Einschränken des öffentlichen Zugriffs auf den Bereitstellungsplatz finden Sie unter Einrichten von Zugriffsbeschränkungen für Azure App Service.
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. Der Artikel Abruf eines Veröffentlichungsprofils aus Azure App Service kann die erforderlichen Informationen für die Bereitstellung des Slot bereitstellen. 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.
Verstehen, was während eines Tauschs passiert
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 die kontinuierliche Bereitstellung , falls aktiviert
- App Service-Authentifizierungseinstellungen , falls aktiviert
Wenn eine der Einstellungen auf den Quell-Slot angewendet wird, löst die Änderung einen Neustart aller Instanzen im Quell-Slot aus. Bei Mit Vorschau austauschen 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 der lokale Cache aktiviert ist, lösen Sie die initialisierung des lokalen Caches aus, indem Sie für jede Instanz des Quellplatzes eine HTTP-Anforderung an den Anwendungsstamm (
/) vornehmen. 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 der automatische Swap mit benutzerdefiniertem Warmup aktiviert ist, triggere die benutzerdefinierte Anwendungsinitialisierung für jede Instanz des Quell-Slots.
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.
Wenn alle Instanzen im Quellslot erfolgreich aufgewärmt wurden, vertauschen Sie die beiden Slots, indem Sie deren Routingregeln ändern. Nach diesem Schritt befindet sich die App, die zuvor im Quellslot vorbereitet wurde, im Zielslot (also beispielsweise im Produktionsslot).
Nachdem der Quellplatz über die Vorab-Swap-App verfügt, die sich zuvor im Zielplatz befand, führen Sie denselben Vorgang aus, indem Sie alle Einstellungen anwenden und die Instanzen neu starten.
An jedem Punkt des Swapvorgangs erfolgt die Initialisierung der getauschten Apps im Quellplatz. 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
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. Stellen Sie sicher, dass Der Anwendungscode fehlertolerant geschrieben wird.
Schritte, um einen Steckplatz nicht tauschbar zu machen
Wenn Sie eine Konfiguration von einem anderen Bereitstellungsslot klonen, kann die geklonte Konfiguration bearbeitet werden. Einige Konfigurationselemente folgen dem Inhalt über einen Austausch hinweg (sie sind nicht slot-spezifisch). Andere Konfigurationselemente bleiben nach einem Tausch im selben Steckplatz (sie sind slotspezifisch).
Wenn Sie Steckplätze tauschen, werden diese Einstellungen getauscht:
- Sprachstapel und Version, 32 Bit und 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 (aktuell)
- Serviceendpunkte (aktuell)
- Azure Content Delivery Network (derzeit)
- Pfadzuordnungen
- Integration in ein virtuelles Netzwerk
Wenn Sie Steckplätze austauschen, werden diese Einstellungen nicht getauscht:
- Allgemeine Einstellungen, die in der vorherigen Liste nicht erwähnt werden
- Veröffentlichungsendpunkte
- Benutzerdefinierte Domänennamen
- Nicht-öffentliche Zertifikate und TLS/SSL-Einstellungen
- Skalierungseinstellungen
- WebJobs-Planer
- IP-Einschränkungen
- Immer eingeschaltet
- Diagnoseeinstellungen
- Ressourcenfreigabe zwischen verschiedenen Ursprüngen (Cross-Origin Resource Sharing, CORS)
- Verwaltete Identitäten und zugehörige Einstellungen
- Einstellungen, die mit dem Suffix
_EXTENSION_VERSIONenden - Einstellungen, die Service Connector erstellt hat
Hinweis
Um Einstellungen auszutauschen, fügen Sie die App-Einstellung WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS in jedem Slot der App hinzu. Legen Sie den Wert auf 0 oder false. Die Einstellungen sind entweder alle austauschbar oder alle nicht austauschbar. 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 z. B. Diagnoseeinstellungen nicht ausgetauscht werden, werden verwandte App-Einstellungen wie WEBSITE_HTTPLOGGING_RETENTION_DAYS und DIAGNOSTICS_AZUREBLOBRETENTIONDAYS auch nicht ausgetauscht, auch wenn sie nicht als Sloteinstellungen angezeigt werden.
So konfigurieren Sie eine App-Einstellung oder Verbindungszeichenfolge so, dass sie an einem bestimmten Steckplatz bleibt, der nicht getauscht wird:
Wechseln Sie zu Einstellungen>Umgebungsvariable für diesen 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 vertauschbar ist.
Wählen Sie Anwenden.
Austauschen von Bereitstellungsslots
Bereitstellungsslots können auf der Seite Bereitstellungsslots Ihrer App sowie auf der Seite Übersicht ausgetauscht werden.
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.
Wählen Sie auf der Seite Bereitstellungsslots Ihrer App die Option Austauschen aus.
Der Dialog 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 außerdem die Registerkarte "Quellplatzänderungen" und die Registerkarte "Zielplatzänderungen" aus, und überprüfen Sie, ob die Konfigurationsänderungen den Erwartungen entsprechen. Wenn Sie fertig sind, können Sie die Slots sofort tauschen, indem Sie "Tausch starten" auswählen.
Wenn Sie sehen möchten, wie ihr Zielplatz mit den neuen Einstellungen ausgeführt wird, bevor der Tausch erfolgt, wählen Sie " Tausch starten" nicht aus. Folgen Sie den Anweisungen in „Swap with preview“ weiter unten in diesem Artikel.
Wählen Sie Schließen aus, um das Dialogfeld zu schließen.
Wenn Probleme auftreten, lesen Sie die Problembehandlung bei Swaps weiter unten in diesem Artikel.
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
Sie können "Swap with preview" nicht verwenden, wenn die Websiteauthentifizierung in einem der Steckplätze aktiviert ist.
Führen Sie die Schritte im Abschnitt Austauschen von Bereitstellungsslots aus, aktivieren Sie dabei jedoch die Option Austausch mit Vorschau ausführen.
Das Dialogfeld zeigt, wie sich die Konfiguration im Quellplatz in der ersten Phase ändert und wie sich der Quell- und Zielplatz in der zweiten Phase ändert.
Wenn Sie so weit sind, wählen Sie Austausch starten aus.
Wenn die erste Phase abgeschlossen ist, benachrichtigt Sie das Dialogfeld.
Wenn Sie bereit sind, den ausstehenden Tausch abzuschließen, wählen Sie "Tausch abschließen" aus, und wählen Sie dann die Schaltfläche "Tausch abschließen" aus.
Um einen ausstehenden Tausch abzubrechen, wählen Sie stattdessen "Tausch abbrechen " und dann die Schaltfläche " Tausch abbrechen" aus .
Wenn Sie fertig sind, wählen Sie "Schließen " aus, um das Dialogfeld zu schließen.
Wenn Probleme auftreten, lesen Sie die Problembehandlung bei Swaps weiter unten in diesem Artikel.
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.
Hinweis
Der automatische Swap wird in Web-Apps unter Linux und in Web App für Container nicht unterstützt.
Bevor Sie den automatischen Swap für den Produktionsplatz konfigurieren, sollten Sie ihn auf einem Nichtproduktionszielplatz testen.
Navigieren Sie zur Ressourcenseite Ihrer App. Wählen Sie Bereitstellung>Bereitstellungsslots aus, und wählen Sie dann den gewünschten Quellslot aus.
Wählen Sie im linken Menü Einstellungen>Konfiguration>Allgemeine Einstellungen aus.
Legen Sie Automatischer Tausch aktiviert auf Ein fest. Wählen Sie als Bereitstellungsslot für automatischen Tausch den Zielslot aus. Wählen Sie dann auf der Befehlsleiste "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.
Wenn Probleme auftreten, lesen Sie die Problembehandlung bei Swaps weiter unten in diesem Artikel.
Angeben der benutzerdefinierten Aufwärmphase
Für einige Apps müssen vor dem Austausch unter Umständen benutzerdefinierte Vorbereitungsschritte ausgeführt werden. Sie können diese benutzerdefinierten Aktionen mithilfe des applicationInitialization-Konfigurationselements in Web.config angeben. Der Austausch mit dem Zielslot erfolgt dann erst nach Abschluss dieser benutzerdefinierten Aufwärmphase. Hier ist ein Beispielfragment: 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 im Blogbeitrag Die häufigsten Probleme beim Wechseln von Bereitstellungs-Slots und wie man sie behebt.
Sie können das Warmupverhalten auch 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. Wenn der zurückgegebene Statuscode nicht in der Liste enthalten ist, werden die Warmup- und Swapvorgä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/.
Das <applicationInitialization> Konfigurationselement ist Teil jedes Applikationsstarts, während die Einstellungen für das Aufwärmverhalten nur bei Slotwechseln gelten.
Wenn Probleme auftreten, lesen Sie die Problembehandlung bei Swaps weiter unten in diesem Artikel.
Überwachen eines Austauschs
Bei länger dauernden Austauschvorgängen können Sie sich anhand des Aktivitätsprotokolls über den Austauschvorgang informieren.
Wählen Sie auf der Ressourcenseite Ihrer App im Portal im linken Menü " Aktivitätsprotokoll" aus.
Ein Austauschvorgang wird in der Protokollabfrage als
Swap Web App Slotsangezeigt. Um die Details anzuzeigen, können Sie sie erweitern und eine der Unteroperationen oder Fehler auswählen.
Automatisches Weiterleiten von Produktionsdatenverkehr
Standardmäßig werden alle Clientanforderungen an die Produktions-URL der App an den Produktionsplatz weitergeleitet. Sie können einen Teil des Datenverkehrs an einen anderen Slot weiterleiten. Dieses Feature ist nützlich, wenn Sie Benutzerfeedback für ein neues Update benötigen, aber nicht bereit sind, es in der Produktion freizugeben.
Wechseln Sie zur Ressourcenseite Ihrer Web-App und wählen Sie Bereitstellung>Bereitstellungsplätze aus.
Geben Sie in der Spalte "Datenverkehr % " des Steckplatzes, zu dem Sie weiterleiten möchten, einen Prozentsatz (zwischen 0 und 100) an, der die Gesamtmenge des Datenverkehrs darstellt, den Sie weiterleiten möchten. Klicken Sie dann auf Speichern.
Nachdem Sie die Einstellung gespeichert haben, wird der angegebene Prozentsatz der Clients zufällig an den Nichtproduktionsplatz weitergeleitet.
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. Eine Anforderung, die an den Staging-Slot weitergeleitet wird, hat 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. 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 weisen neue Steckplätze eine Routingregel auf 0%, die in Grau angezeigt wird. 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 nicht automatisch zum Slot weitergeleitet, da der Routenanteil auf 0 eingestellt 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 wird als App-Dienst (Slot) angezeigt, um Sie daran zu erinnern, dass Sie einen Bereitstellungsplatz anzeigen.
Beenden Sie den Slot und setzen Sie den Datenverkehr im Slot auf Null.
Wählen Sie in der Befehlsleiste Löschen aus.
Automatisieren mit Resource Manager-Vorlagen
Azure Resource Manager-Vorlagen sind deklarative JSON-Dateien zum Automatisieren der Bereitstellung und Konfiguration von Azure-Ressourcen. Zum Austauschen von Slots mithilfe von Ressourcen-Manager-Vorlagen legen Sie zwei Eigenschaften für die Microsoft.Web/sites/slots Und Microsoft.Web/sites Ressourcen 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: Eine Zeichenfolgeneigenschaft, die angibt, über welchenbuildVersionWert der Steckplatz verfügen soll. Wenn dertargetBuildVersionWert nicht dem aktuellenbuildVersionWert entspricht, löst er den Swapvorgang aus, indem er den Steckplatz mit dem angegebenenbuildVersionWert findet.
Beispiel einer Resource Manager-Vorlage
Mit der folgenden Ressourcen-Manager-Vorlage werden zwei Steckplätze ausgetauscht, indem der buildVersion Wert des staging Steckplatzes aktualisiert und der targetBuildVersion Wert für den Produktionsplatz festgelegt wird. 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
Wenn während eines Steckplatztauschs ein Fehler auftritt, erscheint der Fehler in D:\home\LogFiles\eventlog.xml. 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 Swap-Vorgang wartet 90 Sekunden lang auf jede HTTP-Anforderung und versucht es bis zu fünfmal neu. Sollte bei allen Wiederholungen ein Timeout auftreten, wird der Austauschvorgang beendet.
Die Initialisierung des lokalen Caches könnte fehlschlagen, wenn der Anwendungsinhalt das für den lokalen Cache angegebene Datenträgerkontingent überschreitet. Weitere Informationen finden Sie in der Übersicht über den lokalen Cache von Azure App Service.
Während eines Aktualisierungsvorgangs der Website kann der folgende Fehler auftreten: "Der Slot kann nicht geändert werden, da die Konfigurationseinstellungen für den Tausch vorbereitet wurden." Dieser Fehler kann auftreten, wenn die erste Phase eines mehrphasigen Tauschs abgeschlossen ist, aber die zweite Phase noch nicht eingetreten ist. Er kann auch auftreten, wenn ein Austausch fehlgeschlagen ist. Es gibt zwei Möglichkeiten, dieses Problem zu beheben:
- Abbrechen des Swapvorgangs, der die Website wieder auf den alten Zustand zurücksetzt.
- Schließen Sie den Tauschvorgang ab, der die Website auf den gewünschten neuen Zustand aktualisiert.
Informationen zum Abbrechen oder Abschließen des Swap-Vorgangs finden Sie weiter oben in diesem Artikel unter „Swap mit Vorschau (Mehrphasen-Swap)“.
Während der benutzerdefinierten Aufwärmphase werden die HTTP-Anforderungen intern (also nicht über die externe URL) ausgeführt. Bei bestimmten URL-Neuschreibregeln in
Web.configkönnen sie fehlschlagen. 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. Um dieses Problem zu umgehen, ändern Sie Ihre Neuschreibregeln, indem Sie die folgenden beiden 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. Um dieses Problem zu umgehen, ändern Sie Ihre Neuschreibregeln, 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 für die 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).