Migreren naar App Service Environment v3

Artikel
03/06/2024

Notitie

Er zijn twee geautomatiseerde migratiefuncties beschikbaar om u te helpen bij het upgraden naar App Service Environment v3. Zie de beslissingsstructuur voor migratiepaden voor meer informatie over deze functies en voor hulp bij het bepalen welke migratieoptie geschikt is voor u. Overweeg een van de geautomatiseerde opties voor een sneller pad naar App Service Environment v3.

Als u momenteel App Service Environment v1 of v2 gebruikt, hebt u de mogelijkheid om uw workloads te migreren naar App Service Environment v3. App Service Environment v3 heeft voordelen en functieverschillen die uitgebreide ondersteuning bieden voor uw workloads en kunnen de totale kosten verlagen. Overweeg het gebruik van de geautomatiseerde migratiefuncties als uw omgeving voldoet aan de criteria die worden beschreven in de beslissingsstructuur van het migratiepad.

Als uw App Service Environment niet wordt ondersteund voor de migratiefuncties, moet u een van de handmatige methoden gebruiken om te migreren naar App Service Environment v3.

Vereisten

Scenario: U hebt een app die wordt uitgevoerd op App Service Environment v1 of App Service Environment v2 en u hebt die app nodig om uit te voeren op App Service Environment v3.

Voor elke migratiemethode die niet gebruikmaakt van de geautomatiseerde migratiefuncties, moet u de App Service Environment v3-resource en een nieuw subnet maken met behulp van de methode van uw keuze.

Netwerkwijzigingen tussen App Service Environment v1/v2 en App Service Environment v3 omvatten nieuwe (en voor internetgerichte omgevingen, extra) IP-adressen. U moet alle infrastructuur bijwerken die afhankelijk is van deze IP-adressen. Zorg ervoor dat u rekening houdt met binnenkomende afhankelijkheidswijzigingen, zoals de Azure Load Balancer-poort.

Meerdere App Service-omgevingen kunnen niet bestaan in één subnet. Als u uw bestaande subnet wilt gebruiken voor uw nieuwe App Service Environment v3-resource, moet u de bestaande App Service Environment verwijderen voordat u een nieuw subnet maakt. Voor dit scenario raden we u aan een back-up te maken van uw apps en deze vervolgens te herstellen in de nieuwe omgeving nadat u de omgeving hebt gemaakt en geconfigureerd. Dit proces veroorzaakt downtime van toepassingen vanwege de tijd die nodig is om:

Verwijder de oude omgeving.
Maak de App Service Environment v3-resource.
Configureer alle infrastructuur en verbonden resources om met de nieuwe omgeving te werken.
Implementeer uw apps in de nieuwe omgeving.

Controlelijst voordat u apps migreert

Maak een App Service Environment v3-resource .
Werk netwerkafhankelijkheden bij met de IP-adressen die zijn gekoppeld aan de nieuwe omgeving.
Plan downtime (indien van toepassing).
Beslis over een proces voor het opnieuw maken van uw apps in uw nieuwe omgeving.

De grootte en schaal van de omgeving aanpassen

App Service Environment v3 maakt gebruik van Isolated v2 Azure-app Service-abonnementen die verschillend zijn geprijsd en een andere grootte hebben dan geïsoleerde abonnementen. Bekijk de prijsgegevens om te begrijpen hoe u een nieuwe omgeving hebt, moet worden aangepast en geschaald om de juiste capaciteit te garanderen. Er is geen verschil in hoe u App Service-plannen voor App Service Environment v3 maakt in vergelijking met eerdere versies.

Back-up en herstel evalueren

U kunt de functie back-up en herstel gebruiken om uw app-configuratie, bestandsinhoud en database verbonden met uw app te houden wanneer u naar de nieuwe omgeving migreert.

U moet aangepaste back-ups voor uw apps configureren om ze te herstellen naar App Service Environment v3. Automatische back-up biedt geen ondersteuning voor herstel in verschillende App Service Environment-versies. Zie Automatische en aangepaste back-ups voor meer informatie over aangepaste back-ups. Schermopname met opties voor het configureren van aangepaste back-ups voor een App Service-app.

U kunt een aangepaste back-up selecteren en deze herstellen naar App Service in uw App Service Environment v3-resource. U moet het App Service-plan maken waarnaar u herstelt voordat u de app herstelt. U kunt ervoor kiezen om de back-up te herstellen naar de productiesite, een bestaande site of een nieuwe site die u tijdens het herstelproces maakt.

Schermopname die laat zien hoe u een back-up gebruikt om een App Service-app te herstellen in App Service Environment v3.

Vergoedingen	Beperkingen
Snel: het duurt slechts 5 tot 10 minuten per app.	Ondersteuning is beperkt tot bepaalde databasetypen.
U kunt meerdere apps tegelijk herstellen. (U moet herstel voor elke app afzonderlijk configureren.)	De oude omgeving, de nieuwe omgeving en ondersteunende resources (bijvoorbeeld apps, databases, opslagaccounts en containers) moeten zich allemaal in hetzelfde abonnement bevinden.
In-app MySQL-databases worden automatisch een back-up gemaakt zonder enige configuratie.	Back-ups kunnen maximaal 10 GB aan app- en database-inhoud zijn. Maximaal 4 GB aan die inhoud kan de back-up van de database zijn. Als de back-upgrootte deze limiet overschrijdt, krijgt u een foutmelding.
U kunt de app herstellen naar een momentopname van een eerdere status.	Het gebruik van een opslagaccount met firewalls als doel voor uw back-ups wordt niet ondersteund.
U kunt integreren met Azure Traffic Manager en Azure-toepassing Gateway om verkeer over oude en nieuwe omgevingen te distribueren.	Het gebruik van een opslagaccount met privé-eindpunten voor back-up en herstel wordt niet ondersteund.
U kunt lege web-apps maken om in uw nieuwe omgeving te herstellen voordat u begint met herstellen, om het proces te versnellen.	Alleen aangepaste back-ups worden ondersteund.

Uw app klonen naar App Service Environment v3

Het klonen van uw apps is een andere functie die u kunt gebruiken om uw Windows-apps op App Service Environment v3 te krijgen. De beperkingen voor het klonen van apps zijn hetzelfde als die voor de App Service-back-upfunctie. Zie Een back-up maken van een app in Azure-app Service voor meer informatie.

Notitie

Het klonen van apps wordt alleen ondersteund voor App Service-abonnementen in Windows.

We raden deze oplossing aan voor gebruikers die App Service in Windows gebruiken en die niet kunnen migreren met behulp van de migratiefunctie. U moet uw nieuwe App Service Environment v3-resource instellen voordat u apps kloont. Het klonen van een app kan tot 30 minuten duren.

Als u een app wilt klonen met behulp van PowerShell, raadpleegt u de instructies.

Een app klonen met behulp van Azure Portal:

Ga in Azure Portal naar uw bestaande App Service-plan. Selecteer Onder Ontwikkelhulpprogramma's de optie App klonen.
Vul de vereiste velden in met behulp van de details voor uw nieuwe App Service Environment v3-resource:
1. Selecteer voor resourcegroep een bestaande resourcegroep of maak een nieuwe.
2. Geef bij Naam een naam op voor uw app. Deze naam kan hetzelfde zijn als de oude app, maar de standaard-URL van de site voor de nieuwe omgeving is anders. U moet aangepaste DNS- of verbonden resources bijwerken om naar de nieuwe URL te verwijzen.
3. Gebruik voor Regio de naam van uw App Service Environment v3.
4. Als u de implementatiebron wilt klonen, schakelt u het selectievakje Implementatiebron klonen in.
5. Voor Windows-abonnement kunt u een bestaand App Service-plan gebruiken vanuit uw nieuwe omgeving als u er al een hebt gemaakt, of u kunt een nieuw plan maken. De beschikbare App Service-plannen in uw nieuwe App Service Environment v3-resource worden weergegeven in de vervolgkeuzelijst.
6. Wijzig voor SKU en grootte het geheugen en de CPU indien nodig met behulp van een van de geïsoleerde v2-opties als u een nieuw App Service-plan maakt. App Service Environment v3 maakt gebruik van isolated v2-abonnementen, met meer geheugen en CPU per bijbehorende instantiegrootte in vergelijking met de geïsoleerde plannen. Zie de prijsinformatie voor App Service Environment v3 voor meer informatie.

Schermopname met opties voor het klonen van een app naar App Service Environment v3 met behulp van de portal.

Vergoedingen	Beperkingen
U kunt het klonen automatiseren met behulp van PowerShell.	Alleen ondersteund voor App Service-abonnementen in Windows.
U kunt meerdere apps tegelijk klonen. (Klonen moet afzonderlijk of via een script worden geconfigureerd voor elke app.)	Ondersteuning is beperkt tot bepaalde databasetypen.
U kunt integreren met Azure Traffic Manager en Azure-toepassing Gateway om verkeer over oude en nieuwe omgevingen te distribueren.	De oude omgeving, de nieuwe omgeving en ondersteunende resources (bijvoorbeeld apps, databases, opslagaccounts en containers) moeten zich allemaal in hetzelfde abonnement bevinden.

Uw apps handmatig maken in App Service Environment v3

Als de migratiefunctie uw apps niet ondersteunt of als u een meer handmatige route wilt uitvoeren, kunt u uw apps implementeren door hetzelfde proces te volgen dat u hebt gebruikt voor uw bestaande App Service Environment.

U kunt Azure Resource Manager-sjablonen (ARM-sjablonen) van uw bestaande apps, App Service-plannen en andere ondersteunde resources exporteren en deze implementeren in of met uw nieuwe omgeving. Als u een sjabloon voor slechts een app wilt exporteren, gaat u naar uw App Service-plan. Selecteer onder Automation de optie Sjabloon Exporteren.

Schermopname van de optie voor het exporteren van een sjabloon in het linkerdeelvenster van Azure Portal.

U kunt sjablonen voor meerdere resources ook rechtstreeks vanuit uw resourcegroep exporteren. Ga naar uw resourcegroep, selecteer de resources waarvoor u een sjabloon wilt gebruiken en selecteer vervolgens Sjabloon exporteren.

Schermopname van de optie voor het exporteren van een sjabloon voor resources uit een resourcegroep.

De volgende initiële wijzigingen in uw ARM-sjablonen zijn vereist om uw apps op App Service Environment v3 te krijgen:

Parameters sku voor een App Service-plan bijwerken naar een geïsoleerd v2-plan:

"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
},

Werk de parameter van het App Service-plan (serverfarm) bij waarmee de app wordt geïmplementeerd in het plan dat is gekoppeld aan App Service Environment v3.
Werk de parameter voor het hostomgevingsprofiel (hostingEnvironmentProfile) bij naar de nieuwe Resource-id van App Service Environment v3.

Een ARM-sjabloonexport bevat alle eigenschappen die de resourceproviders beschikbaar maken voor de resources. Verwijder alle niet-benodigde eigenschappen, zoals eigenschappen die verwijzen naar het domein van de oude app. U kunt de sites resource bijvoorbeeld vereenvoudigen naar het volgende voorbeeld:

"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')]"
    }
}

Er zijn mogelijk andere wijzigingen vereist, afhankelijk van hoe u uw app hebt geconfigureerd. Als u bijvoorbeeld door het systeem toegewezen beheerde identiteiten en dezelfde toepassingsnamen voor uw oude en nieuwe omgevingen gebruikt, kunnen er conflicten optreden. Als u dit conflict wilt oplossen en downtime wilt voorkomen, kunt u een door de gebruiker toegewezen beheerde identiteit gebruiken.

U kunt ARM-sjablonen implementeren met behulp van Azure Portal, De Azure CLI of PowerShell.

Handmatig migreren

Met de in-place migratiefunctie wordt de migratie naar App Service Environment v3 geautomatiseerd en worden al uw apps overgedragen naar de nieuwe omgeving. Er is ongeveer één uur downtime tijdens deze migratie. Als uw apps geen downtime kunnen hebben, raden we u aan de functie naast elkaar te gebruiken. Dit is een migratieoptie zonder downtime, omdat de nieuwe omgeving in een ander subnet wordt gemaakt. Als u er ook voor kiest om de migratiefunctie naast elkaar te gebruiken, kunt u een van de handmatige opties gebruiken om uw apps opnieuw te maken in App Service Environment v3.

U kunt verkeer verdelen tussen uw oude en nieuwe omgevingen met behulp van Application Gateway. Als u een interne load balancer (ILB) App Service Environment gebruikt, maakt u een Azure-toepassing Gateway-exemplaar met een extra back-endpool om verkeer tussen uw omgevingen te verdelen. Zie Application Gateway-integratie voor informatie over ILB App Service Environments en internetgerichte App Service Environments.

U kunt ook services zoals Azure Front Door, Azure Content Delivery Network en Azure Traffic Manager gebruiken om verkeer tussen omgevingen te distribueren. Door deze services te gebruiken, kunt u uw nieuwe omgeving op een gecontroleerde manier testen en kunt u in uw eigen tempo naar uw nieuwe omgeving gaan.

Nadat uw migratie en tests met uw nieuwe omgeving zijn voltooid, verwijdert u uw oude App Service Environment, de apps die erop staan en eventuele ondersteunende resources die u niet meer nodig hebt. Er worden nog steeds kosten in rekening gebracht voor resources die u niet verwijdert.

Veelgestelde vragen

Hoe kan ik weten of ik moet migreren naar App Service Environment v3 met behulp van een van de handmatige opties?
Zie de beslissingsstructuur van het migratiepad voor hulp bij het bepalen welke migratieoptie geschikt is voor u. Als uw omgeving voldoet aan de criteria die worden beschreven in de beslissingsstructuur van het migratiepad, kunt u overwegen een van de geautomatiseerde migratiefuncties te gebruiken voor een sneller pad naar App Service Environment v3. Handmatige migratie wordt aanbevolen als u uw apps langzaam naar uw nieuwe omgeving moet verplaatsen en gedurende het hele proces moet valideren.
Ondervind ik downtime tijdens de migratie?
Downtime is afhankelijk van uw migratieproces. Als u een andere App Service-omgeving hebt waarnaar u verkeer kunt verwijzen terwijl u migreert of als u een ander subnet kunt gebruiken om uw nieuwe omgeving te maken, hebt u geen downtime. Als u hetzelfde subnet moet gebruiken, is er downtime tijdens het verwijderen van de oude omgeving, het maken van de App Service Environment v3-resource, het maken van de nieuwe App Service-plannen, het opnieuw maken van de apps en het bijwerken van resources die gebruikmaken van de nieuwe IP-adressen.
Moet ik iets wijzigen over mijn apps om ze uit te voeren op App Service Environment v3?
Nee Apps die worden uitgevoerd op App Service Environment v1 en v2, hoeven geen wijzigingen te worden uitgevoerd op App Service Environment v3. Als u IP SSL gebruikt, moet u de IP SSL-bindingen verwijderen voordat u migreert.
Wat gebeurt er als mijn App Service Environment een aangepast domeinachtervoegsel heeft?
De migratiefunctie ondersteunt dit migratiescenario. U kunt migreren met behulp van een handmatige methode als u de migratiefunctie niet wilt gebruiken. U kunt het achtervoegsel van uw aangepaste domein configureren bij het maken van uw App Service Environment v3-resource of op elk gewenst moment daarna.
Wat gebeurt er als mijn App Service Environment v2-resource is vastgemaakt aan de zone?
Zonepinning is geen ondersteunde functie in App Service Environment v3. U kunt ervoor kiezen om zoneredundantie in te schakelen bij het maken van uw App Service Environment v3-resource.
Welke eigenschappen van mijn App Service Environment worden gewijzigd?
Bekijk de functieverschillen tussen App Service Environment v3 en eerdere versies. Voor ILB App Service-omgevingen behoudt u hetzelfde IP-adres voor ILB. Voor internetgerichte App Service-omgevingen worden het openbare IP-adres en het uitgaande IP-adres gewijzigd.

Voor internetgerichte App Service-omgevingen was er eerder één IP-adres voor zowel inkomend als uitgaand verkeer. Voor App Service Environment v3 zijn ze gescheiden. Zie App Service Environment V3-netwerken voor meer informatie.
Wordt back-up en herstel ondersteund voor het verplaatsen van apps van App Service Environment v2 naar v3? De back-up- en herstelfunctie ondersteunt het herstellen van apps tussen App Service Environment-versies zolang u een aangepaste back-up gebruikt voor het herstellen. Automatische back-up biedt geen ondersteuning voor herstel naar verschillende App Service Environment-versies.
Wat gebeurt er met mijn App Service Environment v1- en v2-resources na 31 augustus 2024?
Als u na 31 augustus 2024 niet bent gemigreerd naar App Service Environment v3, zijn uw App Service Environment v1- en v2-resources en de apps die erin zijn geïmplementeerd, niet meer beschikbaar.

App Service Environment v1 en v2 worden gehost op App Service-schaaleenheden die worden uitgevoerd op de Azure Cloud Services-architectuur (klassiek). Omdat deze architectuur op 31 augustus 2024 buiten gebruik wordt gesteld, zijn App Service Environment v1 en v2 na die datum niet meer beschikbaar. Migreer naar App Service Environment v3 om uw apps actief te houden of sla resources of gegevens op die u moet onderhouden of maak er een back-up van.