Udostępnij za pośrednictwem

Przenoszenie aplikacji funkcji do innego regionu świadczenia usługi Azure

  • Artykuł

W tym artykule opisano sposób przenoszenia aplikacji funkcji hostowanej przez usługę Azure Functions 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 platformy Azure, które hostują aplikację funkcji, są specyficzne dla regionu i nie można ich przenosić między regionami. Zamiast tego należy utworzyć kopię istniejących zasobów aplikacji funkcji w regionie docelowym, a następnie ponownie wdrożyć kod funkcji w nowej aplikacji.

Możesz przenieść te same zasoby do innej grupy zasobów lub subskrypcji, o ile pozostaną w tym samym regionie. Aby uzyskać więcej informacji, zobacz Przenoszenie zasobów usługi App Service do nowej grupy zasobów lub subskrypcji.

Wymagania wstępne

  • Upewnij się, że region docelowy obsługuje usługę Azure Functions i dowolną powiązaną usługę, której zasoby chcesz przenieść.
  • Upewnij się, że masz uprawnienia do tworzenia zasobów potrzebnych w nowym regionie.

Przygotowywanie

Zidentyfikuj wszystkie zasoby aplikacji funkcji używane w regionie źródłowym, które potencjalnie obejmują:

Podczas przygotowywania do przeniesienia aplikacji do nowego regionu istnieje kilka części architektury, które wymagają szczególnej uwagi i planowania.

Nazwa aplikacji funkcji

Nazwy aplikacji funkcji muszą być globalnie unikatowe we wszystkich aplikacjach platformy Azure. Oznacza to, że nowa aplikacja funkcji nie może mieć takiej samej nazwy i adresu URL jak oryginalna. Jest to nawet prawdą w przypadku korzystania z niestandardowego systemu DNS, ponieważ bazowe <APP_NAME>.azurewebsites.net muszą być nadal unikatowe. Może być konieczne zaktualizowanie wszystkich klientów łączących się z punktami końcowymi HTTP w aplikacji funkcji. Ci klienci muszą używać nowego adresu URL podczas tworzenia żądań.

Kod źródłowy

W idealnym przypadku kod źródłowy jest utrzymywany w repozytorium kodu pewnego rodzaju lub w repozytorium kontenerów, jeśli działa w kontenerze systemu Linux. Jeśli używasz ciągłego wdrażania, zaplanuj przełączenie połączenia repozytorium lub wdrożenia kontenera z nowym adresem aplikacji funkcji. Jeśli z jakiegoś powodu nie masz już kodu źródłowego, możesz pobrać aktualnie uruchomiony pakiet z oryginalnej aplikacji funkcji. Zalecamy przechowywanie plików źródłowych w repozytorium kodu i używanie ciągłego wdrażania aktualizacji.

Domyślne konto magazynu

Host usługi Functions wymaga konta usługi Azure Storage. Aby uzyskać więcej informacji, zobacz Wymagania dotyczące konta magazynu. Aby uzyskać najlepszą wydajność, aplikacja funkcji powinna używać konta magazynu w tym samym regionie. Podczas tworzenia nowej aplikacji przy użyciu nowego konta magazynu w nowym regionie aplikacja otrzymuje nowy zestaw kluczy dostępu do funkcji, a stan wszystkich wyzwalaczy (takich jak wyzwalacze czasomierza) jest resetowany.

Utrwalone miejsce do magazynowania lokalnego

Wykonania funkcji mają być bezstanowe. Nie zapobiegamy jednak zapisywaniu danych w lokalnym systemie plików. Istnieje możliwość przechowywania danych generowanych i używanych przez aplikację na %HOME%\site dysku wirtualnym, ale te dane nie powinny być powiązane ze stanem. Jeśli scenariusz wymaga zachowania stanu między wykonywaniem funkcji, rozważ użycie rozszerzenia Durable Functions.

Jeśli aplikacja będzie utrwalać dane na udostępnionej ścieżce magazynu aplikacji, pamiętaj, aby zaplanować sposób zarządzania tym stanem podczas przenoszenia zasobu. Należy pamiętać, że w przypadku aplikacji dedykowanych (App Service) udział jest częścią witryny. W przypadku planów Zużycie i Premium udział jest domyślnie udziałem usługi Azure Files na domyślnym koncie magazynu. Aplikacje działające w systemie Linux mogą używać jawnie zainstalowanego udziału dla magazynu utrwalonego.

Połączone usługi

Funkcje mogą łączyć się z usługami platformy Azure i innymi zasobami przy użyciu zestawu SDK usługi lub wyzwalaczy i powiązań. Każda połączona usługa może mieć negatywny wpływ na przejście aplikacji do nowego regionu. Jeśli opóźnienie lub przez cały czas występują problemy, rozważ przeniesienie dowolnej połączonej usługi do nowego regionu. Aby dowiedzieć się, jak przenieść te zasoby między regionami, zapoznaj się z dokumentacją odpowiednich usług. Podczas przenoszenia aplikacji z połączonymi usługami warto rozważyć odzyskiwanie po awarii między regionami i strategię ciągłości działania podczas przenoszenia.

Zmiany usług połączonych mogą wymagać zaktualizowania wartości przechowywanych w ustawieniach aplikacji, które są używane do łączenia się z tymi usługami.

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.

Niestandardowe domeny

Jeśli aplikacja funkcji używa domeny niestandardowej, powiąż ją z aplikacją docelową z preemptively. Zweryfikuj i włącz domenę w aplikacji docelowej. Po przeniesieniu należy ponownie zamapować nazwę domeny.

Sieci wirtualne

Usługa Azure Functions umożliwia integrację aplikacji z zasobami sieci wirtualnej, a nawet uruchamianie ich w sieci wirtualnej. Aby uzyskać więcej informacji, zobacz Opcje sieci usługi Azure Functions. Podczas przechodzenia do nowego regionu należy najpierw przenieść lub ponownie utworzyć wszystkie wymagane zasoby sieci wirtualnej i podsieci przed wdrożeniem aplikacji. Obejmuje to przenoszenie lub ponowne tworzenie prywatnych punktów końcowych i punktów końcowych usługi.

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.

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.

Access keys

Usługa Functions używa kluczy dostępu, aby utrudnić dostęp do punktów końcowych HTTP w aplikacji funkcji. Te klucze są przechowywane zaszyfrowane na domyślnym koncie magazynu. Podczas tworzenia nowej aplikacji w nowym regionie zostanie utworzony nowy zestaw kluczy. Należy zaktualizować wszystkich istniejących klientów, którzy używają kluczy dostępu, aby używać nowych kluczy w nowym regionie. Chociaż należy użyć nowych kluczy, można ponownie utworzyć stare klucze w nowej aplikacji. Aby uzyskać więcej informacji, zobacz Praca z kluczami dostępu w usłudze Azure Functions.

Przestój

Jeśli wymagany jest minimalny przestój, rozważ uruchomienie aplikacji funkcji w obu regionach zgodnie z zaleceniami w celu zaimplementowania architektury odzyskiwania po awarii. Implementacja konkretnej architektury zależy od typów wyzwalaczy w aplikacji funkcji. Aby uzyskać więcej informacji, zobacz Niezawodność w usłudze Azure Functions.

Trwałe funkcje

Rozszerzenie Durable Functions umożliwia definiowanie aranżacji, gdzie stan jest utrzymywany w wykonaniach funkcji przy użyciu jednostek stanowych. W idealnym przypadku przed migracją aplikacji Durable Functions należy zezwolić na uruchamianie orkiestracji, zwłaszcza jeśli planujesz przełączyć się na nowe konto magazynu w nowym regionie. Podczas migracji aplikacji Durable Functions rozważ użycie jednej z tych strategii odzyskiwania po awarii i dystrybucji geograficznej.

Przenieść

Ponowne utworzenie aplikacji funkcji w nowym regionie wymaga ponownego utworzenia infrastruktury platformy Azure planu usługi App Service, wystąpienia aplikacji funkcji i powiązanych zasobów, takich jak sieci wirtualne, tożsamości i miejsca. Musisz również ponownie nawiązać połączenie lub ponownie utworzyć zasoby platformy Azure wymagane przez aplikację w nowym regionie. Te zasoby mogą obejmować domyślne konto usługi Azure Storage i wystąpienie usługi Application Insights.

Następnie możesz spakować i ponownie wdrożyć rzeczywisty kod źródłowy lub kontener aplikacji do aplikacji funkcji działającej w nowym regionie.

Ponowne tworzenie infrastruktury platformy Azure

Istnieje kilka sposobów tworzenia aplikacji funkcji i powiązanych zasobów na platformie Azure w regionie docelowym:

  • Szablony wdrażania: jeśli pierwotnie wdrożono aplikację funkcji przy użyciu plików infrastruktury jako kodu (IaC) (Bicep, szablony usługi ARM lub Terraform), możesz zaktualizować te poprzednie wdrożenia w celu kierowania do nowego regionu i użyć ich do ponownego utworzenia zasobów w nowym regionie. Jeśli nie masz już tych plików wdrażania, zawsze możesz pobrać szablon usługi ARM dla istniejącej grupy zasobów z witryny Azure Portal.
  • Skrypty interfejsu wiersza polecenia platformy Azure/programu PowerShell: jeśli pierwotnie wdrożono aplikację funkcji przy użyciu interfejsu wiersza polecenia platformy Azure lub skryptów programu Azure PowerShell, możesz zaktualizować te skrypty, aby zamiast tego kierować je do nowego regionu i uruchamiać je ponownie. Jeśli nie masz już tych skryptów, możesz również pobrać szablon usługi ARM dla istniejącej grupy zasobów z witryny Azure Portal.
  • Witryna Azure Portal: Jeśli aplikacja funkcji została utworzona pierwotnie w portalu lub nie czujesz się komfortowo przy użyciu skryptów lub plików IaC, możesz po prostu odtworzyć wszystko w portalu. Upewnij się, że używasz tego samego planu hostingu, środowiska uruchomieniowego języka i wersji językowej co oryginalna aplikacja.

Przeglądanie skonfigurowanych zasobów

Przejrzyj i skonfiguruj zasoby zidentyfikowane w powyższym kroku Przygotowywania w regionie docelowym, jeśli nie zostały skonfigurowane podczas wdrażania. Jeśli używasz ciągłego wdrażania z uwierzytelnianiem tożsamości zarządzanej, upewnij się, że w nowej aplikacji funkcji istnieją wymagane tożsamości i mapowania ról.

Ponowne wdrażanie kodu źródłowego

Teraz, gdy masz już infrastrukturę, możesz ponownie spakować i ponownie wdrożyć kod źródłowy w aplikacji funkcji. Jest to dobry moment na przeniesienie kodu źródłowego lub obrazu kontenera do repozytorium i włączenie ciągłego wdrażania z tego repozytorium.

Można również użyć dowolnej innej metody publikowania obsługiwanej przez usługę Functions. Większość publikowania opartego na narzędziach wymaga włączenia uwierzytelniania podstawowego scm w punkcie końcowym, co nie jest zalecane w przypadku aplikacji produkcyjnych.

Zagadnienia dotyczące relokacji

  • Pamiętaj, aby zweryfikować konfigurację i przetestować funkcje w regionie docelowym.
  • Jeśli skonfigurowano domenę niestandardową, zamapuj ponownie nazwę domeny.
  • W przypadku aplikacji funkcji działającej w ramach planu dedykowanego (App Service) zapoznaj się również z planem migracji usługi App Service, gdy plan jest współużytkowany z co najmniej jedną aplikacją internetową.

Czyszczenie

Po zakończeniu przenoszenia usuń aplikację funkcji i plan hostingu z regionu źródłowego. Płacisz za aplikacje funkcji w planach premium lub dedykowanych, nawet jeśli sama aplikacja nie jest uruchomiona. Jeśli utworzono ponownie inne usługi w nowym regionie, należy również usunąć starsze usługi po tym, jak masz pewność, że nie są już potrzebne.

Zapoznaj się z centrum architektury platformy Azure, aby zapoznać się z przykładami aplikacji funkcji działających w wielu regionach w ramach bardziej zaawansowanych i geograficznie nadmiarowych architektur rozwiązań.