Bewerken

Algemene webtoepassing

Azure App Service
Azure Key Vault
Azure Monitor
Azure SQL Database

Deze architectuur toont de fundamentele onderdelen van een eenvoudige webtoepassing. U kunt de architectuur gebruiken om een webtoepassing te bouwen en vervolgens de toepassing aan te passen aan uw behoeften.

Architectuur

Diagram showing the reference architecture for a basic web application in Azure.

Een Visio-bestand van deze architectuur downloaden.

Onderdelen

  • Azure App Service is een volledig beheerd platform voor het maken en implementeren van cloudtoepassingen. Hiermee kunt u een set rekenresources definiëren voor een web-app om uit te voeren, web-apps te implementeren en implementatiesites te configureren.
  • Met implementatiesites kunt u een implementatie faseeren en deze vervolgens wisselen met de productie-implementatie. Op deze manier voorkomt u rechtstreekse implementatie op de productiesite. Zie de sectie release-engineering en -implementatie hieronder voor specifieke aanbevelingen.
  • IP-adres: de App Service-app heeft een openbaar IP-adres en een domeinnaam. De domeinnaam is een subdomein van azurewebsites.net, zoals contoso.azurewebsites.net.
  • Azure DNS is een service voor het hosten van DNS-domeinen die naamomzetting biedt met behulp van de Microsoft Azure-infrastructuur. Door uw domeinen in Azure te hosten, kunt u uw DNS-records met dezelfde referenties, API's, hulpprogramma's en facturering beheren als voor uw andere Azure-services. Als u een aangepaste domeinnaam wilt gebruiken (zoals contoso.com), maakt u DNS-records die de aangepaste domeinnaam toewijzen aan het IP-adres. Zie Configure a custom domain name in Azure App Service (Een aangepaste domeinnaam configureren in Azure App Service) voor meer informatie.
  • Azure SQL Database is een relationele database-as-a-service in de cloud. SQL Database deelt de codebasis met de database-engine van Microsoft SQL Server. Afhankelijk van uw toepassingsvereisten kunt u ook Azure Database for MySQL of Azure Database for PostgreSQL gebruiken. Deze alternatieven zijn volledig beheerde databaseservices op basis van de open-source MySQL-server- en Postgres-database-engines.
  • Microsoft Entra ID is een cloudservice voor identiteits- en toegangsbeheer waarmee werknemers toegang hebben tot cloud-apps die zijn ontwikkeld voor uw organisatie.
  • Azure Monitor is een oplossing voor het verzamelen, analyseren en uitvoeren van logboeken en metrische gegevens in uw omgevingen.
  • Azure Key Vault biedt ondersteuning voor geheimenbeheer, sleutelbeheer en certificaatbeheer. Het kan toepassingsgeheimen opslaan, zoals database-verbindingsreeks s.

Aanbevelingen

Uw vereisten kunnen afwijken van de architectuur die in de code wordt beschreven en opgegeven. De code wordt geïmplementeerd met productieconfiguraties. Gebruik de aanbevelingen om uw implementatie aan te passen aan uw behoeften.

App Service-plan

Het App Service-plan heeft verschillende prijscategorieën. Elke prijscategorie ondersteunt verschillende instantiegrootten die verschillen per aantal kernen en geheugen. U kunt de prijscategorie na de implementatie wijzigen door 'Omhoog schalen (App Service-plan)' te selecteren in het linkernavigatievenster. Hier volgen enkele Aanbevelingen voor App Service:

  • Voer uw productieworkload uit op de prijscategorieën Basic, Standard en Premium . In deze drie lagen wordt de app uitgevoerd op toegewezen vm-exemplaren en heeft de app resources toegewezen die kunnen worden uitgeschaald.
  • Gebruik de Standard - en Premier-lagen als u automatische schaalaanpassing en TLS/SSL nodig hebt.
  • Maak een ander App Service-plan voor testen en ontwikkelen. Gebruik de lagen Gratis en Gedeeld (preview) voor testen en ontwikkelen voor kostenefficiëntie. Gebruik echter niet de gratis en gedeelde lagen voor productieworkloads. Gedeelde resources kunnen niet worden uitgeschaald.
  • Zorg ervoor dat u plannen verwijdert die u niet gebruikt, zoals het testen van implementaties. App Service-abonnementen worden per seconde gefactureerd. Er worden kosten in rekening gebracht voor de exemplaren in het App Service-plan, zelfs als de app is gestopt. Zie voor meer informatie over App Service-abonnementen en -facturering:

De onderstaande ARM-sjabloon wordt geïmplementeerd in de prijscategorie Standard.

SQL Database

  • Gebruik Azure SQL Database om de beheeroverhead te verminderen. Azure SQL Database maakt een logische constructie die fungeert als een centraal beheerpunt voor een verzameling databases. Deze logische constructie vermindert de beheeroverhead. Elke database in de groep wordt geïmplementeerd met een specifieke servicelaag. Binnen elke groep kunnen de databases geen resources delen. Er zijn geen rekenkosten voor de server, maar u moet de laag voor elke database opgeven. Daarom kunnen de prestaties beter zijn vanwege de toegewezen resources, maar de kosten kunnen hoger zijn.
  • Plan de capaciteiten, en kies een laag en prestatieniveau die voldoen aan uw vereisten. SQL Database biedt ondersteuning voor de servicelagen Basic, Standard en Premium, met meerdere prestatieniveaus binnen elke laag die worden gemeten in DTU’s (Database Transaction Units).

Regio

  • Maak het App Service-plan en de SQL Database in dezelfde regio om de netwerklatentie te minimaliseren. In het algemeen kiest u de regio die het meest in de buurt van uw gebruikers is.
  • De resourcegroep heeft ook een regio. Hiermee geeft u op waar de metagegevens van de implementatie worden opgeslagen. Plaats de resourcegroep en de bijbehorende resources in dezelfde regio om de beschikbaarheid tijdens de implementatie te verbeteren.
  • Gebruik de prijscalculator om de kosten te schatten.
  • Raadpleeg de kostensectie in Microsoft Azure Well-Architected Framework voor meer informatie.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. De pijlers zijn een set richtlijnen die de kwaliteit van een workload verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Prestatie-efficiëntie

Een groot voordeel van Azure App Service is de mogelijkheid om uw toepassing te schalen op basis van de belasting. Hier volgen enkele overwegingen om rekening mee te houden bij het plannen van het schalen van uw toepassing.

De App Service-app schalen

Er zijn twee manieren om een App Service-app te schalen:

  • Omhoog schalen betekent dat de instantiegrootte wordt gewijzigd. De instantiegrootte bepaalt het geheugen, het aantal kerngeheugens en de opslag op elke VM-instantie. U kunt handmatig omhoog schalen door de instantiegrootte of planlaag te wijzigen.
  • Uitschalen betekent het toevoegen van exemplaren voor het afhandelen van een verhoogde belasting. Elke prijslaag heeft een maximum aantal instanties. U kunt uitschalen door het aantal exemplaren handmatig te wijzigen of door automatisch schalen te configureren zodat Azure automatisch exemplaren toevoegt of verwijdert op basis van een schema en/of metrische prestatiegegevens. Elke schaalbewerking vindt snel plaats, meestal binnen enkele seconden.

Als u automatisch schalen wilt inschakelen, maakt u een profiel voor automatische schaalaanpassing waarmee het minimum- en maximumaantal exemplaren wordt gedefinieerd. U kunt profielen op basis van een planning instellen om schaalgebeurtenissen te activeren. U kunt bijvoorbeeld afzonderlijke profielen maken voor weekdagen en weekenden. Een profiel kan regels bevatten voor het toevoegen of verwijderen van exemplaren. Voeg bijvoorbeeld twee exemplaren toe als het CPU-gebruik gedurende vijf minuten hoger is dan 70%.

Aanbevelingen voor het schalen van een web-app:

  • Beperk omhoog en omlaag schalen zoveel mogelijk. Het kan een toepassing opnieuw opstarten activeren. Schaal in plaats daarvan uit. Selecteer een laag en grootte die voldoet aan uw prestatievereisten onder normale belasting en schaal vervolgens de exemplaren uit om wijzigingen in het verkeersvolume te verwerken.
  • Schakel automatisch schalen in. Als uw toepassing een voorspelbare, reguliere workload heeft, maakt u profielen om het aantal instanties van tevoren te plannen. Als de workload niet voorspelbaar is, gebruikt u automatisch schalen op basis van regels om te reageren op wijzigingen in de belasting wanneer deze optreden. U kunt beide benaderingen combineren.
  • Gebruik CPU-gebruik voor regels voor automatisch schalen. CPU-gebruik is gewoonlijk een goede meetwaarde voor regels voor automatisch schalen. Het is wel raadzaam om de belasting voor de toepassing te testen, mogelijke knelpunten te identificeren, en de regels voor automatisch schalen te baseren op deze gegevens.
  • Stel een kortere afkoelperiode in voor het toevoegen van exemplaren en een langere afkoelperiode voor het verwijderen van exemplaren. Regels voor automatisch schalen bevatten een afkoelperiode . De afkoelperiode is het interval dat moet worden gewacht nadat een schaalactie is voltooid voordat een nieuwe schaalactie wordt gestart. Dankzij de afkoelperiode kan het systeem stabiliseren voordat er opnieuw wordt geschaald. Stel bijvoorbeeld 5 minuten in voor het toevoegen van een instantie, maar 60 minuten voor het verwijderen van een instantie. Het is beter om snel nieuwe exemplaren toe te voegen onder zware belasting om het extra verkeer te verwerken en vervolgens geleidelijk terug te schalen.

SQL-databases schalen

Schaal afzonderlijke databases omhoog zonder uitvaltijd van toepassingen als u een hogere servicelaag of een hoger prestatieniveau nodig hebt voor SQL Database.

Zie Resources voor het schalen van één database in Azure SQL Database voor meer informatie.

Betrouwbaarheid

Op het moment van schrijven is de SLA (Service Level Agreement) voor App Service 99,95%. De App Service-SLA geldt voor zowel één als meerdere instanties. De SLA voor SQL Database is 99,99% voor Basic-, Standard- en Premium-lagen.

Back-ups

SQL Database biedt herstel naar een bepaald tijdstip en geo-herstel om gegevensverlies te herstellen. Deze functies zijn beschikbaar in alle lagen en zijn automatisch ingeschakeld. U hoeft geen back-ups te plannen of te beheren.

  • Gebruik herstel naar een bepaald tijdstip. U kunt herstellen van menselijke fouten door de database terug te keren naar een eerder tijdstip.
  • Geo-herstel gebruiken. U kunt herstellen na een servicestoring door een database te herstellen vanuit een geografisch redundante back-up.
  • Overweeg back-up en herstel van App Service te gebruiken. Back-up en herstel is een functie voor uw toepassingsbestanden. De back-upbestanden bevatten echter app-instellingen in tekst zonder opmaak, zoals verbindingsreeks s.
  • Vermijd het gebruik van de App Service-back-upfunctie om een back-up te maken van uw SQL-databases. De database wordt geëxporteerd naar een SQL BACPAC-bestand, met DTU's. Gebruik in plaats hiervan herstel naar een bepaald tijdstip van SQL Database, een functie die hierboven wordt beschreven. Zie de bedrijfscontinuïteit van de cloud en herstel na noodgevallen van databases met SQL Database voor meer informatie.

Operationele uitmuntendheid

Maak afzonderlijke resourcegroepen voor productie-, ontwikkelings- en testomgevingen. Door omgevingen te scheiden, kunt u eenvoudiger implementaties beheren, testimplementaties verwijderen en toegangsrechten toewijzen.

Houd rekening met de volgende functies bij het toewijzen van resources aan resourcegroepen:

  • Levenscyclus. In het algemeen kunt u resources met dezelfde levenscyclus het beste in dezelfde resourcegroep onderbrengen.
  • Toegang. U kunt op rollen gebaseerd toegangsbeheer (RBAC) van Azure gebruiken om toegangsbeleid toe te passen op de resources in een groep.
  • Facturering. U kunt de samengevoegde kosten voor de resourcegroep bekijken.

Zie voor meer informatie Overzicht van Azure Resource Manager.

App-configuraties

  • Sla configuratie-instellingen op als app-instellingen. Definieer de app-instellingen in uw Resource Manager-sjablonen of gebruik PowerShell. Tijdens het uitvoeren zijn app-instellingen beschikbaar voor de toepassing als omgevingsvariabelen.
  • Schakel wachtwoorden, toegangstoetsen of verbindingsreeksen nooit in broncodebeheer in. Geef in plaats daarvan geheimen door als parameters aan een implementatiescript waarin deze waarden als app-instellingen worden opgeslagen.
  • Wanneer u een implementatiesite wisselt, worden de app-instellingen standaard ook gewisseld. Als u verschillende productie- en faseringsinstellingen nodig hebt, kunt u app-instellingen maken die zich aan een site houden en niet worden gewisseld.

Diagnose en controle

DevOps

  • Arm-sjablonen gebruiken om Azure-resources en hun afhankelijkheden te implementeren. Met de bijbehorende ARM-sjabloon wordt één webtoepassing geïmplementeerd. Alle resources worden geïsoleerd in dezelfde basisworkload. Dankzij deze isolatie is het eenvoudiger om de specifieke resources van de workload aan een team te koppelen. Het team kan vervolgens onafhankelijk alle aspecten van deze resources beheren. Dankzij deze isolatie kan het DevOps-team continue integratie en continue levering (CI/CD) uitvoeren.
  • Gebruik verschillende ARM-sjablonen en integreer deze met Azure DevOps-services. Met deze installatie kunt u binnen enkele minuten verschillende omgevingen maken. U kunt bijvoorbeeld productieachtige scenario's of testomgevingen voor belasting alleen repliceren wanneer dat nodig is en kosten besparen.
  • Richt meerdere exemplaren van de webtoepassing in. U wilt niet dat uw web-app afhankelijk is van één exemplaar en mogelijk een single point of failure maakt. Meerdere exemplaren verbeteren de tolerantie en schaalbaarheid.

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

Release-engineering en -implementatie

  • Gebruik Azure Resource Manager-sjablonen om Azure-resources in te richten. Met sjablonen kunt u eenvoudiger implementaties automatiseren via PowerShell of de Azure CLI.
  • Implementeer de toepassing (code, binaire bestanden en inhoudsbestanden). U hebt verschillende opties, waaronder implementeren vanuit een lokale Git-opslagplaats, via Visual Studio, of continue implementatie vanuit broncodebeheer in de cloud. Zie Deploy your app to Azure App Service (Uw app implementeren in Azure App Service).

Een App Service-app heeft altijd één implementatiesite met de naam production. De productiesite vertegenwoordigt de live productiesite. We raden u aan om een staging-site te maken voor het implementeren van updates. De voordelen van het gebruik van een staging-site zijn:

  • U kunt controleren of de implementatie is voltooid voordat u deze overwisselt naar productie.
  • Door te implementeren op een staging-site kunt u controleren of alle instanties juist werken voordat ze in productie komen. Veel toepassingen hebben een aanzienlijke opwarm- en koude starttijd.
  • Maak een derde site voor de laatste bekende implementatie. Nadat u de fasering en de productie hebt gewisseld, verplaatst u de vorige productie-implementatie (die nu gefaseerd wordt uitgevoerd) naar de site voor de laatste bekende juiste implementatie. Op deze manier kunt u, als u later een probleem ontdekt, snel terugkeren naar de laatst bekende juiste versie.

Swapping slots for production and staging deployments

  • Als u terugkeert naar een vorige versie, moet u ervoor zorgen dat eventuele wijzigingen in het databaseschema compatibel zijn met eerdere versies.
  • Gebruik geen testsites in de productie-implementatie, omdat alle apps in hetzelfde App Service-plan dezelfde VM-instanties delen. Belastingstests kunnen bijvoorbeeld de live productiesite verminderen. Maak in plaats hiervan afzonderlijke App Service-plannen voor productie en testen. Door testimplementaties in een afzonderlijk plan te plaatsen, isoleert u deze van de productieversie.

Beveiliging

In deze sectie vindt u beveiligingsoverwegingen die specifiek zijn bedoeld voor de Azure-services die worden beschreven in dit artikel. Het is geen volledige lijst met aanbevolen procedures voor beveiliging. Zie Een app beveiligen in Azure-app Service voor andere beveiligingsoverwegingen.

SQL Database Auditing

Dankzij controles kunt u zorgen voor naleving van wet- en regelgeving, en krijgt u inzicht in de discrepanties en onregelmatigheden die kunnen wijzen op problemen voor het bedrijf of vermoedelijke schendingen van de beveiliging. Zie Get started with SQL database auditing (Aan de slag met SQL Database Auditing).

Implementatiesites

Elke implementatiesite heeft een openbaar IP-adres. Beveilig de niet-productiesites met behulp van de Microsoft Entra-aanmelding , zodat alleen leden van uw ontwikkel- en DevOps-teams deze eindpunten kunnen bereiken.

Logboekregistratie

Leg nooit wachtwoorden van gebruikers of andere informatie die kan worden gebruikt voor identiteitsfraude, vast in logboeken. Wis deze details uit de gegevens voordat u ze opslaat.

SSL

Een App Service-app bevat een SSL-eindpunt op een subdomein zonder azurewebsites.net extra kosten. Het SSL-eindpunt bevat een jokertekencertificaat voor het domein *.azurewebsites.net. Als u een aangepaste domeinnaam gebruikt, moet u een certificaat opgeven dat overeenkomt met het aangepaste domein. De eenvoudigste methode hiervoor is om rechtstreeks in Azure Portal een certificaat aan te schaffen. U kunt certificaten ook importeren uit andere certificeringsinstanties. Zie een SSL-certificaat kopen en configureren voor uw Azure-app Service voor meer informatie.

HTTPS is niet standaard ingeschakeld in de ARM-sjabloonimplementatie. Het is een aanbevolen procedure om met de app HTTPS af te dwingen door HTTP-aanvragen om te leiden. U kunt HTTPS in uw toepassing implementeren of een regel voor het herschrijven van URL's gebruiken, zoals beschreven in HTTPS inschakelen voor een app in Azure-app Service.

Verificatie

We raden u aan om te verifiëren via een id-provider (IDP), zoals Microsoft Entra ID, Facebook, Google of Twitter. Gebruik OAuth 2 of OIDC (OpenID Connect) voor de verificatiestroom. Microsoft Entra ID biedt functionaliteit voor het beheren van gebruikers en groepen, het maken van toepassingsrollen, het integreren van uw on-premises identiteiten en het verbruiken van back-endservices zoals Microsoft 365 en Skype voor Bedrijven.

Vermijd dat de toepassing gebruikersaanmelding en -referenties rechtstreeks beheert. Het creëert een potentieel kwetsbaarheid voor aanvallen. U moet minimaal een e-mailbevestiging, wachtwoordherstel en meervoudige verificatie hebben, wachtwoordsterkte valideren en wachtwoordhashes veilig opslaan. De grote id-providers verwerken al deze dingen voor u en controleren en verbeteren hun beveiligingsprocedures voortdurend.

Overweeg het gebruik van App Service-verificatie om de OAuth- of OIDC-verificatiestroom te implementeren. Een aantal voordelen van App Service-verificatie:

  • Eenvoudig te configureren.
  • Geen code vereist voor eenvoudige verificatiescenario's.
  • Ondersteunt gedelegeerde autorisatie met OAuth-toegangstokens voor het gebruik van resources namens de gebruiker.
  • Biedt een ingebouwde tokencache.

Een aantal beperkingen van App Service-verificatie:

  • Beperkte aanpassingsopties.
  • Gedelegeerde autorisatie is beperkt tot één back-endresource per aanmeldingssessie.
  • Als u meer dan één IDP gebruikt, is er geen ingebouwd mechanisme voor detectie van thuisrealm.
  • In scenario’s met meerdere tenants, moet voor de toepassing de logica worden geïmplementeerd om de uitgever van het token te valideren.

Dit scenario implementeren

Deze architectuur bevat een Azure-app Service-plan en een lege toepassing. Azure SQL Database, Azure Key Vault wordt gebruikt voor het opslaan van de database verbindingsreeks en Azure Monitor voor logboekregistratie, bewaking en waarschuwingen.

Gebruik de volgende opdracht om een resourcegroep te maken voor de implementatie. Selecteer de knop Uitproberen om een ingesloten shell te gebruiken.

az group create --name basic-web-app --location eastus

Voer de volgende opdracht uit om de webtoepassing en ondersteunende infrastructuur te implementeren. Voer een gebruikersnaam en wachtwoord in wanneer u hierom wordt gevraagd. Deze waarden worden gebruikt voor toegang tot het Azure SQL Database-exemplaar.

az deployment group create --resource-group basic-web-app  \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/basic-web-app/azuredeploy.json

Zie de ARM-sjablonen die worden gebruikt om deze oplossing te implementeren voor gedetailleerde informatie en meer implementatieopties.

ARM-sjabloon basiswebtoepassing

Volgende stappen

Tips voor het oplossen van problemen met uw toepassing:

  • Gebruik de blade Problemen oplossen in Azure Portal om oplossingen te vinden voor bekende problemen.
  • Schakel logboekstreaming in om logboekgegevens in bijna realtime weer te geven.
  • Het Kudu-dashboard heeft verschillende hulpprogramma’s voor het controleren en opsporen van fouten in de toepassing. Zie Azure Websites online tools you should know about (Onlinehulpprogramma’s voor Azure Websites die u zou moeten kennen) (blogpost) voor meer informatie. U kunt het Kudu-dashboard bereiken via Azure Portal. Open de blade voor uw app en selecteer Extra en selecteer Vervolgens Kudu.
  • Als u Visual Studio gebruikt, raadpleegt u het artikel Troubleshoot a web app in Azure App Service using Visual Studio (Problemen met een web-app in Azure App Service oplossen met behulp van Visual Studio) voor tips over het opsporen van fouten en het oplossen van problemen.

Productdocumentatie:

Microsoft Learn-modules: