Grundläggande webbprogram

Azure App Service

Azure Monitor

Azure SQL Database

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

Viktigt!

Den här arkitekturen är inte avsedd för produktionsprogram. Det fungerar som en introduktionsinställning för inlärning och demonstration av koncept (Proof of Concept/POC). Information om hur du utformar en produktionsmiljö för App Service-applikationer finns i Baslinjen för högtillgängliga zonredundanta webbapplikationer.

Arkitektur

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

Arbetsflöde

Följande arbetsflöde motsvarar föregående diagram.

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å den inbyggda offentliga IP-adressen för ditt App Service-program. TLS-anslutningen (Transport Layer Security) upprättas från klienten direkt till App Service. Azure hanterar certifikatet fullständigt.
Easy Auth, som är en funktion i App Service, ser till att användaren som kommer åt webbplatsen autentiseras med hjälp av Microsoft Entra ID.
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 reťazec pripojenia som konfigureras i App Service som en appinställning.
Informationen om den ursprungliga begäran till App Service och anropet till SQL Database loggas i Application Insights.

Komponenter

Microsoft Entra ID är en molnbaserad identitets- och åtkomsthanteringstjänst som tillhandahåller autentiserings- och auktoriseringsfunktioner. I den här arkitekturen integreras den med App Service via Enkel autentisering för att säkerställa autentisering för användare som har åtkomst till webbprogrammet. Det förenklar också autentiseringsprocessen utan att kräva betydande kodändringar.
App Service är en hanterad plattform för att skapa, distribuera och skala webbprogram. I den här arkitekturen är den värd för webbprogramkoden, hanterar HTTPS-begäranden på standarddomänen azurewebsites.net och ansluter till SQL Database via konfigurerade anslutningssträngar.
Azure Monitor är en övervakningstjänst som samlar in, analyserar och agerar på telemetridata från molnmiljöer och lokala miljöer. I den här arkitekturen samlar den in och lagrar information om begäranden till App Service och anrop till SQL Database via Application Insights-integrering.
SQL Database är en hanterad relationsdatabastjänst som tillhandahåller SQL Server-funktioner i molnet. I den här arkitekturen fungerar den som datalagringslagret, vilket gör att App Service-programmet kan ansluta via anslutningssträngar som definieras i appinställningarna.

Överväganden

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som du kan använda för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Well-Architected Framework.

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

Den här grundläggande arkitekturen är endast utformad för utvärderings- och inlärningsändamål. Den prioriterar enkelhet och kostnadseffektivitet framför funktioner i produktionsklass. Följande avsnitt beskriver viktiga begränsningar i den här arkitekturen och ger rekommendationer och överväganden som hjälper dig att planera för mer robusta distributioner.

Tillförlitlighet

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

Den här arkitekturen är inte utformad för produktionsdistributioner. Följande viktiga tillförlitlighetsfunktioner utelämnas i den här arkitekturen:

App Service-planen är konfigurerad för standardnivån, som inte innehåller stöd för Azure tillgänglighetszoner. App Service blir otillgänglig om ett problem uppstår med instansen, racket eller det datacenter som är värd för instansen.
SQL Database har konfigurerats för Basic-nivån, som inte stöder zonredundans. Därför replikeras inte data i Azure tillgänglighetszoner, vilket riskerar att förlora incheckade data om ett avbrott inträffar.
Distributioner till den här arkitekturen kan leda till driftstopp för 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. Den här driftstoppet åtgärdas i baslinjearkitekturen via distributionsplatser. Noga applikationsdesign, schemabehandling och applikationskonfigurationshantering krävs för att stödja samtidig distribution av platser. Använd denna POC för att utforma och verifiera din strategi för fackbaserad produktionsdrift.
Autoskalning är inte aktiverat i den här grundläggande arkitekturen. För att undvika tillförlitlighetsproblem som orsakas av otillräckliga beräkningsresurser måste du överetablera för att säkerställa tillräckligt med kapacitet för att hantera maximal samtidig efterfrågan.

För mer information om hur du hanterar dessa tillförlitlighetsproblem, se Baslinje: högtillgänglig zonredundant webbapplikation – tillförlitlighet.

Om arbetsbelastningen kräver en aktiv-aktiv eller aktiv-passiv arkitektur i flera regioner, se metoder för App Service-appar över flera regioner för haveriberedskap.

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.

Den här arkitekturen är inte utformad för produktionsdistributioner. Följande viktiga säkerhetsfunktioner utelämnades i den här arkitekturen, tillsammans med andra rekommendationer och överväganden för tillförlitlighet:

Den här grundläggande arkitekturen implementerar inte nätverkssekretess. Data- och hanteringsplan för resurserna, till exempel 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. Mer information om hur implementering av privata nätverk säkerställer följande säkerhetsfunktioner finns i Baslinje med hög tillgänglighet zonredundant webbapp – Nätverk. Genom att implementera privata nätverk kan du minska dessa risker genom att tillhandahålla följande säkerhetsfunktioner:
- En enda säker startpunkt för klienttrafik.
- Nätverkstrafiken filtreras på både paketnivå och DDoS-nivå (distribuerad denial-of-service).
- Dataexfiltrering minimeras genom att trafik hålls i Azure med hjälp av Azure 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. Information om hur Azure Web Application Firewall kan implementeras med Azure Application Gateway i en App Services-arkitektur finns i baslinjeimplementering.
Den här grundläggande arkitekturen lagrar hemligheter som SQL Server reťazec pripojenia i Appinställningar. Appinställningarna krypteras som standard. Men när du flyttar till produktion bör du överväga att lagra hemligheter i Azure Key Vault för ökad styrning. Om du vill ha bättre säkerhet och lägre kostnader för hemlig hantering bör du överväga att använda hanterad identitet för autentisering i stället för att bädda in hemligheter i anslutningssträngar.
Fjärrfelsökning och Kudu-slutpunkter kan vara aktiverade under utveckling eller POC-fasen. När du går över till produktion bör du inaktivera onödiga kontrollplaner, driftsättningar eller fjärråtkomster.
Lokala autentiseringsmetoder för distributioner av filöverföringsprotokoll (FTP) och källkontrollhantering (SCM) kan förbli aktiverade under utvecklings- eller POC-fasen. 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 POC-fasen. När du flyttar till produktion bör du aktivera Defender för App Service för att generera säkerhetsrekommendationer. Du bör implementera dessa rekommendationer för att öka din säkerhetsstatus och identifiera flera hot mot din App Service-distribution.
App Service innehåller en SSL-slutpunkt (Secure Sockets Layer) på en underdomän azurewebsites.net utan extra kostnad. HTTP-begäranden omdirigeras som standard till HTTPS-slutpunkten. För produktionsdistributioner används vanligtvis en anpassad domän med Application Gateway eller API Management framför din App Service-distribution.
Använd den integrerade autentiseringsmekanismen för App Service. Easy Auth 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 med hjälp av ett lösenord i en reťazec pripojenia. Överväg att använda hanterad identitet för att autentisera till SQL Server.

Mer information finns i Skydda en app i App Service.

Kostnadsoptimering

Kostnadsoptimering fokuserar på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i checklistan Designgranskning för kostnadsoptimering.

Den här arkitekturen optimerar för kostnader genom de många kompromisserna mot de andra grundpelarna i Well-Architected Framework. Dessa kompromisser görs specifikt för att överensstämma med inlärnings- och POC-målen för den här arkitekturen. Kostnadsbesparingarna jämfört med en mer produktionsklar arkitektur, till exempel baslinjen med hög tillgänglighet zonredundant webbapp, beror främst på följande alternativ:

En enda App Service-instans utan automatisk skalning aktiverad
Standardprisnivå för App Service
Inget anpassat TLS-certifikat eller statisk IP-adress
Ingen brandvägg för webbprogram (WAF)
Inget dedikerat lagringskonto för programdistribution
Grundläggande prisnivå för SQL Database, utan kvarhållningsprinciper för säkerhetskopiering
Inga komponenter i Microsoft Defender för Cloud
Ingen utgående kontroll av nätverkstrafik via en brandvägg
Inga privata slutpunkter
Minimal logg- och loggkvarhållningsperiod i Azure Monitor loggar

För att se den uppskattade kostnaden för den här arkitekturen, se den uppskattning från priskalkylatorn som använder komponenterna i denna arkitektur. Kostnaden för den här arkitekturen kan vanligtvis minskas ytterligare med hjälp av en Azure Dev/Test-prenumeration, vilket skulle vara en idealisk prenumerationstyp för POC:er som denna.

Operativ skicklighet

Operational Excellence 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 App Service-programmet.

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. Du kan lagra hemligheter i App Service-konfigurationen under POC-fasen. Du använder inte verkliga hemligheter och behöver inte styrning av hemligheter som produktionsarbetsbelastningar kräver.

Överväg följande konfigurationsrekommendationer och överväganden:

Börja med att använda App Service-konfiguration för att lagra konfigurationsvärden och anslutningssträngar i POC-distributioner. Appinställningar och anslutningssträngar krypteras och dekrypteras omedelbart innan de matas in i appen när den startas.
När du flyttar till produktion lagrar du dina hemligheter i Key Vault. Key Vault förbättrar styrningen av hemligheter på två sätt:
- Om du externaliserar dina hemligheter till Key Vault får du en enda central plats för säker hantering av hemligheter.
- Med hjälp av 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 Key Vault och App Service-konfigurationen med hjälp av Key Vault referenser.

Behållare

Du kan använda den grundläggande arkitekturen 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 som du kan använda för att köra ditt containerbaserade webbprogram. App Service tillhandahåller olika inbyggda containrar. Anpassade appar eller appar med flera containrar hjälper till att finjustera körningsmiljön eller stödja kodspråk som inte stöds internt. Den här metoden kräver införandet av ett containerregister.

Kontrollplan

Under POC-fasen bekantar du dig med App Service-kontrollplanet, som är tillgängligt via Kudu-tjänsten. Den här tjänsten tillhandahåller vanliga distributions-API:er, till exempel ZIP-distributioner, och den exponerar råloggar och miljövariabler.

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

Diagnostik och övervakning

Under POC-fasen är det viktigt att få en förståelse för vilka loggar och mått som är tillgängliga för avbildning. Överväg följande rekommendationer och idéer för övervakning i POC-fasen:

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 åt dig direkt och hjälper dig att identifiera eventuella luckor som du behöver stänga med hjälp av ett loggningsramverk i programkoden. När du flyttar till produktion eliminerar du loggkällor som inte lägger till värde men lägger till brus och kostnad i arbetsbelastningens loggmottagare.
Konfigurera loggning för att använda Azure Log Analytics. Azure Log Analytics ger dig en skalbar plattform för att centralisera loggning som är enkel att fråga efter.
Använd Application Insights eller ett annat verktyg för programprestandahantering (APM) för att generera telemetri och loggar för att övervaka programmets prestanda.

Deployment

Följande punkter ger vägledning för hur du distribuerar ditt App Service-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 kontinuerlig integrering och kontinuerlig leverans (CI/CD) tidigt i utvecklingsprocessen kan du snabbt och säkert iterera i ditt program när du går mot produktion.
Använd Azure Resource Manager mallar (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 Services. 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 designprinciperna för operational excellence.

Prestandaeffektivitet

Prestandaeffektivitet syftar på arbetsbelastningens förmåga att skala för att effektivt uppfylla användarnas krav. Mer information finns i Checklista för designgranskning för prestandaeffektivitet.

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

Ett resultat av din POC bör vara ett SKU-val som du uppskattar är lämpligt för din arbetsbelastning. Utforma din arbetsbelastning 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-distributionen i den här grundläggande arkitekturen har inte automatisk skalning implementerad. Tjänsten skalas inte ut dynamiskt eller skalas in för att effektivt hålla sig i linje med efterfrågan.
- Standardnivån stöder autoskalningsinställningar så att du kan konfigurera regelbaserad autoskalning. Som en del av DIN POC-process kan du fastställa effektiva inställningar för automatisk skalning som är skräddarsydda för programkodens resurskrav och förväntade användningsmönster.
- För produktionsdistributioner bör du överväga Premium-nivåer som stöder automatisk skalning 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.

Nästa steg

Handledningar för utplacering:

Produktdokumentation:

Microsoft Learn-moduler:

Feedback

Var den här sidan till hjälp?