Podstawowa aplikacja internetowa strefowo nadmiarowa o wysokiej dostępności

Azure App Service
Azure Application Gateway
Azure Storage
Azure SQL Database
Azure Private Link
Azure Virtual Network
Azure Monitor

Ta architektura bazowa jest oparta na podstawowej architekturze aplikacji internetowej i rozszerza ją w celu zapewnienia szczegółowych wskazówek dotyczących projektowania bezpiecznej, strefowo nadmiarowej i wysoce dostępnej aplikacji internetowej na platformie Azure. Architektura uwidacznia publiczny punkt końcowy za pośrednictwem usługi aplikacja systemu Azure Gateway z zaporą aplikacji internetowej. Kieruje żądania do usługi aplikacja systemu Azure za pośrednictwem usługi Private Link. Aplikacja usługi App Service używa integracji sieci wirtualnej i usługi Private Link, aby bezpiecznie komunikować się z usługami PaaS platformy Azure, takimi jak Azure Key Vault i Azure SQL Database.

Ważne

Logo usługi GitHubWskazówki są wspierane przez przykładową implementację, która prezentuje podstawową implementację usługi App Service na platformie Azure. Ta implementacja może służyć jako podstawa do dalszego opracowywania rozwiązań w pierwszym kroku w kierunku produkcji.

Architektura

Diagram przedstawiający podstawową architekturę usługi App Service z nadmiarowością strefową i wysoką dostępnością.

Rysunek 1. Architektura usługi aplikacja systemu Azure wg planu bazowego

Pobierz plik programu Visio z tą architekturą.

Składniki

Wiele składników tej architektury jest takich samych jak podstawowa architektura aplikacji internetowej. Poniższa lista zawiera tylko zmiany w podstawowej architekturze.

  • Application Gateway to moduł równoważenia obciążenia w warstwie 7 (HTTP/S) i internetowy menedżer ruchu. Używa routingu opartego na ścieżkach URL w celu dystrybucji ruchu przychodzącego między strefami dostępności i odciąża szyfrowanie w celu zwiększenia wydajności aplikacji.
  • Zapora aplikacji internetowej (WAF) to natywna dla chmury usługa, która chroni aplikacje internetowe przed typowymi programami wykorzystującymi luki, takie jak wstrzyknięcie kodu SQL i wykonywanie skryptów między witrynami. Zapora aplikacji internetowej zapewnia wgląd w ruch do i z aplikacji internetowej, umożliwiając monitorowanie i zabezpieczanie aplikacji.
  • Azure Key Vault to usługa, która bezpiecznie przechowuje wpisy tajne, klucze szyfrowania i certyfikaty oraz zarządza nimi. Centralizuje zarządzanie poufnymi informacjami.
  • Azure Virtual Network to usługa, która umożliwia tworzenie izolowanych i bezpiecznych prywatnych sieci wirtualnych na platformie Azure. W przypadku aplikacji internetowej w usłudze App Service potrzebna jest podsieć sieci wirtualnej do korzystania z prywatnych punktów końcowych na potrzeby bezpiecznej komunikacji między zasobami.
  • Usługa Private Link umożliwia klientom uzyskiwanie dostępu do usług Platformy jako usługi (PaaS) platformy Azure bezpośrednio z prywatnych sieci wirtualnych bez korzystania z publicznego adresowania IP.
  • Azure DNS to usługa hostingu dla domen DNS, która zapewnia rozpoznawanie nazw przy użyciu infrastruktury platformy Microsoft Azure. Prywatna strefa DNS strefy umożliwiają mapowanie w pełni kwalifikowanej nazwy domeny (FQDN) usługi na adres IP prywatnego punktu końcowego.

Sieć

Zabezpieczenia sieci są podstawą architektury bazowej usług App Services (patrz Rysunek 2). Na wysokim poziomie architektura sieci zapewnia następujące elementy:

  1. Pojedynczy bezpieczny punkt wejścia dla ruchu klienckiego
  2. Ruch sieciowy jest filtrowany
  3. Dane przesyłane są szyfrowane kompleksowo przy użyciu protokołu TLS
  4. Eksfiltracja danych jest zminimalizowana przez utrzymywanie ruchu na platformie Azure za pomocą usługi Private Link
  5. Zasoby sieciowe są logicznie grupowane i odizolowane od siebie za pośrednictwem segmentacji sieci

Przepływy sieciowe

Diagram przedstawiający podstawową architekturę sieci usługi App Service.

Rysunek 2. Architektura sieciowa aplikacji usługi aplikacja systemu Azure

Poniżej przedstawiono opisy przychodzącego przepływu ruchu internetowego do wystąpienia usługi App Service i przepływu z usługi App Service do usług platformy Azure.

Przepływ przychodzący

  1. Użytkownik wysyła żądanie do publicznego adresu IP usługi Application Gateway.
  2. Reguły zapory aplikacji internetowej są oceniane. Reguły zapory aplikacji internetowej pozytywnie wpływają na niezawodność systemu, chroniąc przed różnymi atakami, takimi jak wykonywanie skryptów między witrynami (XSS) i wstrzyknięcie kodu SQL. aplikacja systemu Azure Gateway zwraca błąd do osoby żądającego, jeśli zostanie naruszona reguła zapory aplikacji internetowej i przetwarzanie zostanie zatrzymane. Jeśli żadne reguły zapory aplikacji internetowej nie zostaną naruszone, usługa Application Gateway kieruje żądanie do puli zaplecza, co w tym przypadku jest domeną domyślną usługi App Service.
  3. Prywatna strefa privatelink.azurewebsites.net DNS jest połączona z siecią wirtualną. Strefa DNS ma rekord A, który mapuje domyślną domenę usługi App Service na prywatny adres IP prywatnego punktu końcowego usługi App Service. Ta połączona prywatna strefa DNS umożliwia usłudze Azure DNS rozpoznawanie domyślnej domeny z prywatnym adresem IP punktu końcowego.
  4. Żądanie jest kierowane do wystąpienia usługi App Service za pośrednictwem prywatnego punktu końcowego.

Przepływ usług App Service do usługi Azure PaaS

  1. Usługa App Service wysyła żądanie do nazwy DNS wymaganej usługi platformy Azure. Żądanie może dotyczyć usługi Azure Key Vault w celu uzyskania wpisu tajnego, usługi Azure Storage w celu pobrania pliku zip publikowania, usługi Azure SQL Database lub dowolnej innej usługi platformy Azure obsługującej usługę Private Link. Funkcja integracji sieci wirtualnej usługi App Service kieruje żądanie za pośrednictwem sieci wirtualnej.
  2. Podobnie jak krok 3 w przepływie przychodzącym, połączona prywatna strefa DNS ma rekord A, który mapuje domenę usługi platformy Azure na prywatny adres IP prywatnego punktu końcowego. Ponownie ta połączona prywatna strefa DNS umożliwia usłudze Azure DNS rozpoznawanie domeny z prywatnym adresem IP punktu końcowego usługi.
  3. Żądanie jest kierowane do usługi za pośrednictwem prywatnego punktu końcowego.

Ruch przychodzący do usługi App Services

Usługa Application Gateway to zasób regionalny spełniający wymagania tej architektury punktu odniesienia. Application Gateway to skalowalny, regionalny moduł równoważenia obciążenia warstwy 7 obsługujący funkcje, takie jak zapora aplikacji internetowej i odciążanie protokołu TLS. Podczas implementowania usługi Application Gateway dla ruchu przychodzącego w usługach aplikacja systemu Azure Należy wziąć pod uwagę następujące kwestie.

  • Wdrażanie usługi Application Gateway i konfigurowanie zasad zapory aplikacji internetowej przy użyciu zestawu reguł zarządzanych przez firmę Microsoft. Użyj trybu zapobiegania, aby zapobiec atakom internetowym, co może spowodować, że usługa pochodzenia (usługa App Service w architekturze) stanie się niedostępna.
  • Zaimplementuj kompleksowe szyfrowanie TLS.
  • Użyj prywatnych punktów końcowych, aby zaimplementować przychodzący prywatny dostęp do usługi App Service.
  • Rozważ zaimplementowanie skalowania automatycznego dla usługi Application Gateway, aby łatwo dostosować się do dynamicznych przepływów ruchu.
  • Rozważ użycie minimalnej liczby wystąpień skalowania nie mniejszej niż trzy i zawsze używaj wszystkich stref dostępności, które obsługuje region. Chociaż usługa Application Gateway jest wdrażana w sposób o wysokiej dostępności, nawet w przypadku pojedynczego wystąpienia skalowania tworzenie nowego wystąpienia po awarii może potrwać do siedmiu minut. Wdrażanie wielu wystąpień w Strefy dostępności pomaga zagwarantować, że po awarii wystąpienie jest uruchomione podczas tworzenia nowego wystąpienia.
  • Wyłącz dostęp do sieci publicznej w usłudze App Service, aby zapewnić izolację sieci. W pliku Bicep można to zrobić, ustawiając wartość w obszarze publicNetworkAccess: 'Disabled' properties/siteConfig.

Przepływ z usług App Services do usług platformy Azure

Ta architektura używa integracji sieci wirtualnej dla usługi App Service, w szczególności do kierowania ruchu do prywatnych punktów końcowych za pośrednictwem sieci wirtualnej. Architektura linii bazowej nie umożliwia całego routingu ruchu, aby wymusić cały ruch wychodzący przez sieć wirtualną, tylko ruch wewnętrzny, taki jak ruch związany z prywatnymi punktami końcowymi.

Usługi platformy Azure, które nie wymagają dostępu z publicznego Internetu, powinny mieć włączone prywatne punkty końcowe i wyłączyć publiczne punkty końcowe. Prywatne punkty końcowe są używane w całej tej architekturze w celu zwiększenia bezpieczeństwa, umożliwiając usłudze App Service łączenie się z usługami Private Link bezpośrednio z prywatnej sieci wirtualnej bez używania publicznego adresowania IP.

W tej architekturze wszystkie usługi Azure SQL Database, Azure Storage i Key Vault mają wyłączone publiczne punkty końcowe. Zapory usług platformy Azure są używane tylko do zezwalania na ruch z innych autoryzowanych usług platformy Azure. Należy skonfigurować inne usługi platformy Azure z prywatnymi punktami końcowymi, takimi jak Azure Cosmos DB i Azure Redis Cache. W tej architekturze usługa Azure Monitor nie używa prywatnego punktu końcowego, ale może.

Architektura punktu odniesienia implementuje prywatną strefę DNS dla każdej usługi. Prywatna strefa DNS zawiera rekord A mapowany między w pełni kwalifikowaną nazwą domeny usługi a prywatnym adresem IP prywatnego punktu końcowego. Strefy są połączone z siecią wirtualną. Prywatna strefa DNS grupy stref zapewniają, że rekordy DNS łącza prywatnego są tworzone i aktualizowane automatycznie.

Podczas implementowania integracji sieci wirtualnej i prywatnych punktów końcowych należy wziąć pod uwagę następujące kwestie.

Segmentacja i zabezpieczenia sieci wirtualnej

Sieć w tej architekturze ma oddzielne podsieci dla składników integracji usługi Application Gateway, usługi App Service i prywatnych punktów końcowych. Każda podsieć ma sieciową grupę zabezpieczeń, która ogranicza zarówno ruch przychodzący, jak i wychodzący dla tych podsieci, tylko do tego, co jest wymagane. W poniższej tabeli przedstawiono uproszczony widok reguł sieciowej grupy zabezpieczeń dodaną do każdej podsieci. Tabela zawiera nazwę reguły i funkcję.

Podsieć Przychodzący Wychodzący
snet-AppGateway AppGw.In.Allow.ControlPlane: Zezwalaj na dostęp do płaszczyzny kontroli ruchu przychodzącego

AppGw.In.Allow443.Internet: Zezwalaj na dostęp do przychodzącego internetowego protokołu HTTPS
AppGw.Out.Allow.AppServices: Zezwalaj na dostęp wychodzący do podsieci AppServicesSubnet

AppGw.Out.Allow.PrivateEndpoints: Zezwalaj na dostęp wychodzący do usługi PrivateEndpointsSubnet

AppPlan.Out.Allow.AzureMonitor: Zezwalaj na dostęp wychodzący do usługi Azure Monitor
snet-PrivateEndpoints Reguły domyślne: Zezwalaj na ruch przychodzący z sieci wirtualnej Reguły domyślne: Zezwalaj na ruch wychodzący do sieci wirtualnej
snet-AppService Reguły domyślne: Zezwalaj na ruch przychodzący z sieci wirtualnej AppPlan.Out.Allow.PrivateEndpoints: Zezwalaj na dostęp wychodzący do usługi PrivateEndpointsSubnet

AppPlan.Out.Allow.AzureMonitor: Zezwalaj na dostęp wychodzący do usługi Azure Monitor

Podczas implementowania segmentacji i zabezpieczeń sieci wirtualnej należy wziąć pod uwagę następujące kwestie.

  • Włącz ochronę przed atakami DDoS dla sieci wirtualnej z podsiecią, która jest częścią bramy aplikacji z publicznym adresem IP.
  • W miarę możliwości dodaj sieciową grupę zabezpieczeń do każdej podsieci. Należy użyć najostrzejszych reguł, które umożliwiają korzystanie z pełnej funkcjonalności rozwiązania.
  • Użyj grup zabezpieczeń aplikacji. Grupy zabezpieczeń aplikacji umożliwiają grupowanie sieciowych grup zabezpieczeń, co ułatwia tworzenie reguł w złożonych środowiskach.

Przykładem schematu podsieci wirtualnej może być:

Type Nazwisko Zakres adresów
Virtual Network Przedrostek adresu 10.0.0.0/16
Podsieć GatewaySubnet 10.0.1.0/24
Podsieć AppServicesSubnet 10.0.0.0/24
Podsieć PrivateEndpointsSubnet 10.0.2.0/27
Podsieć AgenciSubject 10.0.2.32/27

Dokumentacja azure-samples\app-service-baseline-implementation

Kwestie wymagające rozważenia

Te zagadnienia implementują filary struktury Azure Well-Architected Framework, która jest zestawem wytycznych, które mogą służyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.

Niezawodność

Niezawodność zapewnia, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Omówienie filaru niezawodności.

Podstawowa architektura usługi App Services koncentruje się na nadmiarowości strefowej dla kluczowych usług regionalnych. Strefy dostępności są fizycznie oddzielone lokalizacjami w obrębie regionu. Zapewniają nadmiarowość strefową na potrzeby obsługi usług, gdy co najmniej dwa wystąpienia są wdrażane w regionach pomocniczych. W przypadku przestoju w jednej strefie inne strefy mogą nadal nie mieć wpływu.

Architektura zapewnia również wystarczającą liczbę wystąpień usług platformy Azure, aby sprostać zapotrzebowaniu. Poniższe sekcje zawierają wskazówki dotyczące niezawodności kluczowych usług w architekturze. Dzięki temu strefy dostępności pomagają w osiągnięciu niezawodności, zapewniając wysoką dostępność i odporność na uszkodzenia.

Application Gateway

Wdróż bramę aplikacja systemu Azure w wersji 2 w konfiguracji strefowo nadmiarowej. Rozważ użycie minimalnej liczby wystąpień skalowania wynoszącej nie mniej niż trzy, aby uniknąć sześciominutowego czasu uruchamiania dla wystąpienia usługi Application Gateway, jeśli wystąpi awaria.

App Services

  • Wdróż co najmniej trzy wystąpienia usług App Services z obsługą stref dostępności.
  • Zaimplementuj punkty końcowe sprawdzania kondycji w aplikacjach i skonfiguruj funkcję sprawdzania aplikacji Kondycja usługi, aby przekierować żądania z dala od wystąpień w złej kondycji. Aby uzyskać więcej informacji na temat sprawdzania kondycji usługi App Service, zobacz Monitorowanie wystąpień usługi App Service przy użyciu kontroli kondycji. Aby uzyskać więcej informacji na temat implementowania punktów końcowych kontroli kondycji w aplikacjach ASP.NET, zobacz Kontrole kondycji w programie ASP.NET Core.
  • Pojemność overprovision w celu obsługi błędów strefy.

SQL Database

  • Wdróż usługę Azure SQL DB Ogólnego przeznaczenia, Premium lub Krytyczne dla działania firmy z włączoną nadmiarowością strefy. Warstwy Ogólnego przeznaczenia, Premium i Krytyczne dla działania firmy obsługują nadmiarowość strefową w usłudze Azure SQL DB.
  • Konfigurowanie kopii zapasowych bazy danych SQL w celu używania magazynu strefowo nadmiarowego (ZRS) lub magazynu geograficznie nadmiarowego (GZRS).

Blob storage

  • Usługa Azure Zone-Redundant Storage (ZRS) replikuje dane synchronicznie w trzech strefach dostępności w regionie. Utwórz konta magazynu magazynu ZRS w warstwie Standardowa lub Standardowa GZRS, aby upewnić się, że dane są replikowane w różnych strefach dostępności.
  • Utwórz oddzielne konta magazynu dla wdrożeń, zasobów internetowych i innych danych, aby można było zarządzać kontami i konfigurować je oddzielnie.

Efektywność wydajności

Efektywność wydajności to możliwość skalowania obciążenia w celu zaspokojenia zapotrzebowania użytkowników w wydajny sposób. Aby uzyskać więcej informacji, zobacz Omówienie filaru wydajności.

W poniższych sekcjach omówiono skalowalność kluczowych składników w tej architekturze.

Application Gateway

  • Zaimplementuj skalowanie automatyczne dla usługi Application Gateway w celu skalowania w poziomie lub w poziomie w celu spełnienia wymagań.
  • Ustaw maksymalną liczbę wystąpień na liczbę większą niż oczekiwano. Opłaty będą naliczane tylko za używane jednostki pojemności.
  • Ustaw minimalną liczbę wystąpień, która może obsługiwać małe skoki ruchu. Aby obliczyć minimalną liczbę wystąpień, możesz użyć średniego użycia jednostek obliczeniowych.
  • Postępuj zgodnie ze wskazówkami dotyczącymi określania rozmiaru podsieci usługi Application Gateway.

App Service

SQL Server

Skalowanie zasobów bazy danych jest złożonym tematem poza zakresem tej architektury. Podczas skalowania bazy danych należy wziąć pod uwagę następujące zasoby.

Inne wskazówki dotyczące skalowalności

  • Przejrzyj limity subskrypcji i limity przydziału , aby upewnić się, że usługi są skalowane na żądanie.
  • Rozważ buforowanie dla następujących rodzajów danych, aby zwiększyć wydajność i skalowalność:
    • Częściowo statyczne dane transakcji.
    • Stan sesji.
    • Dane wyjściowe HTML. Może to być przydatne w aplikacjach renderujących złożone dane wyjściowe HTML.

Zabezpieczenia

Podstawowa architektura usługi App Service koncentruje się na podstawowych zaleceniach dotyczących zabezpieczeń aplikacji internetowej. Zrozumienie sposobu działania szyfrowania i tożsamości w każdej warstwie ma kluczowe znaczenie dla zabezpieczenia obciążenia.

App Service

  • Wyłączanie lokalnych metod uwierzytelniania dla wdrożeń witryn FTP i SCM
  • Wyłącz zdalne debugowanie.
  • Użyj najnowszej wersji protokołu TLS.
  • Włącz usługę Microsoft Defender dla usługi App Service.
  • Użyj najnowszych wersji obsługiwanych platform, języków programowania, protokołów i struktur.
  • Rozważ środowisko App Service Environment , jeśli potrzebujesz wyższej izolacji lub bezpiecznego dostępu do sieci.

Szyfrowanie

Produkcyjna aplikacja internetowa musi szyfrować dane przesyłane przy użyciu protokołu HTTPS. Protokół HTTPS opiera się na protokole Transport Layer Security (TLS) i używa kluczy publicznych i prywatnych do szyfrowania. Należy przechowywać certyfikat (X.509) w usłudze Key Vault i zezwolić usłudze Application Gateway na pobranie klucza prywatnego. W przypadku danych magazynowanych niektóre usługi automatycznie szyfrują dane, a inne umożliwiają dostosowywanie.

Dane przesyłane

W architekturze bazowej dane przesyłane są szyfrowane od użytkownika do aplikacji internetowej w usłudze App Service. W poniższym przepływie pracy opisano sposób działania szyfrowania na wysokim poziomie.

Diagram przedstawiający bazowy przepływ szyfrowania usługi App Service.

  1. Użytkownik wysyła żądanie HTTPS do aplikacji internetowej.
  2. Żądanie HTTPS dociera do bramy aplikacji.
  3. Brama aplikacji używa certyfikatu (X.509) w usłudze Key Vault do utworzenia bezpiecznego połączenia TLS z przeglądarką internetową użytkownika. Brama aplikacji odszyfrowuje żądanie HTTPS, aby zapora aplikacji internetowej mogła ją sprawdzić.
  4. Brama aplikacji tworzy połączenie TLS z usługą App Service w celu ponownego zaszyfrowania żądania użytkownika. Usługa App Service zapewnia natywną obsługę protokołu HTTPS, dlatego nie trzeba dodawać certyfikatu do usługi App Service. Brama aplikacji wysyła zaszyfrowany ruch do usługi App Service. Usługa App Service odszyfrowuje ruch, a aplikacja internetowa przetwarza żądanie.

Podczas konfigurowania szyfrowania danych podczas przesyłania danych należy wziąć pod uwagę następujące zalecenia.

  • Utwórz lub przekaż certyfikat do usługi Key Vault. Szyfrowanie HTTPS wymaga certyfikatu (X.509). Potrzebujesz certyfikatu z zaufanego urzędu certyfikacji dla domeny niestandardowej.
  • Zapisz klucz prywatny do certyfikatu w usłudze Key Vault.
  • Postępuj zgodnie ze wskazówkami w temacie Udzielanie aplikacji uprawnień dostępu do magazynu kluczy platformy Azure przy użyciu kontroli dostępu opartej na rolach platformy Azure i tożsamości zarządzanych dla zasobów platformy Azure, aby zapewnić usłudze Application Gateway dostęp do klucza prywatnego certyfikatu. Nie używaj zasad dostępu do usługi Key Vault, aby zapewnić dostęp. Zasady dostępu umożliwiają tylko przyznawanie szerokich uprawnień nie tylko określonym wartościom.
  • Włącz kompleksowe szyfrowanie. Usługa App Service to pula zaplecza bramy aplikacji. Podczas konfigurowania ustawienia zaplecza dla puli zaplecza użyj protokołu HTTPS za pośrednictwem portu zaplecza 443.
Dane magazynowane
  • Szyfrowanie poufnych danych w usłudze Azure SQL Database przy użyciu przezroczystego szyfrowania danych. Przezroczyste dane szyfrują całą bazę danych, kopie zapasowe i pliki dziennika transakcji oraz nie wymagają żadnych zmian w aplikacji internetowej.
  • Zminimalizuj opóźnienie szyfrowania bazy danych. Aby zminimalizować opóźnienie szyfrowania, umieść dane potrzebne do zabezpieczenia we własnej bazie danych i włącz szyfrowanie tylko dla tej bazy danych.
  • Omówienie wbudowanej obsługi szyfrowania. Usługa Azure Storage automatycznie szyfruje dane magazynowane przy użyciu szyfrowania po stronie serwera (256-bitowego AES). Usługa Azure Monitor automatycznie szyfruje dane magazynowane przy użyciu kluczy zarządzanych przez firmę Microsoft (MMKs).

Zarządzanie tożsamościami i dostępem

Punkt odniesienia usługi App Service konfiguruje uwierzytelnianie i autoryzację dla tożsamości użytkowników (użytkowników) i tożsamości obciążeń (zasobów platformy Azure) oraz implementuje zasadę najniższych uprawnień.

Tożsamości użytkowników
  • Użyj zintegrowanego mechanizmu uwierzytelniania dla usługi App Service ("EasyAuth").. Usługa EasyAuth upraszcza proces integrowania dostawców tożsamości z aplikacją internetową. Obsługuje uwierzytelnianie poza aplikacją internetową, więc nie trzeba wprowadzać znaczących zmian w kodzie.
  • Skonfiguruj adres URL odpowiedzi dla domeny niestandardowej. Musisz przekierować aplikację internetową do https://<application-gateway-endpoint>/.auth/login/<provider>/callback. Zastąp <application-gateway-endpoint> ciąg publicznym adresem IP lub niestandardową nazwą domeny skojarzona z bramą aplikacji. Zastąp <provider> element dostawcą uwierzytelniania, którego używasz, takim jak "aad" dla identyfikatora Entra firmy Microsoft. Możesz użyć dokumentacji usługi Azure Front, aby skonfigurować ten przepływ za pomocą usługi Application Gateway lub skonfigurować usługę Application Gateway.
Tożsamości obciążeń
  • Użyj tożsamości zarządzanej dla tożsamości obciążeń. Tożsamość zarządzana eliminuje konieczność zarządzania poświadczeniami uwierzytelniania przez deweloperów.
  • Użyj tożsamości zarządzanych przypisanych przez użytkownika. Tożsamość przypisana przez system może spowodować niepowodzenie wdrożeń infrastruktury jako kodu w oparciu o warunki wyścigu i kolejność operacji. Aby uniknąć niektórych z tych scenariuszy błędów wdrażania, można użyć tożsamości zarządzanych przypisanych przez użytkownika. Aby uzyskać więcej informacji, zobacz Tożsamości zarządzane.

Doskonałość operacyjna

Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Omówienie filaru doskonałości operacyjnej.

Wdrożenie podstawowej aplikacji usługi App Service jest zgodne ze wskazówkami w temacie Ciągła integracja/ciągłe wdrażanie dla usługi Azure Web Apps z usługą Azure Pipelines. Oprócz tych wskazówek architektura punktu odniesienia usługi App Services uwzględnia zabezpieczenia sieci aplikacji i konta magazynu wdrożenia. Architektura odmawia publicznego dostępu do usługi App Service. Oznacza to, że nie można wdrożyć z zewnątrz sieci wirtualnej. Punkt odniesienia pokazuje, jak wdrożyć kod aplikacji w sieci wirtualnej przy użyciu własnych agentów wdrażania. Poniższe wskazówki dotyczące wdrażania koncentrują się na wdrażaniu kodu aplikacji i nie wdrażaniu zmian infrastruktury lub bazy danych.

Diagram przedstawiający podstawową architekturę wdrażania usługi App Service.

Rysunek 3. Wdrażanie aplikacji usługi aplikacja systemu Azure

Przepływ wdrażania

  1. W ramach potoku wydania potok publikuje żądanie zadania dla własnych agentów w kolejce zadań. Żądanie zadania dotyczy agenta przekazania artefaktu kompilacji pliku zip publikowania na konto usługi Azure Storage.

  2. Własny agent wdrażania pobiera nowe żądanie zadania za pośrednictwem sondowania. Pobiera zadanie i artefakt kompilacji.

  3. Własny agent wdrażania przekazuje plik zip do konta magazynu za pośrednictwem prywatnego punktu końcowego konta magazynu.

  4. Potok będzie kontynuowany, a zarządzany agent pobiera kolejne zadanie. Agent zarządzany wywołuje interfejs wiersza polecenia, aby zaktualizować aplikacjęUstawienia WEBSITE_RUN_FROM_PACKAGE na nazwę nowego pliku zip publikowania dla miejsca przejściowego.

    az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip
    
  5. usługa aplikacja systemu Azure pobiera nowy plik zip publikowania z magazynu za pośrednictwem prywatnego punktu końcowego konta magazynu. Wystąpienie przejściowe jest uruchamiane ponownie przy użyciu nowego pakietu, ponieważ WEBSITE_RUN_FROM_PACKAGE został ustawiony na inną nazwę pliku.

  6. Potok jest wznawiany i uruchamia testy weryfikacyjne kompilacji lub czeka na zatwierdzenie. Jeśli testy przejdą lub zatwierdzą, potok zamienia miejsca przejściowe i produkcyjne.

Wskazówki dotyczące wdrażania

Poniżej przedstawiono najważniejsze wskazówki dotyczące wdrażania architektury punktu odniesienia.

  • Użyj polecenia uruchom z pakietu , aby uniknąć konfliktów wdrażania. Po uruchomieniu aplikacji bezpośrednio z pakietu w usłudze aplikacja systemu Azure pliki w pakiecie nie są kopiowane do katalogu wwwroot. Zamiast tego sam pakiet ZIP jest instalowany bezpośrednio jako katalog wwwroot tylko do odczytu. Eliminuje to konflikty blokady plików między wdrożeniem a środowiskiem uruchomieniowym i zapewnia uruchamianie tylko w pełni wdrożonych aplikacji w dowolnym momencie
  • Dołącz numery wersji do wdrożonych plików zip pakietu. WEBSITE_RUN_FROM_PACKAGE Zaktualizowanie ustawienia aplikacji do pakietu wdrożeniowego przy użyciu innej nazwy pliku powoduje, że usługi App Services automatycznie pobierają nową wersję i ponownie uruchamiają usługę.
  • Użyj miejsc wdrożenia na potrzeby odpornych wdrożeń kodu.
  • Rozważ użycie kombinacji zarządzanych i własnych agentów.
  • Automatyzowanie wdrożeń infrastruktury przy użyciu infrastruktury jako kodu (IaC).
  • Stale weryfikuje obciążenie, aby przetestować wydajność i odporność całego rozwiązania przy użyciu usług, takich jak testowanie obciążenia platformy Azure i usługa Azure Chaos Studio.

Konfigurowanie

Aplikacje wymagają zarówno wartości konfiguracji, jak i wpisów tajnych. Skorzystaj z poniższych wskazówek dotyczących zarządzania konfiguracjami i wpisami tajnymi.

  • Nigdy nie sprawdzaj wpisów tajnych, takich jak hasła lub klucze dostępu do kontroli źródła.
  • Przechowywanie wpisów tajnych za pomocą usługi Azure Key Vault .
  • Użyj konfiguracji usługi App Service dla konfiguracji aplikacji. Jeśli musisz zewnętrznie skonfigurować konfigurację z konfiguracji aplikacji lub wymagać obsługi flag funkcji, rozważ użycie aplikacja systemu Azure Configuration.
  • Użyj odwołań usługi Key Vault w konfiguracji usługi App Service, aby bezpiecznie uwidocznić wpisy tajne w aplikacji.
  • Utwórz ustawienia aplikacji, które trzymają się miejsca i nie są zamieniane, jeśli potrzebujesz różnych ustawień produkcyjnych i przejściowych. Podczas zamiany miejsca wdrożenia ustawienia aplikacji są domyślnie zamieniane.
  • Ustaw lokalne zmienne środowiskowe na potrzeby programowania lokalnego lub korzystaj z funkcji platformy aplikacji. Konfiguracja usługi App Services uwidacznia ustawienia aplikacji jako zmienne środowiskowe. Program Visual Studio umożliwia na przykład ustawianie zmiennych środowiskowych w profilach uruchamiania. Umożliwia również używanie ustawień aplikacji i wpisów tajnych użytkownika do przechowywania lokalnych ustawień aplikacji i wpisów tajnych.

Monitorowanie

Monitorowanie to zbieranie i analiza danych z systemów IT. Celem monitorowania jest obserwowanie na wielu warstwach w celu śledzenia kondycji i zabezpieczeń aplikacji internetowej. Obserwowanie jest kluczowym aspektem architektury usługi App Service bazowej.

Aby monitorować aplikację internetową, musisz zbierać i analizować metryki i dzienniki z kodu aplikacji, infrastruktury (środowiska uruchomieniowego) i platformy (zasobów platformy Azure). Aby uzyskać więcej informacji, zobacz Dziennik aktywności platformy Azure, dzienniki zasobów platformy Azure i dzienniki aplikacji.

Monitorowanie platformy

Monitorowanie platformy to zbieranie danych z usług platformy Azure w architekturze. Zapoznaj się z poniższymi wskazówkami dotyczącymi monitorowania platformy.

Application Gateway

Usługa Application Gateway monitoruje kondycję zasobów w puli zaplecza. Użyj dzienników dostępu usługi Application Gateway, aby zebrać informacje, takie jak sygnatura czasowa, kod odpowiedzi HTTP i ścieżka adresu URL. Aby uzyskać więcej informacji, zobacz Domyślna sonda kondycji usługi Application Gateway oraz kondycja zaplecza i dzienniki diagnostyczne.

App Service

Usługa App Service ma wbudowane i zintegrowane narzędzia do monitorowania, które należy włączyć w celu zwiększenia możliwości obserwacji. Jeśli aplikacja internetowa ma już funkcje telemetrii i monitorowania ("instrumentacja w procesie"), powinna nadal działać w usłudze App Service.

  • Włącz instrumentację automatyczną. Usługa App Service ma rozszerzenie instrumentacji, które można włączyć bez zmian w kodzie. Uzyskasz widoczność monitorowania wydajności aplikacji (APM). Aby uzyskać więcej informacji, zobacz Monitorowanie wydajności usługi aplikacja systemu Azure.
  • Włącz śledzenie rozproszone. Automatyczna instrumentacja umożliwia monitorowanie rozproszonych systemów w chmurze za pośrednictwem śledzenia rozproszonego i profilera wydajności.
  • Użyj instrumentacji opartej na kodzie na potrzeby niestandardowej telemetrii. usługa aplikacja systemu Azure Insights obsługuje również instrumentację opartą na kodzie na potrzeby telemetrii aplikacji niestandardowych. Dodaj zestaw SDK usługi Application Insights do kodu i użyj interfejsu API usługi Application Insights.
  • Włącz dzienniki usługi App Service. Platforma App Service obsługuje cztery dodatkowe dzienniki, które należy włączyć w celu obsługi rozwiązywania problemów. Te dzienniki to dzienniki aplikacji, dzienniki serwera internetowego, szczegółowe komunikaty o błędach i śledzenie żądań niepomyślnych.
  • Użyj rejestrowania strukturalnego. Dodaj bibliotekę rejestrowania strukturalnego do kodu aplikacji. Zaktualizuj kod, aby używał par klucz-wartość i włącz dzienniki aplikacji w usłudze App Service, aby przechowywać te dzienniki w obszarze roboczym usługi Log Analytics.
  • Włącz sprawdzanie kondycji usługi App Service. Sprawdzanie kondycji przekierowuje żądania z dala od wystąpień w złej kondycji i zastępuje wystąpienia w złej kondycji. Plan usługi App Service musi używać co najmniej dwóch wystąpień, aby testy kondycji działały.
baza danych

Ład korporacyjny

Aplikacje internetowe korzystają z usługi Azure Policy, wymuszając decyzje dotyczące architektury i zabezpieczeń. Usługa Azure Policy może uniemożliwić (1) wdrożenie (odmowę) lub (2) łatwe wykrywanie (inspekcja) dryfu konfiguracji z preferowanego żądanego stanu. Ułatwia to przechwytywanie wdrożeń infrastruktury jako kodu (IaC) lub zmian w witrynie Azure Portal, które odbiegają od uzgodnionej architektury. Wszystkie zasoby należy umieścić w architekturze w obszarze ład usługi Azure Policy. Użyj wbudowanych zasad lub inicjatyw zasad, jeśli to możliwe, aby wymusić podstawową topologię sieci, funkcje usług, zabezpieczenia i decyzje dotyczące monitorowania, na przykład:

  • Usługa App Service powinna wyłączyć dostęp do sieci publicznej
  • Usługa App Service powinna używać integracji z siecią wirtualną
  • Usługa App Service powinna używać usługi Azure Private Link do nawiązywania połączenia z usługami PaaS
  • Usługa App Service powinna mieć wyłączone lokalne metody uwierzytelniania dla wdrożeń witryn FTP i SCM
  • Usługa App Service powinna mieć wyłączone zdalne debugowanie
  • Aplikacje usługi App Service powinny używać najnowszej wersji protokołu TLS
  • Usługa Microsoft Defender dla usługi App Service powinna być włączona
  • Zapora aplikacji internetowej (WAF) powinna być włączona dla usługi Application Gateway

Zobacz więcej wbudowanych zasad dla kluczowych usług, takich jak Application Gateway i składniki sieciowe, App Service, Key Vault i Monitorowanie. Istnieje możliwość utworzenia niestandardowych zasad lub użycia zasad społeczności (takich jak ze stref docelowych platformy Azure), jeśli wbudowane zasady nie spełniają w pełni Twoich potrzeb. Preferuj wbudowane zasady, gdy są dostępne.

Następne kroki