Przenoszenie usług aplikacja systemu Azure do innego regionu

W tym artykule opisano sposób przenoszenia zasobów usługi App Service do innego regionu świadczenia usługi Azure.

Istnieją różne powody, dla których możesz przenieść istniejące zasoby platformy Azure z jednego regionu do innego. Możesz chcieć:

• Skorzystaj z nowego regionu świadczenia usługi Azure.
• Wdrażanie funkcji lub usług dostępnych tylko w określonych regionach.
• Spełnij wymagania dotyczące zasad wewnętrznych i ładu.
• Dopasowanie do fuzji i przejęć firmy
• Spełnianie wymagań dotyczących planowania pojemności.

Zasoby usługi App Service są specyficzne dla regionu i nie można ich przenosić między regionami. Musisz utworzyć kopię istniejących zasobów usługi App Service w regionie docelowym, a następnie przenieść zawartość do nowej aplikacji. Jeśli aplikacja źródłowa używa domeny niestandardowej, możesz przeprowadzić migrację jej do nowej aplikacji w regionie docelowym po zakończeniu relokacji.

Aby ułatwić kopiowanie aplikacji, możesz utworzyć kopię zapasową i przywrócić pojedynczą aplikację usługi App Service do planu usługi App Service w innym regionie.

Wymagania wstępne

• Upewnij się, że aplikacja usługi App Service znajduje się w regionie świadczenia usługi Azure, z którego chcesz się przenieść.
• Upewnij się, że region docelowy obsługuje usługę App Service i dowolną powiązaną usługę, której zasoby chcesz przenieść.
• Sprawdź, czy istnieją wystarczające uprawnienia do wdrażania zasobów usługi App Service w subskrypcji docelowej i regionie.
• Sprawdź, czy jakiekolwiek zasady platformy Azure są przypisane z ograniczeniem regionu.
• Rozważ wszelkie koszty operacyjne, ponieważ ceny zasobów obliczeniowych mogą się różnić w zależności od regionu do regionu. Aby oszacować możliwe koszty, zobacz Kalkulator cen.

Przygotowywanie

Zidentyfikuj wszystkie aktualnie używane zasoby usługi App Service. Na przykład:

• Aplikacje usługi App Service
• Plany usługi App Service
• Miejsca wdrożenia
• Domeny niestandardowe zakupione na platformie Azure
• Certyfikaty TLS/SSL
• Integracja z usługą Azure Virtual Network
• Połączenia hybrydowe.
• Tożsamości zarządzane
• Ustawienia kopii zapasowej

Niektóre zasoby, takie jak zaimportowane certyfikaty lub połączenia hybrydowe, zawierają integrację z innymi usługami platformy Azure. Aby uzyskać informacje na temat przenoszenia tych zasobów między regionami, zobacz dokumentację odpowiednich usług.

Planowanie

Ta sekcja jest listą kontrolną planowania w następujących obszarach:

• Zależności stanu, magazynu i podrzędnego
• Certyfikaty
• Konfigurowanie
• Łączność z siecią wirtualną / nazwy niestandardowe / DNS
• Tożsamości
• Punkty końcowe usługi

Zależności stanu, magazynu i podrzędnego

• Ustal, czy aplikacja usługi App Service jest stanowa, czy bezstanowa. Mimo że zalecamy, aby aplikacje usługi App Service były bezstanowe, a pliki na %HOME%\site dysku powinny być tylko tymi, które są wymagane do uruchomienia wdrożonej aplikacji z dowolnymi plikami tymczasowymi, nadal można przechowywać stan aplikacji środowiska uruchomieniowego na %HOME%\site dysku wirtualnym. Jeśli aplikacja zapisuje stan na udostępnionej ścieżce magazynu aplikacji, pamiętaj, aby zaplanować sposób zarządzania tym stanem podczas przenoszenia zasobu.

  Napiwek

  Możesz użyć narzędzia Kudu, aby wraz z dostępem do portalu udostępnić interfejs API dostępu do plików (wirtualny system plików (VFS)), który może odczytywać/zapisywać pliki w %HOME%\site katalogu. Aby uzyskać więcej informacji, zobacz Kudu Wiki.

• Sprawdź wewnętrzne buforowanie i stan w kodzie aplikacji.

• Wyłącz ustawienie koligacji sesji. Jeśli to możliwe, zalecamy wyłączenie ustawienia koligacji sesji. Wyłączenie koligacji sesji poprawia równoważenie obciążenia dla poziomego skalowania w poziomie. Każdy stan wewnętrzny może mieć wpływ na planowanie cięcia obciążenia — szczególnie jeśli wymagany jest zerowy czas pracy. Jeśli to możliwe, korzystne może być refaktoryzację dowolnego stanu aplikacji, aby aplikacja była bezstanowa w ramach przygotowań do przeniesienia.

• Analizowanie parametry połączenia bazy danych. Parametry połączenia bazy danych można znaleźć w obszarze Ustawienia aplikacji. Mogą być one jednak również zakodowane w kodzie twardym lub zarządzane w plikach konfiguracji dostarczanych z aplikacją. Analizowanie i planowanie migracji/replikacji danych w ramach planowania wyższego poziomu w celu przeniesienia obciążenia. W przypadku aplikacji krytycznych o czacie lub opóźnieniach aplikacja w regionie docelowym nie jest wydajna, aby wrócić do źródeł danych w regionie źródłowym.

• Analizowanie zewnętrznego buforowania (na przykład Redis). Pamięci podręczne aplikacji powinny być wdrażane jak najbliżej aplikacji. Przeanalizuj sposób wypełniania pamięci podręcznej, zasad wygasania/eksmisji i wpływu na zimną pamięć podręczną mogą mieć na pierwszych użytkowników dostęp do obciążenia po przecięciu.

• Analizowanie i planowanie zależności interfejsu API (lub aplikacji) między regionami jest znacznie mniej wydajne, jeśli aplikacja w regionie docelowym wraca do zależności, które nadal znajdują się w regionie źródłowym. Zalecamy przeniesienie wszystkich zależności podrzędnych w ramach relokacji obciążenia. Jednak *zasoby lokalne* są wyjątkiem, w szczególności tych zasobów, które są geograficznie bliżej regionu docelowego (tak jak w przypadku scenariuszy repatriacji).

  Usługa Azure Container Registry może być zależnością podrzędną (środowiska uruchomieniowego) dla usługi App Service skonfigurowanej do uruchamiania względem niestandardowych obrazów kontenerów. Bardziej sensowne jest, aby usługa Container Registry znajdowała się w tym samym regionie co sama aplikacja. Rozważ przekazanie wymaganych obrazów do nowego rekordu ACR w docelowym regionie pobierania. W przeciwnym razie rozważ użycie funkcji replikacji geograficznej, jeśli planujesz przechowywanie obrazów w regionie źródłowym.

• Analizowanie i planowanie usług regionalnych. Dane usługi Application Insights i Log Analytics to usługi regionalne. Rozważ utworzenie nowego magazynu usługi Application Insights i usługi Log Analytics w regionie docelowym. W przypadku usługi App Insights nowy zasób ma również wpływ na parametry połączenia, które należy zaktualizować w ramach zmiany w usłudze App Configuration.

Certyfikaty

Zasoby certyfikatów usługi App Service można przenieść do nowej grupy zasobów lub subskrypcji, ale nie między regionami. Certyfikaty, które można wyeksportować, można również zaimportować do aplikacji lub do usługi Key Vault w nowym regionie. Ten proces eksportowania i importowania jest odpowiednikiem przenoszenia między regionami.

Istnieją różne typy certyfikatów, które należy wziąć pod uwagę podczas planowania relokacji usług:

Typ certyfikatu	Można eksportować	Komentarze
Zarządzane przez usługę App Service	Nie.	Utwórz ponownie te certyfikaty w nowym regionie.
Zarządzane przez usługę Azure Key Vault	Tak	Te certyfikaty można wyeksportować z usługi Key Vault, a następnie zaimportować do usługi Key Vault w nowym regionie.
Klucz prywatny (self-managed)	Tak	Certyfikaty uzyskane poza platformą Azure można wyeksportować z usługi App Service, a następnie zaimportować je do nowej aplikacji lub do usługi Key Vault w nowym regionie.
Klucz publiczny	Nie.	Aplikacja może mieć certyfikaty z kluczem publicznym i bez wpisu tajnego, które są używane do uzyskiwania dostępu do innych zabezpieczonych punktów końcowych. Uzyskaj wymagane pliki certyfikatu klucza publicznego i zaimportuj je do aplikacji w nowym regionie.

Kilka dalszych kwestii, które należy wziąć pod uwagę:

• Adresy przypisane do aplikacji, w których połączenie SSL aplikacji usługi App Service jest powiązane z określonym wyznaczonym adresem IP aplikacji, może służyć do wywołań dozwolonych z sieci innych firm do usługi App Service. Na przykład administrator sieci/IT może chcieć zablokować połączenia wychodzące z sieci lokalnej lub sieci wirtualnej, aby używać statycznego, dobrze znanego adresu. W związku z tym, jeśli funkcja Adres przypisany do aplikacji jest używana, nadrzędne reguły zapory — takie jak wewnętrzne, zewnętrzne lub zewnętrzne — dla osób wywołujących w aplikacji powinny być sprawdzane i informowane o nowym adresie. Reguły zapory mogą być wewnętrznymi, zewnętrznymi lub zewnętrznymi firmami, takimi jak partnerzy lub dobrze znani klienci.

• Rozważ wszelkie nadrzędne wirtualne urządzenie sieciowe (WUS) lub zwrotny serwer proxy. Konfiguracja urządzenia WUS może wymagać zmiany, jeśli zapisujesz nagłówek hosta lub/lub kończysz protokół SSL.

Uwaga

Środowisko App Service Environment jest jedyną ofertą usługi App Service, która umożliwia wywołania podrzędne do zależności aplikacji podrzędnych za pośrednictwem protokołu SSL, gdzie protokół SSL opiera się na samodzielnie podpisanej/PKI z wbudowanymi niestandardowymi certyfikatami głównego urzędu certyfikacji. Usługa wielodostępna nie zapewnia klientom dostępu do przekazywania do zaufanego magazynu certyfikatów.

Obecnie środowisko App Service Environment nie zezwala na zakup certyfikatów SSL, tylko bring your own certificates( Bring Your Own Certificates). Protokół IP-SSL nie jest możliwy (i nie ma sensu), ale SNI jest. Wewnętrzne środowisko App Service Environment nie byłoby skojarzone z domeną publiczną, dlatego używane certyfikaty SSL muszą być dostarczane przez klienta i dlatego można je transportować, na przykład certyfikaty do użytku wewnętrznego wygenerowanego przy użyciu infrastruktury kluczy publicznych. Środowisko App Service Environment w wersji 3 w trybie zewnętrznym współudzieli te same funkcje co zwykła wielodostępna usługa App Service.

Konfigurowanie

• Możesz przechwycić migawkę istniejących ustawień aplikacji i parametry połączenia z witryny Azure Portal. Rozwiń węzeł Ustawienia>Zmienne środowiskowe, wybierz pozycję Edycja zaawansowana w obszarze Ustawienia aplikacji lub Ciągi połączeń i zapisz dane wyjściowe JSON zawierające istniejące ustawienia lub połączenia. Należy ponownie utworzyć te ustawienia w nowym regionie, ale same wartości prawdopodobnie zmienią się w wyniku kolejnych zmian regionów w połączonych usługach.

• Istniejących odwołań usługi Key Vault nie można wyeksportować na granicę geograficzną platformy Azure. Należy ponownie utworzyć wszystkie wymagane odwołania w nowym regionie.

• Konfiguracja aplikacji może być zarządzana przez aplikacja systemu Azure Configuration lub z innej zależności centralnej (podrzędnej) bazy danych. Zapoznaj się z dowolnym magazynem usługi App Configuration lub podobnymi magazynami dla ustawień specyficznych dla środowiska i regionu, które mogą wymagać modyfikacji.

• Upewnij się, że sprawdź konfigurację pliku dysku, która może lub nie jest zastępowana przez ustawienia aplikacji.

Łączność z siecią wirtualną / nazwy niestandardowe / DNS

• App Service Environment to pojedyncza usługa dzierżawy z obsługą sieci wirtualnej. Sieć środowiska App Service Environment różni się od wielodostępnej usługi App Service, która wymaga jednej lub obu "prywatnych punktów końcowych" lub "regionalnej integracji z siecią wirtualną". Inne opcje, które mogą być w grze, obejmują starszą integrację sieci VPN typu punkt-lokacja i połączenia hybrydowe (usługa Azure Relay).

  Uwaga

  Sieć ASEv3 jest uproszczona — ruch usługi Azure Management i własne zależności podrzędne środowiska App Service Environment nie są widoczne dla sieci wirtualnej klienta, co znacznie upraszcza konfigurację wymaganą, gdy klient korzysta z tunelu wymuszonego dla całego ruchu lub wysyłania podzbioru ruchu wychodzącego za pośrednictwem wirtualnego urządzenia sieciowego/zapory.

  Połączenia hybrydowe (Azure Relay) są regionalne. Jeśli są używane połączenia hybrydowe i chociaż przestrzeń nazw usługi Azure Relay może zostać przeniesiona do innego regionu, łatwiej byłoby ponownie wdrożyć połączenie hybrydowe (upewnij się, że połączenie hybrydowe jest skonfigurowane w nowym regionie w ramach wdrażania zasobów docelowych) i ponownie połącz je z Menedżer połączeń hybrydowych. Należy dokładnie rozważyć lokalizację Menedżer połączeń hybrydowych.

• Postępuj zgodnie ze strategią dla ciepłego regionu rezerwowego. Upewnij się, że podstawowa sieć i łączność, sieć koncentratora, kontrolery domeny, dns, sieć VPN lub usługa Express Route itp., są obecne i testowane przed przeniesieniem zasobów.

• Zweryfikuj wszystkie listy ACL i konfigurację sieci nadrzędnej lub podrzędnej. Rozważmy na przykład zewnętrzną usługę podrzędną, która zezwala tylko na ruch aplikacji. Przeniesienie do nowego planu aplikacji dla wielodostępnej usługi App Service spowoduje również zmianę wychodzących adresów IP.

• W większości przypadków najlepiej upewnić się, że sieci wirtualne regionu docelowego mają unikatową przestrzeń adresową. Unikatowa przestrzeń adresowa ułatwia łączność z siecią wirtualną, jeśli jest wymagana, na przykład do replikowania danych. W związku z tym w tych scenariuszach istnieje niejawne wymaganie zmiany:

  • Prywatna strefa DNS
  • Każda zakodowana lub zewnętrzna konfiguracja, która odwołuje się do zasobów według adresu IP (bez nazwy hosta)
  • Listy ACL sieci, w tym sieciowe grupy zabezpieczeń i konfiguracja zapory (należy również rozważyć wpływ na wszystkie lokalne urządzenia WUS)
  • Wszystkie reguły routingu, tabele tras zdefiniowane przez użytkownika

  Ponadto upewnij się, że konfiguracja obejmuje zakresy adresów IP lub tagi usługi specyficzne dla regionu, jeśli przeprowadzasz istniejące zasoby wdrożenia metodyki DevOps.

• W przypadku prywatnej usługi DNS wdrożonej przez klienta jest wymagana mniejsza liczba zmian skonfigurowanych do przekazywania dalej na platformę Azure dla domen platformy Azure i stref prywatnych usługi Azure DNS. Jednak ponieważ prywatne punkty końcowe są oparte na nazwie FQDN zasobu i często jest to również nazwa zasobu (która może być inna w regionie docelowym), pamiętaj, aby sprawdzić krzyżowo konfigurację, aby upewnić się, że nazwy FQDN, do których odwołuje się konfiguracja, są odpowiednio aktualizowane.

• Utwórz ponownie prywatne punkty końcowe, jeśli są używane, w regionie docelowym. Dotyczy to również integracji regionalnej sieci wirtualnej.

• Usługa DNS dla środowiska App Service Environment jest zwykle zarządzana za pośrednictwem prywatnego niestandardowego rozwiązania DNS klientów (w przypadku poszczególnych aplikacji w warstwie Podstawowa dostępne są ustawienia ręczne). Środowisko App Service Environment zapewnia moduł równoważenia obciążenia dla ruchu przychodzącego/wychodzącego, a sama usługa App Service filtruje nagłówki hosta. W związku z tym wiele nazw niestandardowych można wskazać na ten sam punkt końcowy ruchu przychodzącego środowiska App Service Environment. Środowisko App Service Environment nie wymaga weryfikacji domeny.

  Uwaga

  Punkt końcowy Kudu dla środowiska App Service Environment w wersji 3 jest dostępny tylko pod adresem {resourcename}.scm.{asename}.appserviceenvironment.net. Aby uzyskać więcej informacji na temat środowiska App Service Environment w wersji 3 dns i sieci itp., zobacz Sieć środowiska App Service Environment.

  W przypadku środowiska App Service Environment klient jest właścicielem routingu i w związku z tym zasobami używanymi do przecięcia. Wszędzie tam, gdzie jest włączony dostęp do środowiska App Service Environment zewnętrznie — zazwyczaj za pośrednictwem wirtualnego urządzenia sieciowego warstwy 7 lub zwrotnego serwera proxy — traffic manager lub usługi Azure Front Door/Other L7 Global Load Balancing Service można używać.

• W przypadku publicznej wielodostępnej wersji usługi domyślna nazwa {resourcename}.azurewebsites.net jest aprowizowana dla punktów końcowych płaszczyzny danych wraz z domyślną nazwą punktu końcowego Kudu (SCM). Ponieważ usługa domyślnie udostępnia publiczny punkt końcowy, powiązanie musi zostać zweryfikowane, aby udowodnić własność domeny. Jednak po utworzeniu powiązania ponowna weryfikacja nie jest wymagana ani nie jest wymagana, aby publiczne rekordy DNS wskazywały punkt końcowy usługi App Service.

• Jeśli używasz domeny niestandardowej, powiąż ją z preemptively z aplikacją docelową. Zweryfikuj i włącz domenę w aplikacji docelowej.

Tożsamości

• Należy ponownie utworzyć wszystkie tożsamości zarządzane przypisane przez system wraz z aplikacją w nowym regionie docelowym. Zazwyczaj automatycznie utworzona aplikacja Microsoft Entra ID używana przez usługę EasyAuth domyślnie określa nazwę zasobu aplikacji.

• Tożsamości zarządzane przypisane przez użytkownika nie mogą być również przenoszone między regionami. Aby zachować tożsamości zarządzane przypisane przez użytkownika w tej samej grupie zasobów w aplikacji, należy je ponownie utworzyć w nowym regionie. Aby uzyskać więcej informacji, zobacz Przenoszenie tożsamości zarządzanych dla zasobów platformy Azure do innego regionu.

• Nadaj tożsamościom zarządzanym te same uprawnienia w przeniesionych usługach co oryginalne tożsamości, które zastępują, w tym członkostw w grupach.

• Zaplanuj przeniesienie dostawcy tożsamości (IDP) do regionu docelowego. Mimo że microsoft Entra ID jest usługą globalną, niektóre rozwiązania korzystają z lokalnego (lub podrzędnego lokalnego) dostawcy tożsamości.

• Zaktualizuj wszystkie zasoby do usługi App Service, które mogą polegać na poświadczeniach protokołu FTP Kudu.

Punkty końcowe usługi

Punkty końcowe usługi sieci wirtualnej dla usługi aplikacja systemu Azure Service ograniczają dostęp do określonej sieci wirtualnej. Punkty końcowe mogą również ograniczyć dostęp do listy zakresów adresów IPv4 (protokół internetowy w wersji 4). Każdy użytkownik nawiązujący połączenie z usługą Event Hubs spoza tych źródeł nie ma dostępu. Jeśli punkty końcowe usługi zostały skonfigurowane w regionie źródłowym dla zasobu usługi Event Hubs, należy to zrobić w tym samym miejscu docelowym.

Aby pomyślnie odtworzyć usługę aplikacja systemu Azure w regionie docelowym, należy wcześniej utworzyć sieć wirtualną i podsieć. W przypadku przenoszenia tych dwóch zasobów za pomocą narzędzia Azure Resource Mover punkty końcowe usługi nie będą konfigurowane automatycznie. W związku z tym należy je skonfigurować ręcznie, co można zrobić za pośrednictwem witryny Azure Portal, interfejsu wiersza polecenia platformy Azure lub programu Azure PowerShell.

Przenieść

Aby przenieść zasoby usługi App Service, możesz użyć witryny Azure Portal lub infrastruktury jako kodu (IaC).

Przenoszenie przy użyciu witryny Azure Portal

Największą zaletą korzystania z witryny Azure Portal do przeniesienia jest jej prostota. Aplikacja, plan i zawartość, a także wiele ustawień są klonowane do nowego zasobu i planu usługi App Service.

Należy pamiętać, że w przypadku warstw Środowiska App Service Environment (izolowanego) należy najpierw ponownie wdrożyć całe środowisko App Service Environment w innym regionie, a następnie rozpocząć ponowne wdrażanie poszczególnych planów w nowym środowisku App Service Environment w nowym regionie.

Aby przenieść zasoby usługi App Service do nowego regionu przy użyciu witryny Azure Portal:

1. Utwórz kopię zapasową aplikacji źródłowej.
2. Utwórz aplikację w nowym planie usługi App Service w regionie docelowym.
3. Przywracanie kopii zapasowej w aplikacji docelowej
4. Jeśli używasz domeny niestandardowej, powiąż ją z preemptively z aplikacją docelową za pomocą asuid. polecenia i włącz domenę w aplikacji docelowej.
5. Skonfiguruj wszystkie inne elementy w aplikacji docelowej tak samo jak aplikacja źródłowa i zweryfikuj konfigurację.
6. Gdy wszystko będzie gotowe, aby domena niestandardowa wskazywała aplikację docelową, zamapuj ponownie nazwę domeny.

Przenoszenie przy użyciu IaC

Użyj funkcji IaC, gdy istnieje istniejący potok ciągłej integracji i ciągłego wdrażania(CI/CD) lub można go utworzyć. Po wdrożeniu potoku ciągłej integracji/ciągłego wdrażania zasób usługi App Service można utworzyć w regionie docelowym za pomocą akcji wdrożenia lub wdrożenia zip Kudu.

Wymagania dotyczące umowy SLA powinny określać, ile dodatkowego nakładu pracy jest wymagany. Na przykład: czy jest to ponowne wdrożenie z ograniczonym przestojem, czy jest to ograniczenie czasu niemal rzeczywistego wymagane z minimalnym przestojem?

Włączenie zewnętrznych, globalnych usług brzegowych routingu ruchu, takich jak Traffic Manager lub Azure Front Door, pomaga ułatwić przecięcia dla użytkowników zewnętrznych i aplikacji.

Napiwek

Usługa Traffic Manager (ATM) może być używana podczas przełączania usługi App Services w tryb failover za prywatnymi punktami końcowymi. Chociaż prywatne punkty końcowe nie są osiągalne przez sondy usługi Traffic Manager — jeśli wszystkie punkty końcowe są obniżone, usługa ATM zezwala na routing. Aby uzyskać więcej informacji, zobacz Kontrolowanie ruchu usługi aplikacja systemu Azure za pomocą usługi Azure Traffic Manager.

Sprawdź poprawność

Po zakończeniu relokacji przetestuj i zweryfikuj usługę aplikacja systemu Azure z zalecanymi wytycznymi:

• Po przeniesieniu usługi aplikacja systemu Azure do regionu docelowego uruchom test weryfikacyjny kompilacji i integracji. Możesz ręcznie przetestować lub uruchomić test za pomocą skryptu. Upewnij się, że wszystkie konfiguracje i zasoby zależne są prawidłowo połączone i czy wszystkie skonfigurowane dane są dostępne.

• Zweryfikuj wszystkie składniki usługi aplikacja systemu Azure i integrację.

• Przeprowadź testy integracji we wdrożeniu regionu docelowego, w tym wszystkie formalne testy regresji. Testowanie integracji powinno być zgodne ze zwykłym rytmem wdrażania biznesowego i procesami testowania mającym zastosowanie do obciążenia.

• W niektórych scenariuszach, szczególnie w przypadku, gdy relokacja obejmuje aktualizacje, zmiany aplikacji lub zasobów platformy Azure lub zmianę profilu użycia, użyj testowania obciążenia, aby sprawdzić, czy nowe obciążenie jest odpowiednie do celu. Testowanie obciążenia jest również okazją do weryfikowania operacji i monitorowania pokrycia. Na przykład użyj testowania obciążenia, aby sprawdzić, czy wymagane dzienniki infrastruktury i aplikacji są generowane poprawnie. Testy obciążeniowe powinny być mierzone względem ustalonych punktów odniesienia wydajności obciążenia.

Napiwek

Relokacja usługi App Service jest również okazją do ponownej oceny planowania dostępności i odzyskiwania po awarii. Środowisko App Service i App Service Environment (App Service Environment w wersji 3) obsługuje strefy dostępności i zaleca się skonfigurowanie przy użyciu konfiguracji strefy dostępności. Należy pamiętać o wymaganiach wstępnych dotyczących wdrażania, cen i ograniczeń oraz uwzględnić je w planowaniu przenoszenia zasobów. Aby uzyskać więcej informacji na temat stref dostępności i usługi App Service, zobacz Niezawodność w usłudze aplikacja systemu Azure Service.

Czyszczenie

Usuń aplikację źródłową i plan usługi App Service. Plan usługi App Service w warstwie innej niż bezpłatna niesie ze sobą opłatę, nawet jeśli żadna aplikacja nie jest w niej uruchomiona.

Następne kroki

klonowanie aplikacji usługi aplikacja systemu Azure Service przy użyciu programu PowerShell