Podnikové nasazení s využitím Aplikace Azure Service Environment

Tato referenční architektura ukazuje běžnou podnikovou úlohu, která používá App Service Environment verze 3. Popisuje také osvědčené postupy pro posílení zabezpečení úlohy.

Referenční implementace pro tuto architekturu je k dispozici na GitHubu.

Architektura

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

Workflow

App Service Environment verze 3 poskytuje různé funkce než starší verze a výhody oproti těmto verzím. Další informace najdete v tématu Rozdíly mezi funkcemi. App Service Environment můžete nasadit dvěma způsoby:

• Jako externí služba App Service Environment s veřejnou IP adresou
• Jako interní prostředí App Service Environment s interní IP adresou, která patří do interního nástroje pro vyrovnávání zatížení (ILB)

Tato referenční architektura nasadí podnikovou webovou aplikaci do interního prostředí App Service Environment, označovanou také jako App Service Environment s interním nástrojem pro vyrovnávání zatížení. Pokud váš scénář vyžaduje, abyste mohli:

• Hostujte intranetové aplikace s rozšířeným zabezpečením v cloudu a přistupovat k nim prostřednictvím sítě VPN typu site-to-site nebo Azure ExpressRoute.
• Poskytuje vrstvu ochrany aplikací pomocí firewallu webových aplikací (WAF).
• Hostovat v cloudu aplikace, které nejsou uvedené na veřejných serverech DNS
• Vytvářejte internetové izolované back-endové aplikace, se kterými se vaše front-endové aplikace můžou integrovat vysoce bezpečným způsobem.

Služba App Service Environment musí být vždy nasazená ve své vlastní podsíti ve virtuální síti podniku, aby byla povolena úzká kontrola příchozího a odchozího provozu. V rámci této podsítě se aplikace App Service nasazují v jednom nebo několika plánech služby App Service, což je kolekce fyzických prostředků potřebných ke spuštění aplikace. V závislosti na složitosti a požadavku na prostředky je možné plán služby App Service sdílet mezi více aplikacemi. Tato referenční implementace nasadí webovou aplikaci s názvem Voting App, která komunikuje s privátním webovým rozhraním API a funkcí. Nasadí také fiktivní webovou aplikaci s názvem Test App , která demonstruje nasazení s více aplikacemi. Každá aplikace služby App Service je hostovaná ve vlastním plánu služby App Service, což umožňuje, aby se každá aplikace v případě potřeby škálovala nezávisle. Všechny prostředky vyžadované těmito hostovanými aplikacemi, jako jsou úložiště a výpočetní prostředky, a také potřeby škálování jsou plně spravované infrastrukturou služby App Service Environment.

Jednoduchá hlasovací aplikace v této implementaci umožňuje uživatelům zobrazit existující položky, vytvářet nové položky a hlasovat o existujících položkách. Webové rozhraní API se používá k vytváření a načítání položek a hlasů. Samotná data jsou uložená v databázi SQL Serveru. Aby bylo možné předvést asynchronní aktualizace dat, webová aplikace zařadí nově přidané hlasy do instance služby Service Bus. Funkce vybere hlasování ve frontě a aktualizuje databázi SQL. Azure Cosmos DB slouží k ukládání napodobené reklamy, kterou webová aplikace načte, aby se zobrazovala v prohlížeči. Aplikace používá ke správě mezipaměti Azure Cache for Redis. Používá se Azure Cache for Redis úrovně Premium, která umožňuje konfiguraci stejné virtuální sítě jako App Service Environment ve vlastní podsíti. To poskytuje lepší zabezpečení a izolaci mezipaměti.

Webové aplikace jsou jediné komponenty přístupné pro internet přes Application Gateway. Rozhraní API a funkce jsou nepřístupné z internetového klienta. Příchozí provoz je chráněný WAF nakonfigurovaným ve službě Application Gateway.

Součásti

Následující služby jsou klíčem k uzamčení služby App Service Environment v této architektuře:

• Azure Virtual Network je privátní cloudová síť Azure, kterou vlastní podnik. Poskytuje vylepšené zabezpečení a izolaci na základě sítě. App Service Environment je nasazení služby App Service do podsítě virtuální sítě vlastněné podnikem. Umožňuje podniku úzce řídit síťový prostor a prostředky, ke kterým přistupuje pomocí skupin zabezpečení sítě a privátních koncových bodů.

• Application Gateway je nástroj pro vyrovnávání zatížení webového provozu na úrovni aplikace s přesměrováním zpracování TLS/SSL a WAF. Naslouchá veřejné IP adrese a směruje provoz do koncového bodu aplikace ve službě App Service Environment s interním nástrojem pro vyrovnávání zatížení. Vzhledem k tomu, že se jedná o směrování na úrovni aplikace, může směrovat provoz do více aplikací ve stejném prostředí App Service Environment s interním nástrojem pro vyrovnávání zatížení. Další informace najdete v tématu Hostování více webů ve službě Application Gateway.

• Azure Firewall slouží k omezení odchozího provozu z webové aplikace. Odchozí provoz, který neprochází kanály privátního koncového bodu, a směrovací tabulka vyžadovaná službou App Service Environment se přesměruje do podsítě brány firewall. Kvůli jednoduchosti tato architektura konfiguruje všechny privátní koncové body v podsíti služeb.

• Microsoft Entra ID nebo Microsoft Entra ID poskytuje přístupová práva a správu oprávnění pro prostředky a služby Azure. Spravované identity přiřazují identity službám a aplikacím, které automaticky spravuje Microsoft Entra ID. Tyto identity je možné použít k ověření u jakékoli služby, která podporuje ověřování Microsoft Entra. Tím se odebere potřeba explicitně nakonfigurovat přihlašovací údaje pro tyto aplikace. Tato architektura přiřadí webovou aplikaci spravovanou identitu.

• Azure Key Vault ukládá všechny tajné kódy a přihlašovací údaje vyžadované aplikacemi. Tuto možnost použijte při ukládání tajných kódů přímo do aplikace.

• GitHub Actions poskytuje v této architektuře možnosti kontinuální integrace a průběžného nasazování. Vzhledem k tomu, že služba App Service Environment je ve virtuální síti, virtuální počítač se používá jako jumpbox uvnitř virtuální sítě k nasazení aplikací v plánech služby App Service. Akce sestaví aplikace mimo virtuální síť. Pokud chcete zvýšit zabezpečení a bezproblémové připojení RDP/SSH, zvažte použití služby Azure Bastion pro jumpbox.

Konfigurace s více lokalitami

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

Interní prostředí App Service Environment může hostovat několik webových aplikací a rozhraní API s koncovými body HTTP. Tyto aplikace jsou uzamčené z veřejného internetu, protože IP adresa interního nástroje pro vyrovnávání zatížení je přístupná pouze z virtuální sítě. Application Gateway se používá k selektivnímu zveřejnění těchto aplikací na internetu. App Service Environment přiřadí výchozí adresu URL každé aplikaci app Service jako <default-appName>.<app-service-environment-domain>.appserviceenvironment.net. Vytvoří se privátní zóna DNS, která mapuje název domény služby App Service Environment na IP adresu interního nástroje pro vyrovnávání zatížení služby App Service Environment. Tím se zabrání použití vlastního DNS pro přístup k aplikacím ve virtuální síti.

Služba Application Gateway je nakonfigurovaná tak, aby naslouchací proces naslouchal na portu HTTPS pro požadavky na IP adresu brány. Pro zjednodušení tato implementace nepoužívá registraci veřejného názvu DNS. Vyžaduje, abyste v počítači upravili soubor localhost tak, aby odkazovat na libovolně zvolenou adresu URL na IP adresu služby Application Gateway. Pro zjednodušení naslouchací proces tyto žádosti zpracovává certifikát podepsaný svým držitelem. Application Gateway má back-endové fondy pro výchozí adresu URL každé aplikace služby App Service. Pravidlo směrování je nakonfigurováno pro připojení naslouchacího procesu k back-endovému fondu. Vytvoří se nastavení HTTP, které určí, jestli se připojení mezi bránou a službou App Service Environment zašifruje. Tato nastavení slouží také k přepsání hlavičky příchozího hostitele HTTP názvem hostitele vybraným z back-endového fondu. Tato implementace používá výchozí certifikáty vytvořené pro výchozí adresy URL aplikací služby App Service Environment, které brána důvěřuje. Požadavek se přesměruje na výchozí adresu URL odpovídající aplikace. Privátní DNS propojené s virtuální sítí předává tento požadavek IP adrese interního nástroje pro vyrovnávání zatížení. Služba App Service Environment ji pak předá požadované službě App Service. Veškerá komunikace HTTP v aplikacích App Service Environment prochází privátním DNS. Všimněte si, že pro každou aplikaci App Service Environment je potřeba nakonfigurovat naslouchací proces, back-endový fond, pravidlo směrování a nastavení HTTP ve službě Application Gateway.

Projděte si appgw.bicep a dns.bicep a zjistěte, jak se tyto konfigurace provádějí, aby bylo možné povolit více webů. Pojmenovaná webová aplikace je prázdná aplikace testapp vytvořená k předvedení této konfigurace. K těmto souborům JSON se přistupuje ze skriptu nasazení commands_std.azcli. K těmto prostředkům se přistupuje také commands_ha.azcli, který se používá pro nasazení služby App Service Environment s vysokou dostupností na více stránkách.

Podrobnosti scénáře

Aplikace Azure Service je služba PaaS, která slouží k hostování různých aplikací v Azure: webové aplikace, aplikace API, funkce a mobilní aplikace. App Service Environment umožňuje podnikům nasazovat své aplikace App Service do podsítě ve své vlastní virtuální síti Azure, která poskytuje izolované, vysoce škálovatelné a vyhrazené prostředí pro své cloudové úlohy.

Požadavky

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

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 tématu Přehled pilíře zabezpečení.

App Service Environment

Interní prostředí App Service Environment je nasazené ve virtuální síti podniku, která je skrytá před veřejným internetem. Umožňuje podniku uzamknout back-endové služby, jako jsou webová rozhraní API a funkce, na úrovni sítě. K jakékoli aplikaci App Service Environment s koncovým bodem HTTP je možné přistupovat prostřednictvím interního nástroje pro vyrovnávání zatížení v rámci virtuální sítě. Služba Application Gateway je nakonfigurovaná tak, aby předávala požadavky webové aplikaci prostřednictvím interního nástroje pro vyrovnávání zatížení. Samotná webová aplikace prochází interním nástrojem pro vyrovnávání zatížení pro přístup k rozhraní API. Důležité back-endové komponenty, tj. rozhraní API a funkce, jsou prakticky nedostupné z veřejného internetu.

Výchozí certifikáty se vytvoří pro každou službu App Service pro výchozí název domény přiřazený službou App Service Environment. Tento certifikát může zpřísnit zabezpečení provozu mezi bránou a aplikací a může být vyžadován v určitých scénářích. Tyto certifikáty nejsou viditelné prostřednictvím klientského prohlížeče. Může reagovat pouze na certifikáty nakonfigurované ve službě Application Gateway.

Application Gateway

Referenční implementace konfiguruje Application Gateway programově v appgw.bicep. Soubor commands_std.azcli používá tuto konfiguraci při nasazování brány:

az deployment group create --resource-group $RGNAME --template-file templates/appgw.bicep --parameters vnetName=$VNET_NAME appgwSubnetAddressPrefix=$APPGW_PREFIX appgwApplications=@appgwApps.parameters.json
APPGW_PUBLIC_IP=$(az deployment group show -g $RGNAME -n appgw --query properties.outputs.appGwPublicIpAddress.value -o tsv)

Šifrování

Jak je popsáno v přehledu ukončení protokolu TLS a koncového šifrování TLS se službou Application Gateway, služba Application Gateway může k šifrování a ochraně veškerého provozu z webových prohlížečů použít protokol TLS (Transport Layer Security)/SSL (Secure Sockets Layer). Šifrování je možné nakonfigurovat následujícími způsoby:

• Šifrování se ukončilo v bráně. Back-endové fondy jsou v tomto případě nakonfigurované pro protokol HTTP. Šifrování se zastaví na bráně a provoz mezi bránou a službou App Service není zašifrovaný. Vzhledem k tomu, že šifrování je náročné na procesor, nešifrovaný provoz v back-endu zlepšuje výkon a umožňuje jednodušší správu certifikátů. To poskytuje přiměřenou úroveň zabezpečení, protože back-end je zabezpečený na základě konfigurace sítě.

• Kompletní šifrování. V některých scénářích, jako jsou konkrétní požadavky na zabezpečení nebo dodržování předpisů, se může vyžadovat šifrování provozu mezi bránou a aplikací. Toho se dosahuje pomocí připojení HTTPS a konfigurace certifikátů v back-endovém fondu.

Tato referenční implementace používá certifikáty podepsané svým držitelem pro službu Application Gateway. Pro produkční kód by se měl použít certifikát vydaný certifikační autoritou. Seznam podporovaných typů certifikátů najdete v tématu Certifikáty podporované pro ukončení protokolu TLS. Přečtěte si článek Konfigurace aplikační brány s ukončením protokolu TLS pomocí webu Azure Portal a zjistěte, jak vytvořit šifrování ukončené bránou. Následující řádky kódu v appgw.bicep konfiguruje tento programově:

          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
          }
        }]

Referenční implementace ukazuje kompletní šifrování provozu mezi službou Application Gateway a webovými aplikacemi ve službě App Service Environment. Používají se výchozí certifikáty SSL. Back-endové fondy v této implementaci jsou nakonfigurované tak, aby přesměrovaly provoz HTTPS s názvem hostitele přepsáným výchozími názvy domén přidruženými k webovým aplikacím. Application Gateway důvěřuje výchozím certifikátům SSL, protože je vydává Microsoft. Informace o tom, jak se tyto konfigurace provádějí, najdete v tématu Konfigurace služby App Service se službou Application Gateway . Následující kód z appgw.bicep ukazuje, jak se tato konfigurace konfiguruje v referenční implementaci:

        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}'
          }
        }
      }]

Firewall webové aplikace

Firewall webových aplikací (WAF) ve službě Application Gateway chrání webové aplikace před škodlivými útoky, jako je například injektáž SQL. Je také integrovaný se službou Azure Monitor a monitoruje útoky pomocí protokolu v reálném čase. WaF musí být na bráně povolená, jak je popsáno v tématu Vytvoření aplikační brány s firewallem webových aplikací pomocí webu Azure Portal. Referenční implementace umožňuje WAF programově v souboru appgw.bicep s následujícím fragmentem kódu:

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

Virtual Network

Skupiny zabezpečení sítě můžou být přidružené k jedné nebo více podsítím ve virtuální síti. Jedná se o pravidla zabezpečení, která povolují nebo zakazují tok provozu mezi různými prostředky Azure. Tato architektura přidruží pro každou podsíť samostatnou skupinu zabezpečení sítě. To umožňuje jemně doladit tato pravidla na podsíť podle služeb obsažených v této podsíti. Podívejte se například na konfiguraci "type": "Microsoft.Network/networkSecurityGroups" v souboru ase.bicep pro skupinu zabezpečení sítě pro podsíť služby App Service Environment a v souboru appgw.bicep pro skupinu zabezpečení sítě pro podsíť služby Application Gateway.

Privátní koncové body umožňují privátní připojení mezi klienty a službami Azure v privátní síti s rozšířeným zabezpečením. Poskytují soukromě přístupnou IP adresu pro službu Azure, která umožňuje provoz rozšířeného zabezpečení do prostředku Azure Private Link. Platforma ověřuje síťová připojení a umožňuje pouze ty, které se připojují k zadanému prostředku Private Link. Privátní koncové body podporují síťové zásady, jako jsou skupiny zabezpečení sítě, trasy definované uživatelem a skupiny zabezpečení aplikací. Pokud chcete zlepšit zabezpečení, měli byste povolit privátní koncové body pro jakoukoli službu Azure, která je podporuje. Zabezpečení služby ve virtuální síti pak můžete zlepšit zakázáním veřejného přístupu a efektivním blokováním přístupu z veřejného internetu. Tato architektura konfiguruje privátní koncové body pro služby, které ji podporují: Azure Service Bus, SQL Server, Key Vault a Azure Cosmos DB. Konfiguraci můžete zobrazit v privatendpoints.bicep.

Pokud chcete povolit privátní koncové body, musíte také nakonfigurovat privátní zóny DNS. Další informace najdete v tématu Konfigurace DNS privátního koncového bodu Azure.

Brána firewall

Azure Firewall a privátní koncové body se vzájemně doplňují. Privátní koncové body pomáhají chránit prostředky tím, že umožňují pouze provoz pocházející z vaší virtuální sítě. Azure Firewall umožňuje omezit odchozí provoz z vašich aplikací. Doporučujeme povolit průchod veškerého odchozího provozu přes podsíť brány firewall, včetně provozu privátního koncového bodu. To umožňuje lepší monitorování odchozího provozu. Kvůli jednoduchosti tato referenční architektura konfiguruje všechny privátní koncové body v podsíti služeb místo v podsíti brány firewall.

Informace o integraci služby Azure Firewall se službou App Service Environment najdete v tématu Konfigurace služby Azure Firewall pomocí služby App Service Environment. Veškerý provoz, který neprochází privátními koncovými body a směrovací tabulkou virtuální sítě, se monitoruje a hradí bránou firewall.

Microsoft Entra ID

Microsoft Entra ID poskytuje funkce zabezpečení pro ověřování aplikací a autorizaci přístupu k prostředkům. Tato referenční architektura používá dvě klíčové funkce Microsoft Entra ID: spravované identity a řízení přístupu na základě role v Azure.

V cloudových aplikacích musí být přihlašovací údaje potřebné k ověření v cloudových službách zabezpečené. V ideálním případě by se přihlašovací údaje nikdy neměly zobrazovat na vývojářských pracovních stanicích ani by se neměly vrátit se změnami do správy zdrojového kódu. Azure Key Vault nabízí způsob bezpečného ukládání přihlašovacích údajů a tajných kódů, ale aplikace se stále musí ověřit ve službě Key Vault, aby je načetla. Spravované identity pro prostředky Azure poskytují službám Azure automaticky spravovanou identitu v Microsoft Entra ID. Tuto identitu je možné použít k ověření u jakékoli služby, která podporuje ověřování Microsoft Entra, včetně služby Key Vault, bez jakýchkoli přihlašovacích údajů v aplikaci.

Řízení přístupu na základě role v Azure (Azure RBAC) spravuje přístup k prostředkům Azure. Sem patří:

• Která entita má přístup: uživatel, spravovaná identita, objekt zabezpečení.
• Jaký typ přístupu má: vlastník, přispěvatel, čtenář, správce.
• Rozsah přístupu: prostředek, skupina prostředků, předplatné nebo skupina pro správu.

Přístup k aplikacím App Service Environment můžete uzamknout tak, že přísně řídíte požadovanou roli a typ přístupu pro každou aplikaci. Tímto způsobem je možné nasadit více aplikací ve stejném prostředí App Service Environment z různých vývojových týmů. Front-end může například zpracovat jeden tým a back-end jiný. Azure RBAC je možné použít k omezení přístupu jednotlivých týmů k aplikacím, na nichž pracuje. Prozkoumejte vlastní role Azure a vytvořte role vhodné pro vaši organizaci.

Key Vault

Některé služby podporují spravované identity, ale k nastavení oprávnění pro aplikaci používají Azure RBAC. Podívejte se například na předdefinované role Service Bus a Azure RBAC ve službě Azure Cosmos DB. K udělení těchto oprávnění se vyžaduje přístup vlastníka k předplatnému, i když pracovníci s přístupem přispěvatele mohou tyto služby nasadit. Pokud chcete širšímu týmu vývojářů umožnit spouštění skriptů nasazení, je nejlepší volbou použít nativní zásady řízení přístupu služby:

• Pro Service Bus se jedná o sdílené přístupové podpisy.
• Pro Službu Azure Cosmos DB se jedná o klíče.

Připojovací řetězec pro tyto zásady řízení přístupu se pak uloží ve službě Key Vault. K samotnému trezoru se přistupuje prostřednictvím spravovaných identit, které vyžadují Azure RBAC. Nastavte zásady přístupu pro tyto připojovací řetězec odpovídajícím způsobem. Například pro back-end, jen pro zápis pro front-end atd., místo použití výchozích zásad kořenového přístupu.

Následující kód v services.bicep ukazuje konfiguraci služby Key Vault pro tyto služby:

      resource keyVaultName_CosmosKey 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'CosmosKey'
      properties: {
        value: cosmosName.listKeys().primaryMasterKey 
      }
    }

      resource keyVaultName_ServiceBusListenerConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusListenerConnectionString'
      properties: {
        value: listKeys(serviceBusName_ListenerSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

      resource keyVaultName_ServiceBusSenderConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusSenderConnectionString'
      properties: {
        value: listKeys(serviceBusName_SenderSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

Tyto připojovací řetězec hodnoty jsou přístupné aplikacím, které odkazují na dvojici klíč/hodnota služby Key Vault. To se provádí v souboru sites.bicep , jak ukazuje následující kód hlasovací aplikace:

  properties: {
    enabled: true
    hostingEnvironmentProfile: {
      id:aseId
    }
    serverFarmId: votingWebPlanName.id
    siteConfig: {
      appSettings: [
        {
          name: 'ConnectionStrings:sbConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, serviceBusSenderConnectionStringSecretName), '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:RedisConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(keyVaultName_redisSecretName.id, '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:CosmosKey'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, cosmosKeySecretName), '2022-07-01').secretUriWithVersion})'
        }
      ]
    }
  }

Funkce také přistupuje k naslouchacímu procesu služby Service Bus připojovací řetězec podobným způsobem.

Škálovatelnost

Návrh škálovatelných aplikací

Aplikace v této referenční architektuře je strukturovaná tak, aby bylo možné škálovat jednotlivé komponenty na základě využití. Každá webová aplikace, rozhraní API a funkce se nasadí ve vlastním plánu služby App Service. V případě potřeby můžete monitorovat každou aplikaci a v případě potřeby ji vertikálně navýšit .

Automatické škálování služby Application Gateway

Automatické škálování je možné povolit na Aplikace Azure Gateway V2. To umožňuje službě Application Gateway vertikálně navýšit nebo snížit kapacitu na základě vzorců zatížení provozu. Tato referenční architektura konfiguruje autoscaleConfiguration v souboru appgw.bicep škálování mezi nulou a 10 dalšími instancemi. Další podrobnosti najdete v tématu Škálování služby Application Gateway a WAF v2 .

Nasazení

Skripty nasazení v této referenční architektuře slouží k nasazení služby App Service Environment, dalších služeb a aplikací uvnitř služby App Service Environment. Po nasazení těchto aplikací můžou podniky chtít mít plán pro kontinuální integraci a nasazování pro údržbu a upgrady aplikací. Tato část ukazuje některé běžné způsoby, jak vývojáři používají CI/CD aplikací App Service Environment.

Aplikace je možné nasadit do interní služby App Service Environment pouze z virtuální sítě. K nasazení aplikací App Service Environment se běžně používají následující tři metody:

• Ručně uvnitř virtuální sítě: Vytvořte virtuální počítač ve virtuální síti App Service Environment s požadovanými nástroji pro nasazení. Otevřete připojení RDP k virtuálnímu počítači pomocí konfigurace NSG. Zkopírujte artefakty kódu do virtuálního počítače, sestavte a nasaďte do podsítě služby App Service Environment. Jedná se o jednoduchý způsob nastavení počátečního vývojového prostředí sestavení a testování. Nedoporučuje se ale pro produkční prostředí, protože nemůže škálovat požadovanou propustnost nasazení.

• Připojení typu point-to-site z místní pracovní stanice: To umožňuje rozšířit virtuální síť služby App Service Environment na váš vývojový počítač a nasadit je odtud. Toto je další způsob, jak nastavit počáteční vývojové prostředí a nedoporučuje se pro produkční prostředí.

• Prostřednictvím Azure Pipelines: Implementuje se kompletní kanál CI/CD, který končí agentem umístěným ve virtuální síti. To je ideální pro produkční prostředí vyžadující vysokou propustnost nasazení. Kanál buildu zůstává zcela mimo virtuální síť. Kanál nasazení zkopíruje vytvořené objekty do agenta sestavení ve virtuální síti a pak se nasadí do podsítě služby App Service Environment. Další informace najdete v této diskuzi o místním agentu sestavení mezi kanály a virtuální sítí App Service Environment.

Použití Azure Pipelines se doporučuje pro produkční prostředí. Skriptování CI/CD pomocí schématu YAML služby Azure Pipelines pomáhá automatizovat procesy sestavení a nasazení. Azure-pipelines.yml implementuje takový kanál CI/CD pro webovou aplikaci v této referenční implementaci. Existují podobné skripty CI/CD pro webové rozhraní API i funkci. Přečtěte si, jak se používají k automatizaci CI/CD pro každou aplikaci pomocí Azure Pipelines .

Některé podniky nemusí chtít udržovat trvalé agenta sestavení ve virtuální síti. V takovém případě můžete vytvořit agenta sestavení v rámci kanálu DevOps a po dokončení nasazení ho vytrhnout. Tím se v DevOps přidá další krok, ale snižuje složitost údržby virtuálního počítače. Můžete dokonce zvážit použití kontejnerů jako agentů sestavení místo virtuálních počítačů. Agenti sestavení se také můžou úplně vyhnout nasazením z komprimovaného souboru umístěného mimo virtuální síť, obvykle v účtu úložiště. Účet úložiště bude muset být přístupný ze služby App Service Environment. Kanál by měl mít přístup k úložišti. Na konci kanálu verze je možné zazipovaný soubor převést do úložiště objektů blob. App Service Environment ji pak může vyzvednout a nasadit. Mějte na paměti následující omezení tohoto přístupu:

• Mezi DevOps a skutečným procesem nasazení existuje odpojení, což vede k potížím při monitorování a trasování jakýchkoli problémů s nasazením.
• V uzamčeném prostředí se zabezpečeným provozem možná budete muset změnit pravidla pro přístup k zazipovanému souboru v úložišti.
• Abyste mohli nasadit soubor ZIP, budete muset do služby App Service Environment nainstalovat konkrétní rozšíření a nástroje.

Další způsoby nasazení aplikací do plánů služby App Service najdete v článcích služby App Service se zaměřením na strategie nasazení.

Optimalizace nákladů

K odhadu nákladů použijte cenovou kalkulačku Azure. Další aspekty jsou popsané v části Náklady v architektuře Microsoft Azure Well-Architected Framework. Rezervace Azure umožňují šetřit peníze tím, že potvrzují závazek využívání řady prostředků Azure v rámci plánů na jeden nebo tři roky. Další informace najdete v článku Nákup rezervace.

Tady je několik bodů, které je potřeba zvážit u některých klíčových služeb používaných v této architektuře.

App Service Environment v3

App Service nabízí různé cenové možnosti. Služba App Service Environment se nasadí pomocí plánu izolované služby v2. V rámci tohoto plánu existuje několik možností pro velikosti procesoru od I1v2 do I6v2. Tato referenční implementace používá tři I1v2s na instanci.

Application Gateway

Ceny služby Application Gateway poskytují různé cenové možnosti. Tato implementace používá skladovou položku Application Gateway Standard v2 a WAF v2, která podporuje automatické škálování a redundanci zón. Další informace o cenovém modelu použitém pro tuto skladovou položku najdete v tématu Škálování služby Application Gateway v2 a WAF v2 .

Azure Cache for Redis

Ceny služby Azure Cache for Redis poskytují různé cenové možnosti pro tuto službu. Tato architektura používá skladovou položku Premium pro podporu virtuální sítě.

Níže jsou uvedené cenové stránky pro jiné služby, které slouží k uzamčení služby App Service Environment:

• Ceny služby Azure Firewall

• Ceny služby Key Vault

• Ceny Microsoft Entra

Nasazení tohoto scénáře

Pokud chcete nasadit referenční implementaci pro tuto architekturu, přečtěte si soubor readme GitHubu a postupujte podle skriptu pro standardní nasazení.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

• Dhanashri Kshirsagar | Hlavní projekt obsahu

Další přispěvatelé:

• Deep Bhattacharya | Architekt cloudového řešení
• Suhas Rao | Architekt cloudového řešení

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

• Spuštění aplikace ve službě Aplikace Azure Service přímo z balíčku ZIP
• Schéma YAML ve službě Azure Pipelines
• Získání adres pro správu z rozhraní API
• Azure Key Vault
• Azure Pipelines

Související prostředky

Pokud chcete zjistit, jak tuto architekturu rozšířit tak, aby podporovala vysokou dostupnost, přečtěte si nasazení aplikace s vysokou dostupností pomocí služby App Services Environment.