Algemene webtoepassing

Azure App Service
Azure Monitor
Azure SQL-database

Dit artikel bevat een basisarchitectuur voor meer informatie over het uitvoeren van webtoepassingen op Azure App Service in één regio.

Belangrijk

Deze architectuur is niet bedoeld voor productietoepassingen. Het fungeert als een inleidende instelling voor leer- en proof-of-concept-doeleinden (POC). Als u een App Service-productietoepassing wilt ontwerpen, raadpleeg dan Basislijn voor zeer beschikbare zone-redundante webtoepassing.

Architectuur

Diagram met een eenvoudige App Service-architectuur.

Een Visio-bestand van deze architectuur downloaden.

Werkproces

De volgende workflow komt overeen met het voorgaande diagram.

  1. Een gebruiker geeft een HTTPS-aanvraag uit aan het standaarddomein van App Service.azurewebsites.net Dit domein verwijst automatisch naar het ingebouwde openbare IP-adres van uw App Service-toepassing. De TLS-verbinding (Transport Layer Security) wordt tot stand gebracht van de client rechtstreeks naar App Service. Azure het certificaat volledig beheert.

  2. Easy Auth, een functie van App Service, zorgt ervoor dat de gebruiker die toegang heeft tot de site wordt geverifieerd met behulp van 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 die is geconfigureerd in App Service als app-instelling.

  4. De informatie over de oorspronkelijke aanvraag voor App Service en de aanroep naar SQL Database wordt vastgelegd in Application Insights.

Onderdelen

  • Microsoft Entra ID is een cloudservice voor identiteits- en toegangsbeheer die verificatie- en autorisatiemogelijkheden biedt. In deze architectuur wordt het geïntegreerd met App Service via Easy Auth om verificatie te garanderen voor gebruikers die toegang hebben tot de webtoepassing. Het vereenvoudigt ook het verificatieproces zonder dat er aanzienlijke codewijzigingen nodig zijn.

  • App Service is een beheerd platform voor het bouwen, implementeren en schalen van webtoepassingen. In deze architectuur wordt de code van de webtoepassing gehost, HTTPS-aanvragen in het standaarddomein azurewebsites.net verwerkt en wordt verbinding gemaakt met SQL Database via geconfigureerde verbindingsreeksen.

  • Azure Monitor is een bewakingsservice waarmee telemetriegegevens uit cloud- en on-premises omgevingen worden verzameld, geanalyseerd en verwerkt. In deze architectuur worden gegevens vastgelegd en opgeslagen over aanvragen voor App Service en aanroepen naar SQL Database via Application Insights-integratie.

  • SQL Database is een beheerde relationele databaseservice die SQL Server-mogelijkheden biedt in de cloud. In deze architectuur fungeert het als de gegevensopslaglaag, waarmee de App Service-toepassing verbinding kan maken via verbindingsreeksen die zijn gedefinieerd in app-instellingen.

Overwegingen

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

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

Deze basisarchitectuur is alleen ontworpen voor evaluatie- en leerdoeleinden. Het geeft prioriteit aan eenvoud en kostenefficiëntie ten opzichte van functionaliteit op productieniveau. In de volgende secties worden belangrijke beperkingen van deze architectuur gemarkeerd en worden aanbevelingen en overwegingen geboden om u te helpen bij het plannen van robuustere implementaties.

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.

Deze architectuur is niet ontworpen voor productie-implementaties. De volgende kritieke betrouwbaarheidsfuncties worden weggelaten in deze architectuur:

  • Het App Service-plan is geconfigureerd voor de Standard-laag, met geen ondersteuning voor Azure beschikbaarheidszones. App Service is niet beschikbaar als er een probleem optreedt met het exemplaar, het rek of het datacenter dat als host fungeert voor het exemplaar.

  • SQL Database is geconfigureerd voor de Basic-laag, die geen zoneredundantie ondersteunt. Als gevolg hiervan worden gegevens niet gerepliceerd in Azure beschikbaarheidszones, wat verlies van vastgelegde gegevens riskeert als er een storing optreedt.

  • Implementaties in deze architectuur kunnen leiden tot downtime voor toepassingsimplementaties, omdat voor de meeste implementatietechnieken alle actieve exemplaren opnieuw moeten worden opgestart. Gebruikers kunnen tijdens dit proces 503-fouten ervaren. Deze downtime van de implementatie wordt opgelost in de basislijnarchitectuur via implementatieslots. Zorgvuldig toepassingsontwerp, schemabeheer en toepassingsconfiguratiebeheer zijn nodig om gelijktijdige slotimplementatie te ondersteunen. Gebruik deze POC om uw slot-gebaseerde productie-implementatiemethode te ontwerpen en te valideren.

  • Automatisch schalen is niet ingeschakeld in deze basisarchitectuur. Om betrouwbaarheidsproblemen te voorkomen die worden veroorzaakt door onvoldoende rekenresources, moet u overprovisioning uitvoeren om ervoor te zorgen dat er voldoende capaciteit is om de maximale gelijktijdige vraag af te handelen.

Zie Basislijn hoogbeschikbare zone-redundante webtoepassing - Betrouwbaarheid voor meer informatie over het overwinnen van deze betrouwbaarheidszorgen.

Als een workload een actief-actief of actief-passieve architectuur vereist over meerdere regio's, raadpleegt u Benaderingen van App Service-apps voor meerdere regio's voor herstel na noodgevallen.

Beveiliging

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

Deze architectuur is niet ontworpen voor productie-implementaties. De volgende essentiële beveiligingsfuncties zijn weggelaten in deze architectuur, samen met andere aanbevelingen en overwegingen voor betrouwbaarheid:

  • Deze basisarchitectuur implementeert geen netwerkprivacy. De gegevens- en beheervlakken voor de resources, zoals 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. Zie Basislijn maximaal beschikbare zone-redundante webtoepassing - Netwerken voor meer informatie over het implementeren van privénetwerken voor de volgende beveiligingsfuncties. Het implementeren van privénetwerken helpt deze risico's te beperken door de volgende beveiligingsfuncties te bieden:

    • Eén beveiligd toegangspunt voor clientverkeer.

    • Netwerkverkeer wordt gefilterd op zowel pakketniveau als op DDoS-niveau (Distributed Denial of Service).

    • Gegevensexfiltratie worden geminimaliseerd door verkeer in Azure te houden met behulp van Azure 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 baseline-implementatie om te zien hoe Azure Web Application Firewall kan worden geïmplementeerd met Azure Application Gateway in een App Services-architectuur.

  • In deze basisarchitectuur worden geheimen opgeslagen, zoals de SQL Server verbindingsreeks in App-instellingen. App-instellingen worden standaard versleuteld. Wanneer u echter overstapt op productie, kunt u overwegen geheimen op te slaan in Azure Key Vault voor meer governance. Voor sterkere beveiliging en minder overhead voor geheimbeheer kunt u overwegen om beheerde identiteit te gebruiken voor verificatie in plaats van geheimen in te sluiten in verbindingsreeksen.

  • Externe foutopsporing en Kudu-eindpunten kunnen ingeschakeld blijven tijdens de ontwikkeling of de POC-fase. Wanneer u naar productie gaat, moet u onnodige besturingsvlakken, implementaties of externe toegang uitschakelen.

  • Lokale verificatiemethoden voor SCM-site-implementaties (File Transfer Protocol) en source control management (SCM) kunnen ingeschakeld blijven tijdens de ontwikkeling of POC-fase. Wanneer u naar productie gaat, moet u lokale verificatie uitschakelen voor deze eindpunten.

  • U hoeft Microsoft Defender niet in te schakelen voor App Service in de POC-fase. Wanneer u overstapt naar de productieomgeving, moet u Defender for App Service inschakelen om beveiligingsaanbevelingen te genereren. U moet deze aanbevelingen implementeren om uw beveiligingspostuur te verhogen en om meerdere bedreigingen voor uw App Service-implementatie te detecteren.

  • App Service omvat een Secure Sockets Layer (SSL)-eindpunt op een subdomein van azurewebsites.net zonder extra kosten. HTTP-aanvragen worden standaard omgeleid naar het HTTPS-eindpunt. Voor productie-implementaties wordt doorgaans een aangepast domein gebruikt met Application Gateway of API Management vóór uw App Service-implementatie.

  • Gebruik het geïntegreerde verificatiemechanisme voor App Service. Easy Auth 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 workload-identiteiten. Beheerde identiteit elimineert de noodzaak voor ontwikkelaars om verificatiereferenties te beheren. De basisarchitectuur wordt geverifieerd bij SQL Server met behulp van een wachtwoord in een verbindingsreeks. Overweeg het gebruik van beheerde identiteit om te verifiëren bij SQL Server.

Zie Een app beveiligen in App Service voor meer informatie.

Kostenoptimalisatie

Kostenoptimalisatie richt zich op manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie controlelijst ontwerpbeoordeling voor kostenoptimalisatievoor meer informatie.

Deze architectuur optimaliseert kosten door de vele afwegingen ten opzichte van de andere pijlers van het Well-Architected Framework. Deze afwegingen worden specifiek gemaakt om te voldoen aan de leer- en POC-doelstellingen van deze architectuur. De kostenbesparingen ten opzichte van een meer productieklare architectuur, zoals de maximaal beschikbare zone-redundante basiswebtoepassing, zijn voornamelijk het gevolg van de volgende keuzes:

  • Een enkel App Service-exemplaar zonder autoscaling ingeschakeld.

  • Prijscategorie Standard voor App Service

  • Geen aangepast TLS-certificaat of statisch IP-adres

  • Geen WAF (Web Application Firewall)

  • Geen toegewezen opslagaccount voor toepassingsimplementatie

  • Basisprijscategorie voor SQL Database, zonder back-upretentiebeleid

  • Geen Microsoft Defender voor Cloud-onderdelen

  • Geen controle over uitgaand netwerkverkeer via een firewall

  • Geen privé-eindpunten

  • Minimale logboeken en bewaarperiode in Azure Monitor Logs

Als u de geschatte kosten van deze architectuur wilt bekijken, raadpleegt u de prijscalculatorschatting die gebruikmaakt van de onderdelen van deze architectuur. De kosten van deze architectuur kunnen meestal verder worden verlaagd met behulp van een Azure Dev/Test-abonnement, wat een ideaal abonnementstype zou zijn voor PC's zoals deze.

Operationele uitmuntendheid

Operational Excellence behandelt 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 over de 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. U kunt geheimen opslaan in de App Service-configuratie tijdens de POC-fase. U gebruikt geen echte geheimen en vereist geen geheimenbeheer waarvoor productieworkloads nodig zijn.

Houd rekening met de volgende aanbevelingen en overwegingen voor de configuratie:

  • Begin met het gebruik van App Service-configuratie om configuratiewaarden en verbindingsreeksen op te slaan in POC-implementaties. App-instellingen en verbindingsreeksen worden onmiddellijk versleuteld en ontsleuteld voordat ze worden opgenomen in uw app wanneer deze wordt gestart.

  • Wanneer u naar productie gaat, slaat u uw geheimen op in Key Vault. Key Vault verbetert het beheer van geheimen op twee manieren:

    • Het externaliseren van uw geheimen naar Key Vault biedt één centrale locatie voor veilig geheimbeheer.

    • Met behulp van Key Vault kunt u elke interactie met geheimen vastleggen, inclusief telkens wanneer een geheim wordt geopend.

  • Wanneer u overstapt naar productie, kunt u uw gebruik van zowel Key Vault als App Service-configuratie onderhouden met behulp van Key Vault verwijzingen.

Verpakkingen

U kunt de basisarchitectuur gebruiken om ondersteunde code rechtstreeks te implementeren op Windows- of Linux-exemplaren. App Service is ook een containerhostingplatform dat u kunt gebruiken om uw in een container geplaatste webtoepassing uit te voeren. App Service biedt verschillende ingebouwde containers. Aangepaste of apps met meerdere containers helpen de runtime-omgeving af te stemmen of codetalen te ondersteunen die niet systeemeigen worden ondersteund. Deze aanpak vereist de introductie van een containerregister.

Besturingsvlak

Verdiep jezelf tijdens de Proof of Concept (POC)-fase in de App Service beheeromgeving, die toegankelijk is via de Kudu-service. Deze service biedt algemene implementatie-API's, zoals ZIP-implementaties, en biedt onbewerkte logboeken en omgevingsvariabelen.

Als u containers gebruikt, moet u ervoor zorgen dat u begrijpt dat Kudu een SSH-sessie (Secure Shell) kan openen naar een container om geavanceerde foutopsporingsmogelijkheden te ondersteunen.

Diagnostiek en bewaking

Tijdens de POC-fase is het belangrijk om inzicht te krijgen in welke logboeken en metrische gegevens beschikbaar zijn voor vastleggen. Houd rekening met de volgende aanbevelingen en ideeën voor bewaking in de POC-fase:

  • Schakel diagnostische logboekregistratie in voor logboekbronnen voor alle items. Als u het gebruik van alle diagnostische instellingen configureert, krijgt u inzicht in de logboeken en metrische gegevens die u direct voor u krijgt en kunt u eventuele hiaten identificeren die u moet sluiten met behulp van een logboekframework in uw toepassingscode. Wanneer u naar productie gaat, elimineert u logboekbronnen die geen waarde toevoegen, maar voegt u ruis en kosten toe 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.

  • Gebruik een statusmodel dat meerdere gecorreleerde signalen samenvoegt in statusstatussen. Waarschuwingen verzenden op basis van statusovergangen in uw architectuur, niet op geïsoleerde metrische drempelwaarden. Azure Monitor-gezondheidsmodellen helpen u bij het definiëren, meten en visualiseren van de gezondheid van workloads door metrische gegevens, loggegevens en traceringen te correleren tot bruikbare gezondheidsstatussen voor Azure-resources en -onderdelen.

    In deze architectuur verzamelt het statusmodel signalen van de App Service- en SQL Database-resources en de toepassingsonderdelen die zijn geïmplementeerd in App Service. Het evalueert beschikbaarheid en latentie, databaseconnectiviteit en queryprestaties, geslaagde verificatiepercentages en relevante signalen op toepassingsniveau. Elke entiteit in het model geeft een gezondheidsstatus af, die door afhankelijkheidsketens wordt doorgegeven en samengevoegd tot één indicator op topniveau voor de algehele gezondheid van de workload.

Implementatie

De volgende punten bieden 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 continue integratie en continue levering (CI/CD) vroeg in het ontwikkelingsproces te implementeren, kunt u uw toepassing snel en veilig herhalen terwijl u naar productie gaat.

  • Gebruik Azure Resource Manager-sjablonen (ARM-sjablonen) om Azure resources en de bijbehorende 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 ze 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 ontwerpprincipes van Operational Excellence voor meer informatie.

Prestatie-efficiëntie

Prestatie-efficiëntie verwijst naar de mogelijkheid van uw workload om efficiënt te voldoen aan de behoeften van de gebruiker. Zie de controlelijst ontwerpbeoordeling voor prestatie-efficiëntie voor meer informatie.

Omdat deze architectuur niet is ontworpen voor productie-implementaties, worden in deze sectie 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 POC moet een SKU-selectie zijn die u schat, geschikt is voor uw workload. Ontwerp uw werkbelasting om efficiënt te voldoen aan de vraag middels horizontale schaalvergroting door het aantal geïmplementeerde rekeninstanties in het App Service plan aan te passen. Ontwerp het systeem niet om afhankelijk te zijn van het wijzigen van de reken-SKU zodat deze overeenkomt met de vraag.

  • Voor de App Service-implementatie in deze basisarchitectuur is automatisch schalen niet geïmplementeerd. De service wordt niet dynamisch uitgeschaald of ingeschaald om efficiënt te blijven afgestemd op de vraag.

    • De Standaard-laag ondersteunt instellingen voor automatisch schalen, zodat u automatisch schalen op basis van regels kunt configureren. Bepaal als onderdeel van uw POC-proces efficiënte instellingen voor automatisch schalen die zijn afgestemd op de resourcevereisten van uw toepassingscode en verwachte gebruikspatronen.

    • Voor productie-implementaties kunt u Premium-lagen overwegen die ondersteuning bieden voor automatisch schalen , 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.

Volgende stappen

Zelfstudies voor implementatie:

Productdocumentatie:

Microsoft Learn-modules: