Standardní vysoce dostupná zónově redundantní webová aplikace

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

Tato základní architektura vychází ze základní architektury webových aplikací a poskytuje podrobné pokyny k návrhu zabezpečené, zónově redundantní a vysoce dostupné webové aplikace v Azure. V této architektuře služba Azure Application Gateway se službou Azure Web Application Firewall zveřejňuje veřejný koncový bod a směruje požadavky do služby Azure App Service prostřednictvím služby Azure Private Link. Aplikace App Service používá integraci virtuální sítě a službu Private Link k zabezpečené komunikaci s řešeními PaaS (Platforma jako služba) Azure, jako je Azure Key Vault a Azure SQL Database.

Důležité

Ukázková implementace ukazuje tuto základní implementaci služby App Service v Azure. Použijte ho jako základ pro produkční řešení.

Architektura

Diagram znázorňující základní architekturu služby App Service s redundancí zón a vysokou dostupností

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

Komponenty

Tato architektura sdílí mnoho komponent se základní architekturou webové aplikace. Následující seznam popisuje pouze komponenty, které se liší od základní architektury nebo ji rozšiřují:

  • Application Gateway je nástroj pro vyrovnávání zatížení HTTP a HTTPS vrstvy 7 a správce webového provozu. V této architektuře služba Application Gateway funguje jako jediný veřejný vstupní bod. Application Gateway ukončí protokol TLS (Transport Layer Security) a vyhodnotí pravidla firewallu webových aplikací Azure. Pak předá schválené žádosti soukromě instancím služby App Service napříč zónami dostupnosti.

  • Azure Web Application Firewall je nativní cloudová služba, která chrání webové aplikace před běžným zneužitím, jako je injektáž SQL a skriptování mezi weby (XSS). V této architektuře služba Azure Web Application Firewall běží ve službě Application Gateway a blokuje škodlivé požadavky, než se dostanou ke službě App Service. Toto nastavení zlepšuje zabezpečení a pomáhá udržovat dostupnost.

  • Key Vault je služba, která bezpečně ukládá a spravuje tajné kódy, šifrovací klíče a certifikáty. V této architektuře ukládá certifikát TLS (X.509), který služba Application Gateway používá, a uchovává tajné kódy aplikací, ke kterým služba App Service přistupuje soukromě.

  • Azure Virtual Network je služba, která poskytuje izolované a zabezpečené privátní virtuální sítě v Azure. V této architektuře poskytuje virtuální síť privátní koncové body, integraci služby App Service a vyhrazené podsítě pro službu Application Gateway. Toto nastavení izoluje provoz a umožňuje službě App Service bezpečně komunikovat se závislými službami Azure prostřednictvím privátních koncových bodů.

  • Private Link je síťová služba, která poskytuje privátní přístup ke službám Azure přes páteřní síť Microsoftu, aby se zabránilo vystavení veřejnému internetu. V této architektuře služba Private Link umožňuje privátní příchozí připojení ke službě App Service a privátní odchozí připojení ze služby App Service ke službám, jako je Key Vault, SQL Database a Azure Storage.

  • Azure DNS je hostitelská služba pro domény DNS (Domain Name System). Poskytuje rozlišení názvů pomocí infrastruktury Microsoft Azure. Privátní zóny DNS mapují plně kvalifikovaný název domény (FQDN) služby na IP adresu privátního koncového bodu. V této architektuře namapují privátní zóny DNS výchozí doménu služby App Service a další domény služby PaaS na adresy privátního koncového bodu tak, aby veškerý provoz zůstal v privátní síti.

Sítě

Zabezpečení sítě je centrální pro základní architekturu služby App Service. Na vysoké úrovni poskytuje síťová architektura následující možnosti:

  • Jeden zabezpečený vstupní bod pro klientský provoz

  • Filtrování provozu přes Azure Web Application Firewall

  • Kompletní šifrování TLS pro přenášená data

  • Minimalizovaná exfiltrace dat prostřednictvím služby Private Link, která udržuje provoz v rámci Azure

  • Logické seskupení a izolace síťových prostředků prostřednictvím segmentace sítě

Toky sítě

Diagram znázorňující toky sítě v základní síťové architektuře služby App Service

Příchozí tok

Následující kroky popisují příchozí tok z internetu do instance služby App Service:

  1. Uživatel vydá žádost o veřejnou IP adresu služby Application Gateway.

  2. Application Gateway vyhodnocuje pravidla firewallu webových aplikací, která chrání před útoky, jako je XSS a injektáž SQL. Pokud pravidlo zjistí porušení, služba Application Gateway vrátí žadateli chybu a zastaví zpracování. V opačném případě služba Application Gateway směruje požadavek do back-endového fondu, což je v tomto případě výchozí doména služby App Service.

  3. Privátní zóna privatelink.azurewebsites.net DNS odkazuje na virtuální síť. Zóna DNS obsahuje záznam A , který mapuje výchozí doménu služby App Service na privátní IP adresu privátního koncového bodu služby App Service. Azure DNS tento záznam používá k překladu výchozí domény na IP adresu privátního koncového bodu.

  4. Application Gateway směruje požadavek na instanci služby App Service prostřednictvím privátního koncového bodu.

Odchozí tok

Následující kroky popisují odchozí tok ze služby App Service do služeb Azure PaaS:

  1. App Service odešle požadavek na název DNS požadované služby Azure, jako je Key Vault, Storage, SQL Database nebo jakákoli jiná služba Azure, která podporuje službu Private Link. Funkce integrace virtuální sítě služby App Service směruje požadavek přes virtuální síť.

  2. Podobně jako krok 3 v příchozím toku obsahuje propojená zóna DNS záznam A , který mapuje doménu služby Azure na IP adresu privátního koncového bodu. Azure DNS tento záznam používá k překladu domény na IP adresu privátního koncového bodu služby.

  3. Virtuální síť směruje požadavek do služby prostřednictvím privátního koncového bodu.

Odchozí provoz, který nepřechází do služeb Azure PaaS, opustí veřejnou IP adresu, kterou sdílí více zákazníků. Například webová aplikace může během požadavku HTTP volat veřejné rozhraní API. Pokud chcete řídit tento typ odchozího provozu, nasměrujte ho přes síťové zařízení, jako je Azure Firewall. Brána firewall používá překlad zdrojových síťových adres (SNAT), takže toky pocházejí z veřejných IP adres brány firewall, nikoli ze sdíleného odchozího fondu služby App Service, což poskytuje stabilní odchozí identitu, kterou můžou povolit podřízení partneři. Další informace najdete v tématu Řízení odchozího provozu pomocí služby Azure Firewall.

Implementace služby Application Gateway

Application Gateway je škálovatelný, regionální nástroj pro vyrovnávání zatížení vrstvy 7, který podporuje firewall webových aplikací Azure a snižování zátěže TLS. Při implementaci služby Application Gateway pro příchozí provoz do služby App Service zvažte následující body:

Tok ze služby App Service do služeb Azure

Tato architektura využívá integraci virtuální sítě ke směrování provozu služby App Service do privátních koncových bodů přes virtuální síť. Základní architektura nepovoluje veškeré směrování provozu, což by vynutilo veškerý odchozí provoz přes virtuální síť. Místo toho směruje pouze interní provoz, který směřuje na privátní koncové body.

U služeb Azure, které nevyžadují veřejný přístup k internetu, povolte privátní koncové body a zablokujte veřejné koncové body. Privátní koncové body zlepšují zabezpečení tím, že umožňují službě App Service připojit se ke službám Private Link přímo z privátní virtuální sítě bez přidělování veřejných IP adres.

V této architektuře mají služba SQL Database, Storage a Key Vault blokované veřejné koncové body. Brány firewall služeb povolují provoz pouze z jiných služeb Azure, které jsou autorizované. Nakonfigurujte další služby Azure, jako je Azure Cosmos DB a Azure Managed Redis, s využitím privátních koncových bodů. V této architektuře Azure Monitor nepoužívá privátní koncový bod, ale můžete ho implementovat pomocí oboru služby Azure Monitor Private Link (AMPLS).

Základní architektura implementuje privátní zónu DNS pro každou službu. Každá privátní zóna DNS obsahuje záznam A, který mapuje úplný název domény služby na IP adresu privátního koncového bodu. Zóny jsou propojeny s virtuální sítí. Skupiny privátních zón DNS automaticky vytvářejí a aktualizují záznamy DNS pro privátní koncové body.

Při implementaci integrace virtuální sítě a privátních koncových bodů zvažte následující body:

Segmentace a zabezpečení virtuální sítě

Síť v této architektuře má samostatné podsítě pro službu Application Gateway, integrační komponenty služby App Service a privátní koncové body. Skupina zabezpečení sítě (NSG) v každé podsíti umožňuje pouze požadovaný příchozí a odchozí provoz. Následující tabulka popisuje výběr pravidel NSG, která můžete přidat do každé podsítě.

Podsíť Příchozí Odchozí
GatewaySubnet AppGw.In.Allow.ControlPlane: Povolit příchozí přístup k řídicí rovině.

AppGw.In.Allow443.Internet: Povolte příchozí přístup přes internet HTTPS.
AppGw.Out.Allow.PrivateEndpoints: Povolit odchozí přístup k PrivateEndpointsSubnet.

AppPlan.Out.Allow.AzureMonitor: Povolit odchozí přístup ke službě Azure Monitor.
PrivateEndpointsSubnet Výchozí pravidla: Povolí příchozí přístup z virtuální sítě. Výchozí pravidla: Povolí odchozí přístup k virtuální síti.
AppServiceSubnet Výchozí pravidla: Povolí příchozí přístup z virtuální sítě. AppPlan.Out.Allow.PrivateEndpoints: Povolit odchozí přístup k PrivateEndpointsSubnet.

AppPlan.Out.Allow.AzureMonitor: Povolit odchozí přístup ke službě Azure Monitor.

Při implementaci segmentace a zabezpečení virtuální sítě zvažte následující body:

  • Povolte ochranu před útoky DDoS pro virtuální síť, která obsahuje podsíť aplikační brány s veřejnou IP adresou.

  • Pokud je to možné, přidejte NSG (skupinu zabezpečení sítě) do každé podsítě. Použijte nejpřísnější pravidla, která umožňují plnou funkčnost řešení.

  • Skupiny zabezpečení aplikací můžete použít k logickému seskupení prostředků, což zjednodušuje vytváření pravidel NSG v složitých prostředích.

Následující tabulka ukazuje příklad schématu sítě.

Typ Název Rozsah adres
Virtuální síť Předpona adresy 10.0.0.0/16
Podsíť GatewaySubnet 10.0.1.0/24
Podsíť AppServiceSubnet 10.0.0.0/24
Podsíť PrivateEndpointsSubnet 10.0.2.0/27
Podsíť AgentsSubnet 10.0.2.32/27

Úvahy

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které můžete použít ke zlepšení kvality úlohy. Další informace najdete v tématu Well-Architected Framework.

Reliability

Spolehlivost pomáhá zajistit, aby vaše aplikace splňovala závazky, které jste pro své zákazníky udělali. Další informace naleznete v tématu Kontrolní seznam pro kontrolu spolehlivosti.

Základní architektura služby App Service se zaměřuje na redundanci zón pro klíčové regionální služby. Zóny dostupnosti jsou fyzicky oddělená umístění v rámci oblasti, která poskytují vysokou dostupnost a odolnost proti chybám. Když nasadíte dvě nebo více instancí napříč zónami dostupnosti v podporovaných oblastech, selhání jedné zóny neovlivní ostatní. Tento přístup pomáhá udržovat dostupnost služeb.

Architektura také zajišťuje dostatečné instance služeb Azure pro splnění poptávky. Následující části poskytují pokyny ke spolehlivosti pro každou klíčovou službu v architektuře.

Aplikační brána

Nasaďte službu Application Gateway v zónově redundantní konfiguraci s minimálním počtem tří škálovacích instancí. Více instancí zajišťuje, aby služba zůstala dostupná během selhání, aniž by čekala na 6minutovou až sedmiminutovou dobu spuštění potřebnou k nastavení nové instance.

Aplikační služba

  • Nasaďte minimálně dvě instance služby App Service, které podporují zóny dostupnosti. Pokud chcete vyšší odolnost, nasaďte alespoň jednu instanci pro každou zónu dostupnosti ve vaší oblasti a další instance v rámci každé zóny kvůli redundanci.

  • Implementujte do svých aplikací koncové body kontroly stavu a nakonfigurujte funkci kontroly zdraví služby App Service tak, aby přesměrovávala požadavky od instancí ve špatném stavu. Další informace najdete v tématu Monitorování instancí služby App Service pomocí kontroly stavu a kontrol stavu v ASP.NET Core.

  • Nadměrná kapacita pro zvládnutí výpadků zóny.

Blob Storage

  • Použijte zónově redundantní úložiště (ZRS), které replikuje data synchronně napříč třemi zónami dostupnosti v dané oblasti. Vytvořte účty úložiště Standard ZRS nebo Standard geograficky zónově redundantního úložiště (GZRS), abyste zajistili replikaci dat napříč zónami dostupnosti.

  • Vytvořte samostatné účty úložiště pro nasazení, webové prostředky a další data pro správu a konfiguraci každého z jednotlivých účtů nezávisle.

SQL databáze

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 naleznete v tématu Kontrolní seznam pro kontrolu návrhu prozabezpečení .

Základní architektura služby App Service se zaměřuje na základní doporučení zabezpečení pro vaši webovou aplikaci. Musíte pochopit, jak funguje šifrování a identita v každé vrstvě, abyste mohli úlohu zabezpečit.

Aplikační služba

  • Vypněte místní metody ověřování pro nasazení lokality protokolu File Transfer Protocol (FTP) a správy zdrojového kódu (SCM).

  • Vypněte vzdálené ladění.

  • Použijte nejnovější verzi protokolu TLS, kterou podporují všichni vaši klienti.

  • Zapněte plán služby Microsoft Defender for App Service.

  • Používejte nejnovější verze podporovaných platforem, programovacích jazyků, protokolů a architektur.

  • Pokud potřebujete vyšší izolaci nebo zabezpečený přístup k síti, zvažte službu App Service Environment .

Šifrování

Produkční webové aplikace musí šifrovat přenášená data pomocí protokolu HTTPS. HTTPS využívá protokol TLS a k šifrování používá veřejné a privátní klíče. Uložte certifikát TLS (X.509) ve službě Key Vault a udělte službě Application Gateway oprávnění k načtení privátního klíče. U neaktivních uložených dat některé služby automaticky šifrují data a jiné umožňují přizpůsobit nastavení.

Přenášená data

Základní architektura šifruje přenášená data od uživatele do webové aplikace ve službě App Service.

Diagram znázorňující základní tok šifrování služby App Service

Následující pracovní postup popisuje, jak funguje šifrování na vysoké úrovni:

  1. Uživatel odešle do webové aplikace požadavek HTTPS.

  2. HTTPS požadavek se dostane k aplikační bráně.

  3. Aplikační brána používá ve službě Key Vault certifikát (X.509) k vytvoření zabezpečeného připojení TLS s webovým prohlížečem uživatele. Aplikační brána dešifruje požadavek HTTPS, aby ji firewall webových aplikací mohl zkontrolovat.

  4. Aplikační brána vytvoří připojení TLS ke službě App Service a znovu zašifruje požadavek uživatele. App Service poskytuje nativní podporu protokolu HTTPS, takže do služby App Service nemusíte přidávat certifikát. Aplikační brána odesílá šifrovaný provoz do služby App Service. App Service dešifruje provoz a webová aplikace požadavek zpracuje.

Při konfiguraci šifrování přenášených dat zvažte následující doporučení:

  • Vytvořte nebo nahrajte certifikát do služby Key Vault. Šifrování HTTPS vyžaduje certifikát (X.509). Pro vlastní doménu potřebujete certifikát od důvěryhodné certifikační autority.

  • Uložte privátní klíč do certifikátu ve službě Key Vault.

  • Poskytněte službě Application Gateway přístup k privátnímu klíči certifikátu. Další informace najdete v tématu Udělení oprávnění pomocí řízení přístupu na základě role v Azure (Azure RBAC) a spravovaných identit pro prostředky Azure. Nepoužívejte zásady přístupu ke službě Key Vault k poskytování přístupu. Zásady přístupu umožňují udělit pouze obecná oprávnění, ne konkrétní hodnoty.

  • Zapněte komplexní šifrování. App Service je back-endový fond pro aplikační bránu. Při konfiguraci nastavení back-endu pro back-endový fond použijte protokol HTTPS na back-endovém portu 443.

Data v klidu
  • Transparentní šifrování dat slouží k šifrování citlivých dat ve službě SQL Database. Transparentní šifrování dat šifruje celou databázi, zálohy a soubory transakčních protokolů a nevyžaduje změny ve webové aplikaci.

  • Umístěte citlivá data do vlastní databáze a zapněte šifrování pouze pro tuto databázi. Tento přístup minimalizuje latenci šifrování databáze.

  • Seznamte se s integrovanou podporou šifrování. Azure Storage automaticky šifruje neaktivní uložená data prostřednictvím šifrování na straně serveru (256bitový standard AES (Advanced Encryption Standard). Azure Monitor automaticky šifruje neaktivní uložená data prostřednictvím klíčů spravovaných Microsoftem.

Řízení

Azure Policy pomáhá vynucovat rozhodnutí o architektuře a zabezpečení pro webové aplikace. Může zabránit tomu, aby se nasazovány nevyhovující prostředky (režim zamítnutí) nebo je označit k posouzení (režim auditu). Tento přístup pomáhá odhalit posun konfigurace od zamýšlené architektury, ať už se posun provádí prostřednictvím nasazení infrastruktury jako kódu (IaC) nebo ručních změn na webu Azure Portal.

Umístěte všechny prostředky vaší architektury pod řízení Azure Policy. Pokud je to možné, použijte předdefinované zásady nebo iniciativy zásad k vynucení základní topologie sítě, funkcí služeb, zabezpečení a monitorování rozhodnutí. Zvažte následující předdefinované zásady:

  • Služba App Service by měla zakázat přístup k veřejné síti.
  • Služba App Service by měla používat integraci virtuální sítě.
  • Služba App Service by měla používat službu Private Link pro připojení ke službám PaaS.
  • Služba App Service by měla mít zakázané místní metody ověřování pro nasazení serveru FTP a SCM.
  • Služba App Service by měla mít vypnuté vzdálené ladění.
  • Aplikace app Service by měly používat nejnovější verzi protokolu TLS.
  • Měla by být povolená služba Defender for App Service.
  • Firewall webových aplikací Azure by měl být povolený pro službu Application Gateway.

Podívejte se na další předdefinované zásady pro klíčové služby, jako jsou application gateway a síťové komponenty, App Service, Key Vault a monitorovací komponenty. Pokud předdefinované zásady nevyhovují vašim potřebám, můžete vytvářet vlastní zásady nebo používat zásady komunity, jako jsou zásady z cílových zón Azure. Pokud je to možné, upřednostněte předdefinované zásady.

Správa identit a přístupu

Základní architektura služby App Service konfiguruje ověřování a autorizaci pro identity uživatelů (uživatele) a identity úloh (prostředky Azure). Implementuje princip nejnižších oprávnění.

Uživatelské identity
  • Použijte integrovaný mechanismus ověřování pro Službu App Service, označovaný také jako EasyAuth. EasyAuth zjednodušuje integraci zprostředkovatele identity s vaší webovou aplikací. Zpracovává ověřování mimo vaši webovou aplikaci, takže nemusíte provádět významné změny kódu.

  • Nakonfigurujte adresu URL odpovědi pro vlastní doménu. Nastavte adresu URL přesměrování na https://<application-gateway-endpoint>/.auth/login/<provider>/callback.

    Nahraďte <application-gateway-endpoint> veřejnou IP adresu nebo vlastní název domény vaší aplikační brány. Nahraďte <provider> svým zprostředkovatelem ověřování, například aad Microsoft Entra ID.

    Pokyny k nastavení najdete v tématu Úvahy o Azure Front Door nebo integrace brány Application Gateway s App Service.

Identity úloh
  • Používejte spravované identity pro identity úloh. Spravované identity eliminují potřebu vývojářů spravovat přihlašovací údaje pro ověřování.

  • Použijte spravované identity přiřazené uživatelem. Identity přiřazené systémem můžou způsobit selhání nasazení IaC na základě podmínek časování a pořadí operací. Spravované identity přiřazené uživatelem se vyhýbají některým z těchto scénářů chyb nasazení. Další informace najdete v tématu Spravované identity.

Optimalizace nákladů

Optimalizace nákladů se zaměřuje na způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro optimalizaci nákladů.

Tento cenový odhad Azure zahrnuje pouze komponenty v této architektuře, včetně komponent, které se přenesou z webové aplikace Basic. Upravte ho pomocí jakýchkoli změn architektury, které váš případ použití vyžaduje.

Efektivita provozu

Efektivita provozu se zabývá provozními procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace naleznete v tématu kontrolní seznam pro kontrolu efektivity provozu.

Nasazení pro základní aplikaci App Service se řídí pokyny k architektuře Azure Pipelines. Vzhledem k tomu, že základní architektura zakazuje veřejný přístup ke službě App Service a zabezpečuje účet úložiště nasazení ve virtuální síti, nemůžete nasazení provést mimo virtuální síť. K vyřešení tohoto omezení architektura používá nasazovací agenty hostované sám sebou, které běží ve virtuální síti. Následující pokyny k nasazení se zaměřují na nasazení kódu aplikace, ne na změny infrastruktury nebo databáze.

Diagram znázorňující základní architekturu nasazení služby App Service

Proces nasazení

  1. Vydávací potrubí odesílá žádost o úlohu do fronty úloh pro samosprávní agenty. Úloha dává agentovi pokyn, aby na účet úložiště nahrál artefakt sestavení soubor ZIP pro publikování.

  2. Agent nasazení v místním prostředí dotazuje frontu, převezme žádost o úlohu a stáhne úlohu a artefakt sestavení.

  3. Agent nasazení v místním prostředí nahraje soubor ZIP do účtu úložiště prostřednictvím privátního koncového bodu účtu úložiště.

  4. Pipeline pokračuje a spravovaný agent převezme následující úlohu. Spravovaný agent volá rozhraní příkazového řádku (CLI) k aktualizaci nastavení aplikace WEBSITE_RUN_FROM_PACKAGE , aby odkázalo na nový soubor ZIP publikování pro přípravný slot.

    az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip
    
  5. App Service stáhne nový soubor ZIP pro publikování z úložiště prostřednictvím privátního koncového bodu účtu úložiště. Restartuje přípravnou instanci s novým balíčkem, protože WEBSITE_RUN_FROM_PACKAGE byla nastavena na jiný název souboru.

  6. Potrubí se obnoví a spustí kontrolní testy nebo počká na ruční schválení. Po úspěšném testování nebo schválení pipeline vymění pozice přípravných a produkčních slotů.

Pokyny pro nasazení

Pro základní architekturu použijte následující pokyny k nasazení:

  • Spusťte nasazení přímo z balíčku ve službě App Service, abyste se vyhnuli konfliktům nasazení. Tento přístup připojí balíček ZIP přímo jako adresář wwwroot jen pro čtení místo kopírování souborů. Eliminuje konflikty zámků souborů mezi nasazením a modulem runtime a zajišťuje, aby běžely jenom plně nasazené aplikace.

  • Zahrňte čísla verzí do nasazených názvů souborů ZIP balíčku. Když aktualizujete WEBSITE_RUN_FROM_PACKAGE nastavení aplikace tak, aby odkazovalo na balíček nasazení, který má jiný název souboru, služba App Service automaticky načte nový balíček a restartuje se.

  • Použijte sloty nasazení pro odolné nasazení kódu.

  • Zvažte použití spravovaných i hostovaných agentů.

  • Použití IaC k automatizaci nasazení infrastruktury

  • Nepřetržitě ověřte výkon a odolnost úloh pomocí služeb, jako je Azure Load Testing a Azure Chaos Studio.

Konfigurace

Aplikace vyžadují hodnoty konfigurace i tajné kódy. Ke správě konfigurací a tajných kódů použijte následující doprovodné materiály:

  • Nikdy neukládejte tajné kódy, jako jsou hesla nebo přístupové klíče ve správě zdrojového kódu. Ukládejte tajné kódy ve službě Key Vault.

  • Uložte konfiguraci aplikace v konfiguraci služby App Service. Pokud potřebujete externí konfiguraci nebo podporu pro feature flag, použijte Azure App Configuration.

  • Pomocí odkazů služby Key Vault v konfiguraci služby App Service můžete bezpečně zveřejnit tajné kódy ve vaší aplikaci.

  • Nakonfigurujte nastavení aplikace specifické pro sloty, pokud vaše produkční a přípravné sloty potřebují různé hodnoty. Ve výchozím nastavení se nastavení aplikace během nasazování vymění se slotem.

  • Pro místní vývoj použijte místní proměnné prostředí nebo funkce specifické pro platformu. Konfigurace služby App Service zveřejňuje nastavení aplikace jako proměnné prostředí. Vývojové nástroje, jako je Visual Studio, umožňují nastavit proměnné prostředí ve spouštěcích profilech a poskytovat zabezpečené úložiště pro místní nastavení prostřednictvím tajných kódů uživatelů.

Sledování

Monitorování shromažďuje a analyzuje data ze systémů informačních technologií (IT) za účelem zajištění pozorovatelnosti. V této architektuře monitorování sleduje stav a zabezpečení webových aplikací napříč několika vrstvami, což pomáhá udržovat spolehlivé operace.

Monitorujte tři klíčové vrstvy:

  • Kód aplikace: Sledujte telemetrii specifickou pro aplikaci a vlastní metriky.

  • Infrastruktura (modul runtime): Monitorujte prostředí runtime služby App Service.

  • Platforma (prostředky Azure): Shromážděte metriky a protokoly ze služeb Azure, jako je Application Gateway, SQL Database a Key Vault.

Další informace najdete v protokolu aktivit Azure, protokolech prostředků Azure a protokolování aplikací služby App Service.

Monitorování platformy

Monitorování platformy shromažďuje data ze služeb Azure ve vaší architektuře.

Aplikační brána

Application Gateway monitoruje zdravotní stav back-endového fondu pomocí výchozích zdravotních sond. Pomocí protokolů přístupu ke službě Application Gateway můžete shromažďovat informace, jako jsou časová razítka, kódy odpovědí HTTP a cesty URL. Další informace najdete v tématu Stav back-endu a diagnostické protokoly.

Aplikační služba

App Service poskytuje vestavěné a integrované monitorovací funkce pro lepší přehlednost. Pokud už vaše webová aplikace obsahuje funkce telemetrie a monitorování, jako je instrumentace v procesu, budou tyto funkce dál fungovat ve službě App Service.

  • Zapnutím automatické instrumentace můžete rozšířit instrumentaci beze změn kódu. Tato funkce poskytuje viditelnost monitorování výkonu aplikací (APM). Další informace najdete v tématu Monitorování výkonu služby App Service.

  • Zapněte distribuované trasování a sledujte požadavky napříč několika službami a závislostmi. Distribuované cloudové systémy můžete monitorovat prostřednictvím distribuovaného trasování a profileru výkonu.

  • Pro vlastní telemetrii použijte instrumentaci založenou na kódu. Application Insights také podporuje instrumentaci založenou na kódu pro vlastní telemetrii aplikací. Přidejte do kódu Azure Monitor OpenTelemetry Distro.

  • Zapněte protokoly služby App Service pro diagnostiku na úrovni platformy. App Service poskytuje čtyři typy protokolů pro řešení potíží: protokoly aplikací, protokoly webového serveru, podrobné chybové zprávy a trasování neúspěšných požadavků.

  • Používejte strukturované protokolování. Přidejte do kódu aplikace knihovnu strukturovaného protokolování. Aktualizujte kód tak, aby používal páry klíč-hodnota, a zapněte protokoly aplikací ve službě App Service, abyste je uložili do pracovního prostoru služby Log Analytics.

  • Zapněte funkci kontroly stavu služby App Service , abyste zachovali dostupnost. Kontroly stavu detekují instance, které nejsou v pořádku, směrují provoz mimo ně a nahrazují je automaticky. Tato funkce vyžaduje dvě nebo více instancí služby App Service.

Databáze

Efektivita výkonu

Efektivita výkonu odkazuje na schopnost vaší úlohy efektivně škálovat tak, aby splňovala požadavky uživatelů. Další informace naleznete v tématu Kontrola návrhu kontrolní seznam pro zvýšení efektivity výkonu.

Aplikační brána

Aplikační služba

Databáze SQL

Škálování databáze zahrnuje mnoho aspektů nad rámec této architektury. Další informace o škálování služby SQL Database najdete v následujících zdrojích informací:

Další pokyny ke škálovatelnosti

  • Zkontrolujte limity a kvóty předplatného a ujistěte se, že se služby škálují na vyžádání.

  • Pokud chcete zvýšit výkon a škálovatelnost, zvažte ukládání do mezipaměti pro následující typy dat:

    • Polostatická data transakcí
    • Stav relace
    • Komplexní výstup HTML

Další kroky