podstawowa aplikacja internetowa

Azure App Service

Azure Monitor

Azure SQL Database

Ten artykuł zawiera podstawową architekturę, która ułatwia zapoznanie się z uruchamianiem aplikacji internetowych na Azure App Service w jednym regionie.

Ważne

Ta architektura nie jest przeznaczona dla aplikacji produkcyjnych. Służy jako konfiguracja wprowadzająca do celów uczenia się i weryfikacji koncepcji (POC). Aby zaprojektować produkcyjną aplikację usługi App Service, zobacz Punkt odniesienia aplikacji internetowej o wysokiej dostępności strefowo nadmiarowej.

Architektura

Pobierz plik programu Visio z tą architekturą.

Workflow

Poniższy przepływ pracy odpowiada powyższemu diagramowi.

Użytkownik wysyła żądanie HTTPS do domeny domyślnej usługi App Service w witrynie azurewebsites.net. Ta domena automatycznie wskazuje wbudowany publiczny adres IP aplikacji usługi App Service. Połączenie zabezpieczeń warstwy transportu (TLS) jest ustanawiane bezpośrednio z klienta do usługi App Service. Azure w pełni zarządza certyfikatem.
Usługa Easy Auth, która jest funkcją usługi App Service, zapewnia, że użytkownik, który uzyskuje dostęp do witryny, jest uwierzytelniany przy użyciu Microsoft Entra ID.
Kod aplikacji wdrożony w usłudze App Service obsługuje żądanie. Na przykład ten kod może łączyć się z wystąpieniem Azure SQL Database przy użyciu łańcucha połączenia skonfigurowanego w usłudze App Service jako ustawienie aplikacji.
Informacje o oryginalnym żądaniu do usługi App Service i wywołaniu usługi SQL Database są rejestrowane w usłudze Application Insights.

Składniki

Microsoft Entra ID to oparta na chmurze usługa zarządzania tożsamościami i dostępem, która zapewnia możliwości uwierzytelniania i autoryzacji. W tej architekturze integruje się z usługą App Service za pomocą usługi Easy Auth, aby zapewnić uwierzytelnianie dla użytkowników, którzy uzyskują dostęp do aplikacji internetowej. Upraszcza również proces uwierzytelniania bez konieczności wprowadzania znaczących zmian w kodzie.
App Service to zarządzana platforma do tworzenia, wdrażania i skalowania aplikacji internetowych. W tej architekturze hostuje kod aplikacji internetowej, obsługuje żądania HTTPS w domenie domyślnej azurewebsites.net i łączy się z usługą SQL Database za pośrednictwem skonfigurowanych parametrów połączenia.
Azure Monitor to usługa monitorowania, która zbiera, analizuje i działa na danych telemetrycznych ze środowisk chmurowych i lokalnych. W tej architekturze przechwytuje i przechowuje informacje o żądaniach do usługi App Service i wywołaniach do usługi SQL Database za pośrednictwem integracji usługi Application Insights.
SQL Database to zarządzana usługa relacyjnej bazy danych, która zapewnia możliwości programu SQL Server w chmurze. W tej architekturze służy jako warstwa magazynu danych, która umożliwia aplikacji usługi App Service łączenie się za pośrednictwem parametrów połączenia zdefiniowanych w ustawieniach aplikacji.

Zagadnienia dotyczące

Te zagadnienia obejmują implementację filarów platformy Azure Well-Architected Framework, która jest zestawem wytycznych, których można użyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Well-Architected Framework.

Składniki wymienione w tej architekturze odnoszą się do przewodników dotyczących usługi Well-Architected. Przewodniki dotyczące usług szczegółowo opisują zalecenia i zagadnienia dotyczące określonych usług. Ta sekcja rozszerza te wskazówki, wyróżniając kluczowe zalecenia i zagadnienia dotyczące struktury Well-Architected , które mają zastosowanie do tej architektury.

Ta podstawowa architektura jest przeznaczona tylko do celów ewaluacyjnych i szkoleniowych. Priorytetem jest prostota i efektywność kosztowa, a nie funkcjonalność na poziomie produkcyjnym. W poniższych sekcjach opisano najważniejsze ograniczenia tej architektury oraz przedstawiono zalecenia i zagadnienia ułatwiające zaplanowanie bardziej niezawodnych wdrożeń.

Niezawodność

Niezawodność pomaga zapewnić, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca niezawodności.

Ta architektura nie jest przeznaczona dla wdrożeń produkcyjnych. W tej architekturze pominięto następujące krytyczne funkcje niezawodności:

Plan usługi App Service jest skonfigurowany dla warstwy Standardowa, która nie obejmuje obsługi stref dostępności Azure. Usługa App Service może stać się niedostępna, jeśli wystąpi problem z instancją, szafą serwerową lub centrum danych, które hostuje instancję.
Usługa SQL Database jest skonfigurowana dla warstwy Podstawowa, która nie obsługuje nadmiarowości strefowej. W związku z tym dane nie są replikowane w strefach dostępności Azure, co grozi utratą zatwierdzonych danych w przypadku wystąpienia awarii.
Wdrożenia w tej architekturze mogą spowodować przestój wdrożeń aplikacji, ponieważ większość technik wdrażania wymaga ponownego uruchomienia wszystkich uruchomionych wystąpień. Podczas tego procesu użytkownicy mogą napotkać błędy 503. Przerwa w działaniu podczas wdrożenia jest rozwiązywana w architekturze punktu odniesienia za pomocą miejsc wdrożenia. Staranne projektowanie aplikacji, zarządzanie schematami danych i obsługa konfiguracji aplikacji są niezbędne do wspierania współbieżnego wdrażania aplikacji w gniazdach. Użyj tego dowodu koncepcji (POC), aby zaprojektować i zweryfikować podejście do wdrożenia produkcyjnego opartego na slotach.
Skalowanie automatyczne nie jest włączone w tej podstawowej architekturze. Aby uniknąć problemów z niezawodnością spowodowanych niewystarczającymi zasobami obliczeniowymi, należy zaprojektować nadmiar zasobów, aby zapewnić wystarczającą pojemność do obsługi maksymalnego równoczesnego zapotrzebowania.

Aby uzyskać więcej informacji na temat rozwiązywania tych problemów z niezawodnością, zobacz Punkt odniesienia wysoce dostępnej aplikacji internetowej strefowo nadmiarowej — niezawodność.

Jeśli obciążenie wymaga wieloregionowej architektury aktywna-aktywna lub aktywna-pasywna, zobacz Podejścia aplikacji App Service do odzyskiwania po awarii w wielu regionach.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nieprawidłowym użyciem cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca zabezpieczeń.

Ta architektura nie jest przeznaczona dla wdrożeń produkcyjnych. Następujące krytyczne funkcje zabezpieczeń zostały pominięte w tej architekturze wraz z innymi zaleceniami dotyczącymi niezawodności i zagadnieniami:

Ta podstawowa architektura nie implementuje prywatności sieci. Plany danych i zarządzania dla zasobów, takich jak App Service i Azure SQL Server, są dostępne za pośrednictwem publicznego internetu. Pominięcie sieci prywatnej znacznie zwiększa powierzchnię ataku twojej architektury. Aby uzyskać więcej informacji o tym, jak implementowanie sieci prywatnej zapewnia następujące funkcje zabezpieczeń, zobacz Podstawowe informacje na temat aplikacji internetowej o wysokiej dostępności ze strefową nadmiarowością — Sieć. Implementowanie sieci prywatnej pomaga ograniczyć te zagrożenia, zapewniając następujące funkcje zabezpieczeń:
- Pojedynczy bezpieczny punkt wejścia dla ruchu klienta.
- Ruch sieciowy jest filtrowany zarówno na poziomie pakietu, jak i na poziomie rozproszonej odmowy usługi (DDoS).
- Eksfiltracja danych jest zminimalizowana przez utrzymywanie ruchu w Azure przy użyciu Azure Private Link.
- Zasoby sieciowe są logicznie grupowane i odizolowane od siebie za pośrednictwem segmentacji sieci.
Ta podstawowa architektura nie obejmuje wdrożenia Azure Web Application Firewall. Aplikacja internetowa nie jest chroniona przed typowymi exploitami i lukami w zabezpieczeniach. Aby zobaczyć, jak można wdrożyć Azure Web Application Firewall za pomocą Azure Application Gateway w architekturze App Services, zobacz implementację bazową.
Ta podstawowa architektura przechowuje wpisy tajne, takie jak SQL Server parametry połączenia w ustawieniach aplikacji. Ustawienia aplikacji są domyślnie szyfrowane. Jednak podczas przechodzenia do środowiska produkcyjnego rozważ przechowywanie informacji poufnych w Azure Key Vault w celu zwiększenia zarządzania. Aby uzyskać większe bezpieczeństwo i mniejsze obciążenie związane z zarządzaniem wpisami tajnymi, rozważ użycie tożsamości zarządzanej do uwierzytelniania zamiast osadzania wpisów tajnych w parametrach połączenia.
Zdalne debugowanie i punkty końcowe Kudu mogą pozostać włączone podczas opracowywania lub fazy weryfikacji koncepcji. Po przejściu do środowiska produkcyjnego należy wyłączyć niepotrzebną warstwę kontrolną, proces wdrożenia lub dostęp zdalny.
Lokalne metody uwierzytelniania dla wdrożeń lokacji protokołu transferu plików (FTP) i zarządzania kontrolą źródła (SCM) mogą pozostać włączone w fazie opracowywania lub weryfikacji koncepcji. Po przejściu do środowiska produkcyjnego należy wyłączyć uwierzytelnianie lokalne do tych punktów końcowych.
Nie musisz włączać Microsoft Defender dla usługi App Service w fazie Proof of Concept (POC). Po przejściu do środowiska produkcyjnego należy włączyć Defender dla usługi App Service w celu wygenerowania zaleceń dotyczących zabezpieczeń. Te zalecenia należy zaimplementować, aby zwiększyć stan zabezpieczeń i wykryć wiele zagrożeń we wdrożeniu usługi App Service.
Usługa App Service zawiera punkt końcowy Secure Sockets Layer (SSL) w subdomenie azurewebsites.net bez dodatkowych kosztów. Żądania HTTP są domyślnie przekierowywane do punktu końcowego HTTPS. W przypadku wdrożeń produkcyjnych domena niestandardowa jest zwykle używana z usługą Application Gateway lub usługą API Management przed wdrożeniem usługi App Service.
Użyj zintegrowanego mechanizmu uwierzytelniania dla usługi App Service. Usługa Easy Auth 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.
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. Podstawowa architektura uwierzytelnia się w SQL Server przy użyciu hasła w parametry połączenia. Rozważ użycie tożsamości zarządzanej do uwierzytelniania w SQL Server.

Aby uzyskać więcej informacji, zobacz Zabezpieczanie aplikacji w usłudze App Service.

Optymalizacja kosztów

Optymalizacja kosztów koncentruje się na sposobach zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dlaoptymalizacji kosztów.

Ta architektura optymalizuje koszt dzięki wielu kompromisom w stosunku do innych filarów platformy Well-Architected. Te kompromisy zostały specjalnie podjęte, aby współgrały z celami uczenia się i Proof of Concept (POC) tej architektury. Oszczędności kosztów w porównaniu z bardziej przygotowaną do produkcji konfiguracją architektoniczną, taką jak podstawowa aplikacja internetowa o wysokiej dostępności i nadmiarowej strefie, wynikają głównie z następujących wyborów:

Pojedyncze wystąpienie usługi App Service bez włączonego skalowania automatycznego
Standardowy plan cenowy dla usługi App Service
Brak niestandardowego certyfikatu TLS ani statycznego adresu IP
Brak zapory sieciowej dla aplikacji (WAF)
Brak dedykowanego konta magazynu na potrzeby wdrażania aplikacji
Podstawowa warstwa cenowa usługi SQL Database bez zasad przechowywania kopii zapasowych
Brak składników usługi Microsoft Defender dla Chmury
Brak kontroli ruchu wychodzącego przez zaporę
Brak prywatnych punktów końcowych
Minimalna ilość dzienników i okres ich przechowywania w Azure Monitor Logs

Aby wyświetlić szacowany koszt tej architektury, zobacz oszacowanie prekonfigurowane w kalkulatorze cen Azure który używa składników tej architektury. Koszt tej architektury można zwykle zmniejszyć, korzystając z subskrypcji Azure Dev/Test, co byłoby idealnym typem subskrypcji dla takich POC.

Doskonałość operacyjna

Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i utrzymują jej działanie w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Lista kontrolna projektu dotycząca doskonałości operacyjnej.

Poniższe sekcje zawierają wskazówki dotyczące konfiguracji, monitorowania i wdrażania aplikacji usługi App Service.

Konfiguracje aplikacji

Ponieważ podstawowa architektura nie jest przeznaczona do środowiska produkcyjnego, wykorzystuje konfigurację App Service do przechowywania wartości konfiguracji i tajemnic. Sekrety można przechowywać w konfiguracji App Service podczas fazy weryfikacji koncepcji. Nie używasz prawdziwych tajemnic i nie wymagasz zarządzania tajemnicami, których wymagają produkcyjne obciążenia systemowe.

Weź pod uwagę następujące zalecenia i zagadnienia dotyczące konfiguracji:

Zacznij od użycia konfiguracji App Service do przechowywania wartości konfiguracyjnych i parametrów połączenia we wdrożeniach proof of concept (POC). Ustawienia aplikacji i ciągi znaków połączenia są szyfrowane i odszyfrowywane tuż przed ich wstrzyknięciem do aplikacji podczas jej uruchamiania.
Przechodząc na środowisko produkcyjne, przechowuj swoje tajne dane w Key Vault. Key Vault poprawia zarządzanie tajemnicami na dwa sposoby:
- Przechowywanie tajnych danych poza systemem w Key Vault zapewnia jedno, scentralizowane miejsce do bezpiecznego zarządzania danymi tajnymi.
- Za pomocą Key Vault można rejestrować każdą interakcję z wpisami tajnymi, w tym za każdym razem, gdy uzyskuje się dostęp do wpisu tajnego.
Podczas przenoszenia do środowiska produkcyjnego można zachować użycie zarówno Key Vault, jak i konfiguracji App Service poprzez użycie odwołań Key Vault.

Containers

Można użyć podstawowej architektury do wdrożenia wspieranego kodu bezpośrednio na Windows lub instancjach Linux. Alternatywnie usługa App Service jest również platformą hostingu kontenerów, której można użyć do uruchamiania konteneryzowanej aplikacji internetowej. Usługa App Service udostępnia różne wbudowane kontenery. Niestandardowe lub wielokontenerowe aplikacje pomagają dostosować środowisko uruchomieniowe lub obsługiwać języki kodu, które nie są natywnie obsługiwane. Takie podejście wymaga wprowadzenia rejestru kontenerów.

Płaszczyzna sterowania

W fazie POC (proof of concept) zapoznaj się z kontrolną płaszczyzną usługi App Service, która jest dostępna za pośrednictwem usługi Kudu. Ta usługa udostępnia typowe interfejsy API wdrażania, takie jak wdrożenia ZIP, i udostępnia nieprzetworzone dzienniki i zmienne środowiskowe.

Jeśli używasz kontenerów, upewnij się, że rozumiesz możliwość otwierania sesji protokołu Secure Shell (SSH) w kontenerze w celu obsługi zaawansowanych funkcji debugowania.

Diagnostyka i monitorowanie

Podczas fazy POC ważne jest, aby zrozumieć, jakie logi i metryki są dostępne do przechwycenia. Rozważ następujące zalecenia i pomysły dotyczące monitorowania w fazie weryfikacji koncepcji:

Włącz rejestrowanie diagnostyczne dla wszystkich źródeł dzienników elementów. Skonfigurowanie użycia wszystkich ustawień diagnostycznych pomaga zrozumieć, jakie dzienniki i metryki są dostępne domyślnie, oraz pozwala zidentyfikować wszelkie luki, które należy wypełnić, używając frameworku do rejestrowania w kodzie aplikacji. Po przejściu do środowiska produkcyjnego wyeliminuj źródła dzienników, które nie dodają wartości, ale dodają szum i koszty do ujścia dziennika obciążenia.
Konfigurowanie rejestrowania w celu korzystania z usługi Azure Log Analytics. Azure Log Analytics zapewnia skalowalną platformę do scentralizowania rejestrowania, z łatwością umożliwiającą przeprowadzanie zapytań.
Użyj usługi Application Insights lub innego narzędzia do zarządzania wydajnością aplikacji (APM), aby emitować dane telemetryczne i dzienniki w celu monitorowania wydajności aplikacji.
Użyj modelu kondycji , który agreguje wiele skorelowanych sygnałów do stanów kondycji. Wysyłaj alerty na podstawie przejść stanów w całej architekturze, a nie na podstawie pojedynczych progów metryk. Modele kondycji usługi Azure Monitor pomagają definiować, mierzyć i wizualizować kondycję obciążeń poprzez korelowanie metryk, logów i śladów w użyteczne stany kondycji w obrębie zasobów i składników platformy Azure.

W tej architekturze model kondycji agreguje sygnały z zasobów usługi App Service i usługi SQL Database oraz składników aplikacji wdrożonych w usłudze App Service. Ocenia dostępność i opóźnienia, łączność z bazą danych i wydajność zapytań, współczynniki powodzenia uwierzytelniania oraz odpowiednie sygnały na poziomie aplikacji. Każdy element modelu generuje stan kondycji, który jest propagowany i konsolidowany przez łańcuchy zależności do postaci jednego wskaźnika najwyższego poziomu ogólnego stanu kondycji obciążenia.

Wdrożenie

Poniższe kwestie zawierają wskazówki dotyczące sposobu wdrażania aplikacji usługi App Service:

Postępuj zgodnie ze wskazówkami w CI/CD dla usługi Azure Web Apps za pomocą usługi Azure Pipelines, aby stworzyć automatyzację wdrażania aplikacji. Rozpocznij tworzenie logiki wdrażania w fazie POC. Zaimplementowanie ciągłej integracji i ciągłego dostarczania (CI/CD) na wczesnym etapie procesu programowania umożliwia szybkie i bezpieczne iterowanie aplikacji w miarę przechodzenia do środowiska produkcyjnego.
Użyj szablonów Azure Resource Manager (ARM) do wdrażania zasobów Azure i ich zależności. Ważne jest, aby rozpocząć ten proces w fazie POC. W miarę przechodzenia do środowiska produkcyjnego chcesz automatycznie wdrażać infrastrukturę.
Użyj różnych szablonów usługi ARM i zintegruj je z usługami Azure DevOps. Ta konfiguracja umożliwia tworzenie różnych środowisk. Można na przykład replikować scenariusze przypominające środowisko produkcyjne lub środowiska testowania obciążenia tylko wtedy, gdy jest to konieczne, i zaoszczędzić na kosztach.

Aby uzyskać więcej informacji, zobacz Zasady projektowania doskonałości operacyjnej.

Wydajność

Wydajność odnosi się do możliwości skalowania obciążenia w celu efektywnego zaspokojenia wymagań użytkowników. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu pod kątem wydajności.

Ponieważ ta architektura nie jest przeznaczona do wdrożeń produkcyjnych, w tej sekcji przedstawiono niektóre kluczowe cechy wydajności, które zostały pominięte w tej architekturze, wraz z innymi zaleceniami i zagadnieniami.

Wynikiem dowodu koncepcji powinien być wybór jednostki SKU, którą uważasz za odpowiednią dla obciążenia roboczego. Zaprojektuj obciążenie tak, aby efektywnie spełniało zapotrzebowanie za pośrednictwem skalowania w poziomie, dostosowując liczbę wystąpień obliczeniowych wdrożonych w planie usługi App Service. Nie projektuj systemu, aby zależeć od zmiany jednostki SKU obliczeniowej w celu dopasowania do zapotrzebowania.

Wdrożenie usługi App Service w tej podstawowej architekturze nie ma zaimplementowanego automatycznego skalowania. Usługa nie skaluje się dynamicznie ani na zewnątrz, ani do wewnątrz, aby efektywnie dopasować się do zapotrzebowania.
- Warstwa Standardowa obsługuje ustawienia autoskalowania , aby umożliwić konfigurowanie skalowania automatycznego opartego na regułach. W ramach procesu weryfikacji koncepcji określ efektywne ustawienia skalowania automatycznego dostosowane do wymagań dotyczących zasobów kodu aplikacji i oczekiwanych wzorców użycia.
- W przypadku wdrożeń produkcyjnych rozważ warstwy Premium, które obsługują skalowanie automatyczne , gdzie platforma automatycznie obsługuje decyzje dotyczące skalowania.
Postępuj zgodnie ze wskazówkami, aby skalować poszczególne bazy danych w górę bez przestojów aplikacji, jeśli potrzebujesz wyższej warstwy usługi lub poziomu wydajności dla usługi SQL Database.

Następne kroki

Samouczki dotyczące wdrażania:

Dokumentacja produktu:

Moduły microsoft Learn:

Opinia

Czy ta strona była pomocna?