Redigera

Grundläggande webbprogram

Azure App Service
Azure Key Vault
Azure Monitor
Azure SQL Database

Den här arkitekturen visar de grundläggande komponenterna i ett grundläggande webbprogram. Du kan använda arkitekturen för att skapa ett webbprogram och sedan anpassa programmet efter dina behov.

Arkitektur

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

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

Komponenter

  • Azure App Service är en helt hanterad plattform för att skapa och distribuera molnprogram. Med den kan du definiera en uppsättning beräkningsresurser för en webbapp som ska köras, distribuera webbappar och konfigurera distributionsplatser.
  • Med distributionsfack kan du mellanlagra en distribution och sedan växla den med produktionsdistributionen. På så sätt undviker du att distribuera direkt till produktionen. Se avsnittet versionstekniker och distribution nedan för specifika rekommendationer.
  • IP-adress: App Service-appen har en offentlig IP-adress och ett domännamn. Domännamnet är en underdomän till azurewebsites.net, t.ex. contoso.azurewebsites.net.
  • Azure DNS är en värdtjänst för DNS-domäner som ger namnmatchning med hjälp av Microsoft Azure-infrastrukturen. Genom att använda Azure som värd för dina domäner kan du hantera dina DNS-poster med samma autentiseringsuppgifter, API:er, verktyg och fakturering som för dina andra Azure-tjänster. Om du vill använda ett anpassat domännamn (till exempel contoso.com) skapar du DNS-poster som mappar det anpassade domännamnet till IP-adressen. Mer information finns i Konfigurera ett anpassat domännamn i Azure App Service.
  • Azure SQL Database är en relationsdatabas som en tjänst i molnet. SQL-databas delar sin kodbas med Microsoft SQL Server-databasmotorn. Beroende på dina programkrav kan du också använda Azure Database for MySQL eller Azure Database for PostgreSQL. De här alternativen är fullständigt hanterade databastjänster baserade på databasmotorerna MySQL Server och Postgres med öppen källkod.
  • Microsoft Entra ID är en molnbaserad identitets- och åtkomsthanteringstjänst som ger anställda åtkomst till molnappar som utvecklats för din organisation.
  • Azure Monitor är en lösning för att samla in, analysera och agera på loggar och mått i dina miljöer.
  • Azure Key Vault stöder hantering av hemligheter, nyckelhantering och certifikathantering. Den kan lagra programhemligheter som databas anslutningssträng.

Rekommendationer

Dina krav kan skilja sig från den arkitektur som beskrivs och anges i koden. Koden distribueras med produktionskonfigurationer. Använd rekommendationerna för att anpassa distributionen efter dina behov.

App Service-plan

App Service-planen har olika prisnivåer. Varje prisnivå stöder flera instansstorlekar som skiljer sig mellan antalet kärnor och minne. Du kan ändra prisnivån efter distributionen genom att välja "Skala upp (App Service-plan)" i det vänstra navigeringsfältet. Här följer några App Service-rekommendationer:

  • Kör produktionsarbetsbelastningen på prisnivåerna Basic, Standard och Premium . På dessa tre nivåer körs appen på dedikerade virtuella datorinstanser och har allokerat resurser som kan skalas ut.
  • Använd nivåerna Standard och Premier om du behöver autoskalning och TLS/SSL.
  • Skapa en annan App Service-plan för testning och utveckling. Använd nivåerna Kostnadsfri och Delad (förhandsversion) för testning och utveckling för kostnadseffektivitet. Men använd inte nivåerna Kostnadsfri och Delad för produktionsarbetsbelastningar. Delade resurser kan inte skalas ut.
  • Se till att ta bort planer som du inte använder, till exempel testa distributioner. App Service-planer faktureras per sekund. Du debiteras för instanserna i App Service-planen även om appen stoppas. Mer information om App Service-planer och fakturering finns i:

ARM-mallen nedan distribueras till prisnivån Standard.

SQL Database

  • Använd Azure SQL Database för att minska hanteringskostnaderna. Azure SQL Database skapar en logisk konstruktion som fungerar som en central administrativ plats för en samling databaser. Den här logiska konstruktionen minskar hanteringskostnaderna. Varje databas i gruppen distribueras med en specifik tjänstnivå. I varje grupp kan databaserna inte dela resurser. Det finns inga beräkningskostnader för servern, men du måste ange nivån för varje databas. Därför kan prestandan vara bättre på grund av de dedikerade resurserna, men kostnaden kan vara högre.
  • Utför kapacitetsplanering och välj en tjänst- och prestandanivå som uppfyller dina krav. SQL Database har stöd för tjänstnivåerna Basic, Standard och Premium, med flera prestandanivåer inom varje nivå, som mäts i databastransaktionsenheter (DTU).

Region

  • Skapa App Service-planen och SQL Database i samma region för att minimera nätverksfördröjningen. Du väljer normalt den region som är närmast dina användare.
  • Resursgruppen har också en region. Den anger var distributionsmetadata lagras. Placera resursgruppen och dess resurser i samma region för att förbättra tillgängligheten under distributionen.
  • Använd priskalkylatorn för att beräkna kostnader.
  • Mer information finns i kostnadsavsnittet i Microsoft Azures välstrukturerade ramverk.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework. Grundpelarna är en uppsättning vägledande grundsatser som förbättrar kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Prestandaeffektivitet

En stor fördel med Azure App Service är möjligheten att skala programmet baserat på belastning. Följande är några saker att tänka på när du planerar att skala programmet.

Skala App Service-appen

Det finns två sätt att skala en App Service-app:

  • Skala upp innebär att ändra instansstorleken. Instansstorleken avgör minne, antal kärnor och lagring på varje VM-instans. Du kan skala upp manuellt genom att ändra instansstorleken eller plannivån.
  • Skala ut innebär att lägga till instanser för att hantera ökad belastning. Varje prisnivå har ett maximalt antal instanser. Du kan skala ut genom att manuellt ändra antalet instanser eller genom att konfigurera automatisk skalning så att Azure automatiskt lägger till eller tar bort instanser baserat på ett schema och/eller prestandamått. Varje skalningsåtgärd sker snabbt, vanligtvis inom några sekunder.

Om du vill aktivera autoskalning skapar du en profil för autoskalning som definierar det lägsta och högsta antalet instanser. Du kan konfigurera schemabaserade profiler för att utlösa skalningshändelser. Du kan till exempel skapa separata profiler för vardagar och helger. En profil kan innehålla regler för när instanser ska läggas till eller tas bort. Du kan till exempel lägga till två instanser om CPU-användningen är över 70 % i 5 minuter.

Rekommendationer för att skala ett webbprogram:

  • Begränsa upp- och nedskalning så mycket som möjligt. Det kan utlösa en omstart av programmet. Skala ut i stället. Välj en nivå och storlek som uppfyller dina prestandakrav under typisk belastning och skala sedan ut instanserna för att hantera ändringar i trafikvolymen.
  • Aktivera automatisk skalning. Om programmet har en förutsägbar, vanlig arbetsbelastning kan du skapa profiler för att schemalägga antalet instanser i förväg. Om arbetsbelastningen inte är förutsägbar använder du regelbaserad autoskalning för att reagera på ändringar i belastningen när de inträffar. Du kan kombinera båda metoderna.
  • Använd CPU-användning för regler för automatisk skalning. CPU-användning är vanligtvis ett bra mått för autoskalningsregler. Du bör dock belastningstesta programmet, identifiera potentiella flaskhalsar och basera autoskalningsreglerna på dessa data.
  • Ange en kortare nedkylningsperiod för att lägga till instanser och en längre nedkylningsperiod för att ta bort instanser. Regler för autoskalning innehåller en nedkylningsperiod . Nedkylningsperioden är intervallet som ska vänta efter att en skalningsåtgärd har slutförts innan en ny skalningsåtgärd startas. Nedkylningsperioden gör att systemet hinner stabiliseras innan skalning utförs igen. Du kan till exempel ange 5 minuter för att lägga till en instans, men 60 minuter för att ta bort en instans. Det är bättre att lägga till nya instanser snabbt under tung belastning för att hantera den extra trafiken och sedan gradvis skala tillbaka.

Skala SQL-databaser

Skala upp enskilda databaser utan programavbrott om du behöver en högre tjänstnivå eller prestandanivå för SQL Database.

Mer information finns i Skala enkla databasresurser i Azure SQL Database.

Tillförlitlighet

I skrivande stund är serviceavtalet (SLA) för App Service 99,95 %. Serviceavtalet för App Service gäller både enstaka och flera instanser. Serviceavtalet för SQL Database är 99,99 % för nivåerna Basic, Standard och Premium.

Säkerhetskopior

SQL Database tillhandahåller återställning till tidpunkt och geo-återställning för att återställa dataförlust. De här funktionerna är tillgängliga på alla nivåer och aktiveras automatiskt. Du behöver inte schemalägga eller hantera säkerhetskopieringar.

Driftsäkerhet

Skapa separata resursgrupper för produktions-, utvecklings- och testmiljöer. Genom att separera miljöer blir det enklare att hantera distributioner, ta bort testdistributioner och tilldela åtkomsträttigheter.

När du tilldelar resurser till resursgrupper bör du överväga följande funktioner:

  • Livscykel. I allmänhet ska du placera resurser med samma livscykel i samma resursgrupp.
  • Åtkomst. Du kan använda rollbaserad åtkomstkontroll i Azure (RBAC) för att tillämpa åtkomstprinciper på resurserna i en grupp.
  • Fakturering. Du kan visa de samlade kostnaderna för resursgruppen.

Mer information finns i Översikt över Azure Resource Manager.

Appkonfigurationer

  • Lagra konfigurationsinställningar som appinställningar. Definiera appinställningarna i dina Resource Manager-mallar eller med hjälp av PowerShell. Appinställningarna är tillgängliga för programmet som miljövariabler under körning.
  • Lägg aldrig in lösenord, åtkomstnycklar eller anslutningssträngar i källkontrollen. Skicka i stället hemligheter som parametrar till ett distributionsskript som lagrar dessa värden som appinställningar.
  • När du växlar en distributionsplats kommer appinställningarna att växlas som standard. Om du behöver olika produktions- och mellanlagringsinställningar kan du skapa appinställningar som håller sig till ett fack och inte byts ut.

Diagnostik och övervakning

DevOps

  • Använd ARM-mallar för att distribuera Azure-resurser och deras beroenden. Den medföljande ARM-mallen distribuerar ett enda webbprogram. Alla resurser är isolerade i samma grundläggande arbetsbelastning. Den här isoleringen gör det enklare att associera arbetsbelastningens specifika resurser till ett team. Teamet kan sedan självständigt hantera alla aspekter av dessa resurser. Den här isoleringen gör det möjligt för DevOps-teamet att utföra kontinuerlig integrering och kontinuerlig leverans (CI/CD).
  • Använd olika ARM-mallar och integrera dem med Azure DevOps-tjänster. Med den här konfigurationen kan du skapa olika miljöer på några minuter. Du kan till exempel bara replikera produktionsliknande scenarier eller belastningstestningsmiljöer när det behövs och spara på kostnaden.
  • Etablera flera instanser av webbprogrammet. Du vill inte att webbappen ska vara beroende av en enda instans och eventuellt skapa en enskild felpunkt. Flera instanser förbättrar återhämtning och skalbarhet.

Mer information finns i avsnittet DevOps i Azure Well-Architected Framework.

Versionstekniker och distribution

  • Använd Azure Resource Manager-mallar för att etablera Azure-resurser. Mallar gör det enklare att automatisera distributioner via PowerShell eller Azure CLI.
  • Distribuera programmet (kod, binärfiler och innehållsfiler). Det finns flera alternativ, inklusive distribution från ett lokalt Git-lager, använda Visual Studio eller kontinuerlig distribution från molnbaserad källkontroll. Se Distribuera din app till Azure App Service.

En App Service-app har alltid ett distributionsfack med namnet production. Produktionsplatsen representerar den aktiva produktionsplatsen. Vi rekommenderar att du skapar en mellanlagringsplats för att distribuera uppdateringar. Fördelarna med att använda en mellanlagringsplats är bland annat:

  • Du kan kontrollera att distributionen lyckades innan du byter den till produktion.
  • Distribution till en mellanlagringsplats säkerställer att alla instanser är uppvärmda innan de växlas till produktion. Många program har en betydande uppvärmning och kall starttid.
  • Skapa ett tredje fack för att lagra den senaste kända distributionen. När du växlar mellan mellanlagring och produktion flyttar du den föregående produktionsdistributionen (som nu är i mellanlagringen) till platsen för senaste fungerande. Om du upptäcker ett problem senare gör detta att du snabbt kan gå tillbaka till den senaste fungerande versionen.

Swapping slots for production and staging deployments

  • Om du återställer till en tidigare version ser du till att alla schemaändringar för databasen är bakåtkompatibla.
  • Använd inte platser i produktionsdistributionen för testning, eftersom alla appar i samma App Service-plan delar samma VM-instanser. Till exempel kan belastningstester försämra den aktiva produktionsplatsen. Skapa i stället separata App Service-planer för produktion och testning. Genom att placera testdistributioner i en separat plan isolerar du dem från produktionsversionen.

Säkerhet

Det här avsnittet innehåller säkerhetsaspekter som är specifika för Azure-tjänster i den här artikeln. Det är inte en fullständig lista över säkerhetsmetoder. Några andra säkerhetsöverväganden finns i Skydda en app i Azure App Service.

Granskning av SQL Database

Granskning kan hjälpa dig att upprätthålla regelefterlevnad och få insyn i avvikelser och fel som kan tyda på affärsproblem eller potentiella säkerhetsöverträdelser. Se Kom igång med SQL-databasgranskning.

Distributionsfack

Varje distributionsplats har en offentlig IP-adress. Skydda icke-produktionsplatserna med hjälp av Microsoft Entra-inloggningen så att endast medlemmar i dina utvecklings- och DevOps-team kan nå dessa slutpunkter.

Loggning

Loggar ska aldrig registrera användarnas lösenord eller annan information som kan användas för identitetsbedrägerier. Rensa bort denna information från data innan de lagras.

SSL

En App Service-app innehåller en SSL-slutpunkt på en underdomän azurewebsites.net utan extra kostnad. SSL-slutpunkten innehåller ett jokerteckencertifikat för *.azurewebsites.net-domänen. Om du använder ett anpassat domännamn måste du ange ett certifikat som matchar den anpassade domänen. Det enklaste sättet är att köpa ett certifikat direkt via Azure-portalen. Du kan även importera certifikat från andra certifikatutfärdare. Mer information finns i köpa och konfigurera ett SSL-certifikat för din Azure App Service.

HTTPS är inte aktiverat som standard i ARM-malldistributionen. Den bästa säkerhetsmetoden är att se till att appen använder tvingande HTTPS genom att dirigera om HTTP-begäranden. Du kan implementera HTTPS i ditt program eller använda en URL-omskrivningsregel enligt beskrivningen i aktivera HTTPS för en app i Azure App Service.

Autentisering

Vi rekommenderar att du autentiserar via en identitetsprovider (IDP), till exempel Microsoft Entra-ID, Facebook, Google eller Twitter. Använd OAuth 2 eller OpenID Connect (OIDC) för autentiseringsflödet. Microsoft Entra ID tillhandahåller funktioner för att hantera användare och grupper, skapa programroller, integrera dina lokala identiteter och använda serverdelstjänster som Microsoft 365 och Skype för företag.

Undvik att programmet hanterar användarinloggningar och autentiseringsuppgifter direkt. Det skapar en potentiell attackyta. Du måste minst ha en e-postbekräftelse, lösenordsåterställning och multifaktorautentisering, validera lösenordsstyrkan och lagra lösenordshashvärden på ett säkert sätt. De stora identitetsprovidrar hanterar alla dessa saker åt dig och övervakar och förbättrar ständigt sina säkerhetsrutiner.

Överväg att använda App Service-autentisering för att implementera OAuth- eller OIDC-autentiseringsflödet. Fördelarna med App Service-autentisering är bland annat:

  • Enkelt att konfigurera.
  • Ingen kod krävs för enkla verifieringsscenarier.
  • Har stöd för delegerad auktorisering med OAuth-åtkomsttoken för att använda resurser på uppdrag av användaren.
  • Ger inbyggd token-cache.

Några begränsningar hos App Service-autentisering:

  • Begränsade anpassningsalternativ.
  • Delegerad auktorisering är begränsad till en serverdelsresurs per inloggningssession.
  • Om du använder mer än en IDP finns det ingen inbyggd mekanism för identifiering av hemsfär.
  • Vid scenarier med flera innehavare måste programmet implementera logiken för att validera tokenutfärdaren.

Distribuera det här scenariot

Den här arkitekturen innehåller en Azure App Service-plan och ett tomt program. Den använder Azure SQL Database, Azure Key Vault för att lagra databasen anslutningssträng och Azure Monitor för loggning, övervakning och aviseringar.

Använd följande kommando för att skapa en resursgrupp för distributionen. Välj knappen Prova om du vill använda ett inbäddat gränssnitt.

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

Kör följande kommando för att distribuera webbprogrammet och stödinfrastrukturen. När du uppmanas till det anger du ett användarnamn och lösenord. Dessa värden används för att komma åt Azure SQL Database-instansen.

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

Detaljerad information och fler distributionsalternativ finns i ARM-mallar som används för att distribuera den här lösningen.

Arm-mall för grundläggande webbprogram

Nästa steg

Tips för felsökning av program:

Produktdokumentation:

Microsoft Learn-moduler: