Migrowanie środowiska App Service Environment w wersji 2 do środowiska App Service Environment w wersji 3 przy użyciu funkcji migracji równoległej
Uwaga
Funkcja migracji opisana w tym artykule jest używana do automatycznej migracji środowiska App Service Environment w wersji 2 do środowiska App Service Environment w wersji 3 obok siebie (innej podsieci).
Jeśli szukasz informacji na temat funkcji migracji w miejscu, zobacz Migrowanie do środowiska App Service Environment w wersji 3 przy użyciu funkcji migracji w miejscu. Jeśli szukasz informacji na temat opcji migracji ręcznej, zobacz Opcje migracji ręcznej. Aby uzyskać pomoc przy podejmowaniu decyzji o tym, która opcja migracji jest odpowiednia, zobacz Drzewo decyzyjne ścieżki migracji. Aby uzyskać więcej informacji na temat środowiska App Service Environment w wersji 3, zobacz Omówienie środowiska App Service Environment w wersji 3.
Środowisko App Service Environment w wersji 2 można automatycznie migrować do środowiska App Service Environment w wersji 3 przy użyciu funkcji migracji równoległej. Aby dowiedzieć się więcej na temat procesu migracji i sprawdzić, czy środowisko App Service Environment obsługuje migrację w tej chwili, zobacz omówienie funkcji migracji równoległej.
Ważne
Zalecamy użycie tej funkcji w środowiskach deweloperskich przed migracją jakichkolwiek środowisk produkcyjnych, aby uniknąć nieoczekiwanych problemów. Przekaż wszelkie opinie związane z tym artykułem lub funkcją, korzystając z przycisków w dolnej części strony.
Wymagania wstępne
Upewnij się, że rozumiesz, jak migracja do środowiska App Service Environment w wersji 3 wpływa na aplikacje. Zapoznaj się z procesem migracji, aby zrozumieć oś czasu procesu i gdzie i kiedy trzeba się zaangażować. Zapoznaj się również z często zadawanych pytań, które mogą odpowiedzieć na niektóre pytania.
Upewnij się, że w sieci wirtualnej, grupach zasobów, zasobach lub subskrypcji nie ma żadnych blokad. Blokuje operacje platformy podczas migracji.
Upewnij się, że żadne zasady platformy Azure nie blokują akcji wymaganych do migracji, w tym modyfikacji podsieci i tworzenia zasobów usługi aplikacja systemu Azure. Zasady blokujące modyfikacje zasobów i tworzenie mogą spowodować zablokowanie lub niepowodzenie migracji.
Ponieważ środowisko App Service Environment w wersji 3 znajduje się w innej podsieci w sieci wirtualnej, musisz upewnić się, że masz dostępną podsieć w sieci wirtualnej, która spełnia wymagania dotyczące podsieci dla środowiska App Service Environment w wersji 3. Wybrana podsieć musi również mieć możliwość komunikowania się z podsiecią, w której znajduje się istniejące środowisko App Service Environment. Upewnij się, że komunikacja między dwiema podsieciami nie blokuje żadnych blokowania. Jeśli nie masz dostępnej podsieci, musisz go utworzyć przed migracją. Utworzenie nowej podsieci może obejmować zwiększenie przestrzeni adresowej sieci wirtualnej. Aby uzyskać więcej informacji, zobacz Tworzenie sieci wirtualnej i podsieci.
Ponieważ skalowanie jest blokowane podczas migracji, przed rozpoczęciem migracji należy skalować środowisko do żądanego rozmiaru. Jeśli musisz skalować środowisko po migracji, możesz to zrobić po zakończeniu migracji.
Wykonaj kroki opisane tutaj w kolejności i zgodnie z opisem, ponieważ wywołujesz interfejs API REST platformy Azure. Zalecamy użycie interfejsu wiersza polecenia platformy Azure do wykonania tych wywołań interfejsu API. Aby uzyskać informacje o innych metodach, zobacz Dokumentacja interfejsu API REST platformy Azure.
W tym przewodniku zainstaluj interfejs wiersza polecenia platformy Azure lub użyj usługi Azure Cloud Shell i użyj powłoki Bash.
Uwaga
Zalecamy użycie powłoki Bash do uruchamiania poleceń podanych w tym przewodniku. Polecenia mogą nie być zgodne z konwencjami programu PowerShell i znakami ucieczki.
Ważne
Podczas migracji witryna Azure Portal może wyświetlać niepoprawne informacje o środowisku App Service Environment i aplikacjach. Nie przejdź do środowiska migracji w witrynie Azure Portal, ponieważ funkcja migracji równoległej nie jest dostępna. Zalecamy sprawdzenie stanu migracji przy użyciu interfejsu wiersza polecenia platformy Azure. Jeśli masz jakiekolwiek pytania dotyczące stanu migracji lub aplikacji, skontaktuj się z pomocą techniczną.
1. Wybierz podsieć dla nowego środowiska App Service Environment w wersji 3
Wybierz podsieć w środowisku App Service Environment w wersji 3 spełniającą wymagania podsieci środowiska App Service Environment w wersji 3. Zanotuj nazwę wybranej podsieci. Ta podsieć musi być inna niż podsieć, w których znajduje się istniejące środowisko App Service Environment.
2. Uzyskiwanie identyfikatora środowiska App Service Environment
Uruchom następujące polecenia, aby pobrać identyfikator środowiska App Service Environment i zapisać go jako zmienną środowiskową. Zastąp symbole zastępcze nazw i grup zasobów wartościami środowiska App Service Environment, które chcesz zmigrować. ASE_RG i VNET_RG są takie same, jeśli sieć wirtualna i środowisko App Service Environment znajdują się w tej samej grupie zasobów.
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)
3. Sprawdzanie, czy migracja jest obsługiwana
Następujące polecenie sprawdza, czy środowisko App Service Environment jest obsługiwane do migracji. Jeśli wystąpi błąd lub jeśli środowisko App Service Environment jest w złej kondycji lub jest w stanie wstrzymania, nie możesz przeprowadzić migracji w tej chwili. Zobacz sekcję rozwiązywania problemów, aby uzyskać opisy potencjalnych komunikatów o błędach, które można uzyskać. Jeśli środowisko nie jest obsługiwane w przypadku migracji przy użyciu funkcji migracji równoległej lub chcesz przeprowadzić migrację do środowiska App Service Environment w wersji 3 bez korzystania z funkcji migracji równoległej, zobacz opcje migracji ręcznej. To polecenie sprawdza również, czy środowisko App Service Environment znajduje się w obsługiwanej wersji kompilacji na potrzeby migracji. Jeśli środowisko App Service Environment nie korzysta z obsługiwanej wersji kompilacji, musisz samodzielnie uruchomić uaktualnienie. Aby uzyskać więcej informacji na temat uaktualniania premii, zobacz Weryfikowanie, czy migracja jest obsługiwana przy użyciu funkcji migracji równoległej dla środowiska App Service Environment.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=Validation&api-version=2022-03-01"
Jeśli nie ma żadnych błędów, migracja jest obsługiwana i możesz przejść do następnego kroku.
Jeśli musisz uruchomić uaktualnienie w celu uaktualnienia środowiska App Service Environment do obsługiwanej wersji kompilacji, co może potrwać od 8 do 12 godzin lub dłużej w zależności od rozmiaru środowiska, uruchom następujące polecenie. Uruchom to polecenie tylko wtedy, gdy krok weryfikacji zakończy się niepowodzeniem i zostanie wyświetlony monit o uaktualnienie środowiska App Service Environment.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigrationUpgrade&api-version=2022-03-01"
4. Generowanie wychodzących adresów IP dla nowego środowiska App Service Environment w wersji 3
Utwórz plik o nazwie zoneredundancy.json z następującymi szczegółami dotyczącymi wybranego regionu i nadmiarowości strefy.
{
"location":"<region>",
"Properties": {
"zoneRedundant": "<true/false>"
}
}
Możesz zwolnić nową strefę środowiska App Service Environment w wersji 3, jeśli istniejące środowisko znajduje się w regionie obsługującym nadmiarowość stref. Nadmiarowość strefy można skonfigurować, ustawiając zoneRedundant właściwość na true. Nadmiarowość strefy jest opcjonalną konfiguracją. Tę konfigurację można ustawić tylko podczas tworzenia nowego środowiska App Service Environment w wersji 3 i nie można jej usunąć później.
Uruchom następujące polecenie, aby utworzyć nowe wychodzące adresy IP. Wykonanie tego kroku trwa około 15 minut. Nie skaluj ani nie wprowadzaj zmian w istniejącym środowisku App Service Environment w tym czasie.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigration&api-version=2022-03-01" --body @zoneredundancy.json
Uruchom następujące polecenie, aby sprawdzić stan tego kroku:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.status
Jeśli krok jest w toku, otrzymasz stan Migrating. Po otrzymaniu Readystanu uruchom następujące polecenie, aby wyświetlić nowe adresy IP ruchu wychodzącego. Jeśli nowe adresy IP nie są widoczne natychmiast, zaczekaj kilka minut i spróbuj ponownie.
az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2022-03-01" --query properties.windowsOutboundIpAddresses
5. Aktualizowanie zasobów zależnych przy użyciu nowych wychodzących adresów IP
Korzystając z nowych adresów IP ruchu wychodzącego, zaktualizuj dowolne zasoby lub składniki sieciowe, aby upewnić się, że nowe środowisko działa zgodnie z oczekiwaniami po zakończeniu migracji. Twoim obowiązkiem jest wprowadzenie wszelkich niezbędnych aktualizacji.
6. Delegowanie podsieci środowiska App Service Environment
Środowisko App Service Environment w wersji 3 wymaga, aby podsieć miała pojedyncze delegowanie Microsoft.Web/hostingEnvironments. Poprzednie wersje nie wymagały tego delegowania. Przed migracją należy potwierdzić, że podsieć jest delegowana prawidłowo i zaktualizować delegowanie (w razie potrzeby). Delegowanie można zaktualizować, uruchamiając następujące polecenie lub przechodząc do podsieci w witrynie Azure Portal.
az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments
7. Upewnij się, że w sieci wirtualnej nie ma żadnych blokad
Sieć wirtualna blokuje operacje platformy podczas migracji. Jeśli sieć wirtualna ma blokady, przed migracją należy je usunąć. W razie potrzeby możesz dodać blokady po zakończeniu migracji.
Blokady mogą istnieć w trzech zakresach: subskrypcji, grupie zasobów i zasobie. Po zastosowaniu blokady w zakresie nadrzędnym wszystkie zasoby w tym zakresie dziedziczą tę samą blokadę. Jeśli zastosowano blokady w ramach subskrypcji, grupy zasobów lub zakresu zasobów, należy je usunąć przed migracją. Aby uzyskać więcej informacji na temat blokad i dziedziczenia blokad, zobacz Blokowanie zasobów w celu ochrony infrastruktury.
Użyj następującego polecenia, aby sprawdzić, czy sieć wirtualna ma jakiekolwiek blokady:
az lock list --resource-group $VNET_RG --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks
Usuń wszystkie istniejące blokady przy użyciu następującego polecenia:
az lock delete --resource-group $VNET_RG --name <lock-name> --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks
Aby uzyskać powiązane polecenia, aby sprawdzić, czy subskrypcja lub grupa zasobów ma blokady, zobacz dokumentację interfejsu wiersza polecenia platformy Azure dotyczącą blokad.
8. Przygotowywanie konfiguracji
Jeśli istniejące środowisko App Service Environment używa niestandardowego sufiksu domeny, należy skonfigurować go dla nowego zasobu środowiska App Service Environment w wersji 3 podczas procesu migracji. Migracja nie powiedzie się, jeśli nie skonfigurujesz niestandardowego sufiksu domeny i obecnie używasz go. Aby uzyskać więcej informacji na temat niestandardowych sufiksów domeny środowiska App Service Environment w wersji 3, w tym wymagań, instrukcji krok po kroku i najlepszych rozwiązań, zobacz Niestandardowy sufiks domeny dla środowisk App Service Environment.
Uwaga
Jeśli konfigurujesz sufiks domeny niestandardowej, podczas dodawania uprawnień sieci w magazynie kluczy platformy Azure upewnij się, że magazyn kluczy zezwala na dostęp z nowej podsieci środowiska App Service Environment w wersji 3. Jeśli uzyskujesz dostęp do magazynu kluczy przy użyciu prywatnego punktu końcowego, upewnij się, że dostęp prywatny został poprawnie skonfigurowany z nową podsiecią.
Aby ustawić te konfiguracje, w tym zidentyfikować wybraną wcześniej podsieć, utwórz inny plik o nazwie parameters.json z następującymi szczegółami na podstawie danego scenariusza. Pamiętaj, aby użyć nowej podsieci wybranej dla nowego środowiska App Service Environment w wersji 3. Nie uwzględniaj właściwości sufiksu domeny niestandardowej, jeśli ta funkcja nie ma zastosowania do migracji. Zwróć uwagę na wartość zoneRedundant właściwości i ustaw ją na tę samą wartość, która była używana w kroku generowania wychodzącego adresu IP. Należy użyć tej samej wartości dla nadmiarowości strefy, która była używana w kroku generowania wychodzących adresów IP.
Jeśli przeprowadzasz migrację bez sufiksu domeny niestandardowej, użyj tego kodu:
{
"Properties": {
"VirtualNetwork": {
"Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
},
"zoneRedundant": "<true/false>"
}
}
Jeśli używasz tożsamości zarządzanej przypisanej przez użytkownika do konfiguracji sufiksu domeny niestandardowej, użyj tego kodu:
{
"Properties": {
"VirtualNetwork": {
"Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
},
"zoneRedundant": "<true/false>",
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
}
}
}
Jeśli używasz przypisanej przez system tożsamości zarządzanej dla niestandardowej konfiguracji sufiksu domeny, użyj tego kodu:
{
"properties": {
"VirtualNetwork": {
"Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
},
"zoneRedundant": "<true/false>",
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "SystemAssigned"
}
}
}
9. Migrowanie do środowiska App Service Environment w wersji 3 i sprawdzanie stanu
Po wykonaniu wszystkich powyższych kroków możesz rozpocząć migrację. Upewnij się, że rozumiesz implikacje migracji.
Ten krok trwa od trzech do sześciu godzin. W tym czasie nie ma przestoju aplikacji. Skalowanie, wdrożenia i modyfikacje istniejącego środowiska App Service Environment są blokowane w tym kroku.
Uruchom następujące polecenie, aby rozpocząć migrację:
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=HybridDeployment&api-version=2022-03-01" --body @parameters.json
Uruchom następujące polecenie, aby sprawdzić stan migracji:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus
Po zakończeniu MigrationPendingDnsChangemigracji jest wyświetlany stan i masz zasób środowiska App Service Environment w wersji 3. Twoje aplikacje działają teraz w nowym środowisku i w starym środowisku.
Pobierz szczegóły nowego środowiska, uruchamiając następujące polecenie:
az appservice ase show --name $ASE_NAME --resource-group $ASE_RG
Ważne
Podczas migracji, a także w trakcie MigrationPendingDnsChange kroku witryna Azure Portal wyświetla niepoprawne informacje o środowisku App Service Environment i aplikacjach. Użyj interfejsu wiersza polecenia platformy Azure, aby sprawdzić stan migracji. Jeśli masz jakiekolwiek pytania dotyczące stanu migracji lub aplikacji, skontaktuj się z pomocą techniczną.
Uwaga
Jeśli migracja zawiera sufiks domeny niestandardowej, konfiguracja sufiksu domeny niestandardowej może być wyświetlana jako obniżona po zakończeniu migracji z powodu znanej usterki. Środowisko App Service Environment powinno nadal działać zgodnie z oczekiwaniami. Stan obniżonej wydajności powinien zostać rozwiązany w ciągu 6–8 godzin. Jeśli konfiguracja jest obniżona po upływie 8 godzin lub jeśli sufiks domeny niestandardowej nie działa, skontaktuj się z pomocą techniczną.
10. Pobierz przychodzące adresy IP dla nowego środowiska App Service Environment w wersji 3 i zaktualizuj zasoby zależne
Na tym etapie w procesie migracji są dostępne dwa środowiska App Service Environment. Aplikacje działają w obu środowiskach. Należy zaktualizować wszystkie zasoby zależne, aby używać nowego adresu przychodzącego IP dla nowego środowiska App Service Environment w wersji 3. W przypadku środowisk App Service Environment z wewnętrznym modułem równoważenia obciążenia należy zaktualizować prywatne strefy DNS, aby wskazywały nowy przychodzący adres IP.
Nowy adres IP dla ruchu przychodzącego dla nowego środowiska App Service Environment w wersji 3 można uzyskać, uruchamiając następujące polecenie odpowiadające typowi modułu równoważenia obciążenia środowiska App Service Environment. Twoim obowiązkiem jest wprowadzenie wszelkich niezbędnych aktualizacji.
W przypadku środowisk App Service Environment z wewnętrznym modułem równoważenia obciążenia pobierz prywatny adres IP dla ruchu przychodzącego, uruchamiając następujące polecenie:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.internalInboundIpAddresses
W przypadku środowisk ELB App Service Environment pobierz publiczny adres IP dla ruchu przychodzącego, uruchamiając następujące polecenie:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.externalInboundIpAddresses
11. Przekieruj ruch klientów, zweryfikuj środowisko App Service Environment w wersji 3 i ukończ migrację
Ten krok jest okazją do przetestowania i zweryfikowania nowego środowiska App Service Environment w wersji 3. Domyślnie ruch jest wysyłany do frontonów środowiska App Service Environment w wersji 2. Jeśli używasz środowiska App Service Environment wewnętrznego modułu równoważenia obciążenia w wersji 3, możesz przetestować frontony środowiska App Service Environment w wersji 3, aktualizując prywatną strefę DNS przy użyciu nowego przychodzącego adresu IP. Jeśli używasz środowiska ELB App Service Environment w wersji 3, proces testowania zależy od określonej konfiguracji sieci. Jedną z prostych metod testowania dla środowisk ELB jest zaktualizowanie pliku hostów w celu użycia nowego adresu IP przychodzącego środowiska App Service Environment w wersji 3. Jeśli masz domeny niestandardowe przypisane do poszczególnych aplikacji, możesz też zaktualizować ich system DNS tak, aby wskazywał nowy przychodzący adres IP. Testowanie tej zmiany pozwala w pełni zweryfikować środowisko App Service Environment w wersji 3 przed zainicjowanym ostatnim krokiem migracji, w którym stare środowisko App Service Environment zostało usunięte. Jeśli możesz uzyskać dostęp do aplikacji bez problemów, oznacza to, że wszystko jest gotowe do ukończenia migracji.
Po potwierdzeniu, że aplikacje działają zgodnie z oczekiwaniami, możesz przekierować ruch klientów do nowego środowiska App Service Environment w wersji 3, uruchamiając następujące polecenie. To polecenie powoduje również usunięcie starego środowiska. Ten krok należy wykonać przez 14 dni. Jeśli ten krok nie zostanie ukończony w ciągu 14 dni, migracja zostanie automatycznie przywrócona do środowiska App Service Environment w wersji 2. Jeśli do wykonania tego kroku potrzebujesz więcej niż 14 dni, skontaktuj się z pomocą techniczną.
Jeśli w tym momencie znajdziesz jakiekolwiek problemy lub zdecydujesz, że nie chcesz już kontynuować migracji, skontaktuj się z pomocą techniczną, aby przywrócić migrację. Nie uruchamiaj polecenia zmiany DNS, jeśli chcesz przywrócić migrację. Aby uzyskać więcej informacji, zobacz Przywracanie migracji.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=DnsChange&api-version=2022-03-01"
Uruchom następujące polecenie, aby sprawdzić stan tego kroku:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus
W tym kroku zostanie wyświetlony stan CompletingMigration. Po otrzymaniu MigrationCompletedstanu krok przekierowania ruchu zostanie wykonany i migracja zostanie ukończona.