Wdrażanie w przedsiębiorstwie przy użyciu środowiska usługi aplikacja systemu Azure

Ta architektura referencyjna przedstawia typowe obciążenie przedsiębiorstwa korzystające ze środowiska App Service Environment w wersji 3. Opisano w nim również najlepsze rozwiązania dotyczące wzmacniania zabezpieczeń obciążenia.

Implementacja referencyjna dla tej architektury jest dostępna w usłudze GitHub.

Architektura

Pobierz plik programu Visio z tą architekturą.

Przepływ pracy

Środowisko App Service Environment można wdrożyć na dwa sposoby:

• Jako zewnętrzne środowisko App Service Environment z publicznym adresem IP
• Jako wewnętrzne środowisko App Service Environment z wewnętrznym adresem IP należącym do wewnętrznego modułu równoważenia obciążenia (ILB)

Ta architektura referencyjna wdraża aplikację internetową przedsiębiorstwa w wewnętrznym środowisku App Service Environment nazywanym również środowiskiem App Service Environment wewnętrznego modułu równoważenia obciążenia. Użyj środowiska App Service Environment z wewnętrznym modułem równoważenia obciążenia, jeśli scenariusz wymaga:

• Hostowanie aplikacji intranetowych z rozszerzonymi zabezpieczeniami w chmurze i uzyskiwanie do nich dostępu za pośrednictwem sieci VPN typu lokacja-lokacja lub usługi Azure ExpressRoute.
• Zapewnienie warstwy ochrony aplikacji przy użyciu zapory aplikacji internetowej (WAF).
• Hostowanie w chmurze aplikacji, które nie są wymienione na publicznych serwerach DNS.
• Twórz aplikacje zaplecza odizolowane od Internetu, z którymi aplikacje frontonu mogą integrować się w sposób wysoce bezpieczny.

Środowisko App Service Environment musi być zawsze wdrażane we własnej podsieci w sieci wirtualnej przedsiębiorstwa, aby umożliwić ścisłą kontrolę nad ruchem przychodzącym i wychodzącym. W tej podsieci aplikacje usługi App Service są wdrażane w co najmniej jednym planie usługi App Service, który jest kolekcją zasobów fizycznych wymaganych do uruchomienia aplikacji. W zależności od złożoności i wymagań dotyczących zasobów plan usługi App Service może być współużytkowany między wieloma aplikacjami. Ta implementacja referencyjna wdraża aplikację internetową o nazwie Voting App, która współdziała z prywatnym internetowym interfejsem API i funkcją. Wdraża ona również fikcyjną aplikację internetową o nazwie Test App w celu zademonstrowania wdrożeń wielu aplikacji. Każda aplikacja usługi App Service jest hostowana we własnym planie usługi App Service, co pozwala na niezależne skalowanie każdej aplikacji w razie potrzeby. Wszystkie zasoby wymagane przez te hostowane aplikacje, takie jak magazyn i zasoby obliczeniowe, a także potrzeby skalowania, są w pełni zarządzane przez infrastrukturę środowiska App Service Environment.

Prosta aplikacja do głosowania w tej implementacji umożliwia użytkownikom wyświetlanie istniejących wpisów, tworzenie nowych wpisów i głosowanie nad istniejącymi wpisami. Internetowy interfejs API służy do tworzenia i pobierania wpisów i głosów. Same dane są przechowywane w bazie danych programu SQL Server. Aby zademonstrować aktualizacje danych asynchronicznych, aplikacja internetowa kolejkuje nowo dodane głosy w wystąpieniu usługi Service Bus. Funkcja pobiera głosy w kolejce i aktualizuje bazę danych SQL. Usługa Azure Cosmos DB służy do przechowywania makiety reklamy, którą aplikacja internetowa pobiera w celu wyświetlenia w przeglądarce. Aplikacja używa usługi Azure Cache for Redis do zarządzania pamięcią podręczną. Używana jest warstwa Premium Azure Cache for Redis, która umożliwia skonfigurowanie tej samej sieci wirtualnej co środowisko App Service Environment we własnej podsieci. Zapewnia to zwiększone zabezpieczenia i izolację pamięci podręcznej.

Aplikacje internetowe są jedynymi składnikami dostępnymi dla Internetu za pośrednictwem usługi Application Gateway. Interfejs API i funkcja są niedostępne z poziomu klienta internetowego. Ruch przychodzący jest chroniony przez zaporę aplikacji internetowej skonfigurowaną w usłudze Application Gateway.

Składniki

Następujące usługi są kluczem do zablokowania środowiska App Service Environment w tej architekturze:

• Azure Virtual Network to prywatna sieć w chmurze platformy Azure, która jest własnością przedsiębiorstwa. Zapewnia ulepszone zabezpieczenia i izolację opartą na sieci. App Service Environment to wdrożenie usługi App Service w podsieci sieci wirtualnej należącej do przedsiębiorstwa. Dzięki niej przedsiębiorstwo może ściśle kontrolować przestrzeń sieciową i zasoby, do których uzyskuje dostęp przy użyciu sieciowych grup zabezpieczeń i prywatnych punktów końcowych.

• Application Gateway to moduł równoważenia obciążenia ruchu internetowego na poziomie aplikacji z odciążaniem protokołu TLS/SSL i zaporą aplikacji internetowej. Nasłuchuje on publicznego adresu IP i kieruje ruch do punktu końcowego aplikacji w środowisku App Service Environment modułu równoważenia obciążenia. Ponieważ jest to routing na poziomie aplikacji, może kierować ruch do wielu aplikacji w ramach tego samego środowiska app service modułu równoważenia obciążenia. Aby uzyskać więcej informacji, zobacz Hostowanie wielu witryn w usłudze Application Gateway.

• Usługa Azure Firewall służy do ograniczania ruchu wychodzącego z aplikacji internetowej. Ruch wychodzący, który nie przechodzi przez kanały prywatnego punktu końcowego, a tabela tras wymagana przez środowisko App Service Environment jest kierowana do podsieci zapory. Dla uproszczenia ta architektura konfiguruje wszystkie prywatne punkty końcowe w podsieci usług.

• Microsoft Entra ID lub Microsoft Entra ID zapewnia prawa dostępu i uprawnienia do zarządzania zasobami i usługami platformy Azure. Tożsamości zarządzane przypisuje tożsamości do usług i aplikacji, automatycznie zarządzanych przez identyfikator Entra firmy Microsoft. Te tożsamości mogą służyć do uwierzytelniania w dowolnej usłudze obsługującej uwierzytelnianie firmy Microsoft Entra. Spowoduje to usunięcie konieczności jawnego skonfigurowania poświadczeń dla tych aplikacji. Ta architektura przypisuje tożsamość zarządzaną do aplikacji internetowej.

• Usługa Azure Key Vault przechowuje wszelkie wpisy tajne i poświadczenia wymagane przez aplikacje. Ta opcja umożliwia przechowywanie wpisów tajnych bezpośrednio w aplikacji.

• Funkcja GitHub Actions zapewnia funkcje ciągłej integracji i ciągłego wdrażania w tej architekturze. Ponieważ środowisko App Service Environment znajduje się w sieci wirtualnej, maszyna wirtualna jest używana jako serwer przesiadkowy wewnątrz sieci wirtualnej do wdrażania aplikacji w planach usługi App Service. Akcja kompiluje aplikacje poza siecią wirtualną. W celu zapewnienia zwiększonych zabezpieczeń i bezproblemowej łączności RDP/SSH rozważ użycie usługi Azure Bastion dla serwera przesiadkowego.

Konfiguracja wielu lokacji

Pobierz plik programu Visio z tą architekturą.

Wewnętrzne środowisko App Service Environment może hostować kilka aplikacji internetowych i interfejsów API z punktami końcowymi HTTP. Te aplikacje są blokowane z publicznego Internetu, ponieważ adres IP wewnętrznym modułu równoważenia obciążenia jest dostępny tylko z poziomu sieci wirtualnej. Usługa Application Gateway służy do selektywnego uwidaczniania tych aplikacji w Internecie. Środowisko App Service Environment przypisuje domyślny adres URL do każdej aplikacji usługi App Service jako <default-appName>.<app-service-environment-domain>.appserviceenvironment.net. Zostanie utworzona prywatna strefa DNS, która mapuje nazwę domeny środowiska App Service Environment na adres IP wewnętrznego modułu równoważenia obciążenia środowiska App Service Environment. Pozwala to uniknąć używania niestandardowego systemu DNS do uzyskiwania dostępu do aplikacji w sieci wirtualnej.

Usługa Application Gateway jest skonfigurowana tak, że odbiornik nasłuchuje na porcie HTTPS dla żądań do adresu IP bramy. Dla uproszczenia ta implementacja nie używa rejestracji publicznej nazwy DNS. Wymaga to zmodyfikowania pliku localhost na komputerze w celu wskazania arbitralnie wybranego adresu URL do adresu IP usługi Application Gateway. Dla uproszczenia odbiornik używa certyfikatu z podpisem własnym do przetwarzania tych żądań. Usługa Application Gateway ma pule zaplecza dla domyślnego adresu URL każdej aplikacji usługi App Service. Reguła routingu jest skonfigurowana do łączenia odbiornika z pulą zaplecza. Tworzone są ustawienia PROTOKOŁU HTTP, które określają, czy połączenie między bramą a środowiskiem App Service Environment zostanie zaszyfrowane. Te ustawienia są również używane do zastępowania przychodzącego nagłówka hosta HTTP z nazwą hosta wybraną z puli zaplecza. Ta implementacja używa domyślnych certyfikatów utworzonych dla domyślnych adresów URL aplikacji środowiska App Service Environment, które są zaufane przez bramę. Żądanie jest przekierowywane do domyślnego adresu URL odpowiedniej aplikacji. Prywatny serwer DNS połączony z siecią wirtualną przekazuje to żądanie do adresu IP wewnętrznego modułu równoważenia obciążenia. Następnie środowisko App Service Environment przekazuje je do żądanej usługi app Service. Każda komunikacja HTTP w aplikacjach środowiska App Service Environment przechodzi przez prywatny system DNS. Należy pamiętać, że odbiornik, pula zaplecza, reguła routingu i ustawienia HTTP muszą być skonfigurowane w bramie aplikacji dla każdej aplikacji środowiska App Service Environment.

Przejrzyj sekcję appgw.bicep i dns.bicep , aby dowiedzieć się, jak te konfiguracje są tworzone w celu zezwolenia na wiele witryn. Aplikacja internetowa o nazwie testapp to pusta aplikacja utworzona w celu zademonstrowania tej konfiguracji. Te pliki JSON są dostępne ze skryptu wdrażania commands_std.azcli. Są one również dostępne przez commands_ha.azcli, który jest używany do wdrożenia środowiska App Service Environment o wysokiej dostępności.

Szczegóły scenariusza

aplikacja systemu Azure Service to usługa PaaS używana do hostowania różnych aplikacji na platformie Azure: aplikacji internetowych, aplikacji interfejsu API, funkcji i aplikacji mobilnych. Środowisko App Service Environment umożliwia przedsiębiorstwom wdrażanie aplikacji usługi App Service w podsieci we własnej sieci wirtualnej platformy Azure, zapewniając izolowane, wysoce skalowalne i dedykowane środowisko dla obciążeń w chmurze.

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.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Omówienie filaru zabezpieczeń.

Środowisko usługi App Service

Wewnętrzne środowisko App Service Environment jest wdrażane w sieci wirtualnej przedsiębiorstwa ukrytej przed publicznym Internetem. Dzięki temu przedsiębiorstwo może zablokować swoje usługi zaplecza, takie jak internetowe interfejsy API i funkcje, na poziomie sieci. Dostęp do dowolnej aplikacji środowiska App Service Environment z punktem końcowym HTTP można uzyskać za pośrednictwem modułu równoważenia obciążenia z poziomu sieci wirtualnej. Usługa Application Gateway jest skonfigurowana do przekazywania żądań do aplikacji internetowej za pośrednictwem wewnętrznym modułu równoważenia obciążenia. Sama aplikacja internetowa przechodzi przez moduł równoważenia obciążenia w celu uzyskania dostępu do interfejsu API. Krytyczne składniki zaplecza, czyli interfejs API i funkcja, są skutecznie niedostępne z publicznego Internetu.

Domyślne certyfikaty są tworzone dla każdej usługi app service dla domyślnej nazwy domeny przypisanej przez środowisko App Service Environment. Ten certyfikat może zaostrzyć bezpieczeństwo ruchu między bramą a aplikacją i może być wymagany w niektórych scenariuszach. Te certyfikaty nie są widoczne za pośrednictwem przeglądarki klienta. Może ona odpowiadać tylko na certyfikaty skonfigurowane w usłudze Application Gateway.

Application Gateway

Zgodnie z opisem w temacie Overview of TLS termination and end to end TLS with Application Gateway,Application Gateway can use Transport Layer Security (TLS)/Secure Sockets Layer (SSL) to encrypt and protect all traffic from web browsers (Szyfrowanie i ochrona całego ruchu przed przeglądarkami internetowymi). Szyfrowanie można skonfigurować na następujące sposoby:

• Szyfrowanie zostało zakończone w bramie. Pule zaplecza w tym przypadku są skonfigurowane dla protokołu HTTP. Szyfrowanie zatrzymuje się na bramie, a ruch między bramą a usługą App Service jest niezaszyfrowany. Ponieważ szyfrowanie intensywnie korzysta z procesora CPU, niezaszyfrowany ruch w zapleczu zwiększa wydajność i umożliwia prostsze zarządzanie certyfikatami. Zapewnia to rozsądny poziom zabezpieczeń, ponieważ zaplecze jest zabezpieczone z powodu konfiguracji sieci.

• Kompleksowe szyfrowanie. W niektórych scenariuszach, takich jak określone wymagania dotyczące zabezpieczeń lub zgodności, ruch może być wymagany do szyfrowania między bramą a aplikacją. Jest to osiągane przy użyciu połączenia HTTPS i konfigurowania certyfikatów w puli zaplecza.

Ta implementacja referencyjna używa certyfikatów z podpisem własnym dla usługi Application Gateway. W przypadku kodu produkcyjnego należy użyć certyfikatu wystawionego przez urząd certyfikacji. Aby uzyskać listę obsługiwanych typów certyfikatów, zobacz Certyfikaty obsługiwane w przypadku kończenia żądań protokołu TLS. Przeczytaj artykuł Konfigurowanie bramy aplikacji z kończeniem szyfrowania TLS przy użyciu witryny Azure Portal , aby dowiedzieć się, jak utworzyć szyfrowanie zakończone przez bramę. Następujące wiersze kodu w pliku appgw.bicep konfigurują to programowo:

httpListeners: [for item in appgwApplications: {
name: '${appgwListenerName}${item.name}'
properties: {
  frontendIPConfiguration: {
    id: '${appgwId}/frontendIPConfigurations/${appgwFrontendName}'
  }
  frontendPort: {
    id: '${appgwId}/frontendPorts/port_443'
  }
  protocol: 'Https'
  sslCertificate: {
    id: '${appgwId}/sslCertificates/${appgwSslCertificateName}${item.name}'
  }
  hostName: item.hostName
  requireServerNameIndication: true
}
}]

Implementacja referencyjna demonstruje kompleksowe szyfrowanie ruchu między usługą Application Gateway i aplikacjami internetowymi w środowisku App Service Environment. Są używane domyślne certyfikaty SSL. Pule zaplecza w tej implementacji są skonfigurowane do przekierowywania ruchu HTTPS z nazwą hosta zastąpioną przez domyślne nazwy domen skojarzone z aplikacjami internetowymi. Usługa Application Gateway ufa domyślnym certyfikatom SSL, ponieważ są wystawiane przez firmę Microsoft. Aby uzyskać informacje o sposobie tworzenia tych konfiguracji, zobacz Konfigurowanie usługi App Service z usługą Application Gateway . Poniższy kod z pliku appgw.bicep pokazuje, jak jest to skonfigurowane w implementacji referencyjnej:

backendHttpSettingsCollection: [for item in appgwApplications: {
name: '${appgwHttpSettingsName}${item.name}'
properties: {
  port: 443
  protocol: 'Https'
  cookieBasedAffinity: 'Disabled'
  pickHostNameFromBackendAddress: true
  requestTimeout: 20
  probe: {
    id: '${appgwId}/probes/${appgwHealthProbeName}${item.name}'
  }
}
}]

Web Application Firewall

Zapora aplikacji internetowej (WAF) w usłudze Application Gateway chroni aplikacje internetowe przed złośliwymi atakami, takimi jak wstrzyknięcie kodu SQL. Jest ona również zintegrowana z usługą Azure Monitor w celu monitorowania ataków przy użyciu dziennika czasu rzeczywistego. Zapora aplikacji internetowej musi być włączona w bramie, zgodnie z opisem w temacie Tworzenie bramy aplikacji z zaporą aplikacji internetowej przy użyciu witryny Azure Portal. Implementacja referencyjna umożliwia programowe korzystanie z zapory aplikacji internetowej w pliku appgw.bicep z następującym fragmentem kodu:

webApplicationFirewallConfiguration: {
  enabled: true
  firewallMode: 'Detection'
  ruleSetType: 'OWASP'
  ruleSetVersion: '3.2'
}

Virtual Network

Sieciowe grupy zabezpieczeń mogą być skojarzone z co najmniej jedną podsiecią w sieci wirtualnej. Są to reguły zabezpieczeń, które zezwalają na przepływ ruchu między różnymi zasobami platformy Azure lub zezwalają na ruch. Ta architektura kojarzy oddzielną sieciową grupę zabezpieczeń dla każdej podsieci. Umożliwia to precyzyjne dostrajanie tych reguł na podsieć, zgodnie z usługami zawartymi w tej podsieci. Na przykład zobacz konfigurację pliku "type": "Microsoft.Network/networkSecurityGroups" ase.bicep dla sieciowej grupy zabezpieczeń podsieci App Service Environment i w pliku appgw.bicep dla sieciowej grupy zabezpieczeń podsieci usługi Application Gateway.

Prywatne punkty końcowe umożliwiają rozszerzoną łączność prywatną zabezpieczeń między klientami i usługami platformy Azure za pośrednictwem sieci prywatnej. Zapewniają one prywatnie dostępny adres IP dla usługi Platformy Azure, umożliwiając zwiększony ruch zabezpieczeń do zasobu usługi Azure Private Link. Platforma weryfikuje połączenia sieciowe, zezwalając tylko tym, którzy łączą się z określonym zasobem usługi Private Link. Prywatne punkty końcowe obsługują zasady sieciowe, takie jak sieciowe grupy zabezpieczeń, trasy zdefiniowane przez użytkownika i grupy zabezpieczeń aplikacji. Aby zwiększyć bezpieczeństwo, należy włączyć prywatne punkty końcowe dla dowolnej usługi platformy Azure, która je obsługuje. Następnie można zwiększyć bezpieczeństwo usługi w sieci wirtualnej, wyłączając dostęp publiczny, co skutecznie blokuje dostęp z publicznego Internetu. Ta architektura umożliwia skonfigurowanie prywatnych punktów końcowych dla usług, które go obsługują: Azure Service Bus, SQL Server, Key Vault i Azure Cosmos DB. Konfigurację można zobaczyć w pliku privatendpoints.bicep.

Aby włączyć prywatne punkty końcowe, należy również skonfigurować prywatne strefy DNS. Aby uzyskać więcej informacji, zobacz Konfiguracja usługi DNS prywatnego punktu końcowego platformy Azure.

Firewall

Usługa Azure Firewall i prywatne punkty końcowe uzupełniają się wzajemnie. Prywatne punkty końcowe pomagają chronić zasoby, zezwalając tylko na ruch pochodzący z sieci wirtualnej. Usługa Azure Firewall umożliwia ograniczenie ruchu wychodzącego z aplikacji. Zalecamy zezwolenie na przekazywanie całego ruchu wychodzącego przez podsieć zapory, w tym ruch prywatnego punktu końcowego. Umożliwia to lepsze monitorowanie ruchu wychodzącego. Dla uproszczenia ta architektura referencyjna konfiguruje wszystkie prywatne punkty końcowe w podsieci usług zamiast w podsieci zapory.

Aby dowiedzieć się, jak usługa Azure Firewall integruje się ze środowiskiem App Service Environment, zobacz Konfigurowanie usługi Azure Firewall przy użyciu środowiska App Service Environment. Każdy ruch, który nie przechodzi przez prywatne punkty końcowe, a tabela tras sieci wirtualnej jest monitorowana i bramowana przez zaporę.

Microsoft Entra ID

Microsoft Entra ID udostępnia funkcje zabezpieczeń do uwierzytelniania aplikacji i autoryzacji dostępu do zasobów. Ta architektura referencyjna korzysta z dwóch kluczowych funkcji identyfikatora entra firmy Microsoft: tożsamości zarządzanych i kontroli dostępu opartej na rolach na platformie Azure.

W aplikacjach w chmurze należy zabezpieczyć poświadczenia wymagane do uwierzytelniania w usługach w chmurze. Najlepiej, aby poświadczenia nigdy nie pojawiały się na stacjach roboczych deweloperów ani nie zaewidencjonowywały kontroli źródła. Usługa Azure Key Vault umożliwia bezpieczne przechowywanie poświadczeń i wpisów tajnych, ale aplikacja nadal musi uwierzytelniać się w usłudze Key Vault, aby je pobrać. Tożsamości zarządzane dla zasobów platformy Azure udostępniają usługom platformy Azure automatycznie zarządzaną tożsamość w identyfikatorze Entra firmy Microsoft. Ta tożsamość może służyć do uwierzytelniania w dowolnej usłudze, która obsługuje uwierzytelnianie firmy Microsoft Entra, w tym usługę Key Vault, bez żadnych poświadczeń w aplikacji.

Kontrola dostępu oparta na rolach (RBAC) platformy Azure zarządza dostępem do zasobów platformy Azure. Obejmuje to:

• Która jednostka ma dostęp: użytkownik, tożsamość zarządzana, podmiot zabezpieczeń.
• Jakiego typu dostęp ma: właściciel, współautor, czytelnik, administrator.
• Zakres dostępu: zasób, grupa zasobów, subskrypcja lub grupa zarządzania.

Dostęp do aplikacji App Service Environment można zablokować, ściśle kontrolując wymaganą rolę i typ dostępu dla każdej aplikacji. W ten sposób można wdrożyć wiele aplikacji w tym samym środowisku App Service Environment z różnych zespołów programistycznych. Na przykład fronton może być obsługiwany przez jeden zespół, a zaplecze przez inny. Kontrola dostępu oparta na rolach platformy Azure może służyć do ograniczania dostępu poszczególnych zespołów do aplikacji, nad którymi pracuje. Zapoznaj się z rolami niestandardowymi platformy Azure, aby tworzyć role odpowiednie dla twojej organizacji.

Key Vault

Niektóre usługi obsługują tożsamości zarządzane i używają kontroli dostępu opartej na rolach platformy Azure w celu skonfigurowania uprawnień dla aplikacji. Zobacz na przykład wbudowane role usługi Service Bus i kontrolę dostępu opartą na rolach platformy Azure w usłudze Azure Cosmos DB. Dostęp administratora dostępu użytkowników do subskrypcji jest wymagany do udzielania tych uprawnień, mimo że personel z dostępem współautora może wdrożyć te usługi. Aby umożliwić szerszemu zespołowi deweloperów uruchamianie skryptów wdrażania, alternatywą jest użycie natywnej kontroli dostępu udostępnianej przez usługi:

• W przypadku usługi Service Bus jest to sygnatury dostępu współdzielonego.
• W przypadku usługi Azure Cosmos DB jest to klucze.

Jeśli obciążenie wymaga dostępu opartego na usłudze, te wstępnie udostępnione wpisy tajne powinny być przechowywane w usłudze Key Vault. Dostęp do samego magazynu należy uzyskać za pośrednictwem tożsamości zarządzanej aplikacji internetowej.

Dostęp do wpisów tajnych przechowywanych w usłudze Key Vault są uzyskiwane przez aplikacje odwołujące się do pary klucz/wartość usługi Key Vault. Odbywa się to w pliku sites.bicep , jak pokazano w poniższym kodzie aplikacji do głosowania:

properties: {
  enabled: true
  hostingEnvironmentProfile: {
    id: aseId
  }
  serverFarmId: votingWebPlanName.id
  siteConfig: {
    appSettings: [
      {
        name: 'ASecret'
        value: '@Microsoft.KeyVault(SecretUri=${applicationKeyVault::secretName.secretUriWithVersion})'
      }
    ]
  }
}

Skalowalność

Projektowanie skalowalnych aplikacji

Aplikacja w tej architekturze referencyjnej ma strukturę, dzięki czemu poszczególne składniki można skalować na podstawie użycia. Każda aplikacja internetowa, interfejs API i funkcja są wdrażane we własnym planie usługi App Service. Możesz monitorować każdą aplikację pod kątem wszelkich wąskich gardeł wydajności, a następnie skalować ją w górę , jeśli jest to wymagane.

Autoskalowanie usługi Application Gateway

Skalowanie automatyczne można włączyć w bramie aplikacja systemu Azure w wersji 2. Dzięki temu usługa Application Gateway może skalować w górę lub w dół na podstawie wzorców obciążenia ruchu. Ta architektura referencyjna konfiguruje autoscaleConfiguration w pliku appgw.bicep w celu skalowania między zero i 10 dodatkowych wystąpień. Aby uzyskać więcej informacji, zobacz Scaling Application Gateway and WAF v2 (Skalowanie usługi Application Gateway i zapory aplikacji internetowej w wersji 2 ).

Wdrożenie

Skrypty wdrażania w tej architekturze referencyjnej są używane do wdrażania środowiska App Service Environment, innych usług i aplikacji w środowisku App Service Environment. Po wdrożeniu tych aplikacji przedsiębiorstwa mogą chcieć mieć plan ciągłej integracji i wdrażania na potrzeby konserwacji i uaktualnień aplikacji. W tej sekcji przedstawiono niektóre typowe sposoby, w jaki deweloperzy korzystają z ciągłej integracji/ciągłego wdrażania aplikacji środowiska App Service Environment.

Aplikacje można wdrażać w wewnętrznym środowisku App Service Environment tylko z poziomu sieci wirtualnej. Następujące trzy metody są powszechnie używane do wdrażania aplikacji środowiska App Service Environment:

• Ręcznie wewnątrz sieci wirtualnej: utwórz maszynę wirtualną w sieci wirtualnej środowiska App Service Environment przy użyciu wymaganych narzędzi do wdrożenia. Otwórz połączenie RDP z maszyną wirtualną przy użyciu konfiguracji sieciowej grupy zabezpieczeń. Skopiuj artefakty kodu do maszyny wirtualnej, skompiluj i wdróż je w podsieci środowiska App Service Environment. Jest to prosty sposób konfigurowania początkowego środowiska deweloperskiego kompilacji i testowania. Nie jest to jednak zalecane w środowisku produkcyjnym, ponieważ nie może skalować wymaganej przepływności wdrożenia.

• Połączenie typu punkt-lokacja z lokalnej stacji roboczej: umożliwia rozszerzenie sieci wirtualnej środowiska App Service Environment na maszynę deweloperów i wdrożenie z tego miejsca. Jest to inny sposób konfigurowania początkowego środowiska deweloperskiego i niezalecane w środowisku produkcyjnym.

• Za pośrednictwem usługi Azure Pipelines: spowoduje to zaimplementowanie kompletnego potoku ciągłej integracji/ciągłego wdrażania kończącego się agentem znajdującym się w sieci wirtualnej. Jest to idealne rozwiązanie dla środowisk produkcyjnych wymagających wysokiej przepływności wdrożenia. Potok kompilacji pozostaje całkowicie poza siecią wirtualną. Potok wdrażania kopiuje wbudowane obiekty do agenta kompilacji w sieci wirtualnej, a następnie wdraża w podsieci Środowiska App Service Environment. Aby uzyskać więcej informacji, przeczytaj tę dyskusję na temat własnego agenta kompilacji między potokami i siecią wirtualną środowiska App Service Environment.

Korzystanie z usługi Azure Pipelines jest zalecane w środowiskach produkcyjnych. Tworzenie skryptów ciągłej integracji/ciągłego wdrażania za pomocą schematu YAML usługi Azure Pipelines pomaga zautomatyzować procesy kompilacji i wdrażania. Azure-pipelines.yml implementuje taki potok ciągłej integracji/ciągłego wdrażania dla aplikacji internetowej w tej implementacji referencyjnej. Istnieją podobne skrypty ciągłej integracji/ciągłego wdrażania dla internetowego interfejsu API, a także funkcji. Przeczytaj artykuł Korzystanie z usługi Azure Pipelines , aby dowiedzieć się, jak są one używane do automatyzowania ciągłej integracji/ciągłego wdrażania dla każdej aplikacji.

Niektóre przedsiębiorstwa mogą nie chcieć zachować stałego agenta kompilacji w sieci wirtualnej. W takim przypadku można utworzyć agenta kompilacji w potoku DevOps i usunąć go po zakończeniu wdrażania. Spowoduje to dodanie kolejnego kroku w metodyce DevOps, jednak zmniejsza złożoność obsługi maszyny wirtualnej. Możesz nawet rozważyć użycie kontenerów jako agentów kompilacji, a nie maszyn wirtualnych. Agenci kompilacji mogą również całkowicie uniknąć, wdrażając plik zip umieszczony poza siecią wirtualną, zazwyczaj na koncie magazynu. Konto magazynu musi być dostępne z poziomu środowiska App Service Environment. Potok powinien mieć dostęp do magazynu. Na końcu potoku wydania można porzucić spakowany plik do magazynu obiektów blob. Środowisko App Service Environment może następnie pobrać je i wdrożyć. Należy pamiętać o następujących ograniczeniach tego podejścia:

• Istnieje rozłączenie między metodyką DevOps a rzeczywistym procesem wdrażania, co prowadzi do problemów z monitorowaniem i śledzeniem problemów z wdrażaniem.
• W zablokowanym środowisku z zabezpieczonym ruchem może być konieczne zmianę reguł dostępu do spakowanego pliku w magazynie.
• Aby można było wdrożyć z pliku zip, należy zainstalować określone rozszerzenia i narzędzia w środowisku App Service Environment.

Aby dowiedzieć się więcej sposobów wdrażania aplikacji w planach usługi App Service, przeczytaj artykuły usługi App Service koncentrujące się na strategiach wdrażania.

Optymalizacja kosztów

Koszty możesz szacować za pomocą kalkulatora cen platformy Azure. Inne zagadnienia zostały opisane w sekcji Koszt w witrynie Microsoft Azure Well-Architected Framework. Rezerwacje platformy Azure pomagają zaoszczędzić pieniądze dzięki rocznym lub 3-letnim planom dla wielu zasobów platformy Azure. Przeczytaj więcej w artykule Kupowanie rezerwacji.

Poniżej przedstawiono kilka kwestii, które należy wziąć pod uwagę w przypadku niektórych kluczowych usług używanych w tej architekturze.

Środowisko App Service Environment v3

Dla usługi App Service są dostępne różne opcje cenowe. Środowisko App Service Environment jest wdrażane przy użyciu izolowanego planu usługi w wersji 2. W ramach tego planu istnieje wiele opcji dla rozmiarów procesora CPU — od I1v2 do I6v2. Ta implementacja referencyjna używa trzech klas I1v2 na wystąpienie.

Application Gateway

Cennik usługi Application Gateway oferuje różne opcje cenowe. Ta implementacja używa jednostki SKU Usługi Application Gateway w wersji 2 i zapory aplikacji internetowej w wersji 2, która obsługuje skalowanie automatyczne i nadmiarowość stref. Aby uzyskać więcej informacji na temat modelu cenowego używanego dla tej jednostki SKU, zobacz Scaling Application Gateway v2 and WAF v2 (Skalowanie usługi Application Gateway w wersji 2 i zapory aplikacji internetowej w wersji 2 ).

Azure Cache for Redis

Cennik usługi Azure Cache for Redis zawiera różne opcje cenowe dla tej usługi. Ta architektura używa jednostki SKU Premium do obsługi sieci wirtualnej.

Poniżej znajdują się strony cennika innych usług, które są używane do blokowania środowiska App Service Environment:

• Cennik usługi Azure Firewall

• Cennik usługi Key Vault

• Cennik firmy Microsoft Entra

Wdrażanie tego scenariusza

Aby wdrożyć implementację referencyjną dla tej architektury, zobacz plik readme usługi GitHub i postępuj zgodnie ze skryptem w celu wdrożenia standardowego.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

• Dhanashri Kshirsagar | Starszy pm zawartości

Inni współautorzy:

• Deep Bhattacharya | Architekt rozwiązań w chmurze
• Suhas Rao | Architekt rozwiązań w chmurze

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

• Uruchamianie aplikacji w usłudze aplikacja systemu Azure bezpośrednio z pakietu ZIP
• Schemat YAML usługi Azure Pipelines
• Pobieranie adresów zarządzania z interfejsu API
• Azure Key Vault
• Azure Pipelines

Powiązane zasoby

Aby dowiedzieć się, jak rozszerzyć tę architekturę w celu zapewnienia wysokiej dostępności, przeczytaj artykuł Wdrażanie aplikacji o wysokiej dostępności przy użyciu środowiska App Services Environment.