Algemene webtoepassing

Dit artikel bevat een basisarchitectuur die is bedoeld voor informatie over het uitvoeren van webtoepassingen in Azure-app Service in één regio.

Architectuur

Afbeelding 1: Basic Azure-app Service-architectuur

Een Visio-bestand van deze architectuur downloaden.

Workflow

1. Een gebruiker geeft een HTTPS-aanvraag uit aan het standaarddomein van App Service op azurewebsites.net. Dit domein verwijst automatisch naar het ingebouwde openbare IP-adres van uw App Service. De TLS-verbinding wordt rechtstreeks tot stand gebracht vanaf de client naar app service. Het certificaat wordt volledig beheerd door Azure.
2. Easy Auth, een functie van Azure-app Service, zorgt ervoor dat de gebruiker die toegang heeft tot de site, wordt geverifieerd met Microsoft Entra-id.
3. De toepassingscode die is geïmplementeerd in App Service verwerkt de aanvraag. Deze code kan bijvoorbeeld verbinding maken met een Azure SQL Database-exemplaar met behulp van een verbindingsreeks geconfigureerd in de App Service die is geconfigureerd als een app-instelling.
4. De informatie over de oorspronkelijke aanvraag voor App Service en de aanroep naar Azure SQL Database wordt vastgelegd in Application Insights.

Onderdelen

• Microsoft Entra ID is een cloudservice voor identiteits- en toegangsbeheer. Het biedt één identiteitsbeheervlak voor het beheren van machtigingen en rollen voor gebruikers die toegang hebben tot uw webtoepassing. Het integreert met App Service en vereenvoudigt verificatie en autorisatie voor web-apps.
• App Service is een volledig beheerd platform voor het bouwen, implementeren en schalen van webtoepassingen.
• Azure Monitor is een bewakingsservice die telemetriegegevens verzamelt, analyseert en uitvoert in uw implementatie.
• Azure SQL Database is een beheerde relationele databaseservice voor relationele gegevens.

Aanbevelingen en overwegingen

De onderdelen die in deze architectuur worden vermeld, zijn gekoppeld aan azure Well-Architected-servicehandleidingen. Servicehandleidingen bevatten gedetailleerde aanbevelingen en overwegingen voor specifieke services. Deze sectie breidt deze richtlijnen uit door belangrijke aanbevelingen en overwegingen voor Azure Well-Architected Framework te markeren die van toepassing zijn op deze architectuur. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Deze basisarchitectuur is niet bedoeld voor productie-implementaties. De architectuur bevordert eenvoud en kostenefficiëntie ten opzichte van functionaliteit, zodat u Azure-app Service kunt evalueren en leren. In de volgende secties worden enkele tekortkomingen van deze basisarchitectuur beschreven, samen met aanbevelingen en overwegingen.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie de controlelijst ontwerpbeoordeling voor betrouwbaarheid voor meer informatie.

Omdat deze architectuur niet is ontworpen voor productie-implementaties, worden enkele van de essentiële betrouwbaarheidsfuncties beschreven die in deze architectuur worden weggelaten:

• Het App Service-plan is geconfigureerd voor de Standard laag, waarvoor geen ondersteuning voor de Azure-beschikbaarheidszone wordt geboden. De App Service is niet meer beschikbaar in het geval van een probleem met het exemplaar, het rek of het datacenter dat als host fungeert voor het exemplaar.
• De Azure SQL Database is geconfigureerd voor de Basic laag, die geen zoneredundantie ondersteunt. Dit betekent dat gegevens niet worden gerepliceerd in Azure-beschikbaarheidszones, waardoor het verlies van vastgelegde gegevens in het geval van een storing gevaar loopt.
• Implementaties in deze architectuur kunnen leiden tot downtime met toepassingsimplementaties, omdat voor de meeste implementatietechnieken alle actieve exemplaren opnieuw moeten worden opgestart. Gebruikers kunnen tijdens dit proces 503-fouten ervaren. Dit wordt aangepakt in de basislijnarchitectuur via implementatiesites. Zorgvuldige verwerking van toepassingsontwerp, schemabeheer en verwerking van toepassingsconfiguraties zijn nodig om gelijktijdige site-implementatie te ondersteunen. Gebruik deze POC om uw productie-implementatiemethode op basis van sleuf te ontwerpen en te valideren.
• Automatisch schalen is niet ingeschakeld in deze basisarchitectuur. Als u betrouwbaarheidsproblemen wilt voorkomen als gevolg van een gebrek aan beschikbare rekenresources, moet u de inrichting te veel inrichten om altijd te kunnen worden uitgevoerd met voldoende rekenkracht om de maximale gelijktijdige capaciteit te verwerken.

Bekijk hoe u deze problemen met betrouwbaarheid kunt oplossen in de sectie Betrouwbaarheid in de sectie Basislijn voor maximaal beschikbare zone-redundante webtoepassing.

Als deze workload uiteindelijk een actief-actief-actief- of actief-passieve architectuur voor meerdere regio's vereist, raadpleegt u de volgende resources:

• App Service-benaderingen voor meerdere regio's voor herstel na noodgevallen voor hulp bij het implementeren van uw door App Service gehoste workload in meerdere regio's.
• Maximaal beschikbare webtoepassing voor meerdere regio's voor een referentiearchitectuur die een actief-passieve benadering volgt.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie de controlelijst ontwerpbeoordeling voor beveiliging voor meer informatie.

Omdat deze architectuur niet is ontworpen voor productie-implementaties, worden enkele van de essentiële beveiligingsfuncties beschreven die in deze architectuur zijn weggelaten, samen met andere aanbevelingen en overwegingen voor betrouwbaarheid:

• Deze basisarchitectuur implementeert geen netwerkprivacy. De gegevens- en beheervlakken voor de resources, zoals de Azure-app Service en Azure SQL Server, zijn bereikbaar via het openbare internet. Als u privénetwerken weglaat, neemt de kwetsbaarheid voor aanvallen van uw architectuur aanzienlijk toe. Als u wilt zien hoe het implementeren van privénetwerken zorgt voor de volgende beveiligingsfuncties, raadpleegt u de sectie Netwerken van de maximaal beschikbare zone-redundante webtoepassing Basislijn:

  • Eén beveiligd toegangspunt voor clientverkeer
  • Netwerkverkeer wordt zowel op pakketniveau als op DDoS-niveau gefilterd.
  • Gegevensexfiltratie wordt geminimaliseerd door verkeer in Azure te houden met behulp van Private Link
  • Netwerkbronnen worden logisch gegroepeerd en geïsoleerd van elkaar via netwerksegmentatie.

• Deze basisarchitectuur bevat geen implementatie van Azure Web Application Firewall. De webtoepassing is niet beschermd tegen veelvoorkomende aanvallen en beveiligingsproblemen. Zie de implementatie van de basislijn om te zien hoe de Web Application Firewall kan worden geïmplementeerd met Azure-toepassing Gateway in een architectuur van Azure-app Services.

• In deze basisarchitectuur worden geheimen opgeslagen, zoals de Azure SQL Server-verbindingsreeks in App-instellingen. Hoewel app-instellingen worden versleuteld, kunt u overwegen om geheimen op te slaan in Azure Key Vault voor meer governance. Een nog betere oplossing is om beheerde identiteit te gebruiken voor verificatie en geen geheimen op te slaan in de verbindingsreeks.

• Het is prima om externe foutopsporing en Kudu-eindpunten ingeschakeld te laten terwijl ze in ontwikkeling zijn of de proof-of-conceptfase. Wanneer u naar productie gaat, moet u onnodig besturingsvlak, implementatie of externe toegang uitschakelen.

• Het is prima om lokale verificatiemethoden voor FTP- en SCM-site-implementaties ingeschakeld te laten in de ontwikkelingsfase of het proof-of-concept. Wanneer u naar productie gaat, moet u lokale verificatie uitschakelen voor deze eindpunten.

• U hoeft Microsoft Defender for App Service niet in te schakelen in de fase Proof of Concept . Wanneer u overstapt op productie, moet u Defender voor App Service inschakelen om beveiligingsaanbeveling te genereren die u moet implementeren om uw beveiligingspostuur te verhogen en om meerdere bedreigingen voor uw App Service te detecteren.

• Azure-app Service bevat een SSL-eindpunt op een subdomein zonder azurewebsites.net extra kosten. HTTP-aanvragen worden standaard omgeleid naar het HTTPS-eindpunt. Voor productie-implementaties gebruikt u doorgaans een aangepast domein dat is gekoppeld aan de toepassingsgateway of API-beheer vóór uw App Service-implementatie.

• Gebruik het geïntegreerde verificatiemechanisme voor App Service ('EasyAuth'). EasyAuth vereenvoudigt het proces van het integreren van id-providers in uw web-app. Hiermee wordt verificatie buiten uw web-app verwerkt, zodat u geen belangrijke codewijzigingen hoeft aan te brengen.

• Beheerde identiteit gebruiken voor workloadidentiteiten. Beheerde identiteit elimineert de noodzaak voor ontwikkelaars om verificatiereferenties te beheren. De basisarchitectuur wordt geverifieerd bij SQL Server via een wachtwoord in een verbindingsreeks. Overweeg het gebruik van een beheerde identiteit om te verifiëren bij Azure SQL Server.

Zie Een app beveiligen in Azure-app Service voor andere beveiligingsoverwegingen.

Operationele uitmuntendheid

Operationele uitmuntendheid omvat de operationele processen die een toepassing implementeren en deze in productie houden. Zie de controlelijst ontwerpbeoordeling voor Operational Excellence voor meer informatie.

De volgende secties bevatten richtlijnen voor configuratie, bewaking en implementatie van uw App Service-toepassing.

App-configuraties

Omdat de basisarchitectuur niet is bedoeld voor productie, wordt de App Service-configuratie gebruikt om configuratiewaarden en geheimen op te slaan. Het opslaan van geheimen in de App Service-configuratie is prima voor de PoC-fase. U gebruikt geen echte geheimen en vereist geen beheer van geheimen die productieworkloads vereisen.

Hier volgen aanbevelingen en overwegingen voor configuratie:

• Begin met het gebruik van App Service-configuratie om configuratiewaarden en verbindingsreeks s op te slaan in proof-of-conceptimplementaties. App-instellingen en verbindingsreeks s worden versleuteld en ontsleuteld net voordat ze worden geïnjecteerd in uw app wanneer deze wordt gestart.
• Wanneer u overstapt naar de productiefase, slaat u uw geheimen op in Azure Key Vault. Het gebruik van Azure Key Vault verbetert het beheer van geheimen op twee manieren:
  • Door uw opslag van geheimen naar Azure Key Vault te externaliseren, kunt u uw opslag van geheimen centraliseren. U hebt één plek om geheimen te beheren.
  • Met Behulp van Azure Key Vault kunt u elke interactie met geheimen registreren, inclusief telkens wanneer een geheim wordt geopend.
• Wanneer u overstapt naar productie, kunt u uw gebruik van zowel Azure Key Vault- als App Service-configuratie onderhouden met behulp van Key Vault-verwijzingen.

Diagnose en controle

Tijdens de proof-of-conceptfase is het belangrijk om inzicht te krijgen in welke logboeken en metrische gegevens beschikbaar zijn om te worden vastgelegd. Hieronder volgen aanbevelingen en overwegingen voor bewaking in de proof-of-conceptfase:

• Schakel diagnostische logboekregistratie in voor alle itemslogboekbronnen. Als u het gebruik van alle diagnostische instellingen configureert, krijgt u inzicht in de logboeken en metrische gegevens die u direct ontvangt en eventuele hiaten die u moet sluiten met behulp van een logboekframework in uw toepassingscode. Wanneer u naar productie gaat, moet u logboekbronnen elimineren die geen waarde toevoegen en ruis en kosten toevoegen aan de logboeksink van uw workload.
• Configureer logboekregistratie voor het gebruik van Azure Log Analytics. Azure Log Analytics biedt u een schaalbaar platform om logboekregistratie te centraliseren die eenvoudig te doorzoeken is.
• Gebruik Application Insights of een ander APM-hulpprogramma (Application Performance Management) om telemetrie en logboeken te verzenden om de prestaties van toepassingen te bewaken.

Implementatie

Hieronder vindt u richtlijnen voor het implementeren van uw App Service-toepassing.

• Volg de richtlijnen in CI/CD voor Azure Web Apps met Azure Pipelines om de implementatie van uw toepassing te automatiseren . Begin met het bouwen van uw implementatielogica in de PoC-fase. Door CI/CD vroeg in het ontwikkelingsproces te implementeren, kunt u uw toepassing snel en veilig herhalen terwijl u naar productie gaat.
• Arm-sjablonen gebruiken om Azure-resources en hun afhankelijkheden te implementeren. Het is belangrijk om dit proces in de PoC-fase te starten. Wanneer u naar productie gaat, wilt u dat uw infrastructuur automatisch kan worden geïmplementeerd.
• Gebruik verschillende ARM-sjablonen en integreer deze met Azure DevOps-services. Met deze installatie kunt u verschillende omgevingen maken. U kunt bijvoorbeeld productieachtige scenario's of testomgevingen voor belasting alleen repliceren wanneer dat nodig is en kosten besparen.

Zie de sectie DevOps in Azure Well-Architected Framework voor meer informatie.

Containers

De basisarchitectuur kan worden gebruikt om ondersteunde code rechtstreeks te implementeren in Windows- of Linux-exemplaren. App Service is ook een containerhostingplatform om uw in containers geplaatste webtoepassing uit te voeren. App Service biedt verschillende ingebouwde containers. Als u aangepaste of apps met meerdere containers gebruikt om uw runtime-omgeving verder af te stemmen of om een codetaal te ondersteunen die niet systeemeigen wordt ondersteund, moet u een containerregister introduceren.

Besturingsvlak

Tijdens de POC-fase kunt u vertrouwd raken met het besturingsvlak van Azure-app Service, zoals weergegeven via de Kudu-service. Met deze service worden algemene implementatie-API's, zoals ZIP-implementaties, onbewerkte logboeken en omgevingsvariabelen weergegeven.

Als u containers gebruikt, moet u weten hoe Kudu een SSH-sessie kan openen naar een container om geavanceerde foutopsporingsmogelijkheden te ondersteunen.

Prestatie-efficiëntie

Prestatie-efficiëntie is de mogelijkheid om op efficiënte wijze uw werkbelasting te schalen om te voldoen aan de vereisten die gebruikers eraan stellen. Zie de controlelijst ontwerpbeoordeling voor prestatie-efficiëntie voor meer informatie.

Omdat deze architectuur niet is ontworpen voor productie-implementaties, worden enkele van de essentiële prestatie-efficiëntiefuncties beschreven die in deze architectuur zijn weggelaten, samen met andere aanbevelingen en overwegingen.

Een resultaat van uw proof-of-concept moet SKU-selectie zijn die u schat, is geschikt voor uw workload. Uw workload moet zijn ontworpen om efficiënt te voldoen aan de vraag via horizontaal schalen door het aantal rekeninstanties dat is geïmplementeerd in het App Service-plan aan te passen. Ontwerp het systeem niet zodat het afhankelijk is van het wijzigen van de reken-SKU zodat deze overeenkomt met de vraag.

• De App Service in deze basisarchitectuur heeft geen automatisch schalen geïmplementeerd. De service wordt niet dynamisch uitgeschaald of ingeschaald om efficiënt te blijven voldoen aan de vraag.
  • De Standard-laag biedt ondersteuning voor instellingen voor automatisch schalen, zodat u automatisch schalen op basis van regels kunt configureren. Een deel van uw POC-proces moet zijn om te komen tot efficiënte instellingen voor automatisch schalen op basis van de resourcebehoeften van uw toepassingscode en de verwachte gebruikskenmerken.
  • Voor productie-implementaties kunt u Premium-lagen overwegen die automatische schaalaanpassing ondersteunen, waarbij het platform automatisch schaalbeslissingen afhandelt.
• Volg de richtlijnen voor het omhoog schalen van afzonderlijke databases zonder uitvaltijd van toepassingen als u een hogere servicelaag of een hoger prestatieniveau voor SQL Database nodig hebt.

Dit scenario implementeren

De richtlijnen worden ondersteund door een voorbeeld-implementatie die een eenvoudige App Service-implementatie in Azure laat zien.

Volgende stappen

Verwante resources

• Zone-redundante basislijnwebtoepassing
• Maximaal beschikbare webtoepassing voor meerdere regio's
• App Service-benaderingen voor meerdere regio's voor herstel na noodgevallen

Productdocumentatie:

• Overzicht van App Service
• Overzicht van Azure Monitor
• Overzicht van Azure App Service-plan
• Overzicht van Log Analytics in Azure Monitor
• Wat is Microsoft Entra ID?
• Wat is Azure SQL Database?

Microsoft Learn-modules:

• Azure Monitor configureren en beheren
• Microsoft Entra-id configureren
• Azure Monitor configureren
• Servers, exemplaren en databases implementeren en configureren voor Azure SQL
• Azure-app Service verkennen
• Een webtoepassing hosten met Azure-app Service
• Uw domein hosten in Azure DNS
• Azure Key Vault implementeren
• Gebruikers en groepen beheren in Microsoft Entra-id