Redigera

Dela via

Grundläggande webbprogram

Azure App Service
Azure Monitor
Azure SQL Database

Den här artikeln innehåller en grundläggande arkitektur som är avsedd för att lära dig hur du kör webbprogram i Azure App Service i en enda region.

Viktigt!

Den här arkitekturen är inte avsedd att användas för produktionsprogram. Det är avsett att vara en introduktionsarkitektur som du kan använda för inlärning och konceptbevis (POC). När du utformar ditt Azure App Service-program för produktion läser du webbprogrammet Med hög tillgänglighet för zonredundant.

Viktigt!

GitHub-logotyp Vägledningen stöds av en exempelimplementering som visar den här grundläggande App Service-implementeringen i Azure. Den här implementeringen kan användas som grund för din POC för att få erfarenhet av att arbeta med Azure App Service.

Arkitektur

Diagram som visar en grundläggande App Service-arkitektur.

Bild 1: Grundläggande Azure App Service-arkitektur

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

Arbetsflöde

  1. En användare utfärdar en HTTPS-begäran till App Service-standarddomänen på azurewebsites.net. Den här domänen pekar automatiskt på apptjänstens inbyggda offentliga IP-adress. TLS-anslutningen upprättas från klienten direkt till App Service. Certifikatet hanteras helt av Azure.
  2. Easy Auth, en funktion i Azure App Service, ser till att användaren som kommer åt webbplatsen autentiseras med Microsoft Entra-ID.
  3. Programkoden som distribueras till App Service hanterar begäran. Koden kan till exempel ansluta till en Azure SQL Database-instans med hjälp av en anslutningssträng som konfigurerats i App Service som konfigurerats som en appinställning.
  4. Informationen om den ursprungliga begäran till App Service och anropet till Azure SQL Database loggas i Application Insights.

Komponenter

  • Microsoft Entra ID är en molnbaserad identitets- och åtkomsthanteringstjänst. Det ger ett enda identitetskontrollplan för att hantera behörigheter och roller för användare som har åtkomst till din webbapp. Den integreras med App Service och förenklar autentisering och auktorisering för webbappar.
  • App Service är en fullständigt hanterad plattform för att skapa, distribuera och skala webbprogram.
  • Azure Monitor är en övervakningstjänst som samlar in, analyserar och agerar på telemetridata i distributionen.
  • Azure SQL Database är en hanterad relationsdatabastjänst för relationsdata.

Rekommendationer och överväganden

De komponenter som anges i den här arkitekturen länkar till Azure Well-Architected-tjänstguider. Serviceguider beskriver rekommendationer och överväganden för specifika tjänster. Det här avsnittet utökar den vägledningen genom att lyfta fram viktiga rekommendationer och överväganden för Azure Well-Architected Framework som gäller för den här arkitekturen. Mer information finns i Microsoft Azure Well-Architected Framework.

Den här grundläggande arkitekturen är inte avsedd för produktionsdistributioner. Arkitekturen gynnar enkelhet och kostnadseffektivitet framför funktioner så att du kan utvärdera och lära dig Azure App Service. I följande avsnitt beskrivs några brister i den här grundläggande arkitekturen, tillsammans med rekommendationer och överväganden.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Checklista för designgranskning för tillförlitlighet.

Eftersom den här arkitekturen inte är utformad för produktionsdistributioner beskriver följande några av de kritiska tillförlitlighetsfunktioner som utelämnas i den här arkitekturen:

  • App Service-planen har konfigurerats för nivån, som inte har stöd för Standard Azure-tillgänglighetszoner. App Service blir otillgänglig i händelse av problem med instansen, racket eller det datacenter som är värd för instansen.
  • Azure SQL Database har konfigurerats för Basic nivån, som inte stöder zonredundans. Det innebär att data inte replikeras i Azures tillgänglighetszoner, vilket riskerar att förlora incheckade data i händelse av ett avbrott.
  • Distributioner till den här arkitekturen kan leda till driftstopp med programdistributioner, eftersom de flesta distributionstekniker kräver att alla instanser som körs startas om. Användare kan uppleva 503 fel under den här processen. Detta åtgärdas i baslinjearkitekturen via distributionsfack. Noggrann programdesign, schemahantering och programkonfigurationshantering krävs för att stödja samtidig distribution av fack. Använd denna POC för att utforma och verifiera din distributionsmetod för fackbaserad produktion.
  • Autoskalning är inte aktiverat i den här grundläggande arkitekturen. För att förhindra tillförlitlighetsproblem på grund av brist på tillgängliga beräkningsresurser måste du överetablera för att alltid köras med tillräckligt med beräkning för att hantera maximal samtidig kapacitet.

Se hur du eliminerar dessa tillförlitlighetsproblem i avsnittet tillförlitlighet i webbprogrammet Med hög tillgänglighet i zonen Med hög tillgänglighet.

Om den här arbetsbelastningen så småningom kräver en aktiv-aktiv eller aktiv-passiv arkitektur i flera regioner kan du läsa följande resurser:

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Checklista för designgranskning för säkerhet.

Eftersom den här arkitekturen inte är utformad för produktionsdistributioner beskriver följande några av de kritiska säkerhetsfunktioner som utelämnades i den här arkitekturen, tillsammans med andra tillförlitlighetsrekommendationer och överväganden:

  • Den här grundläggande arkitekturen implementerar inte nätverkssekretess. Data- och hanteringsplan för resurserna, till exempel Azure App Service och Azure SQL Server, kan nås via det offentliga Internet. Om du utelämnar privata nätverk ökar angreppsytan avsevärt i din arkitektur. Om du vill se hur implementering av privata nätverk säkerställer följande säkerhetsfunktioner kan du läsa nätverksavsnittet i webbprogrammet Med hög tillgänglighet i zonen Med hög tillgänglighet:

    • En enda säker startpunkt för klienttrafik
    • Nätverkstrafiken filtreras både på paketnivå och på DDoS-nivå.
    • Dataexfiltrering minimeras genom att hålla trafiken i Azure med hjälp av Private Link
    • Nätverksresurser grupperas logiskt och isoleras från varandra via nätverkssegmentering.

  • Den här grundläggande arkitekturen innehåller inte någon distribution av Azure Web Application Firewall. Webbprogrammet skyddas inte mot vanliga sårbarheter. Se baslinjeimplementeringen för att se hur brandväggen för webbprogram kan implementeras med Azure Application Gateway i en Azure App Services-arkitektur.

  • Den här grundläggande arkitekturen lagrar hemligheter som Azure SQL Server-anslutningssträng i Appinställningar. När appinställningarna är krypterade bör du överväga att lagra hemligheter i Azure Key Vault för ökad styrning när du flyttar till produktion. En ännu bättre lösning är att använda hanterad identitet för autentisering och inte ha hemligheter lagrade i anslutningssträng.

  • Det går bra att lämna fjärrfelsökning och Kudu-slutpunkter aktiverade under utveckling eller konceptbevisfasen. När du flyttar till produktion bör du inaktivera onödigt kontrollplan, distribution eller fjärråtkomst.

  • Att låta lokala autentiseringsmetoder för FTP- och SCM-platsdistributioner vara aktiverade är bra i utvecklings- eller koncepttestfasen. När du flyttar till produktion bör du inaktivera lokal autentisering till dessa slutpunkter.

  • Du behöver inte aktivera Microsoft Defender för App Service i koncepttestfasen. När du flyttar till produktion bör du aktivera Defender för App Service för att generera säkerhetsrekommendationer som du bör implementera för att öka din säkerhetsstatus och identifiera flera hot mot din App Service.

  • Azure App Service innehåller en SSL-slutpunkt på en underdomän azurewebsites.net utan extra kostnad. HTTP-begäranden omdirigeras som standard till HTTPS-slutpunkten. För produktionsdistributioner använder du vanligtvis en anpassad domän som är associerad med programgateway eller API-hantering framför din App Service-distribution.

  • Använd den integrerade autentiseringsmekanismen för App Service ("EasyAuth"). EasyAuth förenklar processen med att integrera identitetsprovidrar i din webbapp. Den hanterar autentisering utanför webbappen, så du behöver inte göra några större kodändringar.

  • Använd hanterad identitet för arbetsbelastningsidentiteter. Hanterad identitet eliminerar behovet av att utvecklare hanterar autentiseringsuppgifter. Den grundläggande arkitekturen autentiserar till SQL Server via lösenord i en anslutningssträng. Överväg att använda hanterad identitet för att autentisera till Azure SQL Server.

Några andra säkerhetsöverväganden finns i Skydda en app i Azure App Service.

Driftsäkerhet

Driftskvalitet omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Checklista för designgranskning för Operational Excellence.

Följande avsnitt innehåller vägledning om konfiguration, övervakning och distribution av apptjänstprogrammet.

Appkonfigurationer

Eftersom den grundläggande arkitekturen inte är avsedd för produktion använder den App Service-konfiguration för att lagra konfigurationsvärden och hemligheter. Lagring av hemligheter i App Service-konfigurationen är bra för PoC-fasen. Du använder inte verkliga hemligheter och behöver inte styrning av hemligheter som krävs för produktionsarbetsbelastningar.

Följande är konfigurationsrekommendationer och överväganden:

  • Börja med att använda App Service-konfiguration för att lagra konfigurationsvärden och anslutningssträng i koncepttestdistributioner. Appinställningar och anslutningssträng krypteras och dekrypteras precis innan de matas in i din app när den startas.
  • När du går in i produktionsfasen lagrar du dina hemligheter i Azure Key Vault. Användningen av Azure Key Vault förbättrar styrningen av hemligheter på två sätt:
    • Genom att externalisera lagringen av hemligheter till Azure Key Vault kan du centralisera lagringen av hemligheter. Du har ett ställe där du kan hantera hemligheter.
    • Med Hjälp av Azure Key Vault kan du logga varje interaktion med hemligheter, inklusive varje gång en hemlighet används.
  • När du flyttar till produktion kan du behålla din användning av både Azure Key Vault- och App Service-konfigurationen med hjälp av Key Vault-referenser.

Diagnostik och övervakning

Under konceptbevisfasen är det viktigt att få en förståelse för vilka loggar och mått som är tillgängliga för insamling. Följande är rekommendationer och överväganden för övervakning i konceptbevisfasen:

  • Aktivera diagnostikloggning för alla objektloggkällor. Genom att konfigurera användningen av alla diagnostikinställningar kan du förstå vilka loggar och mått som tillhandahålls direkt och eventuella luckor som du behöver stänga med hjälp av ett loggningsramverk i programkoden. När du flyttar till produktion bör du eliminera loggkällor som inte lägger till värde och lägger till brus och kostnad i arbetsbelastningens loggmottagare.
  • Konfigurera loggning för att använda Azure Log Analytics. Med Azure Log Analytics får du en skalbar plattform för att centralisera loggning som är lätt att fråga efter.
  • Använd Application Insights eller ett annat APM-verktyg (Application Performance Management) för att generera telemetri och loggar för att övervaka programmets prestanda.

Distribution

Följande innehåller vägledning om hur du distribuerar apptjänstens program.

  • Följ riktlinjerna i CI/CD för Azure Web Apps med Azure Pipelines för att automatisera distributionen av ditt program. Börja skapa distributionslogik i PoC-fasen. Genom att implementera CI/CD tidigt i utvecklingsprocessen kan du snabbt och säkert iterera i ditt program när du går mot produktion.
  • Använd ARM-mallar för att distribuera Azure-resurser och deras beroenden. Det är viktigt att starta den här processen i PoC-fasen. När du går mot produktion vill du kunna distribuera infrastrukturen automatiskt.
  • Använd olika ARM-mallar och integrera dem med Azure DevOps-tjänster. Med den här konfigurationen kan du skapa olika miljöer. Du kan till exempel bara replikera produktionsliknande scenarier eller belastningstestningsmiljöer när det behövs och spara på kostnaden.

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

Containers

Den grundläggande arkitekturen kan användas för att distribuera kod som stöds direkt till Windows- eller Linux-instanser. Alternativt är App Service också en värdplattform för containrar för att köra ditt containerbaserade webbprogram. App Service erbjuder olika inbyggda containrar. Om du använder anpassade appar eller appar med flera containrar för att finjustera din körningsmiljö ytterligare eller för att stödja ett kodspråk som inte stöds internt måste du införa ett containerregister.

Kontrollplan

Under POC-fasen kan du bekanta dig med Azure App Services kontrollplan så som det exponeras via Kudu-tjänsten. Den här tjänsten exponerar vanliga distributions-API:er, till exempel ZIP-distributioner, exponerar råloggar och miljövariabler.

Om du använder containrar måste du förstå Kudus möjlighet att öppna en SSH-session till en container för att stödja avancerade felsökningsfunktioner.

Prestandaeffektivitet

Prestandaeffektivitet handlar om att effektivt skala arbetsbelastningen baserat på användarnas behov. Mer information finns i Checklista för designgranskning för prestandaeffektivitet.

Eftersom den här arkitekturen inte är utformad för produktionsdistributioner beskriver följande några av de kritiska prestandaeffektivitetsfunktioner som utelämnades i den här arkitekturen, tillsammans med andra rekommendationer och överväganden.

Ett resultat av ditt konceptbevis bör vara SKU-val som du uppskattar är lämpligt för din arbetsbelastning. Din arbetsbelastning bör utformas för att effektivt möta efterfrågan genom horisontell skalning genom att justera antalet beräkningsinstanser som distribueras i App Service-planen. Utforma inte systemet så att det är beroende av att ändra beräknings-SKU:n så att den överensstämmer med efterfrågan.

  • App Service i den här grundläggande arkitekturen har inte automatisk skalning implementerad. Tjänsten skalas inte ut dynamiskt eller in för att effektivt hålla sig i linje med efterfrågan.
    • Standardnivån stöder inställningar för automatisk skalning så att du kan konfigurera regelbaserad autoskalning. En del av POC-processen bör vara att komma fram till effektiva inställningar för automatisk skalning baserat på programkodens resursbehov och förväntade användningsegenskaper.
    • För produktionsdistributioner bör du överväga Premium-nivåer som stöder automatisk autoskalning där plattformen automatiskt hanterar skalningsbeslut.
  • Följ riktlinjerna för att skala upp enskilda databaser utan programavbrott om du behöver en högre tjänstnivå eller prestandanivå för SQL Database.

Distribuera det här scenariot

Vägledningen stöds av en exempelimplementering som visar en grundläggande App Service-implementering i Azure.

Nästa steg

Baslinje med hög tillgänglighet zonredundant webbapp

Produktdokumentation:

Microsoft Learn-moduler: