Verwenden des Features für die direkte Migration zum Migrieren von App Service-Umgebung v1 und v2 zu App Service-Umgebung v3
Hinweis
Die in diesem Artikel beschriebene Migrationsfunktion wird für die automatisierte Migration von App Service-Umgebung v1 und v2 zu App Service-Umgebung v3 verwendet. Wenn Sie nach Informationen zum Feature für die parallele Migration suchen, lesen Sie Migrieren zu App Service-Umgebung v3 mithilfe des Features für die parallele Migration. Wenn Sie nach Informationen zu Optionen für die manuelle Migration suchen, lesen Sie Optionen für die manuelle Migration. Hilfe bei der Entscheidung, welche Migrationsoption für Sie geeignet ist, finden Sie unter Entscheidungsstruktur für den Migrationspfad. Weitere Informationen zu Version 3 der App Service-Umgebung finden Sie unter Übersicht über die App Service-Umgebung (Version 3).
Sie können App Service-Umgebung v1 und v2 mithilfe des Features für die direkte Migration automatisch zu App Service-Umgebung v3 migrieren. Wenn Sie mehr über den Migrationsprozess erfahren und überprüfen möchten, ob Ihre App Service-Umgebung die Migration zu diesem Zeitpunkt unterstützt, lesen Sie die Informationen in der Übersicht über das Feature für die direkte Migration.
Wichtig
Es wird empfohlen, dieses Feature für Entwicklungsumgebungen vor der Migration von Produktionsumgebungen zu verwenden, um unerwartete Probleme zu vermeiden. Senden Sie uns über die Schaltflächen am unteren Rand der Seite Feedback zu diesem Artikel oder zum Feature.
Voraussetzungen
Stellen Sie sicher, dass Sie wissen, wie sich die Migration zur App Service-Umgebung v3 auf Ihre Anwendungen auswirkt. Sehen Sie sich den Migrationsprozess an, um den zeitlichen Ablauf des Prozesses zu verstehen und zu ermitteln, wann und wo Aktionen Ihrerseits erforderlich sind. Schauen Sie sich auch die FAQs an, die Ihnen einige Ihrer Fragen beantworten können.
Vergewissern Sie sich, dass keine Sperren für Ihr virtuelles Netzwerk, Ihre Ressourcengruppe, Ihre Ressource oder Ihr Abonnement vorhanden sind. Sperren blockieren Plattformvorgänge während der Migration.
Stellen Sie sicher, dass keine Azure-Richtlinien vorhanden sind, die Aktionen blockieren, die für die Migration erforderlich sind, einschließlich Subnetzänderungen und Azure App Service-Ressourcenerstellungen. Richtlinien, die Ressourcenänderungen und Erstellungen blockieren, können dazu führen, dass die Migration hängen bleibt oder fehlschlägt.
Da die Skalierung während der Migration blockiert wird, sollten Sie Ihre Umgebung auf die gewünschte Größe skalieren, bevor Sie die Migration starten. Wenn Sie Ihre Umgebung nach der Migration skalieren müssen, können Sie dies nach Abschluss der Migration tun.
Es wird empfohlen, das Azure-Portal für die direkte Migration zu verwenden. Wenn Sie die Azure CLI für die Migration verwenden möchten, führen Sie die hier beschriebenen Schritte der Reihe nach aus, da Sie Azure-REST-API-Aufrufe ausführen. Es wird empfohlen, diese API-Aufrufe mithilfe der Azure CLI auszuführen. Informationen zu anderen Methoden finden Sie in der Azure-REST-API-Referenz.
Für dieses Handbuch können Sie die Azure CLI installieren oder Azure Cloud Shell verwenden, und verwenden Sie eine Bash-Shell.
Hinweis
Es wird empfohlen, dass Sie eine Bash-Shell verwenden, um die in diesem Handbuch angegebenen Befehle auszuführen. Die Befehle sind möglicherweise nicht mit PowerShell-Konventionen und Escapezeichen kompatibel.
1. Abrufen der ID für Ihre App Service-Umgebung
Führen Sie die folgenden Befehle aus, um die ID für Ihre App Service-Umgebung abzurufen und als Umgebungsvariable zu speichern. Ersetzen Sie die Platzhalter für den Namen und Ressourcengruppen durch Ihre Werte für die App Service-Umgebung, die Sie migrieren möchten. ASE_RG und VNET_RG sind identisch, wenn sich Ihr virtuelles Netzwerk und die App Service-Umgebung in derselben Ressourcengruppe befinden.
ASE_NAME=<Your-App-Service-Environment-name>
ASE_RG=<Your-ASE-Resource-Group>
VNET_RG=<Your-VNet-Resource-Group>
ASE_ID=$(az appservice ase show --name $ASE_NAME --resource-group $ASE_RG --query id --output tsv)
2. Überprüfen, ob die Migration unterstützt wird
Mit dem folgenden Befehl wird überprüft, ob die Migration Ihrer App Service-Umgebung unterstützt wird. Wenn Sie einen Fehler erhalten oder sich Ihre App Service-Umgebung im Zustand „Fehlerhaft“ oder „Angehalten“ befindet, können Sie sie zu diesem Zeitpunkt nicht migrieren. Eine Beschreibung der möglichen Fehlermeldungen finden Sie im Abschnitt zur Problembehandlung. Wenn für Ihre Umgebung die Migration mit dem Feature für die direkte Migration nicht unterstützt wird oder wenn Sie ohne die Parallelmigrationsfunktion zu App Service-Umgebung v3 migrieren möchten, sehen Sie sich die Optionen zur manuellen Migration an. Mit diesem Befehl wird auch überprüft, ob Ihre App Service-Umgebung die für die Migration unterstützte Buildversion verwendet. Wenn die App Service-Umgebung nicht die unterstützte Buildversion verwendet, müssen Sie das Upgrade selbst starten. Weitere Informationen zum Upgrade vor der Migration finden Sie unter Überprüfen, ob die Migration mithilfe des Features für die parallele Migration für Ihre App Service-Umgebung unterstützt wird.
az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=validation"
Wenn keine Fehler auftreten, wird Ihre Migration unterstützt, und Sie können mit dem nächsten Schritt fortfahren.
Wenn Sie ein Upgrade starten müssen, um Ihre App Service-Umgebung auf die unterstützte Buildversion zu aktualisieren, führen Sie den folgenden Befehl aus. Führen Sie diesen Befehl nur aus, wenn beim Überprüfungsschritt ein Fehler auftritt und Sie angewiesen werden, die App Service-Umgebung zu aktualisieren.
az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=PreMigrationUpgrade"
3. Generieren von IP-Adressen für Ihre neue App Service-Umgebung v3-Ressource
Führen Sie den folgenden Befehl aus, um neue IP-Adressen zu erstellen. Dieser Schritt dauert ungefähr 15 Minuten. Nehmen Sie während dieser Zeit keine Skalierung und keine Änderungen an Ihrer vorhandenen App Service-Umgebung vor.
az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=premigration"
Führen Sie den folgenden Befehl aus, um den Status dieses Schritts zu überprüfen:
az rest --method get --uri "${ASE_ID}?api-version=2021-02-01" --query properties.status
Während der Schritt ausgeführt wird, sehen Sie den Status Migrating. Wenn der Status Ready angezeigt wird, führen Sie den folgenden Befehl aus, um Ihre neuen IP-Adressen anzuzeigen. Werden die neuen IP-Adressen nicht sofort angezeigt, warten Sie einige Minuten, und versuchen Sie es noch einmal.
az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2021-02-01"
Hinweis
Aufgrund eines bekannten Fehlers kann sich die IP-Adresse für eingehenden Datenverkehr bei Migrationen einer ELB-App Service-Umgebung nach Abschluss des Migrationsschritts erneut ändern. Bereiten Sie sich darauf vor, Ihre abhängigen Ressourcen erneut mit der neuen IP-Adresse für eingehenden Datenverkehr zu aktualisieren, nachdem der Migrationsschritt abgeschlossen wurde. An diesem Fehler wird bereits gearbeitet, und er wird so bald wie möglich behoben. Öffnen Sie einen Supportfall, wenn Sie Fragen oder Bedenken hinsichtlich dieses Problems haben oder Hilfe beim Migrationsprozess benötigen.
4. Aktualisieren abhängiger Ressourcen mit neuen IP-Adressen
Aktualisieren Sie unter Verwendung der neuen IP-Adressen alle Ihrer Ressourcen oder Netzwerkkomponenten, um sicherzustellen, dass Ihre neue Umgebung nach Abschluss der Migration wie vorgesehen funktioniert. Es liegt in Ihrer Verantwortung, alle notwendigen Aktualisierungen vorzunehmen.
Dieser Schritt ist auch ein guter Zeitpunkt, um die Abhängigkeitsänderungen ein- und ausgehender Netzwerk zu überprüfen, wenn Sie zur App Service-Umgebung v3 wechseln. Zu diesen Änderungen gehören die Portänderung für Azure Load Balancer, wofür jetzt Port 80 verwendet wird. Migrieren Sie erst, wenn Sie diesen Schritt abgeschlossen haben.
5. Delegieren des Subnetzes Ihrer App Service-Umgebung
Die App Service-Umgebung v3 setzt voraus, dass das Subnetz, in dem sie sich befindet, über eine einzelne Delegierung von Microsoft.Web/hostingEnvironments verfügt. In früheren Versionen war diese Delegierung nicht erforderlich. Sie müssen bestätigen, dass Ihr Subnetz ordnungsgemäß delegiert ist, und die Delegierung (bei Bedarf) vor der Migration aktualisieren. Sie können die Delegierung entweder durch Ausführen des folgenden Befehls oder durch Navigieren zum Subnetz im Azure-Portal aktualisieren.
az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments
6. Bestätigen, dass keine Sperren für das virtuelle Netzwerk vorhanden sind
Sperren für virtuelle Netzwerke blockieren Plattformvorgänge während der Migration. Wenn für Ihr virtuelles Netzwerk Sperren vorhanden sind, müssen Sie sie vor der Migration entfernen. Bei Bedarf können Sie die Sperren nach Abschluss der Migration wieder hinzufügen.
Sperren können in drei Bereichen vorhanden sein: Abonnement, Ressourcengruppe und Ressource. Wenn Sie eine Sperre in einem übergeordneten Bereich anwenden, erben alle Ressourcen in diesem Bereich die entsprechende Sperre. Wenn Sperren im Abonnement, der Ressourcengruppe oder im Ressourcengruppenbereich angewendet sind, müssen Sie diese vor der Migration entfernen. Weitere Informationen zu Sperren und zur Vererbung von Sperren finden Sie unter Sperren von Ressourcen zum Schutz Ihrer Infrastruktur.
Verwenden Sie den folgenden Befehl, um zu überprüfen, ob für Ihr virtuelles Netzwerk Sperren vorhanden sind:
az lock list --resource-group $VNET_RG --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks
Löschen Sie alle vorhandenen Sperren mit dem folgenden Befehl:
az lock delete --resource-group $VNET_RG --name <lock-name> --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks
Informationen zu verwandten Befehlen, mit denen Sie überprüfen können, ob für Ihr Abonnement oder Ihre Ressourcengruppe Sperren vorhanden sind, finden Sie in der Azure CLI-Referenz zu Sperren.
7. Vorbereiten Ihrer Konfigurationen
Sie können Ihre neue App Service-Umgebung v3-Ressourcenzone redundant machen, wenn sich Ihre vorhandene Umgebung in einer Region befindet, die Zonenredundanz unterstützt. Die Zonenredundanz kann durch Festlegen der Eigenschaft zoneRedundant auf true konfiguriert werden.
Zonenredundanz ist eine optionale Konfiguration. Sie können sie nur während der Erstellung Ihrer neuen App Service-Umgebung v3-Ressource festlegen. Sie können sie zu einem späteren Zeitpunkt nicht entfernen. Weitere Informationen finden Sie unter Auswählen der v3-Konfigurationen der App Service-Umgebung. Wenn Sie keine Zonenredundanz konfigurieren möchten, schließen Sie den Parameter zoneRedundant nicht ein.
Wenn Ihre vorhandene App Service-Umgebung ein benutzerdefiniertes Domänensuffix verwendet, müssen Sie dieses während des Migrationsprozesses für Ihre neue App Service-Umgebung v3-Ressource konfigurieren. Die Migration schlägt fehl, wenn Sie kein benutzerdefiniertes Domänensuffix konfigurieren, derzeit jedoch eines verwenden. Die Migration schlägt auch fehl, wenn Sie während der Migration versuchen, ein benutzerdefiniertes Domänensuffix zu einer Umgebung hinzuzufügen, für die keines konfiguriert ist. Weitere Informationen zu benutzerdefinierten Domänensuffixen der App Service-Umgebung v3 (einschließlich Anforderungen, schrittweisen Anleitungen und bewährten Methoden) finden Sie unter Benutzerdefiniertes Domänensuffix für App Service-Umgebungen.
Hinweis
Wenn Sie ein benutzerdefiniertes Domänensuffix konfigurieren, stellen Sie beim Hinzufügen der Netzwerkberechtigungen für Ihre Azure Key Vault-Instanz sicher, dass Ihr Schlüsseltresor den Zugriff von den neuen ausgehenden IP-Adressen Ihrer App Service-Umgebung zulässt, die in Schritt 3 generiert wurden.
Wenn Ihre Migration kein benutzerdefiniertes Domänensuffix enthält und Sie die Zonenredundanz nicht aktivieren, können Sie mit der Migration fortfahren.
Um diese Konfigurationen festzulegen, erstellen Sie eine Datei namens parameters.json mit den folgenden Details, entsprechend Ihrem Szenario. Schließen Sie die Eigenschaften für ein benutzerdefiniertes Domänensuffix nicht ein, wenn dieses Feature nicht für Ihre Migration relevant ist. Achten Sie auf den Wert der Eigenschaft zoneRedundant, da diese Konfiguration nach der Migration nicht mehr geändert werden kann. Legen Sie den Wert der Eigenschaft kind entsprechend der Version Ihrer vorhandenen App Service-Umgebung fest. Gültige Werte für die kind-Eigenschaft sind ASEV1 und ASEV2.
Wenn Sie ohne benutzerdefiniertes Domänensuffix migrieren und Zonenredundanz aktivieren, verwenden Sie diesen Code:
{
"type": "Microsoft.Web/hostingEnvironments",
"name": "sample-ase-migration",
"kind": "ASEV2",
"location": "westcentralus",
"properties": {
"zoneRedundant": true
}
}
Wenn Sie eine benutzerseitig zugewiesene verwaltete Identität für Ihre Konfiguration des benutzerdefinierten Domänensuffixes verwenden und Zonenredundanz aktivieren, verwenden Sie diesen Code:
{
"type": "Microsoft.Web/hostingEnvironments",
"name": "sample-ase-migration",
"kind": "ASEV2",
"location": "westcentralus",
"properties": {
"zoneRedundant": true,
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
}
}
}
Wenn Sie eine systemseitig zugewiesene verwaltete Identität für Ihre Konfiguration des benutzerdefinierten Domänensuffixes verwenden und Zonenredundanz nicht aktivieren, verwenden Sie diesen Code:
{
"type": "Microsoft.Web/hostingEnvironments",
"name": "sample-ase-migration",
"kind": "ASEV2",
"location": "westcentralus",
"properties": {
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "SystemAssigned"
}
}
}
8. Migrieren zu App Service-Umgebung v3 und Überprüfen des Status
Nachdem Sie alle vorherigen Schritte durchgeführt haben, können Sie mit der Migration beginnen. Vergewissern Sie sich, dass Sie die Auswirkungen der Migration.
Dieser Schritt dauert je nach Umgebungsgröße drei bis sechs Stunden für v2-zu-v3-Migrationen und bis zu sechs Stunden für v1-zu-v3-Migrationen. Während dieser Zeit kommt es zu einer Anwendungsdowntime von ca. einer Stunde. Skalierung, Bereitstellungen und Änderungen Ihrer vorhandenen App Service-Umgebung werden während dieses Schritts blockiert.
Schließen Sie den Parameter body im folgenden Befehl ein, wenn Sie Zonenredundanz aktivieren und/oder ein benutzerdefiniertes Domänensuffix konfigurieren. Wenn keine dieser Konfigurationen auf Ihre Migration angewendet wird, können Sie den Parameter aus dem Befehl entfernen.
az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=fullmigration" --body @parameters.json
Führen Sie die folgenden Befehle aus, um den detaillierten Status Ihrer Migration zu überprüfen. Informationen zu den Status finden Sie in den Beschreibungen des Migrationsstatus.
Der erste Befehl ruft die Vorgangs-ID für die Migration ab. Kopieren Sie den Wert der Eigenschaft ID.
az rest --method get --uri "${ASE_ID}/operations?api-version=2022-03-01"
Ersetzen Sie den Platzhalter für die Vorgangs-ID im folgenden Befehl durch den kopierten Wert. Dieser Befehl gibt den detaillierten Status Ihrer Migration zurück. Sie können diesen Befehl so oft wie nötig ausführen, um den neuesten Status zu erhalten.
az rest --method get --uri "${ASE_ID}/operations/<operation-id>/details/default?api-version=2022-09-01"
Wenn der Status Ready angezeigt wird, ist die Migration abgeschlossen, und Sie verfügen über eine App Service-Umgebung v3-Ressource. Ihre Apps werden jetzt in Ihrer neuen Umgebung ausgeführt.
Führen Sie den folgenden Befehl aus, oder navigieren Sie zum Azure-Portal, um die Details Ihrer neuen Umgebung abzurufen.
az appservice ase show --name $ASE_NAME --resource-group $ASE_RG
Hinweis
Aufgrund eines bekannten Fehlers kann sich die IP-Adresse für eingehenden Datenverkehr bei Migrationen einer ELB-App Service-Umgebung nach Abschluss des Migrationsschritts ändern. Überprüfen Sie die IP-Adressen Ihrer App Service-Umgebung v3, und nehmen Sie alle erforderlichen Updates vor, wenn seit dem Schritt der IP-Generierung Änderungen vorgenommen wurden. Öffnen Sie einen Supportfall, wenn Sie Fragen oder Bedenken hinsichtlich dieses Problems haben oder Hilfe beim Bestätigen der neuen IP-Adressen benötigen.
1. Überprüfen, ob die Migration unterstützt wird
Navigieren Sie im Azure-Portal zur Seite Migration für die App Service-Umgebung, die Sie migrieren. Zum Aufrufen der Seite Migration können Sie oben auf der Seite Übersicht für Ihre App Service-Umgebung das Banner auswählen oder im linken Menü das Element Migration auswählen.
Auf der Seite Migration überprüft die Plattform, ob die Migration für Ihre App Service-Umgebung unterstützt wird. Wählen Sie Überprüfen aus, und bestätigen Sie dann, dass Sie mit der Überprüfung fortfahren möchten. Die Überprüfung dauert einige Sekunden.
Wenn Ihre Umgebung für die Migration nicht unterstützt wird, wird oben auf der Seite ein Banner mit einer Fehlermeldung und einem Grund angezeigt. Beschreibungen der Fehlermeldungen, die angezeigt werden können, wenn Sie nicht für die Migration in Frage kommen, finden Sie im Abschnitt Problembehandlung.
Wenn Ihre App Service-Umgebung zu diesem Zeitpunkt nicht für die Migration unterstützt wird oder Ihre Umgebung sich in einem fehlerhaften oder angehaltenen Zustand befindet, können Sie das Migrationsfeature nicht verwenden. Wenn für Ihre Umgebung die Migration mit dem Feature für die direkte Migration nicht unterstützt wird oder wenn Sie ohne das Migrationsfeature zu App Service-Umgebung Version 3 migrieren möchten, sehen Sie sich die Optionen zur manuellen Migration an.
Wenn Sie ein Upgrade starten müssen, um Ihre App Service-Umgebung auf die unterstützte Buildversion zu aktualisieren, werden Sie dazu aufgefordert, das Upgrade zu starten. Wählen Sie Upgrade aus, um das Upgrade zu starten. Wenn das Upgrade abgeschlossen ist, wird die Validierung bestanden und Sie können die Migrationsfunktion verwenden, um Ihre Migration zu starten.
Wenn die Migration für Ihre App Service-Umgebung unterstützt wird, fahren Sie mit dem nächsten Schritt im Prozess fort. Die Seite Migration führt Sie durch die Schritte zum Abschließen der Migration.
2. Generieren von IP-Adressen für Ihre neue App Service-Umgebung v3-Ressource
Vergewissern Sie sich unter Abrufen neuer IP-Adressen, dass Sie die Auswirkungen verstehen, und wählen Sie die Schaltfläche Starten aus. Dieser Schritt dauert ungefähr 15 Minuten. Sie können während dieser Zeit keine Skalierung und keine Änderungen an Ihrer vorhandenen App Service-Umgebung vornehmen.
3. Aktualisieren abhängiger Ressourcen mit neuen IP-Adressen
Wenn der vorherige Schritt abgeschlossen ist, werden die IP-Adressen für Ihre neue App Service-Umgebung v3-Ressource angezeigt. Aktualisieren Sie unter Verwendung der neuen IP-Adressen alle Ressourcen und Netzwerkkomponenten, damit Ihre neue Umgebung nach Abschluss der Migration wie vorgesehen funktioniert. Es liegt in Ihrer Verantwortung, alle notwendigen Aktualisierungen vorzunehmen.
Dieser Schritt ist auch ein guter Zeitpunkt, um die Abhängigkeitsänderungen ein- und ausgehender Netzwerke zu überprüfen, wenn Sie zur App Service-Umgebung v3 wechseln. Zu diesen Änderungen gehören die Portänderung für Azure Load Balancer, wofür jetzt Port 80 verwendet wird. Gehen Sie nicht zum nächsten Schritt über, bevor Sie nicht bestätigt haben, dass Sie diese Aktualisierungen vorgenommen haben.
4. Delegieren des Subnetzes Ihrer App Service-Umgebung
App Service-Umgebung v3 setzt voraus, dass das Subnetz, in dem sie sich befindet, über eine einzelne Delegierung von Microsoft.Web/hostingEnvironments verfügt. In früheren Versionen war diese Delegierung nicht erforderlich. Sie müssen bestätigen, dass Ihr Subnetz ordnungsgemäß delegiert ist, und die Delegierung (bei Bedarf) vor der Migration aktualisieren. Im Portal wird ein Link zu Ihrem Subnetz angezeigt, damit Sie nach Bedarf bestätigen und aktualisieren können.
5. Überprüfen von Änderungen an der Instanzgröße
Ihre App Service-Pläne werden von „App Service (isoliert)“ in die entsprechende Isoliert v2-Ebene konvertiert. „I2“ wird beispielsweise in „I2v2“ konvertiert. Ihre Apps sind nach der Migration möglicherweise überdimensioniert, da die Isoliert v2-Ebene mehr Arbeitsspeicher und CPU pro entsprechender Instanzgröße bietet. Nach Abschluss der Migration haben Sie die Möglichkeit, Ihre Umgebung bedarfsgerecht zu skalieren. Weitere Informationen finden Sie in den Preisdetails.
6. Sicherstellen, dass das virtuelle Netzwerk keine Sperren aufweist
Sperren für virtuelle Netzwerke blockieren Plattformvorgänge während der Migration. Wenn für Ihr virtuelles Netzwerk Sperren vorhanden sind, müssen Sie sie vor der Migration entfernen. Bei Bedarf können Sie die Sperren nach Abschluss der Migration wieder hinzufügen.
Sperren können in drei Bereichen vorhanden sein: Abonnement, Ressourcengruppe und Ressource. Wenn Sie eine Sperre in einem übergeordneten Bereich anwenden, erben alle Ressourcen in diesem Bereich die entsprechende Sperre. Wenn Sperren im Abonnement, der Ressourcengruppe oder im Ressourcengruppenbereich angewendet sind, müssen Sie diese vor der Migration entfernen. Weitere Informationen zu Sperren und zur Vererbung von Sperren finden Sie unter Sperren von Ressourcen zum Schutz Ihrer Infrastruktur.
Ausführliche Informationen zum Überprüfen, ob für Ihr Abonnement oder Ihre Ressourcengruppe Sperren vorhanden sind, finden Sie unter Konfigurieren von Sperren.
7. Auswählen Ihrer Konfigurationen
Sie können Ihre neue App Service-Umgebung v3-Ressourcenzone redundant machen, wenn sich Ihre vorhandene Umgebung in einer Region befindet, die Zonenredundanz unterstützt. Zonenredundanz ist eine optionale Konfiguration. Sie können sie nur während der Erstellung Ihrer neuen App Service-Umgebung v3-Ressource festlegen. Sie können sie zu einem späteren Zeitpunkt nicht entfernen. Weitere Informationen finden Sie unter Auswählen der v3-Konfigurationen der App Service-Umgebung.
Aktivieren Sie das Kontrollkästchen Aktiviert, wenn Sie Zonenredundanz konfigurieren möchten.
Wenn sich Ihre Umgebung in einer Region befindet, die keine Zonenredundanz unterstützt, ist das Kontrollkästchen nicht verfügbar. Wenn Sie eine zonenredundante App Service-Umgebung v3-Ressource benötigen, verwenden Sie eine der manuellen Migrationsoptionen und erstellen Sie die Ressource in einer Region, die Zonenredundanz unterstützt.
Wenn Ihre vorhandene App Service-Umgebung ein benutzerdefiniertes Domänensuffix verwendet, müssen Sie dieses für Ihre neue App Service-Umgebung v3-Ressource konfigurieren. Die Konfigurationsoptionen für ein benutzerdefiniertes Domänensuffix werden angezeigt, wenn diese Situation auf Sie zutrifft. Sie können die Migration erst durchführen, wenn Sie die erforderlichen Informationen angegeben haben.
Wenn Sie ein benutzerdefiniertes Domänensuffix verwenden möchten, aber derzeit noch keines konfiguriert haben, können Sie eines konfigurieren, nachdem die Migration abgeschlossen ist. Weitere Informationen zu benutzerdefinierten Domänensuffixen der App Service-Umgebung v3 (einschließlich Anforderungen, schrittweisen Anleitungen und bewährten Methoden) finden Sie unter Benutzerdefiniertes Domänensuffix für App Service-Umgebungen.
Hinweis
Wenn Sie ein benutzerdefiniertes Domänensuffix konfigurieren, stellen Sie beim Hinzufügen der Netzwerkberechtigungen für Ihre Azure Key Vault-Instanz sicher, dass Ihr Schlüsseltresor den Zugriff von den neuen ausgehenden IP-Adressen Ihrer App Service-Umgebung zulässt, die in Schritt 2 generiert wurden.
Nachdem Sie die Details zu Ihrem benutzerdefinierten Domänensuffix hinzugefügt haben, ist die Schaltfläche Migrieren verfügbar.
8. Migrieren zur App Service-Umgebung v3
Nachdem Sie alle vorherigen Schritte durchgeführt haben, können Sie mit der Migration beginnen. Stellen Sie sicher, dass Sie die Auswirkungen der Migration verstehen, einschließlich der Vorgänge während dieser Zeit.
Dieser Schritt dauert je nach Umgebungsgröße drei bis sechs Stunden für v2-zu-v3-Migrationen und bis zu sechs Stunden für v1-zu-v3-Migrationen. Skalierung und Änderungen an Ihren vorhandenen App Service-Umgebung werden während dieses Schritts blockiert.
Hinweis
In seltenen Fällen kann es vorkommen, dass Sie nach dem Start der Migration die folgende Meldung im Portal erhalten: „Migration zur App Service-Umgebung v3 fehlgeschlagen“. Es gibt einen bekannten Fehler, der diese Benachrichtigung auch dann auslösen kann, wenn die Migration voranschreitet. Überprüfen Sie das Aktivitätsprotokoll für die App-Service-Umgebung, um festzustellen, ob diese Fehlermeldung zutrifft. In den meisten Fällen löst das Aktualisieren der Seite das Problem, und die Fehlermeldung wird nicht mehr angezeigt. Wenn die Fehlermeldung weiterhin angezeigt wird, wenden Sie sich an den Support, um Hilfe zu erhalten.
Zu diesem Zeitpunkt sind detaillierte Migrationsstatus nur verfügbar, wenn Sie die Azure CLI verwenden. Weitere Informationen finden Sie im Abschnitt „Azure CLI“ für die Migration zu App Service-Umgebung v3. Sie können den Status der Migration mit der CLI überprüfen, auch wenn Sie das Portal für die Migration verwenden.
Wenn die Migration abgeschlossen ist, verfügen Sie über eine App Service-Umgebung v3-Ressource, und alle Ihre Apps werden in Ihrer neuen Umgebung ausgeführt. Sie können die Version der Umgebung bestätigen, indem Sie die Seite Konfiguration für Ihre App Service-Umgebung überprüfen.
Hinweis
Aufgrund eines bekannten Fehlers kann sich die IP-Adresse für eingehenden Datenverkehr bei Migrationen einer ELB-App Service-Umgebung nach Abschluss des Migrationsschritts ändern. Überprüfen Sie die IP-Adressen Ihrer App Service-Umgebung v3, und nehmen Sie alle erforderlichen Updates vor, wenn seit dem Schritt der IP-Generierung Änderungen vorgenommen wurden. Öffnen Sie einen Supportfall, wenn Sie Fragen oder Bedenken hinsichtlich dieses Problems haben oder Hilfe beim Bestätigen der neuen IP-Adressen benötigen.
Wenn Ihre Migration ein benutzerdefiniertes Domänensuffix enthält, wurde die Domäne im Abschnitt Grundlagen der Übersichtsseite des Portals für die App Service-Umgebung v1/v2 angezeigt, jedoch nicht mehr in der App Service-Umgebung v3. Navigieren Sie für die App Service-Umgebung v3 stattdessen zur Seite Benutzerdefiniertes Domänensuffix, auf der Sie bestätigen können, dass Ihr benutzerdefiniertes Domänensuffix richtig konfiguriert ist. Sie können die Konfiguration auch entfernen, wenn Sie sie nicht mehr benötigen, oder eine Konfiguration erstellen, wenn Sie dies zuvor noch nicht getan haben.
Hinweis
Wenn Ihre Migration ein benutzerdefiniertes Domänensuffix enthält, wird die Konfiguration des benutzerdefinierten Domänensuffixes möglicherweise nach Abschluss der Migration aufgrund eines bekannten Fehlers als beeinträchtigt angezeigt. Ihre App Service-Umgebung sollte weiterhin wie erwartet funktionieren. Der beeinträchtigte Zustand sollte sich nach sechs bis acht Stunden ändern. Wenn die Konfiguration nach acht Stunden weiterhin beeinträchtigt ist oder Ihr benutzerdefiniertes Domänensuffix nicht funktioniert, wenden Sie sich an den Support.
