Bedrijfsimplementatie met Azure-app Service Environment

Deze referentiearchitectuur demonstreert een algemene ondernemingsworkload die gebruikmaakt van App Service Environment versie 3. Ook worden aanbevolen procedures beschreven voor het versterken van de beveiliging van de workload.

Een referentie-implementatie voor deze architectuur is beschikbaar op GitHub.

Architectuur

Een Visio-bestand van deze architectuur downloaden.

Workflow

App Service Environment versie 3 biedt verschillende functies dan eerdere versies en voordelen ten opzichte van deze versies. Zie Functieverschillen voor meer informatie. U kunt App Service Environment op twee manieren implementeren:

• Als een externe App Service-omgeving met een openbaar IP-adres
• Als een interne App Service-omgeving met een intern IP-adres dat deel uitmaakt van de interne load balancer (ILB)

Met deze referentiearchitectuur wordt een bedrijfswebtoepassing geïmplementeerd in een interne App Service Environment, ook wel een ILB App Service Environment genoemd. Gebruik een ILB App Service-omgeving wanneer u voor uw scenario het volgende moet doen:

• Host intranettoepassingen met verbeterde beveiliging in de cloud en open ze via een site-naar-site-VPN of Azure ExpressRoute.
• Een beveiligingslaag bieden voor apps met behulp van een Web Application Firewall (WAF).
• Apps die niet worden vermeld op openbare DNS-servers, hosten in de cloud.
• Maak internet-geïsoleerde back-end-apps, waarmee uw front-end-apps op een zeer veilige manier kunnen worden geïntegreerd.

App Service Environment moet altijd worden geïmplementeerd in een eigen subnet in het virtuele bedrijfsnetwerk om het binnenkomende en uitgaande verkeer nauw te beheren. Binnen dit subnet worden App Service-toepassingen geïmplementeerd in een of meer App Service-abonnementen. Dit is een verzameling fysieke resources die nodig zijn om de app uit te voeren. Afhankelijk van de complexiteit en resourcevereiste kan een App Service-plan worden gedeeld tussen meerdere apps. Deze referentie-implementatie implementeert een web-app met de naam Voting App, die communiceert met een privé-web-API en een functie. Er wordt ook een dummy-web-app met de naam Test App geïmplementeerd om implementaties met meerdere apps te demonstreren. Elke App Service-app wordt gehost in een eigen App Service-plan, zodat elke app onafhankelijk kan worden geschaald, indien nodig. Alle resources die vereist zijn voor deze gehoste apps, zoals opslag en rekenkracht, evenals schaalbehoeften, worden volledig beheerd door de Infrastructuur van de App Service Environment.

Met de eenvoudige stem-app in deze implementatie kunnen gebruikers bestaande items bekijken, nieuwe items maken en stemmen op bestaande items. De web-API wordt gebruikt voor het maken en ophalen van vermeldingen en stemmen. De gegevens zelf worden opgeslagen in een SQL Server-database. Om asynchrone gegevensupdates te demonstreren, worden in de web-app onlangs toegevoegde stemmen in een Service Bus-exemplaar in de wachtrij geplaatst. De functie haalt stemmen in de wachtrij op en werkt de SQL-database bij. Azure Cosmos DB wordt gebruikt om een mock-upadvertentie op te slaan die door de web-app wordt opgehaald om weer te geven in de browser. De toepassing gebruikt Azure Cache voor Redis voor cachebeheer. Er wordt een Premium-laag Azure Cache voor Redis gebruikt, waarmee configuratie mogelijk is voor hetzelfde virtuele netwerk als de App Service Environment, in een eigen subnet. Dit biedt verbeterde beveiliging en isolatie voor de cache.

De web-apps zijn de enige onderdelen die toegankelijk zijn voor internet via Application Gateway. De API en de functie zijn niet toegankelijk vanaf een internetclient. Het binnenkomende verkeer wordt beveiligd door een WAF die is geconfigureerd in Application Gateway.

Onderdelen

De volgende services zijn essentieel voor het vergrendelen van de App Service-omgeving in deze architectuur:

• Azure Virtual Network is een privé-Azure-cloudnetwerk dat eigendom is van een onderneming. Het biedt verbeterde beveiliging en isolatie op basis van netwerken. App Service Environment is een App Service-implementatie in een subnet van het virtuele netwerk in bedrijfseigendom. Het stelt de onderneming in staat om de netwerkruimte en de resources waartoe deze toegang heeft, nauw te beheren met behulp van netwerkbeveiligingsgroepen en privé-eindpunten.

• Application Gateway is een load balancer voor webverkeer op toepassingsniveau met TLS/SSL-offloading en WAF. Het luistert op een openbaar IP-adres en routeert verkeer naar het toepassingseindpunt in de ILB App Service Environment. Omdat dit routering op toepassingsniveau is, kan het verkeer routeren naar meerdere apps binnen dezelfde ILB App Service Environment. Zie Application Gateway meerdere sites hosten voor meer informatie.

• Azure Firewall wordt gebruikt om het uitgaande verkeer van de webtoepassing te beperken. Uitgaand verkeer dat niet via de privé-eindpuntkanalen gaat en een routetabel die is vereist voor App Service Environment, wordt omgeleid naar het firewallsubnet. Omwille van de eenvoud configureert deze architectuur alle privé-eindpunten in het subnet van de services.

• Microsoft Entra-id of Microsoft Entra-id biedt toegangsrechten en machtigingenbeheer voor Azure-resources en -services. Beheerde identiteiten wijst identiteiten toe aan services en apps, automatisch beheerd door Microsoft Entra ID. Deze identiteiten kunnen worden gebruikt voor verificatie bij elke service die ondersteuning biedt voor Microsoft Entra-verificatie. Hierdoor hoeft u geen referenties voor deze apps expliciet te configureren. Met deze architectuur wordt een beheerde identiteit toegewezen aan de web-app.

• Azure Key Vault slaat alle geheimen en referenties op die vereist zijn voor de apps. Gebruik deze optie om geheimen rechtstreeks in de toepassing op te slaan.

• GitHub Actions biedt mogelijkheden voor continue integratie en continue implementatie in deze architectuur. Omdat de App Service Environment zich in het virtuele netwerk bevindt, wordt een virtuele machine gebruikt als een jumpbox in het virtuele netwerk om apps in de App Service-plannen te implementeren. Met de actie worden de apps buiten het virtuele netwerk gebouwd. Voor verbeterde beveiliging en naadloze RDP-/SSH-connectiviteit kunt u Azure Bastion gebruiken voor de jumpbox.

Configuratie voor meerdere sites

Een Visio-bestand van deze architectuur downloaden.

Interne App Service Environment kan verschillende web-apps en API's hosten met HTTP-eindpunten. Deze toepassingen zijn vergrendeld vanaf het openbare internet omdat het IP-adres van de ILB alleen toegankelijk is vanuit het virtuele netwerk. Application Gateway wordt gebruikt om deze toepassingen selectief beschikbaar te maken op internet. App Service Environment wijst een standaard-URL toe aan elke App Service-toepassing als <default-appName>.<app-service-environment-domain>.appserviceenvironment.net. Er wordt een privé-DNS-zone gemaakt waarmee de domeinnaam van de App Service Environment wordt toegewezen aan het IP-adres van de App Service Environment-omgeving. Dit voorkomt dat u een aangepaste DNS gebruikt om toegang te krijgen tot de apps in het virtuele netwerk.

Application Gateway is zodanig geconfigureerd dat een listener luistert op de HTTPS-poort voor aanvragen naar het IP-adres van de gateway. Omwille van de eenvoud gebruikt deze implementatie geen openbare DNS-naamregistratie. Hiervoor moet u het localhost-bestand op uw computer wijzigen om een willekeurig gekozen URL te laten verwijzen naar het IP-adres van de toepassingsgateway. Ter vereenvoudiging gebruikt de listener een zelfondertekend certificaat om deze aanvragen te verwerken. Application Gateway bevat back-endpools voor de standaard-URL van elke App Service-toepassing. Er is een routeringsregel geconfigureerd om de listener te verbinden met de back-endpool. HTTP-instellingen worden gemaakt die bepalen of de verbinding tussen de gateway en de App Service-omgeving wordt versleuteld. Deze instellingen worden ook gebruikt om de binnenkomende HTTP-hostheader te overschrijven met een hostnaam die is gekozen uit de back-endpool. Deze implementatie maakt gebruik van standaardcertificaten die zijn gemaakt voor de standaard-URL's van app App Service Environment, die worden vertrouwd door de gateway. De aanvraag wordt omgeleid naar de standaard-URL van de bijbehorende app. De privé-DNS die is gekoppeld aan het virtuele netwerk stuurt deze aanvraag door naar het IP-adres van de ILB. App Service Environment stuurt dit vervolgens door naar de aangevraagde app-service. Http-communicatie in de App Service Environment-apps gaat via de privé-DNS. Houd er rekening mee dat de listener, back-endpool, routeringsregel en HTTP-instellingen moeten worden geconfigureerd op de toepassingsgateway voor elke App Service Environment-app.

Bekijk appgw.bicep en dns.bicep om te leren hoe deze configuraties worden gemaakt om meerdere sites toe te staan. De benoemde testapp web-app is een lege app die is gemaakt om deze configuratie te demonstreren. Deze JSON-bestanden worden geopend vanuit het implementatiescript commands_std.azcli. Deze worden ook geopend door commands_ha.azcli, die wordt gebruikt voor een implementatie van een App Service Environment met hoge beschikbaarheid.

Scenariodetails

Azure-app Service is een PaaS-service die wordt gebruikt voor het hosten van verschillende apps in Azure: web-apps, API-apps, functies en mobiele apps. Met App Service Environment kunnen ondernemingen hun App Service-apps implementeren in een subnet in hun eigen Azure Virtual Network, waarbij ze een geïsoleerde, zeer schaalbare en toegewezen omgeving bieden voor hun cloudworkloads.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.

App Service-omgeving

Een interne App Service-omgeving wordt geïmplementeerd in het virtuele bedrijfsnetwerk, verborgen voor het openbare internet. Hiermee kan de onderneming hun back-endservices, zoals web-API's en functies, vergrendelen op netwerkniveau. Elke App Service Environment-app met een HTTP-eindpunt kan worden geopend via de ILB, vanuit het virtuele netwerk. Application Gateway is geconfigureerd voor het doorsturen van aanvragen naar de web-app via de ILB. De web-app zelf doorloopt de ILB voor toegang tot de API. De kritieke back-endonderdelen, de API en de functie, zijn effectief niet toegankelijk vanaf het openbare internet.

Standaardcertificaten worden gemaakt voor elke app-service voor de standaarddomeinnaam die is toegewezen door App Service Environment. Dit certificaat kan de beveiliging van het verkeer tussen de gateway en de app versterken en kan in bepaalde scenario's vereist zijn. Deze certificaten zijn niet zichtbaar via de clientbrowser. Het kan alleen reageren op de certificaten die zijn geconfigureerd op Application Gateway.

Application Gateway

De referentie-implementatie configureert Application Gateway programmatisch in appgw.bicep. Het bestand commands_std.azcli gebruikt deze configuratie bij het implementeren van de gateway:

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)

Versleuteling

Zoals beschreven in Overzicht van TLS-beëindiging en end-to-end TLS met Application Gateway, kan Application Gateway Transport Layer Security (TLS)/Secure Sockets Layer (SSL) gebruiken om al het verkeer van webbrowsers te versleutelen en te beveiligen. Versleuteling kan op de volgende manieren worden geconfigureerd:

• Versleuteling is beëindigd op de gateway. De back-endpools in dit geval zijn geconfigureerd voor HTTP. De versleuteling stopt bij de gateway en verkeer tussen de gateway en de app-service wordt niet versleuteld. Omdat versleuteling cpu-intensief is, verbetert niet-versleuteld verkeer in de back-end de prestaties en maakt eenvoudiger certificaatbeheer mogelijk. Dit biedt een redelijk beveiligingsniveau omdat de back-end wordt beveiligd door de netwerkconfiguratie.

• End-to-end-versleuteling. In sommige scenario's, zoals specifieke beveiligings- of nalevingsvereisten, moet het verkeer mogelijk worden versleuteld tussen de gateway en de app. Dit wordt bereikt door https-verbinding te gebruiken en certificaten te configureren in de back-endpool.

Deze referentie-implementatie maakt gebruik van zelfondertekende certificaten voor Application Gateway. Voor productiecode moet een certificaat dat is uitgegeven door een certificeringsinstantie worden gebruikt. Zie Certificaten die worden ondersteund voor TLS-beëindiging voor een lijst met ondersteunde certificaattypen. Lees Een toepassingsgateway configureren met TLS-beëindiging met behulp van Azure Portal voor meer informatie over het maken van gatewayversleuteling die is beëindigd. De volgende regels code in appgw.bicep configureren dit programmatisch:

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

De referentie-implementatie demonstreert end-to-end-versleuteling voor verkeer tussen Application Gateway en de web-apps in de App Service Environment. De standaard SSL-certificaten worden gebruikt. De back-endpools in deze implementatie zijn geconfigureerd om HTTPS-verkeer om te leiden met hostnaam die wordt overschreven door de standaarddomeinnamen die zijn gekoppeld aan de web-apps. Application Gateway vertrouwt de standaard-SSL-certificaten omdat ze worden uitgegeven door Microsoft. Zie App Service configureren met Application Gateway voor informatie over hoe deze configuraties worden gemaakt. De volgende code van appgw.bicep laat zien hoe dit is geconfigureerd in de referentie-implementatie:

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

Web Application Firewall

Web Application Firewall (WAF) in Application Gateway beschermt de web-apps tegen schadelijke aanvallen, zoals SQL-injectie. Het is ook geïntegreerd met Azure Monitor om aanvallen te bewaken met behulp van een realtime-logboek. WAF moet zijn ingeschakeld op de gateway, zoals beschreven in Een toepassingsgateway maken met een Web Application Firewall met behulp van Azure Portal. De referentie-implementatie schakelt WAF programmatisch in het bestand appgw.bicep in met het volgende codefragment:

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

Virtual Network

Netwerkbeveiligingsgroepen kunnen worden gekoppeld aan een of meer subnetten in het virtuele netwerk. Dit zijn beveiligingsregels waarmee verkeer tussen verschillende Azure-resources kan stromen of weigeren. Deze architectuur koppelt een afzonderlijke netwerkbeveiligingsgroep voor elk subnet. Dit maakt het mogelijk om deze regels per subnet af te stemmen op basis van de services in dat subnet. Zie bijvoorbeeld de configuratie voor "type": "Microsoft.Network/networkSecurityGroups" in het bestand ase.bicep voor de netwerkbeveiligingsgroep voor het subnet App Service Environment en in het bestand appgw.bicep voor de netwerkbeveiligingsgroep voor het Application Gateway-subnet.

Privé-eindpunten maken verbeterde beveiliging mogelijk voor privéconnectiviteit tussen clients en Azure-services via een privénetwerk. Ze bieden een privé toegankelijk IP-adres voor de Azure-service, waardoor het verkeer met verbeterde beveiliging naar een Azure Private Link-resource mogelijk is. Het platform valideert netwerkverbindingen, zodat alleen de verbindingen die verbinding maken met de opgegeven Private Link-resource. Privé-eindpunten ondersteunen netwerkbeleid, zoals netwerkbeveiligingsgroepen, door de gebruiker gedefinieerde routes en toepassingsbeveiligingsgroepen. Om de beveiliging te verbeteren, moet u privé-eindpunten inschakelen voor elke Azure-service die deze ondersteunt. Vervolgens kunt u de beveiliging voor de service in het virtuele netwerk verbeteren door openbare toegang uit te schakelen, waardoor elke toegang vanaf het openbare internet effectief wordt geblokkeerd. Deze architectuur configureert privé-eindpunten voor de services die deze ondersteunen: Azure Service Bus, SQL Server, Key Vault en Azure Cosmos DB. U kunt de configuratie zien in privatendpoints.bicep.

Als u privé-eindpunten wilt inschakelen, moet u ook privé-DNS-zones configureren. Raadpleeg DNS-configuratie voor Azure-privé-eindpunt voor meer informatie.

Firewall

Azure Firewall en privé-eindpunten vormen een aanvulling op elkaar. Met privé-eindpunten kunt u resources beveiligen door alleen verkeer toe te staan dat afkomstig is van uw virtuele netwerk. Met Azure Firewall kunt u het uitgaande verkeer van uw toepassingen beperken. U wordt aangeraden al het uitgaande verkeer toe te staan het firewallsubnet door te geven, inclusief privé-eindpuntverkeer. Hierdoor kan het uitgaande verkeer beter worden bewaakt. Omwille van de eenvoud configureert deze referentiearchitectuur alle privé-eindpunten in het servicessubnet in plaats van op het firewallsubnet.

Zie Azure Firewall configureren met uw App Service Environment voor meer informatie over hoe Azure Firewall kan worden geïntegreerd met App Service Environment. Verkeer dat niet door de privé-eindpunten en de routetabel van het virtuele netwerk gaat, wordt bewaakt en beveiligd door de firewall.

Microsoft Entra ID

Microsoft Entra ID biedt beveiligingsfuncties voor het verifiëren van toepassingen en het autoriseren van toegang tot resources. Deze referentiearchitectuur maakt gebruik van twee belangrijke functies van Microsoft Entra ID: beheerde identiteiten en op rollen gebaseerd toegangsbeheer van Azure.

In cloudtoepassingen moeten de referenties voor verificatie bij cloudservices worden beveiligd. In het ideale geval mogen de referenties nooit worden weergegeven op werkstations van ontwikkelaars of ingecheckt bij broncodebeheer. Azure Key Vault biedt een manier om referenties en geheimen veilig op te slaan, maar de app moet zich nog steeds verifiëren bij Key Vault om ze op te halen. Beheerde identiteiten voor Azure-resources bieden Azure-services met een automatisch beheerde identiteit in Microsoft Entra-id. Deze identiteit kan worden gebruikt voor verificatie bij elke service die ondersteuning biedt voor Microsoft Entra-verificatie, inclusief Key Vault, zonder referenties in de toepassing.

Op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) beheert de toegang tot Azure-resources. Dit zijn onder andere de nieuwe mogelijkheden:

• Welke entiteit heeft de toegang: gebruiker, beheerde identiteit, beveiligingsprincipaal.
• Welk type toegang het heeft: eigenaar, inzender, lezer, beheerder.
• Bereik van de toegang: resource, resourcegroep, abonnement of beheergroep.

U kunt de toegang tot App Service Environment-toepassingen vergrendelen door de vereiste rol en het type toegang voor elke app nauw te beheren. Op deze manier kunnen meerdere apps worden geïmplementeerd in dezelfde App Service Environment van verschillende ontwikkelteams. De front-end kan bijvoorbeeld worden verwerkt door het ene team en de back-end door een andere. Azure RBAC kan worden gebruikt om de toegang van elk team tot de app(s) waaraan het werkt te beperken. Verken aangepaste Azure-rollen om rollen te maken die geschikt zijn voor uw organisatie.

Sleutelkluis

Sommige services ondersteunen beheerde identiteiten, maar gebruiken Azure RBAC om machtigingen voor de app in te stellen. Zie bijvoorbeeld de ingebouwde Service Bus-rollen en Azure RBAC in Azure Cosmos DB. Eigenaarstoegang tot het abonnement is vereist voor het verlenen van deze machtigingen, ook al kunnen medewerkers met inzendertoegang deze services implementeren. Om een breder team van ontwikkelaars in staat te stellen de implementatiescripts uit te voeren, kunt u het beste systeemeigen toegangsbeheerbeleid van de service gebruiken:

• Voor Service Bus zijn het handtekeningen voor gedeelde toegang.
• Voor Azure Cosmos DB zijn dit sleutels.

De verbindingsreeks s voor deze beleidsregels voor toegangsbeheer worden vervolgens opgeslagen in Key Vault. De kluis zelf wordt geopend via beheerde identiteiten, waarvoor Azure RBAC is vereist. Stel het toegangsbeleid voor deze verbindingsreeks op de juiste manier in. Bijvoorbeeld: alleen-lezen voor de back-end, alleen-schrijven voor de front-end, enzovoort, in plaats van het standaardtoegangsbeleid voor de hoofdmap te gebruiken.

De volgende code in services.bicep toont de Key Vault-configuratie voor deze services:

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

Deze verbindingsreeks waarden worden geopend door de apps, die verwijzen naar het sleutel-/waardepaar van Key Vault. Dit wordt gedaan in het bestand sites.bicep , zoals in de volgende code voor stem-app wordt weergegeven:

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

De functie heeft ook toegang tot de Service Bus-listener verbindingsreeks op een vergelijkbare manier.

Schaalbaarheid

Schaalbare apps ontwerpen

De toepassing in deze referentiearchitectuur is gestructureerd zodat afzonderlijke onderdelen kunnen worden geschaald op basis van gebruik. Elke web-app, API en functie wordt geïmplementeerd in een eigen App Service-plan. U kunt elke app controleren op eventuele prestatieknelpunten en deze vervolgens omhoog schalen, indien nodig.

Automatisch schalen van Application Gateway

Automatisch schalen kan worden ingeschakeld op Azure-toepassing Gateway V2. Hierdoor kan Application Gateway omhoog of omlaag schalen op basis van de verkeersbelastingspatronen. Deze referentiearchitectuur configureert autoscaleConfiguration in het bestand appgw.bicep om te schalen tussen nul en 10 extra exemplaren. Zie Application Gateway en WAF v2 schalen voor meer informatie.

Implementatie

De implementatiescripts in deze referentiearchitectuur worden gebruikt voor het implementeren van App Service Environment, andere services en de toepassingen in App Service Environment. Zodra deze toepassingen zijn geïmplementeerd, willen ondernemingen mogelijk een plan hebben voor continue integratie en implementatie voor app-onderhoud en upgrades. In deze sectie worden enkele veelvoorkomende manieren beschreven waarop ontwikkelaars voor CI/CD van App Service Environment-toepassingen gebruikmaken.

Apps kunnen alleen vanuit het virtuele netwerk worden geïmplementeerd in een interne App Service-omgeving. De volgende drie methoden worden veel gebruikt voor het implementeren van App Service Environment-apps:

• Handmatig binnen het virtuele netwerk: maak een virtuele machine in het virtuele netwerk van App Service Environment met de vereiste hulpprogramma's voor de implementatie. Open de RDP-verbinding met de VIRTUELE machine met behulp van een NSG-configuratie. Kopieer uw codeartefacten naar de virtuele machine, bouw en implementeer deze in het subnet app serviceomgeving. Dit is een eenvoudige manier om een eerste build- en testontwikkelingsomgeving in te stellen. Het wordt echter niet aanbevolen voor een productieomgeving, omdat de vereiste implementatiedoorvoer niet kan worden geschaald.

• Punt-naar-site-verbinding vanaf lokaal werkstation: hiermee kunt u uw virtuele App Service Environment-netwerk uitbreiden naar uw ontwikkelcomputer en daar implementeren. Dit is een andere manier om een eerste ontwikkelomgeving in te stellen en niet aanbevolen voor productie.

• Via Azure Pipelines: Hiermee wordt een volledige CI/CD-pijplijn geïmplementeerd, die eindigt op een agent die zich in het virtuele netwerk bevindt. Dit is ideaal voor productieomgevingen waarvoor een hoge doorvoer van de implementatie is vereist. De build-pijplijn blijft volledig buiten het virtuele netwerk. De implementatiepijplijn kopieert de gemaakte objecten naar de buildagent in het virtuele netwerk en implementeert vervolgens in het Subnet app Service Environment. Lees deze discussie over de zelf-hostende buildagent tussen pijplijnen en het virtuele netwerk van App Service Environment voor meer informatie.

Het gebruik van Azure Pipelines wordt aanbevolen voor productieomgevingen. Het uitvoeren van scripts voor CI/CD met behulp van het YAML-schema van Azure Pipelines helpt bij het automatiseren van de build- en implementatieprocessen. De azure-pipelines.yml implementeert een dergelijke CI/CD-pijplijn voor de web-app in deze referentie-implementatie. Er zijn vergelijkbare CI/CD-scripts voor de web-API en de functie. Lees Azure Pipelines gebruiken om te leren hoe deze worden gebruikt om CI/CD voor elke toepassing te automatiseren.

Sommige ondernemingen willen mogelijk geen permanente buildagent binnen het virtuele netwerk onderhouden. In dat geval kunt u ervoor kiezen om een buildagent te maken in de DevOps-pijplijn en deze te afbreken zodra de implementatie is voltooid. Hiermee voegt u nog een stap toe in DevOps, maar de complexiteit van het onderhouden van de VIRTUELE machine wordt verlaagd. U kunt zelfs overwegen om containers te gebruiken als buildagents, in plaats van vm's. Buildagents kunnen ook volledig worden vermeden door te implementeren vanuit een gezipt bestand dat buiten het virtuele netwerk wordt geplaatst, meestal in een opslagaccount. Het opslagaccount moet toegankelijk zijn vanuit de App Service-omgeving. De pijplijn moet toegang hebben tot de opslag. Aan het einde van de release-pijplijn kan een zip-bestand in de blobopslag worden geplaatst. De App Service Environment kan deze vervolgens ophalen en implementeren. Houd rekening met de volgende beperkingen van deze aanpak:

• Er is een verbinding tussen devOps en het daadwerkelijke implementatieproces, wat leidt tot problemen bij het bewaken en traceren van implementatieproblemen.
• In een vergrendelde omgeving met beveiligd verkeer moet u mogelijk de regels wijzigen om toegang te krijgen tot het zip-bestand in de opslag.
• U moet specifieke extensies en hulpprogramma's installeren in de App Service Environment om vanuit het zip-bestand te kunnen implementeren.

Als u meer wilt weten hoe de apps kunnen worden geïmplementeerd in de App Service-plannen, leest u de App Service-artikelen die gericht zijn op implementatiestrategieën.

Kostenoptimalisatie

Gebruik de Azure-prijscalculator om een schatting van de kosten te maken. Andere overwegingen worden beschreven in de sectie Kosten in Microsoft Azure Well-Architected Framework. Azure-reserveringen helpen u geld te besparen door een toezegging te doen voor een abonnement van één of drie jaar voor veel Azure-resources. Lees meer in het artikel Een reservering kopen.

Hier volgen enkele punten om rekening mee te houden voor enkele van de belangrijkste services die in deze architectuur worden gebruikt.

App Service Environment v3

Er zijn verschillende prijsopties beschikbaar voor App Service. Een App Service-omgeving wordt geïmplementeerd met behulp van het Geïsoleerde v2-serviceplan. Binnen dit plan zijn er meerdere opties voor CPU-grootten, van I1v2 tot en met I6v2. Deze referentie-implementatie maakt gebruik van drie I1v2s per exemplaar.

Application Gateway

Application Gateway-prijzen bieden verschillende prijsopties. Deze implementatie maakt gebruik van de Application Gateway Standard v2- en WAF v2-SKU, die ondersteuning biedt voor automatisch schalen en zoneredundantie. Zie Application Gateway v2 en WAF v2 schalen voor meer informatie over het prijsmodel dat voor deze SKU wordt gebruikt.

Azure Cache voor Redis

Azure Cache voor Redis prijzen biedt de verschillende prijsopties voor deze service. Deze architectuur maakt gebruik van de Premium-SKU voor de ondersteuning van het virtuele netwerk.

Hieronder volgen pagina's met prijzen voor andere services die worden gebruikt om de App Service Environment te vergrendelen:

• Prijzen voor Azure Firewall

• Prijzen voor Key Vault

• Prijzen voor Microsoft Entra

Dit scenario implementeren

Als u de referentie-implementatie voor deze architectuur wilt implementeren, raadpleegt u de GitHub-leesmij en volgt u het script voor de standaardimplementatie.

Inzenders

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

• Dhanasī Kshirsagar | Senior Content PM

Andere Inzenders:

• Deep Bhattacharya | Cloud Solution Architect
• Suhas Rao | Cloud Solution Architect

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

• Uw app rechtstreeks vanuit een ZIP-pakket uitvoeren in Azure-app Service
• YAML-schema voor Azure Pipelines
• Uw beheeradressen ophalen uit de API
• Azure Key Vault
• Azure Pipelines

Verwante resources

Lees de app-implementatie met hoge beschikbaarheid met behulp van App Services Environment voor meer informatie over het uitbreiden van deze architectuur ter ondersteuning van hoge beschikbaarheid.