Företagsdistribution som använder App Service Environment

Den här referensarkitekturen visar en vanlig företagsarbetsbelastning som använder App Service-miljön version 3. Den beskriver också metodtips för att stärka säkerheten för arbetsbelastningen.

Architecture

Ladda ned en Visio-fil med den här arkitekturen.

En referensimplementering för den här arkitekturen finns på GitHub.

Arbetsflöde

Du kan distribuera App Service-miljön på två sätt:

• Som en extern App Service-miljö som har en offentlig IP-adress

• Som en intern App Service-miljö som har en intern IP-adress som tillhör en intern lastbalanserare (ILB)

Den här referensarkitekturen distribuerar ett företagswebbprogram i en intern App Service-miljö, även kallad en ILB App Service-miljö. Använd en ILB App Service-miljö i scenarier som kräver följande funktioner:

• Värdhantera intranätprogram med förbättrad säkerhet i molnet och få åtkomst till dem via ett plats-till-plats-VPN eller Azure ExpressRoute.

• Ange ett skyddslager för appar med hjälp av en brandvägg för webbprogram (WAF).

• Värdappar i molnet som inte visas i offentliga DNS-servrar (Domain Name System).

• Skapa internetisolerade serverdelsappar som klientdelsappar kan integreras med på ett mycket säkert sätt.

Distribuera alltid en App Service-miljö i ett eget undernät i det virtuella företagsnätverket. Den här metoden upprätthåller strikt kontroll över inkommande och utgående trafik. I det här undernätet körs Azure App Service-program i en eller flera App Service-planer, som är samlingar med fysiska resurser som krävs för att köra appen. Beroende på komplexiteten och resurskravet kan flera appar dela en App Service-plan. App Service Environment-infrastrukturen hanterar alla resurser som dessa värdbaserade appar kräver, inklusive lagring, beräkning och skalning.

Den här referensimplementeringen distribuerar en webbapp med namnet Voting App, som interagerar med ett privat webb-API och en funktion. Den distribuerar också en falsk webbapp med namnet Test App för att demonstrera distributioner med flera appar. I referensimplementeringen körs varje App Service-app i en egen App Service-plan, vilket möjliggör oberoende skalning vid behov.

Med den enkla röstningsappen i den här implementeringen kan användarna visa befintliga poster, skapa nya poster och rösta på befintliga poster. Webb-API:et skapar och hämtar poster och röster. Data lagras i en Azure SQL-databas. För att demonstrera asynkrona datauppdateringar köar webbappen nyligen tillagda röster i en Azure Service Bus-instans. Funktionen hämtar röster i kö och uppdaterar SQL-databasen. Azure Cosmos DB lagrar en modellannons som webbappen hämtar för visning i webbläsaren. Programmet använder Azure Cache for Redis för cachehantering. Azure Cache for Redis på Premium-nivå konfigureras i samma virtuella nätverk som App Service Environment och körs i ett eget undernät. Den här konfigurationen ger förbättrad säkerhet och isolering för cacheminnet.

Webbapparna är de enda komponenter som kan nås från Internet. Internettrafik måste komma via Azure Application Gateway, som är skyddad med en WAF. En Internetklient kan inte komma åt API:et eller funktionsappen.

Components

Följande tjänster hjälper till att skydda App Service-miljön i den här arkitekturen:

• Azure Virtual Network tillhandahåller ett privat Azure-molnnätverk som företaget äger. Det ger förbättrad nätverksbaserad säkerhet och isolering. Den här arkitekturen distribuerar en App Service-miljö till ett undernät i det företagsägda virtuella nätverket. Med App Service Environment kan företaget noggrant kontrollera det nätverksutrymmet och de resurser som det kommer åt med hjälp av nätverkssäkerhetsgrupper (NSG:er) och privata slutpunkter.

• Application Gateway är en lastbalanserare för webbtrafik på programnivå som har avlastning av Transport Layer Security (TLS) eller Secure Sockets Layer (SSL) och en WAF. I den här arkitekturen accepterar Application Gateway inkommande trafik på en offentlig IP-adress och dirigerar den till programslutpunkten i ILB App Service-miljön. Den här routningen på programnivå kan dirigera trafik till flera appar i samma ILB App Service-miljö. Mer information finns i Application Gateway-värdtjänster för flera platser.

• Azure Firewall är en molnbaserad, tillståndskänslig brandväggstjänst som är inbyggd i Azure. Det ger hög tillgänglighet och obegränsad skalbarhet i molnet och stöder både regler för inkommande och utgående filtrering. I den här arkitekturen begränsar Azure Firewall utgående trafik från webbprogrammet. En routningstabell är konfigurerad för att dirigera utgående trafik som inte går via de privata slutpunktskanalerna till brandväggen. För enkelhetens skull konfigurerar den här arkitekturen alla privata slutpunkter i tjänstundernätet.

• Microsoft Entra-ID ger åtkomsträttigheter och behörighetshantering till Azure-resurser och -tjänster. Hanterade identiteter tilldelar identiteter till tjänster och appar. De kan autentisera till alla tjänster som stöder Microsoft Entra-autentisering. Den här metoden tar bort behovet av att uttryckligen konfigurera autentiseringsuppgifter för dessa appar. Den här arkitekturen tilldelar en hanterad identitet till webbappen.

• Azure Key Vault är en molntjänst som lagrar och hanterar känslig information på ett säkert sätt, till exempel hemligheter, krypteringsnycklar och certifikat. Den här arkitekturen använder Key Vault för att lagra hemligheter och autentiseringsuppgifter som krävs för apparna. Använd det här alternativet i stället för att lagra hemligheter direkt i programmet.

• GitHub Actions är en arbetsflödesautomatiseringsfunktion inbyggd i GitHub som möjliggör CI/CD. I den här arkitekturen finns App Service Environment i det virtuella nätverket, så en virtuell dator fungerar som en jumpbox i det virtuella nätverket för att distribuera appar i App Service-planerna. Åtgärden skapar apparna utanför det virtuella nätverket. Överväg att använda Azure Bastion för jumpboxen för förbättrad säkerhet och sömlös anslutning med RDP (Remote Desktop Protocol) och Secure Shell (SSH).

Konfiguration av flera platser

En intern App Service-miljö kan vara värd för flera webbappar och API:er som har HTTP-slutpunkter. Dessa program exponeras inte för det offentliga Internet eftersom IP-adressen för ILB endast kan nås inifrån det virtuella nätverket. Application Gateway exponerar selektivt dessa program för Internet. App Service Environment tilldelar en standard-URL till varje App Service-program som <default-appName>.<app-service-environment-domain>.appserviceenvironment.net. En privat DNS-zon skapas som mappar App Service-miljön domännamnet till ip-adressen för App Service-miljön ILB. Den här metoden undviker anpassad DNS för appåtkomst i det virtuella nätverket.

Application Gateway har konfigurerats för att inkludera en lyssnare som accepterar HTTP-begäranden på gatewayens IP-adress. För enkelhetens skull använder den här implementeringen inte någon offentlig DNS-namnregistrering. Du måste ändra localhost-filen på datorn så att den pekar en godtyckligt vald URL till Application Gateway IP-adressen. Lyssnaren använder ett självsignerat certifikat för att bearbeta dessa begäranden. Application Gateway har serverdelspooler för varje App Service-programs standard-URL. En routningsregel har konfigurerats för att ansluta lyssnaren till serverdelspoolen. HTTP-inställningar avgör om anslutningen mellan gatewayen och App Service Environment använder kryptering. De här inställningarna åsidosätter även den inkommande HTTP-värdrubriken med ett värdnamn från serverdelspoolen. Den här implementeringen använder standardcertifikat som skapats för app-URL:er för App Service Environment och gatewayen litar på dessa certifikat. Begäran omdirigeras till standard-URL:en för motsvarande app. Den privata DNS som är länkad till det virtuella nätverket vidarebefordrar denna begäran till IP-adressen för ILB. App Service-miljön vidarebefordrar sedan begäran till den begärda apptjänsten. All HTTP-kommunikation i App Service Environment-apparna går via privat DNS. Du måste konfigurera lyssnaren, serverdelspoolen, routningsregeln och HTTP-inställningarna på programgatewayen för varje App Service Environment-app.

Granska filerna appgw.bicep och dns.bicep för att lära dig hur dessa konfigurationer tillåter flera platser. Webbappen med namnet testapp är en tom app som skapats för att demonstrera den här konfigurationen. Distributionsskriptet commands_std.azcli kommer åt JSON-filerna. Och commands_ha.azcli-skriptet använder samma filer för en apptjänstmiljödistribution med hög tillgänglighet.

Scenarioinformation

App Service är en PaaS-lösning (plattform som en tjänst) som är värd för olika appar i Azure, inklusive webbappar, API-appar, funktioner och mobilappar. Du kan använda App Service Environment för att distribuera App Service-appar i ett undernät i ditt eget virtuella Azure-nätverk. Den här metoden ger en isolerad, mycket skalbar och dedikerad miljö för molnarbetsbelastningar.

Överväganden

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som du kan använda för att förbättra kvaliteten på en arbetsbelastning. Mer information finns iWell-Architected Framework.

Security

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Checklista för designgranskning för säkerhet.

Tjänstemiljö för appar

En intern App Service-miljö finns i det virtuella företagsnätverket och är dold från det offentliga Internet. Det gör att du kan skydda serverdelstjänster, till exempel webb-API:er och funktioner, på nätverksnivå. Alla App Service Environment-appar som har en HTTP-slutpunkt kan nås via ILB inifrån det virtuella nätverket. Application Gateway vidarebefordrar begäranden till webbappen via ILB. Själva webbappen går via ILB för att komma åt API:et. Viktiga serverdelskomponenter, till exempel API:et och funktionen, kan inte nås från det offentliga Internet.

App Service-miljön tilldelar ett standarddomännamn till varje apptjänst och skapar automatiskt ett standardcertifikat för varje domännamn. Det här certifikatet hjälper till att skydda trafiken mellan gatewayen och appen och kan krävas i vissa scenarier. Standardcertifikatet visas inte i klientwebbläsaren och svarar bara på certifikatet som konfigurerats på Application Gateway.

Application Gateway

Application Gateway kan använda TLS eller SSL för att kryptera och skydda all trafik från webbläsare. Du kan konfigurera kryptering på två sätt:

• Krypteringen avslutades vid gatewayen: För den här metoden konfigureras serverdelspoolerna för HTTP. Krypteringen stoppas vid gatewayen och trafiken mellan gatewayen och App Service är okrypterad. Krypteringen är processorintensiv, så okrypterad trafik på serverdelen förbättrar prestandan och möjliggör enklare certifikathantering. Den här metoden ger måttlig säkerhet eftersom nätverkskonfigurationen skyddar serverdelen.

• Kryptering från slutpunkt till slutpunkt: I vissa scenarier som har specifika säkerhetskrav eller efterlevnadskrav kan trafiken behöva krypteras mellan gatewayen och appen. Den här konfigurationen använder HTTPS-anslutningar och kräver certifikat i serverdelspoolen.

Den här referensimplementeringen använder självsignerade certifikat för Application Gateway. För produktionskod använder du ett certifikat som utfärdats av en certifikatutfärdare (CA).

• En lista över certifikattyper som stöds finns i Certifikat som stöds för TLS-avslutning.
• Information om hur du skapar gateway-avslutad kryptering finns i Konfigurera en programgateway med TLS-avslutning med hjälp av Azure-portalen.

Följande exempel från appgw.bicep konfigurerar HTTP-lyssnare programmatiskt.

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

Referensimplementeringen visar kryptering från slutpunkt till slutpunkt för trafik mellan Application Gateway och webbapparna i App Service-miljön. Den använder standard-SSL-certifikaten. Serverdelspoolerna i den här implementeringen är konfigurerade för att omdirigera HTTPS-trafik. De åsidosätter också värdnamnet med de standarddomännamn som är associerade med webbapparna. Application Gateway litar på standard-SSL-certifikaten eftersom Microsoft utfärdar dem. Mer information finns i Konfigurera App Service med hjälp av Application Gateway. Följande exempel visar appgw.bicep hur referensimplementeringen konfigurerar den här metoden.

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

Brandvägg för webbaserade program

Brandväggen för webbaserade program på Application Gateway skyddar webbapparna mot skadliga attacker, till exempel SQL-inmatning. Den integreras också med Azure Monitor för att övervaka attacker med hjälp av en realtidslogg. Om du vill aktivera brandväggen för webbaserade program måste du konfigurera gatewayen så att den uppfyller dess krav. Referensimplementeringen aktiverar WAF programmatiskt i appgw.bicep filen med hjälp av följande kod.

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

Virtual Network

Du kan associera NSG:er med ett eller flera undernät i det virtuella nätverket. Dessa grupper definierar säkerhetsregler som tillåter eller nekar trafik att flöda mellan olika Azure-resurser. Den här arkitekturen associerar en separat NSG för varje undernät, vilket möjliggör finjusterade regler baserat på tjänsterna i undernätet.

• Konfigurationen för NSG för App Service Environment-undernätet finns i filen ase.bicep.

• Konfigurationen för NSG för Application Gateway-undernätet finns i filen appgw.bicep.

Båda konfigurationerna använder resursen "type": "Microsoft.Network/networkSecurityGroups".

Privata slutpunkter möjliggör förbättrad privat anslutning mellan klienter och Azure-tjänster via ett privat nätverk. De tillhandahåller en privat åtkomst-IP-adress för Azure-tjänsten, som möjliggör förbättrad säkerhetstrafik till en Azure Private Link-resurs. Plattformen validerar nätverksanslutningar och tillåter endast anslutningar som riktar sig mot den angivna Private Link-resursen.

Privata slutpunkter stöder nätverksprinciper, till exempel NSG:er, användardefinierade vägar och programsäkerhetsgrupper. För att förbättra säkerheten aktiverar du privata slutpunkter för alla Azure-tjänster som stöder dem. Om du vill skydda tjänsten i det virtuella nätverket inaktiverar du offentlig åtkomst för att blockera åtkomst från det offentliga Internet. Den här arkitekturen konfigurerar privata slutpunkter för de tjänster som stöder den, inklusive Azure Service Bus, SQL Database, Key Vault och Azure Cosmos DB. Du kan se konfigurationen i privatendpoints.bicep.

Om du vill aktivera privata slutpunkter måste du också konfigurera privata DNS-zoner. Mer information finns i DNS-konfiguration för privata Slutpunkter i Azure.

Azure Firewall

Azure Firewall och privata slutpunkter kompletterar varandra. Privata slutpunkter hjälper till att skydda resurser genom att endast tillåta trafik som kommer från ditt virtuella nätverk. Med Azure Firewall kan du begränsa utgående trafik från dina program. Vi rekommenderar att du tillåter att all utgående trafik passerar genom brandväggens undernät, inklusive privat slutpunktstrafik. Den här metoden möjliggör bättre övervakning av utgående trafik. För enkelhetens skull konfigurerar den här referensarkitekturen alla privata slutpunkter i tjänstundernätet i stället för brandväggsundernätet.

Mer information finns i Konfigurera Azure Firewall med din App Service-miljö. Brandväggen övervakar och styr trafik som inte passerar de privata slutpunkterna och routningstabellen för virtuella nätverk.

Microsoft Entra ID

Microsoft Entra ID tillhandahåller säkerhetsfunktioner för att autentisera program och auktorisera åtkomst till resurser. Den här referensarkitekturen använder två viktiga funktioner i Microsoft Entra-ID, hanterade identiteter och rollbaserad åtkomstkontroll i Azure (RBAC).

I molnprogram måste du skydda de autentiseringsuppgifter som krävs för att autentisera till molntjänster. Helst bör autentiseringsuppgifterna aldrig visas på utvecklararbetsstationer eller i källkontrollen. Key Vault lagrar autentiseringsuppgifter och hemligheter på ett säkert sätt, men appen måste fortfarande autentisera till Key Vault för att hämta dem. Hanterade identiteter för Azure-resurser tillhandahåller Azure-tjänster med en automatiskt hanterad identitet i Microsoft Entra-ID. Du kan använda den här identiteten för att autentisera till alla tjänster som stöder Microsoft Entra-autentisering, inklusive Key Vault, utan några autentiseringsuppgifter i programmet.

Azure RBAC hanterar åtkomsten till Azure-resurser genom att definiera följande villkor:

• Vilken entitet har åtkomst, till exempel användare, hanterad identitet eller säkerhetsobjekt

• Vilken typ av åtkomst den har, till exempel ägare, deltagare, läsare eller administratör

• Åtkomstomfånget, till exempel resurs, resursgrupp, prenumeration eller hanteringsgrupp

Du kan skydda åtkomsten till App Service Environment-program genom att noggrant kontrollera den roll som krävs och typen av åtkomst för varje app. Med den här metoden kan flera appar distribueras i samma App Service-miljö från olika utvecklingsteam. Ett team kan till exempel hantera klientdelen och ett team kan hantera serverdelen. Azure RBAC kan begränsa varje teams åtkomst till de appar som de arbetar med. Information om hur du skapar roller som passar din organisation finns i Anpassade Azure-roller.

Nyckelvalv

Vissa tjänster stöder hanterade identiteter och använder Azure RBAC för att konfigurera behörigheter för appen. Se till exempel de inbyggda Service Bus-rollerna och Azure RBAC i Azure Cosmos DB. Du måste ha administratörsbehörighet för användaråtkomst till prenumerationen för att bevilja dessa behörigheter. Deltagarrollen kan distribuera dessa tjänster. Om du vill att ett bredare team av utvecklare ska kunna köra distributionsskripten kan du använda den interna åtkomstkontroll som varje tjänst tillhandahåller.

• Använd signaturer för delad åtkomst för Service Bus.

• För Azure Cosmos DB använder du nycklar.

Om arbetsbelastningen behöver tjänstbaserad åtkomst bör du lagra dessa i förväg delade hemligheter i Key Vault. Få åtkomst till valvet via webbprogrammets hanterade identitet.

Appar får åtkomst till hemligheter som lagras i Key Vault. De refererar till nyckel- och värdeparet Key Vault. Den här konfigurationen definieras i filen sites.bicep . Röstningsappen använder följande kod.

properties: {
  enabled: true
  hostingEnvironmentProfile: {
    id: aseId
  }
  serverFarmId: votingWebPlanName.id
  siteConfig: {
    appSettings: [
      {
        name: 'ASecret'
        value: '@Microsoft.KeyVault(SecretUri=${applicationKeyVault::secretName.secretUriWithVersion})'
      }
    ]
  }
}

Kostnadsoptimering

Kostnadsoptimering fokuserar på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Checklista för designgranskning för kostnadsoptimering.

Använd Priskalkylatorn för Azure för att beräkna kostnader. Mer information finns i grundpelare för kostnadsoptimering i Well-Architected Framework. För att spara pengar tillhandahåller Azure-reservationer ett- eller treårsplaner för många Azure-resurser.

Tänk på följande kostnadsfaktorer för vissa viktiga tjänster i den här arkitekturen.

App Service-miljön v3

App Service har olika prisalternativ. En App Service-miljö distribueras via den isolerade v2-tjänstplanen. Den här planen innehåller flera alternativ för CPU-storlekar, från I1v2 till I6v2. Den här referensimplementeringen använder tre I1v2-instanser.

Application Gateway

Application Gateway har olika prisalternativ. Den här implementeringen använder SKU:n Application Gateway Standard v2 och Web Application Firewall v2, som stöder automatisk skalning och zonredundans. Mer information finns i Skala Application Gateway v2 och Brandvägg för webbprogram v2.

Azure-cache för Redis

Azure Cache for Redis har olika prisalternativ. Den här arkitekturen använder Premium SKU för stöd för virtuella nätverk.

Andra beroenden

Andra tjänster som hjälper till att skydda App Service-miljön har också flera prisalternativ:

• Prissättning för Azure Firewall
• Priser för Key Vault
• Priser för Microsoft Entra

Operativ skicklighet

Operational Excellence omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Checklista för designgranskning för Operational Excellence.

Distributionsskripten i den här referensarkitekturen distribuerar App Service Environment, andra tjänster och programmen i App Service Environment. När dessa program har distribuerats kan företaget planera för CI/CD för appunderhåll och uppgraderingar. I det här avsnittet beskrivs vanliga metoder som utvecklare använder för CI/CD för App Service Environment-program.

Du kan bara distribuera appar till en intern App Service-miljö inifrån det virtuella nätverket. Använd någon av följande metoder för att distribuera App Service Environment-appar:

• Använd en virtuell dator i det virtuella nätverket. Skapa en virtuell dator i det virtuella App Service Environment-nätverket med hjälp av de verktyg som krävs för distribution. Om du vill öppna RDP-anslutningen till den virtuella datorn använder du en NSG-konfiguration. Kopiera dina kodartefakter till den virtuella datorn, skapa och distribuera till App Service-miljön undernätet. Den här metoden fungerar bra för att konfigurera en inledande bygg- och testutvecklingsmiljö. Använd inte den här metoden för en produktionsmiljö eftersom den inte kan skalas för att matcha det nödvändiga distributionsdataflödet.

• Använd en punkt-till-plats-VPN-anslutning från en lokal arbetsstation. Utöka ditt virtuella App Service Environment-nätverk till utvecklingsdatorn. Distribuera från din lokala arbetsstation. Den här metoden fungerar också bra för en inledande utvecklingsmiljö men passar inte för en produktionsmiljö.

• Använd Azure Pipelines. Implementera en fullständig CI/CD-pipeline som slutar i en agent som finns i det virtuella nätverket. Den här metoden passar produktionsmiljöer som kräver högt dataflöde för distribution. Bygg-pipelinen förblir helt utanför det virtuella nätverket. Distributionspipelinen kopierar de skapade objekten till byggagenten i det virtuella nätverket och distribueras sedan till App Service Environment-undernätet. Mer information finns i Lokal byggagent mellan Azure Pipelines och det virtuella nätverket App Service Environment.

Vi rekommenderar att du använder Azure Pipelines eller något annat CI/CD-verktyg för produktionsmiljöer. Om du vill automatisera bygg- och distributionsprocesserna skriver du CI/CD med hjälp av AZURE Pipelines YAML-schemat. Den azure-pipelines.yml-filen implementerar en sådan CI/CD-pipeline för webbappen i den här referensimplementeringen. Liknande CI/CD-skript stöder webb-API :et och funktionen. Mer information om hur dessa verktyg hjälper till att automatisera CI/CD för varje program finns i Använda Azure Pipelines.

Vissa företag kanske inte vill ha en permanent byggagent i det virtuella nätverket. I så fall bör du överväga något av följande alternativ:

• Skapa en byggagent dynamiskt: Skapa en byggagent i DevOps-pipelinen och ta bort den när distributionen är klar. Den här metoden lägger till ytterligare ett steg för DevOps men förenklar underhåll av virtuella datorer.

• Behållare: Använd containrar som byggagenter i stället för virtuella datorer.

• Distribuera utan en agent: Undvik att skapa agenter helt genom att distribuera från en zippad fil som placeras utanför det virtuella nätverket, vanligtvis i ett lagringskonto. App Service-miljön och pipelinen måste ha åtkomst till lagringskontot. Slutet av versionspipelinen kan släppa en zippad fil i bloblagringen. App Service-miljön kan sedan hämta den och distribuera den.

  Den här metoden innehåller följande begränsningar:

  • Den här metoden kopplar bort DevOps från den faktiska distributionsprocessen, vilket gör det svårt att övervaka och spåra distributionsproblem.
  • I en låst miljö med säker trafik kan du behöva uppdatera åtkomstreglerna för den zippade filen i lagringen.
  • Du måste installera specifika tillägg och verktyg i App Service Environment för att distribuera från ZIP-filen.

  Mer information om distributionsmetoder för appar finns i Kör din app i App Service.

Prestandaeffektivitet

Prestandaeffektivitet syftar på arbetsbelastningens förmåga att skala för att effektivt uppfylla användarnas krav. Mer information finns i Checklista för designgranskning för prestandaeffektivitet.

Utforma skalbara appar

Den här referensarkitekturen strukturerar programmet så att du kan skala enskilda komponenter baserat på användning. Varje webbapp, API och funktion distribueras i en egen App Service-plan. Du kan övervaka varje app för flaskhalsar i prestanda och sedan skala upp den när det behövs.

Skala Application Gateway automatiskt

Application Gateway stöder automatisk skalning. Med den här funktionen kan Application Gateway skala upp eller ned baserat på trafikbelastningsmönster. Den här referensarkitekturen konfigureras autoscaleConfiguration i filen appgw.bicep för att skala mellan noll och 10 extra instanser. Mer information finns i Skala Application Gateway och Brandvägg för webbprogram.

Distribuera det här scenariot

Information om hur du distribuerar referensimplementeringen för den här arkitekturen finns i GitHub-readme och följer skriptet för standarddistribution.

Bidragsgivare

Microsoft ansvarar för den här artikeln. Följande deltagare skrev den här artikeln.

Huvudförfattare:

• Dhanashri Kshirsagar | Senior Content PM

Övriga medarbetare:

• Deep Bhattacharya | Molnlösningsarkitekt
• Suhas Rao | Molnlösningsarkitekt

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg

• Kör appen i App Service direkt från ett ZIP-paket
• YAML-schema för Azure Pipelines
• 密钥保管��
• Azure-pipelines

Relaterad resurs

• Appdistribution med hög tillgänglighet via App Service Environment.