Edytuj

podstawowa aplikacja internetowa

Azure App Service
Azure Key Vault
Azure Monitor
Azure SQL Database

Ta architektura przedstawia podstawowe składniki podstawowej aplikacji internetowej. Możesz użyć architektury, aby utworzyć aplikację internetową, a następnie dostosować aplikację do własnych potrzeb.

Architektura

Diagram przedstawiający architekturę referencyjną podstawowej aplikacji internetowej na platformie Azure.

Pobierz plik programu Visio z tą architekturą.

Składniki

  • Usługa Azure App Service to w pełni zarządzana platforma umożliwiająca tworzenie i wdrażanie aplikacji w chmurze. Umożliwia zdefiniowanie zestawu zasobów obliczeniowych dla aplikacji internetowej do uruchamiania, wdrażania aplikacji internetowych i konfigurowania miejsc wdrożenia.
  • Miejsca wdrożenia umożliwiają przygotowanie wdrożenia, a następnie zamianę go z wdrożeniem produkcyjnym. Dzięki temu można uniknąć wdrażania bezpośrednio w środowisku produkcyjnym. Zapoznaj się z sekcją inżynierii i wdrażania wersji poniżej, aby uzyskać szczegółowe zalecenia.
  • Adres IP: aplikacja usługi App Service ma publiczny adres IP i nazwę domeny. Nazwa domeny jest poddomeną domeny azurewebsites.net, na przykład contoso.azurewebsites.net.
  • Azure DNS to usługa hostingowa przeznaczona dla domen DNS, która umożliwia rozpoznawanie nazw przy użyciu infrastruktury platformy Microsoft Azure. Dzięki hostowaniu swoich domen na platformie Azure możesz zarządzać rekordami DNS z zastosowaniem tych samych poświadczeń, interfejsów API, narzędzi i rozliczeń co w przypadku innych usług platformy Azure. Aby użyć niestandardowej nazwy domeny (takiej jak contoso.com), utwórz rekordy DNS mapujące niestandardową nazwę domeny na adres IP. Aby uzyskać więcej informacji, zobacz Konfigurowanie niestandardowej nazwy domeny w usłudze Azure App Service.
  • Usługa Azure SQL Database to relacyjna baza danych jako usługa w chmurze. Usługa SQL Database współdzieli swój kod podstawowy z aparatem bazy danych programu Microsoft SQL Server. W zależności od wymagań aplikacji można również użyć usługi Azure Database for MySQL lub Azure Database for PostgreSQL. Te alternatywy to w pełni zarządzane usługi baz danych oparte na aparatach bazy danych MySQL Server i Postgres typu open source.
  • Microsoft Entra ID to oparta na chmurze usługa zarządzania tożsamościami i dostępem, która umożliwia pracownikom dostęp do aplikacji w chmurze opracowanych dla organizacji.
  • Usługa Azure Monitor to rozwiązanie do zbierania, analizowania i działania na dziennikach i metrykach w środowiskach.
  • Usługa Azure Key Vault obsługuje zarządzanie wpisami tajnymi, zarządzanie kluczami i zarządzanie certyfikatami. Może przechowywać wpisy tajne aplikacji, takie jak parametry połączenia bazy danych.

Zalecenia

Wymagania mogą się różnić od architektury opisanej i podanej w kodzie. Kod jest wdrażany z konfiguracjami produkcyjnymi. Skorzystaj z zaleceń, aby dostosować wdrożenie zgodnie z potrzebami.

Plan usługi App Service

Plan usługi App Service ma różne warstwy cenowe. Każda warstwa cenowa obsługuje kilka rozmiarów wystąpień , które różnią się liczbą rdzeni i pamięci. Warstwę cenową po wdrożeniu można zmienić, wybierając pozycję "Skaluj w górę (plan usługi App Service)" w obszarze nawigacji po lewej stronie. Oto kilka zaleceń usługi App Service:

  • Uruchom obciążenie produkcyjne w warstwach cenowych Podstawowa, Standardowa i Premium . W tych trzech warstwach aplikacja działa w dedykowanych wystąpieniach maszyn wirtualnych i ma przydzielone zasoby, które można skalować w poziomie.
  • Użyj warstw Standardowa i Premier, jeśli potrzebujesz automatycznego skalowania i protokołu TLS/SSL.
  • Utwórz inny plan usługi App Service na potrzeby testowania i programowania. Warstwy Bezpłatna i Współdzielona (wersja zapoznawcza) służą do testowania i programowania pod kątem wydajności kosztów. Nie używaj jednak warstw Bezpłatna i Współdzielona dla obciążeń produkcyjnych. Zasoby udostępnione nie mogą być skalowane w poziomie.
  • Upewnij się, że nie używasz planów, takich jak wdrożenia testowe. Plany usługi App Service są rozliczane na sekundę. Opłaty są naliczane za wystąpienia w planie usługi App Service, nawet jeśli aplikacja została zatrzymana. Aby uzyskać więcej informacji na temat planów i rozliczeń usługi App Service, zobacz:

Poniższy szablon usługi ARM jest wdrażany w warstwie cenowej Standardowa.

SQL Database

  • Użyj usługi Azure SQL Database, aby zmniejszyć obciążenie związane z zarządzaniem. Usługa Azure SQL Database tworzy konstrukcję logiczną, która działa jako centralny punkt administracyjny dla kolekcji baz danych. Ta konstrukcja logiczna zmniejsza obciążenie związane z zarządzaniem. Każda baza danych w grupie jest wdrażana z określoną warstwą usługi. W ramach każdej grupy bazy danych nie mogą udostępniać zasobów. Nie ma kosztów obliczeń dla serwera, ale musisz określić warstwę dla każdej bazy danych. W związku z tym wydajność może być lepsza z powodu dedykowanych zasobów, ale koszt może być wyższy.
  • Przeprowadź planowanie pojemności i wybierz warstwę oraz poziom wydajności spełniające Twoje wymagania. Usługa SQL Database obsługuje warstwy usług Podstawowa, Standardowa i Premium z różnymi poziomami wydajności w każdej warstwie mierzonymi w jednostkach transakcji bazy danych (DTU).

Region (Region)

  • Utwórz plan usługi App Service i usługę SQL Database w tym samym regionie, aby zminimalizować opóźnienie sieci. W większości przypadków należy wybrać region najbliżej Twoich użytkowników.
  • Grupa zasobów ma również region. Określa, gdzie są przechowywane metadane wdrożenia. Umieść grupę zasobów i jej zasoby w tym samym regionie, aby zwiększyć dostępność podczas wdrażania.
  • Użyj kalkulatora cen, aby oszacować koszty.
  • Aby uzyskać więcej informacji, zapoznaj się z sekcją kosztów w temacie Dobrze zaprojektowana struktura platformy Microsoft Azure.

Kwestie wymagające rozważenia

Te zagadnienia obejmują implementację filarów platformy Azure Well-Architected Framework. Filary są zestawem wytycznych, które zwiększają jakość obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.

Efektywność wydajności

Główną zaletą usługi Azure App Service jest możliwość skalowania aplikacji w zależności od obciążenia. Poniżej przedstawiono kilka kwestii, które należy wziąć pod uwagę, planując skalowanie aplikacji.

Skalowanie aplikacji usługi App Service

Istnieją dwa sposoby skalowania aplikacji usługi App Service:

  • Skalowanie w górę oznacza zmianę rozmiaru wystąpienia. Rozmiar wystąpienia określa ilość pamięci, liczbę rdzeni i wielkość magazynu w każdym wystąpieniu maszyny wirtualnej. Skalowanie w górę można przeprowadzić ręcznie, zmieniając rozmiar wystąpienia lub warstwę planu.
  • Skalowanie w poziomie oznacza dodanie wystąpień do obsługi zwiększonego obciążenia. Każda warstwa cenowa ma maksymalną liczbę wystąpień. Skalowanie w poziomie można przeprowadzić ręcznie, zmieniając liczbę wystąpień lub konfigurując skalowanie automatyczne , aby platforma Azure automatycznie dodawała lub usuwała wystąpienia na podstawie harmonogramu i/lub metryk wydajności. Każda operacja skalowania odbywa się szybko, zazwyczaj w ciągu kilku sekund.

Aby włączyć skalowanie automatyczne, utwórz profil autoskalowania, który definiuje minimalną i maksymalną liczbę wystąpień. Profile oparte na harmonogramie można skonfigurować w celu wyzwalania zdarzeń skalowania. Można na przykład utworzyć oddzielne profile dla dni powszednie i weekendów. Profil może zawierać reguły dotyczące tego, kiedy dodać lub usunąć wystąpienia. Na przykład dodanie dwóch wystąpień, jeśli użycie procesora CPU przekracza 70% przez 5 minut.

Zalecenia dotyczące skalowania aplikacji internetowych:

  • Ogranicz skalowanie w górę i w dół jak najwięcej. Może ona wyzwolić ponowne uruchomienie aplikacji. Zamiast tego przeprowadź skalowanie w poziomie. Wybierz warstwę i rozmiar spełniający wymagania dotyczące wydajności w ramach typowego obciążenia, a następnie przeprowadź skalowanie wystąpień w poziomie w celu obsługi zmian w woluminie ruchu.
  • Włącz skalowanie automatyczne. Jeśli aplikacja ma przewidywalne, regularne obciążenie, utwórz profile, aby z wyprzedzeniem zaplanować liczbę wystąpień. Jeśli obciążenie nie jest przewidywalne, użyj skalowania automatycznego opartego na regułach, aby reagować na zmiany obciążenia w miarę ich występowania. Możesz połączyć oba podejścia.
  • Użyj użycia procesora CPU dla reguł skalowania automatycznego. Dobrą metryką dla reguł skalowania automatycznego jest na ogół użycie procesora CPU. Jednak należy przeprowadzić test obciążeniowy aplikacji, zidentyfikować wąskie gardła i oprzeć reguły skalowania automatycznego na tych danych.
  • Ustaw krótszy okres ochładzania na potrzeby dodawania wystąpień i dłuższego okresu ochładzania na potrzeby usuwania wystąpień. Reguły automatycznego skalowania obejmują okres ochładzania . Okres ochładzania to interwał oczekiwania po zakończeniu akcji skalowania przed rozpoczęciem nowej akcji skalowania. Okres ochładzania pozwala ustabilizować system przed ponownym skalowaniem. Na przykład ustaw 5 minut, aby dodać wystąpienie, ale 60 minut, aby usunąć wystąpienie. Lepiej jest szybko dodać nowe wystąpienia pod dużym obciążeniem, aby obsłużyć dodatkowy ruch, a następnie stopniowo skalować z powrotem.

Skalowanie baz danych SQL

Skalowanie w górę poszczególnych baz danych bez przestojów aplikacji, jeśli potrzebujesz wyższej warstwy usługi lub poziomu wydajności dla usługi SQL Database.

Aby uzyskać więcej informacji, zobacz Skalowanie zasobów pojedynczej bazy danych w usłudze Azure SQL Database.

Niezawodność

W momencie pisania dokumentu umowa dotycząca poziomu usług (SLA) dla usługi App Service wynosi 99,95%. Umowa SLA dla usługi App Service dotyczy zarówno wystąpień pojedynczych, jak i wielokrotnych. Umowa SLA dla usługi SQL Database wynosi 99,99% dla warstw Podstawowa, Standardowa i Premium.

Kopie zapasowe

Usługa SQL Database umożliwia przywracanie do punktu w czasie i przywracanie geograficzne w celu przywrócenia utraty danych. Te funkcje są dostępne i automatycznie włączone we wszystkich warstwach. Nie musisz planować tworzenia kopii zapasowych ani zarządzać nimi.

Doskonałość operacyjna

Utwórz oddzielne grupy zasobów dla środowisk produkcyjnych, programistycznych i testowych. Oddzielenie środowisk ułatwia zarządzanie wdrożeniami, usuwanie wdrożeń testowych i przypisywanie praw dostępu.

Podczas przypisywania zasobów do grup zasobów należy wziąć pod uwagę następujące funkcje:

  • Cykl życia. Ogólnie rzecz biorąc, umieszczaj zasoby z tym samym cyklem życia w tej samej grupie zasobów.
  • Dostęp. Możesz użyć kontroli dostępu opartej na rolach (RBAC) platformy Azure, aby zastosować zasady dostępu do zasobów w grupie.
  • Rozliczenia. Możesz wyświetlać zestawienia kosztów dla grupy zasobów.

Aby uzyskać więcej informacji, zobacz Omówienie usługi Azure Resource Manager.

Konfiguracje aplikacji

  • Przechowuj ustawienia konfiguracji jako ustawienia aplikacji. Zdefiniuj ustawienia aplikacji w szablonach usługi Resource Manager lub przy użyciu programu PowerShell. W środowisku uruchomieniowym ustawienia aplikacji są dostępne dla aplikacji jako zmienne środowiskowe.
  • Nigdy nie ewidencjonuj haseł, kluczy dostępu ani parametrów połączenia w systemie kontroli kodu źródłowego. Zamiast tego przekaż wpisy tajne jako parametry do skryptu wdrażania, który przechowuje te wartości jako ustawienia aplikacji.
  • Podczas zamiany miejsca wdrożenia ustawienia aplikacji są domyślnie zamieniane. Jeśli potrzebujesz różnych ustawień produkcyjnych i przejściowych, możesz utworzyć ustawienia aplikacji, które trzymają się miejsca i nie są zamieniane.

Diagnostyka i monitorowanie

DevOps

  • Użyj szablonów usługi ARM, aby wdrożyć zasoby platformy Azure i ich zależności. Towarzyszący szablon usługi ARM wdraża jedną aplikację internetową. Wszystkie zasoby są izolowane w tym samym obciążeniu podstawowym. Ta izolacja ułatwia skojarzenie określonych zasobów obciążenia z zespołem. Zespół może następnie niezależnie zarządzać wszystkimi aspektami tych zasobów. Ta izolacja umożliwia zespołowi DevOps wykonywanie ciągłej integracji i ciągłego dostarczania (CI/CD).
  • 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 w ciągu kilku minut. 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.
  • Aprowizuj wiele wystąpień aplikacji internetowej. Nie chcesz, aby aplikacja internetowa zależała od pojedynczego wystąpienia i potencjalnie utworzyć pojedynczy punkt awarii. Wiele wystąpień zwiększa odporność i skalowalność.

Aby uzyskać więcej informacji, zobacz sekcję DevOps w witrynie Azure Well-Architected Framework.

Inżynieria i wdrażanie wersji

Aplikacja usługi App Service zawsze ma jedno miejsce wdrożenia o nazwie production. Miejsce produkcyjne reprezentuje dynamiczną lokację produkcyjną. Zalecamy utworzenie miejsca przejściowego na potrzeby wdrażania aktualizacji. Używanie miejsca przejściowego przynosi następujące korzyści:

  • Przed zamianą wdrożenia na środowisko produkcyjne można sprawdzić, czy wdrożenie zakończyło się pomyślnie.
  • Wdrożenie w miejscu przejściowym gwarantuje rozgrzanie wszystkich wystąpień przed zamianą na środowisko produkcyjne. Wiele aplikacji ma znaczący czas rozgrzewania i zimnego startu.
  • Utwórz trzecie miejsce do przechowywania ostatniego znanego dobrego wdrożenia. Po zamianie miejsca przejściowego i produkcji przenieś poprzednie wdrożenie produkcyjne (które znajduje się teraz w miejscu przejściowym) do miejsca ostatniego znanego dobrego wdrożenia. Dzięki temu jeśli w późniejszym czasie wykryjesz problem, możesz szybko przywrócić ostatnią znaną dobrą wersję.

Zamiana miejscami wdrożeń produkcyjnych i przejściowych

  • Jeśli wracasz do poprzedniej wersji, upewnij się, że wszystkie zmiany schematu bazy danych są zgodne z poprzednimi wersjami.
  • Nie używaj miejsc we wdrożeniu produkcyjnym do testowania, ponieważ wszystkie aplikacje w ramach tego samego planu usługi App Service używają tych samych wystąpień maszyny wirtualnej. Na przykład testy obciążeniowe mogą obniżyć wydajność aktywnej lokacji produkcyjnej. Zamiast tego utwórz oddzielne plany usługi App Service dla celów produkcyjnych i testowych. Wprowadzenie wdrożeń testowych do oddzielnego planu pozwala odizolować je od wersji produkcyjnej.

Zabezpieczenia

W tej sekcji wyszczególniono kwestie dotyczące zabezpieczeń charakterystyczne dla usług platformy Azure opisanych w tym artykule. Nie jest to pełna lista najlepszych rozwiązań dotyczących zabezpieczeń. Aby zapoznać się z innymi zagadnieniami dotyczącymi zabezpieczeń, zobacz Zabezpieczanie aplikacji w usłudze aplikacja systemu Azure Service.

Inspekcja usługi SQL Database

Inspekcja pomaga zachować zgodność z przepisami oraz uzyskać wgląd w odchylenia i nieprawidłowości, które mogą oznaczać problemy biznesowe lub podejrzane naruszenia zabezpieczeń. Zobacz Rozpoczynanie pracy z inspekcją bazy danych SQL.

Miejsca wdrożenia

Każde miejsce wdrożenia ma publiczny adres IP. Zabezpiecz miejsca nieprodukcyjne przy użyciu logowania firmy Microsoft Entra, aby tylko członkowie zespołów deweloperskich i DevOps mogli uzyskać dostęp do tych punktów końcowych.

Rejestrowanie

Dzienniki nigdy nie powinny rejestrować haseł użytkowników ani innych informacji, które mogą być użyte do fałszowania tożsamości. Przed przekazaniem danych do magazynu usuń z nich te szczegóły.

Protokół SSL

Aplikacja usługi App Service zawiera punkt końcowy SSL w poddomenie bez azurewebsites.net dodatkowych kosztów. Punkt końcowy SSL zawiera certyfikat wieloznaczny dla domeny *.azurewebsites.net. Jeśli używasz niestandardowej nazwy domeny, musisz podać certyfikat pasujący do domeny niestandardowej. Najprostszą metodą jest zakup certyfikatu bezpośrednio w witrynie Azure Portal. Można także importować certyfikaty z innych urzędów certyfikacji. Aby uzyskać więcej informacji, zobacz kupowanie i konfigurowanie certyfikatu SSL dla usługi aplikacja systemu Azure Service.

Protokół HTTPS nie jest domyślnie włączony we wdrożeniu szablonu usługi ARM. Ze względów bezpieczeństwa Twoja aplikacja powinna wymuszać protokół HTTPS, przekierowując żądania HTTP. Protokół HTTPS można zaimplementować wewnątrz aplikacji lub użyć reguły ponownego zapisywania adresów URL zgodnie z opisem w temacie Włączanie protokołu HTTPS dla aplikacji w usłudze aplikacja systemu Azure Service.

Uwierzytelnianie

Zalecamy uwierzytelnianie za pośrednictwem dostawcy tożsamości (IDP), takiego jak Microsoft Entra ID, Facebook, Google lub Twitter. Dla przepływu uwierzytelniania użyj protokołu OAuth 2 lub OpenID Connect (OIDC). Microsoft Entra ID udostępnia funkcje zarządzania użytkownikami i grupami, tworzenia ról aplikacji, integrowania tożsamości lokalnych i korzystania z usług zaplecza, takich jak platforma Microsoft 365 i Skype dla firm.

Unikaj bezpośredniego zarządzania identyfikatorami logowania użytkownika i poświadczeniami przez aplikację. Tworzy potencjalną powierzchnię ataków. Musisz mieć co najmniej potwierdzenie wiadomości e-mail, odzyskiwanie hasła i uwierzytelnianie wieloskładnikowe, walidować siłę hasła i bezpiecznie przechowywać skróty haseł. Duzi dostawcy tożsamości obsługują wszystkie te elementy i stale monitoruje i ulepszają swoje praktyki w zakresie zabezpieczeń.

Rozważ użycie uwierzytelniania usługi App Service w celu zaimplementowania przepływu uwierzytelniania OAuth lub OIDC. Korzyści wynikające z uwierzytelniania usługi App Service:

  • Łatwo je skonfigurować.
  • W przypadku prostych scenariuszy uwierzytelniania nie jest wymagany żaden kod.
  • Obsługuje autoryzację delegowaną przy użyciu tokenów dostępu protokołu OAuth w celu korzystania z zasobów w imieniu użytkownika.
  • Zawiera wbudowaną pamięć podręczną tokenów.

Niektóre ograniczenia uwierzytelniania usługi App Service:

  • Ograniczone opcje dostosowywania.
  • Autoryzacja delegowana jest ograniczona do jednego zasobu wewnętrznej bazy danych na sesję logowania.
  • Jeśli używasz więcej niż jednego dostawcy tożsamości, nie ma wbudowanego mechanizmu odnajdywania obszaru macierzystego.
  • W przypadku scenariuszy z wieloma dzierżawami aplikacja musi zaimplementować logikę do weryfikowania wystawcy tokenów.

Wdrażanie tego scenariusza

Ta architektura obejmuje plan usługi aplikacja systemu Azure i pustą aplikację. Używa ona usługi Azure SQL Database, Azure Key Vault do przechowywania parametry połączenia bazy danych oraz usługi Azure Monitor na potrzeby rejestrowania, monitorowania i alertów.

Użyj następującego polecenia, aby utworzyć grupę zasobów dla wdrożenia. Wybierz przycisk Wypróbuj, aby użyć osadzonej powłoki.

az group create --name basic-web-app --location eastus

Uruchom następujące polecenie, aby wdrożyć aplikację internetową i infrastrukturę pomocniczą. Po wyświetleniu monitu wprowadź nazwę użytkownika i hasło. Te wartości są używane do uzyskiwania dostępu do wystąpienia usługi Azure SQL Database.

az deployment group create --resource-group basic-web-app  \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/basic-web-app/azuredeploy.json

Aby uzyskać szczegółowe informacje i więcej opcji wdrażania, zobacz Szablony usługi ARM używane do wdrażania tego rozwiązania.

Podstawowy szablon usługi ARM aplikacji internetowej

Następne kroki

Porady dotyczące rozwiązywania problemów z aplikacją:

Dokumentacja produktu:

Moduły microsoft Learn: