Migrieren zur App Service-Umgebung v3
Hinweis
Es stehen zwei automatisierte Migrationsfeatures zur Verfügung, die Ihnen beim Upgrade auf App Service-Umgebung v3 helfen. Weitere Informationen zu diesen Features und Hilfe bei der Entscheidung, welche Migrationsoption für Sie geeignet ist, finden Sie in der Entscheidungsstruktur für den Migrationspfad. Ziehen Sie eine der automatisierten Optionen für einen schnelleren Pfad zu App Service-Umgebung v3in Betracht.
Wenn Sie derzeit die App Service-Umgebung v1 oder v2 verwenden, haben Sie die Möglichkeit, Ihre Workloads zur App Service-Umgebung v3 zu migrieren. Die App Service-Umgebung v3 bietet Vorteile und Featureunterschiede, die eine verbesserte Unterstützung Ihrer Workloads bieten und die Gesamtkosten senken können. Erwägen Sie die Verwendung der automatisierten Migrationsfeatures, wenn Ihre Umgebung die in der Entscheidungsstruktur für den Migrationspfad beschriebenen Kriterien erfüllt.
Wenn Ihre App Service-Umgebung für das Migrationsfeature nicht unterstützt wird, müssen Sie eine der manuellen Methoden verwenden, um zur App Service-Umgebung v3 zu migrieren.
Voraussetzungen
Szenario: Sie haben eine App, die in App Service-Umgebung v1 oder v2 ausgeführt wird, und diese App soll in App Service-Umgebung v3 ausgeführt werden.
Für Migrationsmethoden, welche die automatisierten Migrationsfeatures nicht verwenden, müssen Sie mit der Methode Ihrer Wahl die Ressource für App Service-Umgebung v3 und ein neues Subnetz erstellen.
Netzwerkänderungen zwischen der App Service-Umgebung v1/v2 und App Service-Umgebung v3 umfassen neue (und, für Umgebungen mit Internetzugriff, zusätzliche) IP-Adressen. Sie müssen sämtliche Infrastruktur aktualisieren, die auf diesen IP-Adressen basiert. Berücksichtigen Sie unbedingt eingehende Abhängigkeitsänderungen, z. B. den Azure Load Balancer-Port.
Mehrere App Service-Umgebungen können nicht in einem einzigen Subnetz vorhanden sein. Wenn Sie Ihr vorhandenes Subnetz für Ihre neue Ressource für App Service-Umgebung v3 verwenden müssen, müssen Sie die vorhandene App Service-Umgebung löschen, bevor Sie eine neue erstellen. In diesem Szenario wird empfohlen, Ihre Apps zu sichern und dann in der neuen Umgebung wiederherzustellen, nachdem diese erstellt und konfiguriert wurde. Dieser Prozess führt aufgrund der benötigten Zeit für folgende Aufgaben zu Downtime der Anwendung:
- Löschen der alten Umgebung
- Erstellen der Ressource für App Service-Umgebung v3
- Konfigurieren einer Infrastruktur und verbundener Ressourcen für die neue Umgebung
- Bereitstellen der Apps in der neuen Umgebung
Prüfliste vor der Migration von Apps
- Erstellen einer Ressource für App Service-Umgebung v3
- Aktualisieren aller Netzwerkabhängigkeiten mit den IP-Adressen der neuen Umgebung
- Planen von Downtime (falls zutreffend)
- Entscheiden für eine Methode zur Neuerstellung Ihrer Apps in Ihrer neuen Umgebung
Dimensionieren und Skalieren der Umgebung
Die App Service-Umgebung v3 verwendet v2-Azure App Service-Pläne vom Typ „I“, deren Preis und Dimensionierung sich von den Plänen vom Typ „I“ unterscheiden. Überprüfen Sie die Preisdetails, um zu verstehen, wie Ihre neue Umgebung für eine angemessene Kapazität dimensioniert und skaliert werden muss. Es gibt keinen Unterschied beim Erstellen von App Service-Plänen für die App Service-Umgebung v3 im Vergleich zu früheren Versionen.
Auswerten von Sicherung und Wiederherstellung
Mit dem Sicherungs- und Wiederherstellungsfeature können Sie die App-Konfiguration, den Dateiinhalte und die mit der App verbundene Datenbank bei der Migration zur neuen Umgebung beibehalten.
Sie müssen benutzerdefinierte Sicherungen für Ihre Apps konfigurieren, um sie in der App Service-Umgebung v3 wiederherzustellen. Die automatische Sicherung unterstützt keine Wiederherstellung in verschiedenen App Service-Umgebungsversionen. Weitere Informationen zu benutzerdefinierten Sicherungen finden Sie unter Automatische und benutzerdefinierte Sicherungen.
Sie können eine benutzerdefinierte Sicherung auswählen und sie in App Service in Ihrer Ressource für App Service-Umgebung v3 wiederherstellen. Sie müssen den App Service-Plan, in dem Sie wiederherstellen möchten, erstellen, bevor Sie die App wiederherstellen. Sie können die Sicherung im Produktionsslot, einem vorhandenen Slot oder einem neu erstellten Slot wiederherstellen, den Sie während des Wiederherstellungsvorgangs erstellen.
| Vorteile | Einschränkungen |
|---|---|
| Schnell – sollte pro App nur 5 bis 10 Minuten dauern | Die Unterstützung ist auf bestimmte Datenbanktypen beschränkt. |
| Sie können mehrere Apps gleichzeitig wiederherstellen. (Sie müssen die Wiederherstellung für jede App einzeln konfigurieren.) | Die alte und die neue Umgebung sowie unterstützende Ressourcen (z. B. Apps, Datenbanken, Speicherkonten und Container) müssen sich alle im selben Abonnement befinden. |
| In-App-MySQL-Datenbanken werden automatisch ohne Konfiguration gesichert. | Sicherungen können bis zu 10GB an App- und Datenbankinhalten umfassen. Bis zu 4 GB dieses Inhalts können die Datenbanksicherung umfassen. Wenn die Sicherungsgröße diesen Grenzwert überschreitet, erhalten Sie eine Fehlermeldung. |
| Sie können eine Momentaufnahme eines vorherigen Zustands der App wiederherstellen. | Die Verwendung eines Speicherkontos mit aktivierter Firewall als Ziel für Ihre Sicherungen wird nicht unterstützt. |
| Sie können eine Integration in Azure Traffic Manager und Azure Application Gateway durchführen, um Datenverkehr auf alte und neue Umgebungen zu verteilen | Die Verwendung eines Speicherkontos mit privaten Endpunkten für die Sicherung und Wiederherstellung wird nicht unterstützt. |
| Sie können zum Beschleunigen des Prozesses leere Web-Apps erstellen, die Sie für die Wiederherstellung in Ihrer neuen Umgebung verwenden, bevor Sie mit der Wiederherstellung beginnen. | Nur benutzerdefinierte Sicherungen werden unterstützt. |
Klonen Ihrer App in App Service-Umgebung v3
Das Klonen Ihrer Apps ist ein weiteres Feature, das Sie verwenden können, um Ihre Windows-Apps in die App Service-Umgebung v3 zu übertragen. Die Einschränkungen für das Klonen von Apps sind identisch mit denen für das App Service-Sicherungsfeature. Weitere Informationen finden Sie unter Sichern einer App in Azure App Service.
Hinweis
Das Klonen von Apps wird nur für App Service-Pläne unter Windows unterstützt.
Diese Lösung wird für Benutzer*innen empfohlen, die App Service unter Windows verwenden und nicht mithilfe des Migrationsfeatures migrieren können. Sie müssen Ihre neue Ressource für App Service-Umgebung v3 einrichten, bevor Sie Apps klonen. Das Klonen einer App kann bis zu 30 Minuten dauern.
Informationen zum Klonen einer App mithilfe von PowerShell finden Sie in den Anweisungen.
So klonen Sie eine App über das Azure-Portal
Wechseln Sie im Azure-Portal zum vorhandenen App Service-Plan. Wählen Sie unter Entwicklungstools die Option App klonen aus.
Füllen Sie die erforderlichen Felder mit den Details für Ihre neue Ressource für App Service-Umgebung v3 aus:
- Wählen Sie für Ressourcengruppe eine vorhandene Ressourcengruppe aus, oder erstellen Sie eine neue.
- Geben Sie unter Name einen Namen für Ihre App ein. Dieser Name kann mit der alten App identisch sein, die Standard-URL der Website für die neue Umgebung ist jedoch anders. Sie müssen sämtliche benutzerdefinierte DNS- oder verbundene Ressourcen aktualisieren, sodass sie auf die neue URL verweisen.
- Verwenden Sie für Region den Namen Ihrer App Service-Umgebung v3.
- Wenn Sie Ihre Bereitstellungsquelle klonen möchten, aktivieren Sie das Kontrollkästchen Bereitstellungsquelle klonen.
- Sie können für Windows-Plan einen vorhandenen App Service-Plan aus Ihrer neuen Umgebung verwenden, wenn Sie bereits einen erstellt haben, oder ansonsten einen neuen erstellen. Die verfügbaren App Service-Pläne in Ihrer neuen Ressource für App Service-Umgebung v3 werden in der Dropdownliste aufgeführt.
- Ändern Sie unter SKU und Größe den Arbeitsspeicher und die CPU nach Bedarf mithilfe einer der Optionen vom Typ „V2 isoliert“, wenn Sie einen neuen App Service-Plan erstellen. Die App Service-Umgebung v3 verwendet Pläne vom Typ „V2 isoliert“, die mehr Arbeitsspeicher und CPU pro entsprechender Instanzgröße als die Pläne vom Typ „I“ haben. Weitere Informationen finden Sie in den Preisdetails für App Service Environment v3.
| Vorteile | Einschränkungen |
|---|---|
| Sie können das Klonen mithilfe von PowerShell automatisieren. | Wird nur für App Service-Pläne unter Windows unterstützt. |
| Sie können mehrere Apps gleichzeitig klonen. (Klonen muss für jede App einzeln oder über ein Skript konfiguriert werden.) | Die Unterstützung ist auf bestimmte Datenbanktypen beschränkt. |
| Sie können eine Integration in Azure Traffic Manager und Azure Application Gateway durchführen, um Datenverkehr auf alte und neue Umgebungen zu verteilen | Die alte und die neue Umgebung sowie unterstützende Ressourcen (z. B. Apps, Datenbanken, Speicherkonten und Container) müssen sich alle im selben Abonnement befinden. |
Manuelles Erstellen Ihrer Apps in App Service-Umgebung v3
Wenn das oben genannten Migrationsfeature Ihre Apps nicht unterstützt oder Sie einen manuellen Ansatz bevorzugen, können Sie Ihre Apps nach demselben Prozess bereitzustellen, den Sie auch für Ihre vorhandene App Service-Umgebung verwendet haben.
Sie können Azure Resource Manager-Vorlagen (ARM-Vorlagen) Ihrer vorhandenen Apps, App Service-Pläne und anderer unterstützter Ressourcen exportieren und in oder mit Ihrer neuen Umgebung bereitstellen. Wenn Sie eine Vorlage nur für eine App exportieren möchten, wechseln Sie zu Ihrem App Service-Plan. Wählen Sie unter Automatisierung die Option Vorlage exportieren aus.
Sie können auch Vorlagen für mehrere Ressourcen direkt aus Ihrer Ressourcengruppe exportieren. Wechseln Sie zu Ihrer Ressourcengruppe, wählen Sie die Ressourcen aus, für die Sie eine Vorlage benötigen, und wählen Sie dann Vorlage exportieren aus.
Die folgenden anfänglichen Änderungen an Ihren ARM-Vorlagen sind erforderlich, um Ihre Apps zu App Service-Umgebung v3 zu migrieren:
Ändern Sie die
sku-Parameter für einen App Service-Plan in einen Plan vom Typ „V2 isoliert“:"type": "Microsoft.Web/serverfarms", "apiVersion": "2021-02-01", "name": "[parameters('serverfarm_name')]", "location": "East US", "sku": { "name": "I1v2", "tier": "IsolatedV2", "size": "I1v2", "family": "Iv2", "capacity": 1 },Ändern Sie den Parameter für den App Service-Plan (
serverfarm), in dem die App bereitgestellt werden soll, in denjenigen, der der App Service-Umgebung v3 zugeordnet ist.Aktualisieren Sie den Parameter für das Hostingumgebungsprofil (
hostingEnvironmentProfile) auf die neue Ressourcen-ID der App Service-Umgebung v3.Ein ARM-Vorlagenexport enthält alle Eigenschaften, die die Ressourcenanbieter für die Ressourcen verfügbar machen. Entfernen Sie alle nicht erforderlichen Eigenschaften, z. B. Eigenschaften, die auf die Domäne der alten App verweisen. Beispielsweise könnten Sie die
sites-Ressource wie folgt vereinfachen:"type": "Microsoft.Web/sites", "apiVersion": "2021-02-01", "name": "[parameters('site_name')]", "location": "East US", "dependsOn": [ "[resourceId('Microsoft.Web/serverfarms', parameters('serverfarm_name'))]" ], "properties": { "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', parameters('serverfarm_name'))]", "siteConfig": { "linuxFxVersion": "NODE|14-lts" }, "hostingEnvironmentProfile": { "id": "[parameters('hostingEnvironments_externalid')]" } }
Je nachdem, wie Ihre App konfiguriert ist, sind möglicherweise weitere Änderungen erforderlich. Wenn Sie beispielsweise vom System zugewiesene verwaltete Identitäten und die gleichen Anwendungsnamen für Ihre alten und neuen Umgebungen verwenden, können Konflikte auftreten. Um diese Konflikte zu beheben und Ausfallzeiten zu vermeiden, können Sie eine vom Benutzer zugewiesene verwaltete Identität verwenden.
Sie können das Azure-Portal, die Azure-Befehlszeilenschnittstelle oder PowerShell verwenden, um ARM-Vorlagen bereitzustellen.
Manuelles Migrieren
Das Features für die direkte Migration automatisiert die Migration zur App Service-Umgebung v3 und überträgt alle Ihre Apps in die neue Umgebung. Während dieser Migration kommt es zu einer Ausfallzeit von etwa einer Stunde. Wenn Ihre Apps keine Downtime haben dürfen, empfehlen wir Ihnen, das Feature für die parallele Migration zu verwenden, bei dem es sich um eine Migrationsoption ohne Downtime handelt, da die neue Umgebung in einem anderen Subnetz erstellt wird. Wenn Sie sich dafür entscheiden, das Feature für die parallele Migration nicht zu verwenden, können Sie eine der manuellen Optionen verwenden, um Ihre Apps in App Service-Umgebung v3 neu zu erstellen.
Sie können Datenverkehr zwischen Ihrer alten und neuen Umgebung mithilfe von Application Gateway verteilen. Wenn Sie eine App Service-Umgebung mit internem Lastenausgleich (Internal Load Balancer, ILB) verwenden, lesen erstellen Sie eine Azure Application Gateway-Instanz mit einem zusätzlichen Back-End-Pool, um den Datenverkehr zwischen Ihren Umgebungen zu verteilen. Informationen zu ILB-App-Dienstumgebungen und App Service-Umgebungen mit Internetzugriff finden Sie unter Application Gateway-Integration.
Sie können auch Dienste wie Azure Front Door, Azure Content Delivery Network und Azure Traffic Manager verwenden, um Datenverkehr zwischen Umgebungen zu verteilen. Die Verwendung dieser Dienste ermöglicht das kontrollierte Testen Ihrer neuen Umgebung und den Wechsel zu Ihrer neuen Umgebung in Ihrem eigenen Tempo.
Nachdem die Migration und alle Tests Ihrer neuen Umgebung abgeschlossen sind, löschen Sie Ihre alte App Service-Umgebung, die darin enthaltenen Apps und alle unterstützenden Ressourcen, die Sie nicht mehr benötigen. Ihnen werden weiterhin alle Ressourcen in Rechnung gestellt, die nicht gelöscht werden.
Häufig gestellte Fragen
Wie weiß ich, ob ich mit einer der manuellen Optionen zu App Service-Umgebung v3 migrieren sollte?
Hilfe bei der Entscheidung, welche Migrationsoption für Sie geeignet ist, finden Sie unter Entscheidungsstruktur für den Migrationspfad. Wenn Ihre Umgebung die in der Entscheidungsstruktur für den Migrationspfad beschriebenen Kriterien erfüllt, sollten Sie eines der automatisierten Migrationsfeatures für einen schnelleren Pfad zur App Service-Umgebung v3 verwenden. Eine manuelle Migration wird empfohlen, wenn Sie Ihre Apps langsam in Ihre neue Umgebung verschieben und während des gesamten Prozesses überprüfen müssen.Kommt es während der Migration zu Ausfallzeiten?
Ausfallzeiten hängen von Ihrem Migrationsprozess ab. Wenn Sie über eine andere App Service-Umgebung verfügen, an die Sie während der Migration Datenverkehr verweisen können, oder wenn Sie ein anderes Subnetz verwenden können, um Ihre neue Umgebung zu erstellen, kommt es zu keiner Downtime. Wenn Sie jedoch dasselbe Subnetz verwenden müssen, kommt es zu Downtime, während Sie die alte Umgebung löschen, die Ressource für App Service-Umgebung v3 erstellen, die neuen App Service-Pläne erstellen, die Apps erneut erstellen und alle Ressourcen aktualisieren, die die neuen IP-Adressen kennen müssen.Muss ich etwas an meinen Apps ändern, damit sie in App Service-Umgebung v3 ausgeführt werden können?
Nein Bei Apps, die in App Service-Umgebung v1 und v2 ausgeführt werden, sollten keine Änderungen erforderlich sein, um in App Service-Umgebung v3 ausgeführt zu werden. Wenn Sie IP-SSL verwenden, müssen Sie die IP-SSL-Bindungen vor der Migration entfernen.Was passiert, wenn meine App Service-Umgebung ein benutzerdefiniertes Domänensuffix hat?
Das Migrationsfeature unterstützt dieses Migrationsszenario. Sie können die Migration mithilfe einer manuellen Methode ausführen, wenn Sie das Migrationsfeature nicht verwenden möchten. Sie können beim Erstellen der Ressource für App Service-Umgebung v3 oder jederzeit danach Ihr benutzerdefiniertes Domänensuffix konfigurieren.Was passiert, wenn meine Ressource für App Service-Umgebung v2 an eine Zone angeheftet ist?
Das Anheften von Zonen ist in App Service-Umgebung v3 kein unterstütztes Feature. Sie können beim Erstellen Ihrer Ressource für App Service-Umgebung v3 Zonenredundanz aktivieren.Welche Eigenschaften meiner App Service-Umgebung werden sich ändern?
Überprüfen Sie die Featureunterschiede zwischen App Service-Umgebung v3 und früheren Versionen. Für App Service-Umgebungen mit ILB behalten Sie die gleiche ILB-IP-Adresse bei. Für App Service-Umgebungen mit Internetzugang ändern sich die öffentliche IP-Adresse und die ausgehende IP-Adresse.Für App Service-Umgebungen mit Internetzugang gab es zuvor eine einzelne IP-Adresse für eingehende und ausgehende Verbindungen. Für die App Service-Umgebung v3 gibt es separate Adressen. Weitere Informationen finden Sie unter Netzwerkfunktionalität in der App Service-Umgebung v3.
Wird Sichern und Wiederherstellen für das Verschieben von Apps von der App Service-Umgebung v2 in v3 unterstützt? Das Feature Sichern und Wiederherstellen unterstützt das Wiederherstellen von Apps zwischen App Service-Umgebungsversionen, solange Sie eine benutzerdefinierte Sicherung für die Wiederherstellung verwenden. Die automatische Sicherung unterstützt keine Wiederherstellung in verschiedenen App Service-Umgebungsversionen.
Was geschieht mit meinen Ressourcen der App Service-Umgebung v1 und v2 nach dem 31. August 2024?
Wenn Sie nach dem 31. August 2024 nicht zu App Service-Umgebung v3 migriert sind, sind Ihre Ressourcen der App Service-Umgebung v1 und v2 und die darin bereitgestellten Apps nicht mehr verfügbar.App Service-Umgebung v1 und v2 wird auf App Service-Skalierungseinheiten gehostet, die in einer Architektur vom Typ Azure Cloud Services (klassisch) ausgeführt werden. Da diese Architektur am 31. August 2024 eingestellt wird, sind App Service-Umgebung v1 und v2 nach diesem Datum nicht mehr verfügbar. Migrieren Sie zu App Service-Umgebung v3, um die Funktionsfähigkeit Ihrer Apps zu gewährleisten, oder speichern bzw. sichern Sie alle Ressourcen oder Daten, die Sie erhalten müssen.