Základní webová aplikace

Tento článek obsahuje základní architekturu určenou pro výuku spouštění webových aplikací ve službě Aplikace Azure Service v jedné oblasti.

Architektura

Obrázek 1: Základní architektura služby Aplikace Azure

Stáhněte si soubor aplikace Visio s touto architekturou.

Workflow

1. Uživatel vydá požadavek HTTPS na výchozí doménu služby App Service na azurewebsites.net. Tato doména automaticky odkazuje na integrovanou veřejnou IP adresu vaší služby App Service. Připojení TLS se naváže z klienta přímo do služby App Service. Certifikát se spravuje kompletně v Azure.
2. Easy Auth, funkce služby Aplikace Azure Service, zajišťuje ověření uživatele, který přistupuje k webu pomocí Microsoft Entra ID.
3. Váš kód aplikace nasazený do služby App Service zpracovává požadavek. Tento kód se může například připojit k instanci služby Azure SQL Database pomocí připojovací řetězec nakonfigurovaného ve službě App Service jako nastavení aplikace.
4. Informace o původním požadavku služby App Service a volání služby Azure SQL Database se protokolují v Application Insights.

Komponenty

• Microsoft Entra ID je cloudová služba pro správu identit a přístupu. Poskytuje jednu rovinu řízení identit pro správu oprávnění a rolí pro uživatele, kteří přistupují k webové aplikaci. Integruje se se službou App Service a zjednodušuje ověřování a autorizaci webových aplikací.
• App Service je plně spravovaná platforma pro sestavování, nasazování a škálování webových aplikací.
• Azure Monitor je monitorovací služba, která shromažďuje, analyzuje a funguje na telemetrických datech v rámci vašeho nasazení.
• Azure SQL Database je spravovaná relační databázová služba pro relační data.

Doporučení a důležité informace

Komponenty uvedené v této architektuře odkazují na příručky ke službám Azure Well-Architected. Průvodci službami podrobně uvádějí doporučení a důležité informace o konkrétních službách. Tato část rozšiřuje tyto pokyny tím, že zvýrazní klíčová doporučení a aspekty architektury Azure Well-Architected Framework, které se vztahují na tuto architekturu. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.

Tato základní architektura není určená pro produkční nasazení. Architektura upřednostňuje jednoduchost a nákladovou efektivitu oproti funkcím, abyste mohli vyhodnocovat a učit se Aplikace Azure service. Následující části popisují některé nedostatky v této základní architektuře spolu s doporučeními a aspekty.

Spolehlivost

Spolehlivost zajišťuje, že vaše aplikace může splňovat závazky, které uděláte pro vaše zákazníky. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro spolehlivost.

Vzhledem k tomu, že tato architektura není určená pro produkční nasazení, uvádí následující informace o některých důležitých funkcích spolehlivosti, které jsou v této architektuře vynechány:

• Plán služby App Service je nakonfigurovaný pro Standard úroveň, která nepodporuje zónu dostupnosti Azure. Služba App Service se stane nedostupnou v případě jakéhokoli problému s instancí, rackem nebo datacentrem, které instanci hostuje.
• Azure SQL Database je nakonfigurovaná pro vrstvu Basic , která nepodporuje zónovou redundanci. To znamená, že se data nereplikují napříč zónami dostupnosti Azure, což riskuje ztrátu potvrzených dat v případě výpadku.
• Nasazení do této architektury můžou vést k výpadkům nasazení aplikací, protože většina technik nasazení vyžaduje restartování všech spuštěných instancí. Uživatelé můžou během tohoto procesu zaznamenat chyby 503. Řeší se to v základní architektuře prostřednictvím slotů nasazení. K zajištění podpory souběžného nasazení slotu je nezbytné pečlivé navrhování aplikací, správa schémat a zpracování konfigurace aplikací. Pomocí tohoto POC můžete navrhnout a ověřit přístup k produkčnímu nasazení založenému na slotech.
• V této základní architektuře není povolené automatické škálování. Aby se zabránilo problémům se spolehlivostí kvůli nedostatku dostupných výpočetních prostředků, budete muset přeřídit, abyste vždy spustili dostatek výpočetních prostředků, aby zvládli maximální souběžnou kapacitu.

Podívejte se, jak tyto obavy týkající se spolehlivosti překonat v části Spolehlivost v zónově redundantní webové aplikaci s vysokou dostupností podle směrného plánu.

Pokud tato úloha nakonec bude vyžadovat architekturu typu aktivní nebo pasivní s více oblastmi, projděte si následující zdroje informací:

• Přístupy k aplikacím App Service pro více oblastí pro zotavení po havárii pro pokyny k nasazení úlohy hostované službou App Service napříč několika oblastmi
• Vysoce dostupná webová aplikace s více oblastmi pro referenční architekturu, která se řídí přístupem typu aktivní-pasivní.

Zabezpečení

Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace najdete v kontrolním seznamu pro kontrolu návrhu zabezpečení.

Vzhledem k tomu, že tato architektura není určená pro produkční nasazení, uvádí následující informace o některých důležitých funkcích zabezpečení, které byly v této architektuře vynechány, spolu s dalšími doporučeními a aspekty spolehlivosti:

• Tato základní architektura neimplementuje ochranu osobních údajů sítě. Roviny dat a správy prostředků, jako je služba Aplikace Azure Service a Azure SQL Server, jsou dostupné přes veřejný internet. Vynechání privátních sítí výrazně zvyšuje prostor pro útoky na vaši architekturu. Pokud chcete zjistit, jak implementace privátních sítí zajišťuje následující funkce zabezpečení, přečtěte si část Sítě standardních zónově redundantních webových aplikací s vysokou dostupností:

  • Jeden zabezpečený vstupní bod pro klientský provoz
  • Síťový provoz se filtruje jak na úrovni paketu, tak na úrovni DDoS.
  • Exfiltrace dat je minimalizovaná díky zachování provozu v Azure pomocí služby Private Link.
  • Síťové prostředky jsou logicky seskupené a izolované od sebe prostřednictvím segmentace sítě.

• Tato základní architektura nezahrnuje nasazení služby Azure Web Application Firewall. Webová aplikace není chráněná před běžným zneužitím a ohrožením zabezpečení. Podívejte se na základní implementaci a zjistěte, jak je možné implementovat firewall webových aplikací s Aplikace Azure lication Gateway v architektuře Aplikace Azure Services.

• Tato základní architektura ukládá tajné kódy, jako je azure SQL Server připojovací řetězec v nastavení aplikace. I když se nastavení aplikace šifrují, zvažte při přechodu do produkčního prostředí ukládání tajných kódů ve službě Azure Key Vault, abyste zvýšili zásady správného řízení. Ještě lepším řešením je použít spravovanou identitu pro ověřování a nemá tajné kódy uložené v připojovací řetězec.

• Vzdálené ladění a koncové body Kudu ponechejte povolené při vývoji nebo testování fáze konceptu. Při přechodu do produkčního prostředí byste měli zakázat nepotřebnou řídicí rovinu, nasazení nebo vzdálený přístup.

• Ponechání místních metod ověřování pro nasazení serveru FTP a SCM je v pořádku při vývoji nebo testování konceptu fáze. Při přechodu do produkčního prostředí byste měli zakázat místní ověřování do těchto koncových bodů.

• Ve fázi testování konceptu není nutné povolit Microsoft Defender for App Service . Při přechodu do produkčního prostředí byste měli povolit Defender for App Service, aby vygeneroval doporučení zabezpečení, která byste měli implementovat, abyste zvýšili stav zabezpečení a zjistili několik hrozeb pro vaši službu App Service.

• služba Aplikace Azure zahrnuje koncový bod SSL na subdoméně azurewebsites.net bez dalších poplatků. Požadavky HTTP se ve výchozím nastavení přesměrují na koncový bod HTTPS. Pro produkční nasazení obvykle před nasazením služby App Service použijete vlastní doménu přidruženou ke službě Application Gateway nebo službě API Management.

• Použijte integrovaný mechanismus ověřování pro Službu App Service ("EasyAuth"). EasyAuth zjednodušuje proces integrace zprostředkovatelů identity do webové aplikace. Zpracovává ověřování mimo vaši webovou aplikaci, takže nemusíte provádět významné změny kódu.

• Používejte spravovanou identitu pro identity úloh. Spravovaná identita eliminuje potřebu vývojářů spravovat přihlašovací údaje pro ověřování. Základní architektura se ověřuje pro SQL Server prostřednictvím hesla v připojovací řetězec. Zvažte použití spravované identity k ověření na Azure SQL Serveru.

Další aspekty zabezpečení najdete v tématu Zabezpečení aplikace ve službě Aplikace Azure Service.

Provozní dokonalost

Efektivita provozu zahrnuje provozní procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro efektivitu provozu.

Následující části obsahují pokyny týkající se konfigurace, monitorování a nasazení vaší aplikace App Service.

Konfigurace aplikací

Vzhledem k tomu, že základní architektura není určená pro produkční prostředí, používá konfiguraci služby App Service k ukládání hodnot konfigurace a tajných kódů. Ukládání tajných kódů v konfiguraci služby App Service je pro fázi PoC v pořádku. Skutečné tajné kódy nepoužíváte a nevyžadujete zásady správného řízení tajných kódů, které vyžadují produkční úlohy.

Tady jsou doporučení a aspekty konfigurace:

• Začněte tím, že pomocí konfigurace služby App Service uložíte hodnoty konfigurace a připojovací řetězec v testování nasazení konceptu. Nastavení aplikace a připojovací řetězec se šifrují a dešifrují těsně před vložením do aplikace při jejím spuštění.
• Když přejdete do produkční fáze, uložte tajné kódy ve službě Azure Key Vault. Použití služby Azure Key Vault zlepšuje zásady správného řízení tajných kódů dvěma způsoby:
  • Externalizace úložiště tajných kódů do služby Azure Key Vault umožňuje centralizovat úložiště tajných kódů. Máte jedno místo pro správu tajných kódů.
  • Pomocí služby Azure Key Vault můžete protokolovat všechny interakce s tajnými kódy, včetně všech přístupných tajných kódů.
• Při přechodu do produkčního prostředí můžete pomocí odkazů na službu Key Vault zachovat použití služby Azure Key Vault i konfigurace služby App Service.

Diagnostika a monitorování

Během fáze testování konceptu je důležité pochopit, jaké protokoly a metriky je možné zachytit. Tady jsou doporučení a důležité informace o monitorování ve fázi testování konceptu:

• Povolte protokolování diagnostiky pro všechny zdroje protokolů položek. Konfigurace použití všech nastavení diagnostiky vám pomůže pochopit, jaké protokoly a metriky jsou k dispozici, a případné mezery, které budete muset zavřít pomocí rozhraní protokolování v kódu aplikace. Při přechodu do produkčního prostředí byste měli eliminovat zdroje protokolů, které nepřidají hodnotu, a přidávat šum a náklady do jímky protokolů úloh.
• Nakonfigurujte protokolování tak, aby používalo Azure Log Analytics. Azure Log Analytics poskytuje škálovatelnou platformu pro centralizované protokolování, které se snadno dotazuje.
• Pomocí Application Insights nebo jiného nástroje pro správu výkonu aplikací (APM) můžete generovat telemetrická data a protokoly pro monitorování výkonu aplikací.

Nasazení

Následující seznam obsahuje pokyny týkající se nasazení aplikace App Service.

• Postupujte podle pokynů v CI/CD pro Azure Web Apps se službou Azure Pipelines a automatizujte nasazení aplikace. Začněte vytvářet logiku nasazení ve fázi PoC. Implementace CI/CD v rané fázi procesu vývoje umožňuje rychle a bezpečně iterovat v aplikaci při přechodu k produkčnímu prostředí.
• Pomocí šablon ARM nasaďte prostředky Azure a jejich závislosti. Tento proces je důležité zahájit ve fázi PoC. Při přechodu k produkčnímu prostředí chcete mít možnost automaticky nasadit infrastrukturu.
• Použijte různé šablony ARM a integrujte je se službami Azure DevOps. Toto nastavení umožňuje vytvářet různá prostředí. Můžete například replikovat produkční scénáře nebo prostředí zátěžového testování pouze v případě potřeby a ušetřit náklady.

Další informace najdete v části DevOps v architektuře Azure Well-Architected Framework.

Kontejnery

Základní architekturu je možné použít k nasazení podporovaného kódu přímo do instancí Windows nebo Linuxu. Služba App Service je také platforma pro hostování kontejnerů pro spuštění kontejnerizované webové aplikace. App Service nabízí různé integrované kontejnery. Pokud používáte vlastní nebo vícekontenerové aplikace k dalšímu vyladění prostředí runtime nebo k podpoře jazyka kódu, který není nativně podporovaný, budete muset zavést registr kontejnerů.

Řídicí rovina

Během fáze POC se seznámíte s řídicí rovinou služby Aplikace Azure, která je vystavená prostřednictvím služby Kudu. Tato služba zveřejňuje běžná rozhraní API nasazení, jako jsou nasazení ZIP, zveřejňuje nezpracované protokoly a proměnné prostředí.

Pokud používáte kontejnery, nezapomeňte pochopit schopnost Kudu otevřít relaci SSH pro kontejner, aby podporovala pokročilé možnosti ladění.

Efektivita výkonu

Efektivita výkonu je schopnost úlohy škálovat se tak, aby efektivním způsobem splňovala požadavky, které na ni kladou uživatelé. Další informace najdete v kontrolním seznamu pro kontrolu návrhu týkajícího se efektivity výkonu.

Vzhledem k tomu, že tato architektura není určená pro produkční nasazení, uvádí následující informace o některých důležitých funkcích efektivity výkonu, které byly v této architektuře vynechány, spolu s dalšími doporučeními a aspekty.

Výsledkem vašeho testování konceptu by měl být výběr skladové položky, kterou odhadnete, je vhodná pro vaši úlohu. Vaše úloha by měla být navržená tak, aby efektivně splňovala poptávku prostřednictvím horizontálního škálování úpravou počtu výpočetních instancí nasazených v plánu služby App Service. Nenavrhujte systém tak, aby závisel na změně skladové položky výpočetních prostředků tak, aby odpovídal poptávce.

• Služba App Service v této základní architektuře nemá implementované automatické škálování. Služba není dynamicky škálovat ani efektivně udržovat v souladu s poptávkou.
  • Úroveň Standard podporuje nastavení automatického škálování, abyste mohli nakonfigurovat automatické škálování založené na pravidlech. Součástí procesu POC by mělo být přijetí efektivního nastavení automatického škálování na základě potřeb prostředků kódu aplikace a očekávaných charakteristik využití.
  • U produkčních nasazení zvažte úrovně Premium, které podporují automatické automatické škálování , kde platforma automaticky zpracovává rozhodnutí o škálování.
• Pokud potřebujete vyšší úroveň služby nebo úroveň výkonu pro SLUŽBU SQL Database, postupujte podle pokynů k vertikálnímu navýšení kapacity jednotlivých databází bez výpadků aplikace.

Nasazení tohoto scénáře

Pokyny jsou podporovány ukázkovou implementací , která představuje základní implementaci služby App Service v Azure.

Další kroky

Související prostředky

• Standardní zónově redundantní webová aplikace
• Vysoce dostupná webová aplikace pro více oblastí
• Přístupy k aplikacím App Service pro více oblastí pro zotavení po havárii

Dokumentace k produktu:

• Přehled služby App Service
• Přehled služby Azure Monitor
• Přehled plánu služby App Service
• Přehled Log Analytics ve službě Azure Monitor
• Co je MICROSOFT Entra ID?
• Co je Azure SQL Database?

Moduly Microsoft Learn:

• Konfigurace a správa služby Azure Monitor
• Konfigurace ID Microsoft Entra
• Konfigurace služby Azure Monitor
• Nasazení a konfigurace serverů, instancí a databází pro Azure SQL
• Seznámení se službou Aplikace Azure Service
• Hostování webové aplikace pomocí služby Aplikace Azure Service
• Hostování domény v Azure DNS
• Implementace služby Azure Key Vault
• Správa uživatelů a skupin v Microsoft Entra ID