Migracja do środowiska App Service Environment w wersji 3
Uwaga
Dostępne są dwie funkcje automatycznej migracji, które ułatwiają uaktualnienie do środowiska App Service Environment w wersji 3. Aby dowiedzieć się więcej na temat tych funkcji i pomóc w podejmowaniu decyzji o tym, która opcja migracji jest odpowiednia dla Ciebie, zobacz Drzewo decyzyjne ścieżki migracji. Rozważ jedną z automatycznych opcji szybszej ścieżki do środowiska App Service Environment w wersji 3.
Jeśli obecnie używasz środowiska App Service Environment w wersji 1 lub 2, możesz przeprowadzić migrację obciążeń do środowiska App Service Environment w wersji 3. Środowisko App Service Environment w wersji 3 ma zalety i różnice w funkcjach , które zapewniają rozszerzoną obsługę obciążeń i mogą zmniejszyć ogólne koszty. Rozważ użycie funkcji automatycznej migracji, jeśli środowisko spełnia kryteria opisane w drzewie decyzyjnym ścieżki migracji.
Jeśli środowisko App Service Environment nie jest obsługiwane w przypadku funkcji migracji, należy użyć jednej z metod ręcznych, aby przeprowadzić migrację do środowiska App Service Environment w wersji 3.
Wymagania wstępne
Scenariusz: masz aplikację działającą w środowisku App Service Environment w wersji 1 lub App Service Environment w wersji 2 i potrzebujesz tej aplikacji do uruchomienia w środowisku App Service Environment w wersji 3.
W przypadku każdej metody migracji, która nie korzysta z funkcji automatycznej migracji, należy utworzyć zasób środowiska App Service Environment w wersji 3 i nową podsieć przy użyciu wybranej metody.
Zmiany sieci między środowiskami App Service Environment w wersji 1/2 i App Service Environment w wersji 3 obejmują nowe (i dla środowisk internetowych, dodatkowe) adresy IP. Należy zaktualizować dowolną infrastrukturę, która opiera się na tych adresach IP. Pamiętaj, aby uwzględnić zmiany zależności dla ruchu przychodzącego, takie jak port usługi Azure Load Balancer.
Wiele środowisk App Service Environment nie może istnieć w jednej podsieci. Jeśli musisz użyć istniejącej podsieci dla nowego zasobu środowiska App Service Environment w wersji 3, przed utworzeniem nowego musisz usunąć istniejące środowisko App Service Environment. W tym scenariuszu zalecamy utworzenie kopii zapasowej aplikacji, a następnie przywrócenie ich w nowym środowisku po utworzeniu i skonfigurowaniu środowiska. Ten proces powoduje przestój aplikacji ze względu na czas potrzebny na:
- Usuń stare środowisko.
- Utwórz zasób środowiska App Service Environment w wersji 3.
- Skonfiguruj dowolną infrastrukturę i połączone zasoby do pracy z nowym środowiskiem.
- Wdróż aplikacje w nowym środowisku.
Lista kontrolna przed migracją aplikacji
- Utwórz zasób środowiska App Service Environment w wersji 3 .
- Zaktualizuj wszystkie zależności sieciowe przy użyciu adresów IP skojarzonych z nowym środowiskiem.
- Zaplanuj przestój (jeśli ma to zastosowanie).
- Zdecyduj o procesie ponownego tworzenia aplikacji w nowym środowisku.
Rozmiar i skalowanie środowiska
Środowisko App Service Environment w wersji 3 używa planów usługi izolowanych w wersji 2 aplikacja systemu Azure w wersji 2, które są wyceniane i mają inny rozmiar niż plany izolowane. Przejrzyj szczegóły cennika, aby dowiedzieć się, jak nowe środowisko musi mieć rozmiar i skalowane w celu zapewnienia odpowiedniej pojemności. Nie ma różnicy w sposobie tworzenia planów usługi App Service dla środowiska App Service Environment w wersji 3 w porównaniu z poprzednimi wersjami.
Ocena kopii zapasowej i przywracania
Możesz użyć funkcji tworzenia kopii zapasowej i przywracania , aby zachować konfigurację aplikacji, zawartość pliku i bazę danych połączoną z aplikacją podczas migracji do nowego środowiska.
Aby przywrócić je do środowiska App Service Environment w wersji 3, należy skonfigurować niestandardowe kopie zapasowe dla aplikacji. Automatyczne tworzenie kopii zapasowej nie obsługuje przywracania w różnych wersjach środowiska App Service Environment. Aby uzyskać więcej informacji na temat niestandardowych kopii zapasowych, zobacz Automatyczne i niestandardowe kopie zapasowe.
Możesz wybrać niestandardową kopię zapasową i przywrócić ją do usługi App Service w zasobie środowiska App Service Environment w wersji 3. Przed przywróceniem aplikacji należy utworzyć plan usługi App Service, do którego zostanie przywrócona. Możesz przywrócić kopię zapasową do miejsca produkcyjnego, istniejącego miejsca lub nowego miejsca utworzonego podczas procesu przywracania.
Świadczenia | Ograniczenia |
---|---|
Szybkie — powinno potrwać od 5 do 10 minut na aplikację. | Obsługa jest ograniczona do niektórych typów baz danych. |
Jednocześnie można przywrócić wiele aplikacji. (Należy skonfigurować przywracanie dla każdej aplikacji osobno). | Stare środowisko, nowe środowisko i zasoby pomocnicze (na przykład aplikacje, bazy danych, konta magazynu i kontenery) muszą znajdować się w tej samej subskrypcji. |
Bazy danych MySQL w aplikacji są automatycznie tworzone bez żadnej konfiguracji. | Kopie zapasowe mogą mieć maksymalnie 10 GB zawartości aplikacji i bazy danych. Do 4 GB tej zawartości może być kopia zapasowa bazy danych. Jeśli rozmiar kopii zapasowej przekroczy ten limit, zostanie wyświetlony błąd. |
Aplikację można przywrócić do migawki poprzedniego stanu. | Używanie konta magazynu z obsługą zapory jako miejsca docelowego kopii zapasowych nie jest obsługiwane. |
Możesz zintegrować z usługą Azure Traffic Manager i usługą aplikacja systemu Azure Gateway, aby dystrybuować ruch między starymi i nowymi środowiskami. | Używanie konta magazynu z prywatnymi punktami końcowymi do tworzenia kopii zapasowych i przywracania nie jest obsługiwane. |
Możesz utworzyć puste aplikacje internetowe, aby przywrócić je w nowym środowisku przed rozpoczęciem przywracania, aby przyspieszyć proces. | Obsługiwane są tylko niestandardowe kopie zapasowe. |
Klonowanie aplikacji do środowiska App Service Environment w wersji 3
Klonowanie aplikacji to kolejna funkcja, której można użyć do pobrania aplikacji systemu Windows do środowiska App Service Environment w wersji 3. Ograniczenia dotyczące klonowania aplikacji są takie same jak w przypadku funkcji tworzenia kopii zapasowej usługi App Service. Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowej aplikacji w usłudze aplikacja systemu Azure Service.
Uwaga
Klonowanie aplikacji jest obsługiwane tylko w przypadku planów usługi App Service w systemie Windows.
Zalecamy to rozwiązanie dla użytkowników korzystających z usługi App Service w systemie Windows i nie można przeprowadzić migracji przy użyciu funkcji migracji. Przed sklonowanie wszystkich aplikacji należy skonfigurować nowy zasób środowiska App Service Environment w wersji 3. Klonowanie aplikacji może potrwać do 30 minut.
Aby sklonować aplikację przy użyciu programu PowerShell, zobacz instrukcje.
Aby sklonować aplikację przy użyciu witryny Azure Portal:
W witrynie Azure Portal przejdź do istniejącego planu usługi App Service. W obszarze Narzędzia programistyczne wybierz pozycję Klonuj aplikację.
Wypełnij wymagane pola, używając szczegółów nowego zasobu środowiska App Service Environment w wersji 3:
- W obszarze Grupa zasobów wybierz istniejącą grupę zasobów lub utwórz nową.
- W polu Nazwa nadaj aplikacji nazwę. Ta nazwa może być taka sama jak stara aplikacja, ale domyślny adres URL witryny dla nowego środowiska będzie inny. Należy zaktualizować wszystkie niestandardowe zasoby DNS lub połączone, aby wskazywały nowy adres URL.
- W polu Region użyj nazwy środowiska App Service Environment w wersji 3.
- Jeśli chcesz sklonować źródło wdrożenia, zaznacz pole wyboru Klonuj źródło wdrożenia.
- W przypadku planu systemu Windows możesz użyć istniejącego planu usługi App Service z nowego środowiska, jeśli został już utworzony, lub utworzyć nowy plan. Dostępne plany usługi App Service w nowym zasobie środowiska App Service Environment w wersji 3 są wyświetlane na liście rozwijanej.
- W przypadku jednostki SKU i rozmiaru zmodyfikuj pamięć i procesor zgodnie z potrzebami, używając jednej z opcji Izolowane w wersji 2, jeśli tworzysz nowy plan usługi App Service. Środowisko App Service Environment w wersji 3 używa planów izolowanych w wersji 2, które mają więcej pamięci i procesora CPU na odpowiedni rozmiar wystąpienia w porównaniu z planami izolowanymi. Aby uzyskać więcej informacji, zobacz szczegóły cennika środowiska App Service Environment w wersji 3.
Świadczenia | Ograniczenia |
---|---|
Klonowanie można zautomatyzować przy użyciu programu PowerShell. | Obsługiwane tylko w przypadku planów usługi App Service w systemie Windows. |
Jednocześnie można sklonować wiele aplikacji. (Klonowanie musi być skonfigurowane dla każdej aplikacji indywidualnie lub za pomocą skryptu). | Obsługa jest ograniczona do niektórych typów baz danych. |
Możesz zintegrować z usługą Azure Traffic Manager i usługą aplikacja systemu Azure Gateway, aby dystrybuować ruch między starymi i nowymi środowiskami. | Stare środowisko, nowe środowisko i zasoby pomocnicze (na przykład aplikacje, bazy danych, konta magazynu i kontenery) muszą znajdować się w tej samej subskrypcji. |
Ręczne tworzenie aplikacji w środowisku App Service Environment w wersji 3
Jeśli funkcja migracji nie obsługuje aplikacji lub chcesz wykonać bardziej ręczną trasę, możesz wdrożyć aplikacje, wykonując ten sam proces, który był używany w istniejącym środowisku App Service Environment.
Możesz wyeksportować szablony usługi Azure Resource Manager (szablony usługi ARM) istniejących aplikacji, planów usługi App Service i innych obsługiwanych zasobów oraz wdrożyć je w nowym środowisku lub w nowym środowisku. Aby wyeksportować szablon tylko dla aplikacji, przejdź do planu usługi App Service. W obszarze Automatyzacja wybierz pozycję Eksportuj szablon.
Szablony dla wielu zasobów można również wyeksportować bezpośrednio z grupy zasobów. Przejdź do grupy zasobów, wybierz zasoby, dla których chcesz utworzyć szablon, a następnie wybierz pozycję Eksportuj szablon.
Następujące początkowe zmiany w szablonach usługi ARM są wymagane do pobrania aplikacji do środowiska App Service Environment w wersji 3:
Aktualizowanie
sku
parametrów planu usługi App Service dla planu izolowanego w wersji 2:"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 },
Zaktualizuj parametr plan usługi App Service (
serverfarm
), do którego aplikacja zostanie wdrożona w planie skojarzonym ze środowiskiem App Service Environment w wersji 3.Zaktualizuj parametr profilu środowiska hostingu (
hostingEnvironmentProfile
) do nowego identyfikatora zasobu środowiska App Service Environment w wersji 3.Eksport szablonu usługi ARM zawiera wszystkie właściwości udostępniane przez dostawców zasobów dla zasobów. Usuń wszystkie niezamagane właściwości, takie jak właściwości wskazujące domenę starej aplikacji. Na przykład można uprościć
sites
zasób do następującego przykładu:"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')]" } }
Inne zmiany mogą być wymagane w zależności od sposobu konfigurowania aplikacji. Jeśli na przykład używasz tożsamości zarządzanych przypisanych przez system i tych samych nazw aplikacji dla starych i nowych środowisk, mogą wystąpić konflikty. Aby rozwiązać ten konflikt i uniknąć przestojów, możesz użyć tożsamości zarządzanej przypisanej przez użytkownika.
Szablony usługi ARM można wdrażać przy użyciu witryny Azure Portal, interfejsu wiersza polecenia platformy Azure lub programu PowerShell.
Migracja ręczna
Funkcja migracji w miejscu automatyzuje migrację do środowiska App Service Environment w wersji 3 i przenosi wszystkie aplikacje do nowego środowiska. Podczas tej migracji występuje około godziny przestoju. Jeśli aplikacje nie mogą mieć żadnych przestojów, zalecamy użycie funkcji migracji równoległej, która jest opcją migracji bez przestojów, ponieważ nowe środowisko zostało utworzone w innej podsieci. Jeśli również nie chcesz używać funkcji migracji równoległej, możesz użyć jednej z opcji ręcznych, aby ponownie utworzyć aplikacje w środowisku App Service Environment w wersji 3.
Ruch między starymi i nowymi środowiskami można dystrybuować przy użyciu usługi Application Gateway. Jeśli używasz środowiska App Service Environment wewnętrznego modułu równoważenia obciążenia( ILB), utwórz wystąpienie bramy aplikacja systemu Azure z dodatkową pulą zaplecza w celu dystrybucji ruchu między środowiskami. Aby uzyskać informacje o środowiskach App Service Environment modułu równoważenia obciążenia i środowiskach App Service Environment dostępnych z Internetu, zobacz Integracja usługi Application Gateway.
Możesz również użyć usług, takich jak Azure Front Door, Azure Content Delivery Network i Azure Traffic Manager , aby dystrybuować ruch między środowiskami. Korzystanie z tych usług umożliwia testowanie nowego środowiska w kontrolowany sposób i ułatwia przejście do nowego środowiska we własnym tempie.
Po zakończeniu migracji i wszystkich testów w nowym środowisku usuń stare środowisko App Service Environment, aplikacje, które są w nim używane i wszystkie zasoby pomocnicze, których już nie potrzebujesz. Opłaty za zasoby, które nie zostaną usunięte, będą nadal naliczane opłaty.
Często zadawane pytania
Jak mogę wiedzieć, czy należy przeprowadzić migrację do środowiska App Service Environment w wersji 3 przy użyciu jednej z opcji ręcznych?
Aby uzyskać pomoc przy podejmowaniu decyzji o tym, która opcja migracji jest odpowiednia, zobacz Drzewo decyzyjne ścieżki migracji. Jeśli środowisko spełnia kryteria opisane w drzewie decyzyjnym ścieżki migracji, rozważ użycie jednej z funkcji automatycznej migracji w celu szybszej ścieżki do środowiska App Service Environment w wersji 3. Migracja ręczna jest zalecana, jeśli musisz powoli przenosić aplikacje do nowego środowiska i weryfikować je w całym procesie.Czy podczas migracji wystąpi przestój?
Przestój zależy od procesu migracji. Jeśli masz inne środowisko App Service Environment, do którego można wskazać ruch podczas migracji, lub jeśli możesz użyć innej podsieci do utworzenia nowego środowiska, nie będziesz mieć przestoju. Jeśli musisz użyć tej samej podsieci, podczas usuwania starego środowiska następuje przestój, utworzenie zasobu środowiska App Service Environment w wersji 3, utworzenie nowych planów usługi App Service, ponowne utworzenie aplikacji i zaktualizowanie wszystkich zasobów korzystających z nowych adresów IP.Czy muszę zmienić coś na temat moich aplikacji, aby można je było uruchamiać w środowisku App Service Environment w wersji 3?
L.p. Aplikacje uruchamiane w środowisku App Service Environment w wersji 1 i 2 nie powinny wymagać żadnych modyfikacji do uruchamiania w środowisku App Service Environment w wersji 3. Jeśli używasz protokołu IP SSL, przed przeprowadzeniem migracji musisz usunąć powiązania PROTOKOŁU SSL ip.Co zrobić, jeśli środowisko App Service Environment posiada niestandardowy sufiks domeny?
Funkcja migracji obsługuje ten scenariusz migracji. Migrację można przeprowadzić przy użyciu metody ręcznej, jeśli nie chcesz używać funkcji migracji. Sufiks domeny niestandardowej można skonfigurować podczas tworzenia zasobu środowiska App Service Environment w wersji 3 lub w dowolnym momencie po.Co zrobić, jeśli mój zasób środowiska App Service Environment w wersji 2 jest przypięty do strefy?
Przypinanie strefy nie jest obsługiwaną funkcją w środowisku App Service Environment w wersji 3. Możesz włączyć nadmiarowość strefową podczas tworzenia zasobu środowiska App Service Environment w wersji 3.Jakie właściwości środowiska App Service Environment zmienią?
Zapoznaj się z różnicami funkcji między środowiskiem App Service Environment w wersji 3 i poprzednimi wersjami. W przypadku środowisk App Service Environment z wewnętrznym modułem równoważenia obciążenia zachowasz ten sam adres IP modułu równoważenia obciążenia. W przypadku środowisk App Service Environment dostępnych z Internetu publiczny adres IP i adres IP ruchu wychodzącego zmieniają się.W przypadku środowisk App Service Environment dostępnych z Internetu wcześniej istniał pojedynczy adres IP zarówno dla ruchu przychodzącego, jak i wychodzącego. W przypadku środowiska App Service Environment w wersji 3 są one oddzielne. Aby uzyskać więcej informacji, zobacz Sieć środowiska usługi App Service v3.
Czy tworzenie kopii zapasowych i przywracanie jest obsługiwane w przypadku przenoszenia aplikacji ze środowiska App Service Environment w wersji 2 do wersji 3? Funkcja tworzenia kopii zapasowej i przywracania obsługuje przywracanie aplikacji między wersjami środowiska App Service Environment, o ile używasz niestandardowej kopii zapasowej na potrzeby przywracania. Automatyczna kopia zapasowa nie obsługuje przywracania do różnych wersji środowiska App Service Environment.
Co się stanie z zasobami środowiska App Service Environment w wersji 1 i 2 po 31 sierpnia 2024 r.?
Po 31 sierpnia 2024 r. jeśli nie przeprowadzono migracji do środowiska App Service Environment w wersji 3, zasoby środowiska App Service Environment w wersji 1 i 2 oraz wdrożone w nich aplikacje nie będą już dostępne.Środowisko App Service Environment w wersji 1 i 2 są hostowane w jednostkach skalowania usługi App Service uruchamianych w architekturze usług Azure Cloud Services (klasycznej ). Ponieważ ta architektura zostanie wycofana 31 sierpnia 2024 r., środowisko App Service Environment w wersji 1 i 2 nie będzie dostępne po tej dacie. Przeprowadź migrację do środowiska App Service Environment w wersji 3, aby zachować działanie aplikacji lub zapisać lub utworzyć kopię zapasową wszystkich zasobów lub danych, które należy zachować.