Samouczek: tworzenie aplikacji o wysokiej dostępności w wielu regionach w usłudze aplikacja systemu Azure Service
Wysoka dostępność i odporność na uszkodzenia to kluczowe składniki dobrze zaprojektowanego rozwiązania. Najlepiej przygotować się na nieoczekiwany plan awaryjny, który może skrócić przestoje i automatycznie uruchomić systemy w przypadku awarii.
Podczas wdrażania aplikacji w chmurze należy wybrać region w tej chmurze, w którym jest oparta infrastruktura aplikacji. Jeśli aplikacja zostanie wdrożona w jednym regionie i region stanie się niedostępny, aplikacja będzie również niedostępna. Ten brak dostępności może być niedopuszczalny zgodnie z warunkami umowy SLA aplikacji. Jeśli tak, wdrażanie aplikacji i jej usług w wielu regionach jest dobrym rozwiązaniem.
Z tego samouczka dowiesz się, jak wdrożyć aplikację internetową o wysokiej dostępności w wielu regionach. Ten scenariusz jest prosty, ograniczając składniki aplikacji tylko do aplikacji internetowej i usługi Azure Front Door, ale koncepcje można rozszerzyć i zastosować do innych wzorców infrastruktury. Jeśli na przykład aplikacja łączy się z ofertą bazy danych platformy Azure lub kontem magazynu, zobacz aktywne replikacji geograficznej dla baz danych SQL i opcji nadmiarowości dla kont magazynu. Aby zapoznać się z architekturą referencyjną dla bardziej szczegółowego scenariusza, zobacz Aplikacja internetowa o wysokiej dostępności w wielu regionach.
Poniższy diagram architektury przedstawia infrastrukturę utworzoną w tym samouczku. Składa się z dwóch identycznych usług App Services w oddzielnych regionach, z których jeden jest aktywnym lub podstawowym regionem, a drugi to region rezerwowy lub pomocniczy. Usługa Azure Front Door służy do kierowania ruchu do usług App Services, a ograniczenia dostępu są konfigurowane tak, aby bezpośredni dostęp do aplikacji z Internetu był blokowany. Linia kropkowana wskazuje, że ruch jest wysyłany do regionu rezerwowego tylko wtedy, gdy aktywny region ulegnie awarii.
Platforma Azure oferuje różne opcje równoważenia obciążenia i routingu ruchu. Dla tego przypadku użycia wybrano usługę Azure Front Door, ponieważ obejmuje ona aplikacje internetowe hostowane w usłudze aplikacja systemu Azure Service wdrożone w wielu regionach. Aby ułatwić podjęcie decyzji o tym, co należy użyć w przypadku użycia, jeśli różni się on od tego samouczka, zobacz drzewo decyzyjne dotyczące równoważenia obciążenia na platformie Azure.
Z tą architekturą:
- Identyczne aplikacje usługi App Service są wdrażane w dwóch oddzielnych regionach.
- Ruch publiczny bezpośrednio do aplikacji usługi App Service jest blokowany.
- Usługa Azure Front Door służy do kierowania ruchu do regionu podstawowego/aktywnego. Region pomocniczy ma usługę App Service, która jest uruchomiona i gotowa do obsługi ruchu w razie potrzeby.
Zawartość:
- Utwórz identyczne usługi App Services w oddzielnych regionach.
- Utwórz usługę Azure Front Door z ograniczeniami dostępu, które blokują publiczny dostęp do usług App Services.
Wymagania wstępne
Jeśli nie masz subskrypcji platformy Azure, przed rozpoczęciem utwórz bezpłatne konto platformy Azure.
W celu ukończenia tego samouczka:
Użyj środowiska powłoki Bash w usłudze Azure Cloud Shell. Aby uzyskać więcej informacji, zobacz Szybki start dotyczący powłoki Bash w usłudze Azure Cloud Shell.
Jeśli wolisz uruchamiać polecenia referencyjne interfejsu wiersza polecenia lokalnie, zainstaluj interfejs wiersza polecenia platformy Azure. Jeśli korzystasz z systemu Windows lub macOS, rozważ uruchomienie interfejsu wiersza polecenia platformy Azure w kontenerze Docker. Aby uzyskać więcej informacji, zobacz Jak uruchomić interfejs wiersza polecenia platformy Azure w kontenerze platformy Docker.
Jeśli korzystasz z instalacji lokalnej, zaloguj się do interfejsu wiersza polecenia platformy Azure za pomocą polecenia az login. Aby ukończyć proces uwierzytelniania, wykonaj kroki wyświetlane w terminalu. Aby uzyskać inne opcje logowania, zobacz Logowanie się przy użyciu interfejsu wiersza polecenia platformy Azure.
Po wyświetleniu monitu zainstaluj rozszerzenie interfejsu wiersza polecenia platformy Azure podczas pierwszego użycia. Aby uzyskać więcej informacji na temat rozszerzeń, zobacz Korzystanie z rozszerzeń w interfejsie wiersza polecenia platformy Azure.
Uruchom polecenie az version, aby znaleźć zainstalowane wersje i biblioteki zależne. Aby uaktualnić do najnowszej wersji, uruchom polecenie az upgrade.
Tworzenie dwóch wystąpień aplikacji internetowej
Na potrzeby tego samouczka potrzebne są dwa wystąpienia aplikacji internetowej, które działają w różnych regionach świadczenia usługi Azure. Jako dwa regiony należy użyć pary regionów Wschodnie stany USA/Zachodnie stany USA i utworzyć dwie puste aplikacje internetowe. W razie potrzeby możesz wybrać własne regiony.
Aby ułatwić zarządzanie i czyszczenie, użyj jednej grupy zasobów dla wszystkich zasobów w tym samouczku. Rozważ użycie oddzielnych grup zasobów dla każdego regionu/zasobu, aby dodatkowo odizolować zasoby w sytuacji odzyskiwania po awarii.
Uruchom następujące polecenie, aby utworzyć grupę zasobów.
az group create --name myresourcegroup --location eastus
Tworzenie planów usługi App Service
Uruchom następujące polecenia, aby utworzyć plany usługi App Service. Zastąp symbole zastępcze symbolami <app-service-plan-east-us> i <app-service-plan-west-us> dwiema unikatowymi nazwami, w których można łatwo zidentyfikować region, w którym się znajduje.
az appservice plan create --name <app-service-plan-east-us> --resource-group myresourcegroup --is-linux --location eastus
az appservice plan create --name <app-service-plan-west-us> --resource-group myresourcegroup --is-linux --location westus
Tworzenie aplikacji internetowych
Po utworzeniu planów usługi App Service uruchom następujące polecenia, aby utworzyć aplikacje internetowe. Zastąp symbole zastępcze wartości <web-app-east-us> i <web-app-west-us> dwiema globalnie unikatowymi nazwami (prawidłowe znaki to a-z, 0-9i -) i pamiętaj, aby zwrócić uwagę na --plan parametr , aby umieścić jedną aplikację w każdym planie (a tym samym w każdym regionie). Zastąp <runtime> parametr wersją językową aplikacji. Uruchom polecenie az webapp list-runtimes , aby wyświetlić listę dostępnych środowisk uruchomieniowych. Jeśli planujesz korzystanie z przykładowej aplikacji Node.js podanej w tym samouczku w poniższych sekcjach, użyj NODE:18-lts go jako środowiska uruchomieniowego.
az webapp create --name <web-app-east-us> --resource-group myresourcegroup --plan <app-service-plan-east-us> --runtime <runtime>
az webapp create --name <web-app-west-us> --resource-group myresourcegroup --plan <app-service-plan-west-us> --runtime <runtime>
Zanotuj domyślną nazwę hosta każdej aplikacji internetowej, aby można było zdefiniować adresy zaplecza podczas wdrażania usługi Front Door w następnym kroku. Powinna ona mieć format <web-app-name>.azurewebsites.net. Te nazwy hostów można znaleźć, uruchamiając następujące polecenie lub przechodząc do strony Przegląd aplikacji w witrynie Azure Portal.
az webapp show --name <web-app-name> --resource-group myresourcegroup --query "hostNames"
Tworzenie usługi Azure Front Door
Wdrożenie w wielu regionach może używać konfiguracji aktywne-aktywne lub aktywne-pasywne. Konfiguracja aktywna-aktywna dystrybuuje żądania w wielu aktywnych regionach. Konfiguracja aktywne-pasywne utrzymuje uruchomione wystąpienia w regionie pomocniczym, ale nie wysyła tam ruchu, chyba że region podstawowy ulegnie awarii. Usługa Azure Front Door ma wbudowaną funkcję, która umożliwia włączenie tych konfiguracji. Aby uzyskać więcej informacji na temat projektowania aplikacji pod kątem wysokiej dostępności i odporności na uszkodzenia, zobacz Projektowanie aplikacji platformy Azure pod kątem odporności i dostępności.
Tworzenie profilu usługi Azure Front Door
Teraz utworzysz usługę Azure Front Door Premium w celu kierowania ruchu do aplikacji.
Uruchom polecenie az afd profile create , aby utworzyć profil usługi Azure Front Door.
Uwaga
Jeśli chcesz wdrożyć usługę Azure Front Door Standard zamiast Premium, zastąp wartość parametru --sku Standard_AzureFrontDoor. W przypadku wybrania warstwy Standardowa nie można wdrożyć reguł zarządzanych za pomocą zasad zapory aplikacji internetowej. Aby uzyskać szczegółowe porównanie warstw cenowych, zobacz Porównanie warstw usługi Azure Front Door.
az afd profile create --profile-name myfrontdoorprofile --resource-group myresourcegroup --sku Premium_AzureFrontDoor
| Parametr | Wartość | Opis |
|---|---|---|
profile-name |
myfrontdoorprofile |
Nazwa profilu usługi Azure Front Door, który jest unikatowy w grupie zasobów. |
resource-group |
myresourcegroup |
Grupa zasobów zawierająca zasoby z tego samouczka. |
sku |
Premium_AzureFrontDoor |
Warstwa cenowa profilu usługi Azure Front Door. |
Dodawanie punktu końcowego
Uruchom polecenie az afd endpoint create , aby utworzyć punkt końcowy w profilu. Po zakończeniu tworzenia możesz utworzyć wiele punktów końcowych w swoim profilu.
az afd endpoint create --resource-group myresourcegroup --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled
| Parametr | Wartość | Opis |
|---|---|---|
endpoint-name |
myendpoint |
Nazwa punktu końcowego w profilu, który jest unikatowy globalnie. |
enabled-state |
Enabled |
Czy włączyć ten punkt końcowy. |
Tworzenie grupy pochodzenia
Uruchom polecenie az afd origin-group create , aby utworzyć grupę pochodzenia zawierającą dwie aplikacje internetowe.
az afd origin-group create --resource-group myresourcegroup --origin-group-name myorigingroup --profile-name myfrontdoorprofile --probe-request-type GET --probe-protocol Http --probe-interval-in-seconds 60 --probe-path / --sample-size 4 --successful-samples-required 3 --additional-latency-in-milliseconds 50
| Parametr | Wartość | Opis |
|---|---|---|
origin-group-name |
myorigingroup |
Nazwa grupy pochodzenia. |
probe-request-type |
GET |
Typ wykonanego żądania sondy kondycji. |
probe-protocol |
Http |
Protokół do użycia dla sondy kondycji. |
probe-interval-in-seconds |
60 |
Liczba sekund między sondami kondycji. |
probe-path |
/ |
Ścieżka względem źródła, który jest używany do określania kondycji źródła. |
sample-size |
4 |
Liczba próbek, które należy wziąć pod uwagę podczas podejmowania decyzji dotyczących równoważenia obciążenia. |
successful-samples-required |
3 |
Liczba próbek w okresie próby, które muszą zakończyć się powodzeniem. |
additional-latency-in-milliseconds |
50 |
Dodatkowe opóźnienie w milisekundach dla sond do przedziału o najniższym opóźnieniu. |
Dodawanie źródła do grupy
Uruchom polecenie az afd origin create , aby dodać źródło do grupy pochodzenia. Dla parametru --host-name zastąp symbol zastępczy nazwą <web-app-east-us> aplikacji w tym regionie. Zwróć uwagę, --priority że parametr jest ustawiony na 1wartość , co oznacza, że cały ruch jest wysyłany do aplikacji podstawowej.
az afd origin create --resource-group myresourcegroup --host-name <web-app-east-us>.azurewebsites.net --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name primaryapp --origin-host-header <web-app-east-us>.azurewebsites.net --priority 1 --weight 1000 --enabled-state Enabled --http-port 80 --https-port 443
| Parametr | Wartość | Opis |
|---|---|---|
host-name |
<web-app-east-us>.azurewebsites.net |
Nazwa hosta podstawowej aplikacji internetowej. |
origin-name |
primaryapp |
Nazwa źródła. |
origin-host-header |
<web-app-east-us>.azurewebsites.net |
Nagłówek hosta do wysłania żądań do tego źródła. Jeśli pozostawisz to pole puste, nazwa hosta żądania określi tę wartość. Źródła usługi Azure CDN, takie jak Web Apps, Blob Storage i Cloud Services, wymagają, aby ta wartość nagłówka hosta domyślnie odpowiadała nazwie hosta pochodzenia. |
priority |
1 |
Ustaw ten parametr na 1, aby kierować cały ruch do podstawowej aplikacji internetowej. |
weight |
1000 |
Waga źródła w danej grupie pochodzenia na potrzeby równoważenia obciążenia. Musi należeć do zakresu od 1 do 1000. |
enabled-state |
Enabled |
Czy włączyć to źródło. |
http-port |
80 |
Port używany dla żądań HTTP do źródła. |
https-port |
443 |
Port używany dla żądań HTTPS do źródła. |
Powtórz ten krok, aby dodać drugie źródło. Zwróć uwagę na --priority parametr . Dla tego źródła jest ustawiona wartość 2. To ustawienie priorytetu nakazuje usłudze Azure Front Door kierowanie całego ruchu do podstawowego źródła, chyba że podstawowy ulegnie awarii. Jeśli ustawisz priorytet dla tego źródła 1, usługa Azure Front Door traktuje oba źródła jako aktywne i kierują ruch do obu regionów. Pamiętaj, aby zastąpić oba wystąpienia symbolu zastępczego nazwą <web-app-west-us> tej aplikacji internetowej.
az afd origin create --resource-group myresourcegroup --host-name <web-app-west-us>.azurewebsites.net --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name secondaryapp --origin-host-header <web-app-west-us>.azurewebsites.net --priority 2 --weight 1000 --enabled-state Enabled --http-port 80 --https-port 443
Dodawanie trasy
Uruchom polecenie az afd route create , aby zamapować punkt końcowy na grupę pochodzenia. Ta trasa przekazuje żądania z punktu końcowego do grupy pochodzenia.
az afd route create --resource-group myresourcegroup --profile-name myfrontdoorprofile --endpoint-name myendpoint --forwarding-protocol MatchRequest --route-name route --https-redirect Enabled --origin-group myorigingroup --supported-protocols Http Https --link-to-default-domain Enabled
| Parametr | Wartość | Opis |
|---|---|---|
endpoint-name |
myendpoint |
Nazwa punktu końcowego. |
| protokół przekazywania | MatchRequest | Protokół używany przez tę regułę podczas przekazywania ruchu do zaplecza. |
route-name |
route |
Nazwa trasy. |
| https-redirect | Enabled |
Czy automatycznie przekierowywać ruch HTTP do ruchu HTTPS. |
supported-protocols |
Http Https |
Lista obsługiwanych protokołów dla tej trasy. |
link-to-default-domain |
Enabled |
Czy ta trasa jest połączona z domyślną domeną punktu końcowego. |
Poczekaj około 15 minut na ukończenie tego kroku, ponieważ propagowanie tej zmiany na całym świecie zajmuje trochę czasu. Po tym okresie usługa Azure Front Door jest w pełni funkcjonalna.
Ograniczanie dostępu do aplikacji internetowych do wystąpienia usługi Azure Front Door
W tym momencie nadal możesz uzyskiwać dostęp do aplikacji bezpośrednio przy użyciu ich adresów URL. Aby zapewnić, że ruch może docierać tylko do aplikacji za pośrednictwem usługi Azure Front Door, należy ustawić ograniczenia dostępu dla poszczególnych aplikacji. Funkcje usługi Front Door działają najlepiej, gdy ruch przepływa tylko przez usługę Front Door. Należy skonfigurować źródła, aby blokować ruch, który nie jest jeszcze wysyłany przez usługę Front Door. W przeciwnym razie ruch może pominąć zaporę aplikacji internetowej usługi Front Door, ochronę przed atakami DDoS i inne funkcje zabezpieczeń. Ruch z usługi Azure Front Door do aplikacji pochodzi z dobrze znanego zestawu zakresów adresów IP zdefiniowanych w tagu AzureFrontDoor.Backend usługi. Korzystając z reguły ograniczeń tagu usługi, można ograniczyć ruch tylko z usługi Azure Front Door.
Przed skonfigurowaniem ograniczeń dostępu usługi App Service zanotuj identyfikator usługi Front Door, uruchamiając następujące polecenie. Ten identyfikator jest potrzebny do zapewnienia, że ruch pochodzi tylko z określonego wystąpienia usługi Front Door. Ograniczenie dostępu dodatkowo filtruje żądania przychodzące na podstawie unikatowego nagłówka HTTP wysyłanego przez usługę Azure Front Door.
az afd profile show --resource-group myresourcegroup --profile-name myfrontdoorprofile --query "frontDoorId"
Uruchom następujące polecenia, aby ustawić ograniczenia dostępu do aplikacji internetowych. Zastąp symbol zastępczy elementem <front-door-id> z wynikiem z poprzedniego polecenia. Zastąp symbole zastępcze nazw aplikacji.
az webapp config access-restriction add --resource-group myresourcegroup -n <web-app-east-us> --priority 100 --service-tag AzureFrontDoor.Backend --http-header x-azure-fdid=<front-door-id>
az webapp config access-restriction add --resource-group myresourcegroup -n <web-app-west-us> --priority 100 --service-tag AzureFrontDoor.Backend --http-header x-azure-fdid=<front-door-id>
Testowanie usługi Front Door
Utworzenie profilu usługi Azure Front Door Standard/Premium potrwa kilka minut, aby konfiguracja została wdrożona globalnie. Po zakończeniu możesz uzyskać dostęp do utworzonego hosta frontonu.
Uruchom polecenie az afd endpoint show , aby uzyskać nazwę hosta punktu końcowego usługi Front Door.
az afd endpoint show --resource-group myresourcegroup --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"
W przeglądarce przejdź do nazwy hosta punktu końcowego zwróconego przez poprzednie polecenie: <myendpoint>-<hash>.z01.azurefd.net. Żądanie powinno zostać automatycznie przekierowane do aplikacji podstawowej w regionie Wschodnie stany USA.
Aby przetestować natychmiastowe globalne przejście w tryb failover:
Otwórz przeglądarkę i przejdź do nazwy hosta punktu końcowego:
<myendpoint>-<hash>.z01.azurefd.net.Zatrzymaj aplikację podstawową, uruchamiając polecenie az webapp stop.
az webapp stop --name <web-app-east-us> --resource-group myresourcegroupOdśwież przeglądarkę. Powinna zostać wyświetlona ta sama strona informacji, ponieważ ruch jest teraz kierowany do uruchomionej aplikacji w regionie Zachodnie stany USA.
Napiwek
Może być konieczne odświeżenie strony kilka razy, aby przejście w tryb failover zostało ukończone.
Teraz zatrzymaj aplikację pomocniczą.
az webapp stop --name <web-app-west-us> --resource-group myresourcegroupOdśwież przeglądarkę. Tym razem powinien zostać wyświetlony komunikat o błędzie.
Uruchom ponownie jedną z aplikacji internetowych, uruchamiając polecenie az webapp start. Odśwież przeglądarkę i powinna zostać ponownie wyświetlona aplikacja.
az webapp start --name <web-app-east-us> --resource-group myresourcegroup
Sprawdzono, że możesz uzyskiwać dostęp do aplikacji za pośrednictwem usługi Azure Front Door i że tryb failover działa zgodnie z oczekiwaniami. Uruchom ponownie inną aplikację, jeśli skończysz z testowaniem trybu failover.
Aby przetestować ograniczenia dostępu i upewnić się, że aplikacje można uzyskać tylko za pośrednictwem usługi Azure Front Door, otwórz przeglądarkę i przejdź do wszystkich adresów URL aplikacji. Aby znaleźć adresy URL, uruchom następujące polecenia:
az webapp show --name <web-app-east-us> --resource-group myresourcegroup --query "hostNames"
az webapp show --name <web-app-west-us> --resource-group myresourcegroup --query "hostNames"
Powinna zostać wyświetlona strona błędu wskazująca, że aplikacje nie są dostępne.
Czyszczenie zasobów
W poprzednich krokach utworzono zasoby platformy Azure w grupie zasobów. Jeśli te zasoby nie będą raczej potrzebne w przyszłości, usuń grupę zasobów, uruchamiając następujące polecenie w usłudze Cloud Shell.
az group delete --name myresourcegroup
Uruchomienie tego polecenia może potrwać kilka minut.
Wdrażanie z usługi ARM/Bicep
Zasoby utworzone w tym samouczku można wdrożyć przy użyciu szablonu ARM/Bicep. Szablon aplikacji internetowej o wysokiej dostępności w wielu regionach umożliwia utworzenie bezpiecznego, wysoce dostępnego, kompleksowego rozwiązania z dwoma aplikacjami internetowymi w różnych regionach za usługą Azure Front Door.
Aby dowiedzieć się, jak wdrażać szablony usługi ARM/Bicep, zobacz How to deploy resources with Bicep and Azure CLI (Jak wdrażać zasoby przy użyciu interfejsu wiersza polecenia platformy Azure i aplikacji Bicep).
Często zadawane pytania
W tym samouczku do tej pory wdrożono infrastrukturę bazową w celu włączenia aplikacji internetowej z wieloma regionami. Usługa App Service udostępnia funkcje, które mogą pomóc w zapewnieniu, że uruchamiasz aplikacje zgodnie z najlepszymi rozwiązaniami i zaleceniami dotyczącymi zabezpieczeń.
Ta sekcja zawiera często zadawane pytania, które ułatwiają dalsze zabezpieczanie aplikacji oraz wdrażanie zasobów i zarządzanie nimi przy użyciu najlepszych rozwiązań.
Jaka jest zalecana metoda zarządzania i wdrażania infrastruktury aplikacji i zasobów platformy Azure?
W tym samouczku użyto interfejsu wiersza polecenia platformy Azure do wdrożenia zasobów infrastruktury. Rozważ skonfigurowanie mechanizmu ciągłego wdrażania w celu zarządzania infrastrukturą aplikacji. Ponieważ wdrażasz zasoby w różnych regionach, musisz niezależnie zarządzać tymi zasobami w różnych regionach. Aby upewnić się, że zasoby są identyczne w każdym regionie, infrastruktura jako kod (IaC), taka jak szablony usługi Azure Resource Manager lub narzędzie Terraform , powinny być używane z potokami wdrażania, takimi jak azure Pipelines lub GitHub Actions. W ten sposób, jeśli skonfigurowano odpowiednio, każda zmiana zasobów spowoduje wyzwolenie aktualizacji we wszystkich regionach, w których wdrożono. Aby uzyskać więcej informacji, zobacz Ciągłe wdrażanie w usłudze aplikacja systemu Azure Service.
Jak za pomocą miejsc przejściowych przećwiczyć bezpieczne wdrażanie w środowisku produkcyjnym?
Wdrażanie kodu aplikacji bezpośrednio w aplikacjach/miejscach produkcyjnych nie jest zalecane. Jest to spowodowane tym, że chcesz mieć bezpieczne miejsce do testowania aplikacji i weryfikowania zmian wprowadzonych przed wypchnięciem do środowiska produkcyjnego. Użyj kombinacji miejsc przejściowych i zamiany miejsc, aby przenieść kod ze środowiska testowego do środowiska produkcyjnego.
Dla tego scenariusza utworzono już infrastrukturę bazową. Teraz utworzysz miejsca wdrożenia dla każdego wystąpienia aplikacji i skonfigurujesz ciągłe wdrażanie do tych miejsc przejściowych za pomocą funkcji GitHub Actions. Podobnie jak w przypadku zarządzania infrastrukturą, skonfigurowanie ciągłego wdrażania kodu źródłowego aplikacji jest również zalecane, aby upewnić się, że zmiany w różnych regionach są zsynchronizowane. Jeśli nie skonfigurujesz ciągłego wdrażania, musisz ręcznie zaktualizować każdą aplikację w każdym regionie przy każdej zmianie kodu.
W pozostałych krokach tego samouczka powinna być gotowa aplikacja do wdrożenia w usłudze App Services. Jeśli potrzebujesz przykładowej aplikacji, możesz użyć przykładowej aplikacji Node.js Hello World. Rozwidlenie tego repozytorium, aby mieć własną kopię.
Pamiętaj, aby ustawić ustawienia stosu usługi App Service dla aplikacji. Ustawienia stosu odnoszą się do języka lub środowiska uruchomieniowego używanego dla aplikacji. To ustawienie można skonfigurować przy użyciu interfejsu wiersza polecenia platformy Azure za az webapp config set pomocą polecenia lub w portalu, wykonując następujące kroki. Jeśli używasz przykładu Node.js, ustaw ustawienia stosu na Node 18 LTS.
- Przejdź do aplikacji i wybierz pozycję Konfiguracja w spisie treści po lewej stronie.
- Wybierz kartę Ustawienia Ogólne.
- W obszarze Ustawienia stosu wybierz odpowiednią wartość dla aplikacji.
- Wybierz pozycję Zapisz , a następnie pozycję Kontynuuj , aby potwierdzić aktualizację.
- Powtórz te kroki dla innych aplikacji.
Uruchom następujące polecenia, aby utworzyć miejsca przejściowe o nazwie "stage" dla każdej aplikacji. Zastąp symbole zastępcze symboli i <web-app-east-us> <web-app-west-us> nazwami aplikacji.
az webapp deployment slot create --resource-group myresourcegroup --name <web-app-east-us> --slot stage --configuration-source <web-app-east-us>
az webapp deployment slot create --resource-group myresourcegroup --name <web-app-west-us> --slot stage --configuration-source <web-app-west-us>
Aby skonfigurować ciągłe wdrażanie, należy użyć witryny Azure Portal. Aby uzyskać szczegółowe wskazówki dotyczące konfigurowania ciągłego wdrażania z dostawcami, takimi jak GitHub Actions, zobacz Ciągłe wdrażanie w usłudze aplikacja systemu Azure Service.
Aby skonfigurować ciągłe wdrażanie za pomocą funkcji GitHub Actions, wykonaj następujące kroki dla każdego miejsca przejściowego.
W witrynie Azure Portal przejdź do strony zarządzania dla jednego z miejsc aplikacji usługi App Service.
W okienku po lewej stronie wybierz pozycję Centrum wdrażania. Następnie wybierz pozycję Ustawienia.
W polu Źródło wybierz pozycję "GitHub" z opcji ciągłej integracji/ciągłego wdrażania:
Jeśli wdrażasz z usługi GitHub po raz pierwszy, wybierz pozycję Autoryzuj i postępuj zgodnie z monitami autoryzacji. Jeśli chcesz wdrożyć z repozytorium innego użytkownika, wybierz pozycję Zmień konto.
Po autoryzaniu konta platformy Azure za pomocą usługi GitHub wybierz pozycję Organizacja, Repozytorium i Gałąź, aby skonfigurować ciągłą integrację/ciągłe wdrażanie. Jeśli nie możesz znaleźć organizacji lub repozytorium, może być konieczne włączenie większej liczby uprawnień w usłudze GitHub. Aby uzyskać więcej informacji, zobacz Zarządzanie dostępem do repozytoriów organizacji.
Jeśli używasz przykładowej aplikacji Node.js, użyj następujących ustawień.
Ustawienie Wartość Organizacja <your-GitHub-organization>Repozytorium nodejs-docs-hello-world Oddział main
Wybierz pozycję Zapisz.
Nowe zatwierdzenia w wybranym repozytorium i gałęzi są teraz stale wdrażane w miejscu aplikacji usługi App Service. Zatwierdzenia i wdrożenia można śledzić na karcie Dzienniki .
Domyślny plik przepływu pracy, który używa profilu publikowania do uwierzytelniania w usłudze App Service, jest dodawany do repozytorium GitHub. Ten plik można wyświetlić, przechodząc do <repo-name>/.github/workflows/ katalogu.
Jak mogę wyłączyć uwierzytelnianie podstawowe w usłudze App Service?
Rozważ wyłączenie uwierzytelniania podstawowego, które ogranicza dostęp do punktów końcowych FTP i SCM do użytkowników, którzy są wspierani przez identyfikator Entra firmy Microsoft. Jeśli używasz narzędzia ciągłego wdrażania do wdrażania kodu źródłowego aplikacji, wyłączenie uwierzytelniania podstawowego wymaga wykonania dodatkowych kroków w celu skonfigurowania ciągłego wdrażania. Na przykład nie można użyć profilu publikowania, ponieważ nie używa poświadczeń firmy Microsoft Entra. Zamiast tego należy użyć jednostki usługi lub openID Connect.
Aby wyłączyć uwierzytelnianie podstawowe dla usługi App Service, uruchom następujące polecenia dla każdej aplikacji i miejsca, zastępując symbole zastępcze dla <web-app-east-us> i <web-app-west-us> nazwami aplikacji. Pierwszy zestaw poleceń wyłącza dostęp FTP do lokacji produkcyjnych i miejsc przejściowych, a drugi zestaw poleceń wyłącza podstawowy dostęp uwierzytelniania do portu WebDeploy i lokacji SCM dla lokacji produkcyjnych i miejsc przejściowych.
az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us> --set properties.allow=false
az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us>/slots/stage --set properties.allow=false
az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us> --set properties.allow=false
az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us>/slots/stage --set properties.allow=false
az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us> --set properties.allow=false
az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us>/slots/stage --set properties.allow=false
az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us> --set properties.allow=false
az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us>/slots/stage --set properties.allow=false
Aby uzyskać więcej informacji na temat wyłączania podstawowego uwierzytelniania, w tym testowania i monitorowania logowania, zobacz Wyłączanie uwierzytelniania podstawowego we wdrożeniach usługi App Service.
Jak mogę wdrożyć kod przy użyciu ciągłego wdrażania, jeśli wyłączyłem uwierzytelnianie podstawowe?
Jeśli zdecydujesz się zezwolić na podstawowe uwierzytelnianie w aplikacjach usługi App Service, możesz użyć dowolnej z dostępnych metod wdrażania w usłudze App Service, w tym przy użyciu profilu publikowania skonfigurowanego w sekcji miejsca przejściowe.
Jeśli wyłączysz podstawowe uwierzytelnianie dla usług App Services, ciągłe wdrażanie wymaga jednostki usługi lub openID Connect na potrzeby uwierzytelniania. Jeśli używasz funkcji GitHub Actions jako repozytorium kodu, zapoznaj się z samouczkiem krok po kroku dotyczącym używania jednostki usługi lub narzędzia OpenID Connect do wdrażania w usłudze App Service przy użyciu funkcji GitHub Actions lub wykonaj kroki opisane w poniższej sekcji.
Tworzenie jednostki usługi i konfigurowanie poświadczeń za pomocą funkcji GitHub Actions
Aby skonfigurować ciągłe wdrażanie za pomocą funkcji GitHub Actions i jednostki usługi, wykonaj następujące kroki.
Uruchom następujące polecenie, aby utworzyć jednostkę usługi. Zastąp symbole zastępcze nazwami aplikacji
<subscription-id>i . Dane wyjściowe to obiekt JSON z poświadczeniami przypisania roli, które zapewniają dostęp do aplikacji usługi App Service. Skopiuj ten obiekt JSON do następnego kroku. Zawiera on wpis tajny klienta, który jest widoczny tylko w tej chwili. Zawsze dobrym rozwiązaniem jest przyznanie minimalnego dostępu. Zakres w tym przykładzie jest ograniczony tylko do aplikacji, a nie całej grupy zasobów.az ad sp create-for-rbac --name "myApp" --role contributor --scopes /subscriptions/<subscription-id>/resourceGroups/myresourcegroup/providers/Microsoft.Web/sites/<web-app-east-us> /subscriptions/<subscription-id>/resourceGroups/myresourcegroup/providers/Microsoft.Web/sites/<web-app-west-us> --sdk-authMusisz podać poświadczenia jednostki usługi do akcji Azure/login w ramach przepływu pracy akcji usługi GitHub, którego używasz. Te wartości można podać bezpośrednio w przepływie pracy lub przechowywać w wpisach tajnych usługi GitHub i odwoływać się do nich w przepływie pracy. Zapisanie wartości jako wpisów tajnych usługi GitHub jest bezpieczniejszą opcją.
Otwórz repozytorium GitHub i przejdź do pozycji Ustawienia>Wpisy tajne zabezpieczeń>i zmienne Akcje>
Wybierz pozycję Nowy wpis tajny repozytorium i utwórz wpis tajny dla każdej z poniższych wartości. Wartości można znaleźć w skopiowanych wcześniej danych wyjściowych json.
Nazwa/nazwisko Wartość AZURE_APP_ID <application/client-id>AZURE_PASSWORD <client-secret>AZURE_TENANT_ID <tenant-id>AZURE_SUBSCRIPTION_ID <subscription-id>
Tworzenie przepływu pracy funkcji GitHub Actions
Teraz, gdy masz jednostkę usługi, która może uzyskiwać dostęp do aplikacji usługi App Service, zmodyfikuj domyślne przepływy pracy utworzone dla aplikacji podczas konfigurowania ciągłego wdrażania. Uwierzytelnianie musi odbywać się przy użyciu jednostki usługi zamiast profilu publikowania. Aby zapoznać się z przykładowymi przepływami pracy, zobacz kartę "Jednostka usługi" w temacie Dodawanie pliku przepływu pracy do repozytorium GitHub. Poniższy przykładowy przepływ pracy może służyć do Node.js przykładowej aplikacji, która została udostępniona.
Otwórz repozytorium GitHub aplikacji i przejdź do
<repo-name>/.github/workflows/katalogu. Powinny zostać wyświetlone automatycznie wygenerowane przepływy pracy.Dla każdego pliku przepływu pracy wybierz przycisk "ołówek" w prawym górnym rogu, aby edytować plik. Zastąp zawartość następującym tekstem, który zakłada, że utworzono wcześniej wpisy tajne usługi GitHub dla poświadczeń. Zaktualizuj symbol zastępczy w
<web-app-name>sekcji "env", a następnie zatwierdź bezpośrednio w gałęzi głównej. To zatwierdzenie wyzwala akcję usługi GitHub w celu ponownego uruchomienia i wdrożenia kodu, tym razem przy użyciu jednostki usługi do uwierzytelniania.name: Build and deploy Node.js app to Azure Web App on: push: branches: - main workflow_dispatch: env: AZURE_WEBAPP_NAME: <web-app-name> # set this to your application's name NODE_VERSION: '18.x' # set this to the node version to use AZURE_WEBAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root AZURE_WEBAPP_SLOT_NAME: stage # set this to your application's slot name jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Set up Node.js version uses: actions/setup-node@v1 with: node-version: ${{ env.NODE_VERSION }} - name: npm install, build run: | npm install npm run build --if-present - name: Upload artifact for deployment job uses: actions/upload-artifact@v2 with: name: node-app path: . deploy: runs-on: ubuntu-latest needs: build environment: name: 'stage' url: ${{ steps.deploy-to-webapp.outputs.webapp-url }} steps: - name: Download artifact from build job uses: actions/download-artifact@v2 with: name: node-app - uses: azure/login@v1 with: creds: | { "clientId": "${{ secrets.AZURE_APP_ID }}", "clientSecret": "${{ secrets.AZURE_PASSWORD }}", "subscriptionId": "${{ secrets.AZURE_SUBSCRIPTION_ID }}", "tenantId": "${{ secrets.AZURE_TENANT_ID }}" } - name: 'Deploy to Azure Web App' id: deploy-to-webapp uses: azure/webapps-deploy@v2 with: app-name: ${{ env.AZURE_WEBAPP_NAME }} slot-name: ${{ env.AZURE_WEBAPP_SLOT_NAME }} package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }} - name: logout run: | az logout
W jaki sposób routing ruchu w miejscu umożliwia mi testowanie aktualizacji, które wprowadzam do moich aplikacji?
Routing ruchu z miejscami umożliwia kierowanie wstępnie zdefiniowanej części ruchu użytkownika do każdego miejsca. Początkowo 100% ruchu jest kierowane do lokacji produkcyjnej. Masz jednak możliwość wysyłania 10% ruchu do miejsca przejściowego. Jeśli w ten sposób skonfigurujesz routing ruchu w miejscu, gdy użytkownicy próbują uzyskać dostęp do aplikacji, 10% z nich zostanie automatycznie przekierowanych do miejsca przejściowego bez zmian w wystąpieniu usługi Front Door. Aby dowiedzieć się więcej o zamianach miejsc i środowiskach przejściowych w usłudze App Service, zobacz Konfigurowanie środowisk przejściowych w usłudze aplikacja systemu Azure Service.
Jak mogę przenieść mój kod z miejsca przejściowego do miejsca produkcyjnego?
Po zakończeniu testowania i walidacji w miejscach przejściowych możesz wykonać zamianę miejsca z miejsca przejściowego na lokację produkcyjną. Tę zamianę należy wykonać dla wszystkich wystąpień aplikacji w każdym regionie. Podczas zamiany miejsca platforma App Service zapewnia, że miejsce docelowe nie powoduje przestoju.
Aby wykonać zamianę, uruchom następujące polecenie dla każdej aplikacji. Zastąp symbol zastępczy elementu <web-app-name>.
az webapp deployment slot swap --resource-group MyResourceGroup -name <web-app-name> --slot stage --target-slot production
Po kilku minutach możesz przejść do punktu końcowego usługi Front Door, aby zweryfikować powodzenie zamiany miejsca.
Na tym etapie aplikacje są uruchomione i wszelkie zmiany wprowadzone w kodzie źródłowym aplikacji automatycznie wyzwalają aktualizację obu miejsc przejściowych. Następnie możesz powtórzyć proces zamiany miejsca, gdy wszystko będzie gotowe do przeniesienia tego kodu do środowiska produkcyjnego.
Jak można używać usługi Azure Front Door we wdrożeniach z wieloma regionami?
Jeśli martwisz się o potencjalne zakłócenia lub problemy z ciągłością w różnych regionach, ponieważ niektórzy klienci widzą jedną wersję aplikacji, podczas gdy inni widzą inną wersję lub jeśli wprowadzasz znaczące zmiany w aplikacjach, możesz tymczasowo usunąć witrynę przechodzącą zamianę miejsca z grupy źródeł usługi Front Door. Cały ruch jest następnie kierowany do innego źródła. Przejdź do okienka Aktualizuj grupę źródeł i usuń źródło, które przechodzi zmianę. Po wprowadzeniu wszystkich zmian i ponownym udostępnieniu ruchu możesz powrócić do tego samego okienka i wybrać pozycję + Dodaj źródło, aby odczytać źródło .
Jeśli nie chcesz usuwać, a następnie odczytywać źródła, możesz utworzyć dodatkowe grupy źródeł dla wystąpienia usługi Front Door. Następnie możesz skojarzyć trasę z grupą pochodzenia wskazującą na zamierzone źródło. Można na przykład utworzyć dwie nowe grupy źródeł, jedną dla regionu podstawowego i jedną dla regionu pomocniczego. Gdy region podstawowy przechodzi zmianę, skojarz trasę z regionem pomocniczym i odwrotnie, gdy region pomocniczy przechodzi zmianę. Po zakończeniu wszystkich zmian możesz skojarzyć trasę z oryginalną grupą pochodzenia zawierającą oba regiony. Ta metoda działa, ponieważ trasa może być skojarzona tylko z jedną grupą pochodzenia jednocześnie.
Aby zademonstrować pracę z wieloma źródłami, na poniższym zrzucie ekranu znajdują się trzy grupy pochodzenia. Element "MyOriginGroup" składa się zarówno z aplikacji internetowych, jak i dwóch pozostałych grup pochodzenia, z których każda składa się z aplikacji internetowej w odpowiednim regionie. W tym przykładzie aplikacja w regionie podstawowym przechodzi zmianę. Przed rozpoczęciem tej zmiany trasa została skojarzona z "MySecondaryRegion", więc cały ruch będzie wysyłany do aplikacji w regionie pomocniczym w okresie zmiany. Możesz zaktualizować trasę, wybierając pozycję Nie skojarzono, co powoduje wyświetlenie okienka Kojarzenie tras .
Jak mogę ograniczyć dostęp do witryny narzędzi zaawansowanych?
W przypadku usługi aplikacja systemu Azure witryna narzędzi SCM/advanced służy do zarządzania aplikacjami i wdrażania kodu źródłowego aplikacji. Rozważ zablokowanie witryny narzędzi SCM/zaawansowanych, ponieważ najprawdopodobniej ta witryna nie musi być osiągana za pośrednictwem usługi Front Door. Można na przykład skonfigurować ograniczenia dostępu, które umożliwiają przeprowadzanie testów i włączanie ciągłego wdrażania z wybranego narzędzia. Jeśli używasz miejsc wdrożenia, w szczególności w przypadku miejsc produkcyjnych możesz odmówić prawie całego dostępu do witryny SCM, ponieważ testowanie i walidacja odbywa się przy użyciu miejsc przejściowych.