Operativsystemfunktioner i Azure App Service
Den här artikeln beskriver baslinjeoperativsystemets funktioner som är tillgängliga för alla Windows-appar som körs i Azure App Service. Den här funktionen omfattar fil-, nätverks- och registeråtkomst, tillsammans med diagnostikloggar och händelser.
Kommentar
Linux-appar i App Service körs i sina egna containrar. Du har rotåtkomst till containern men ingen åtkomst till värdoperativsystemet. På samma sätt har du administrativ åtkomst till containern för appar som körs i Windows-containrar, men ingen åtkomst till värdoperativsystemet.
App Service-plannivåer
App Service kör kundappar i en värdmiljö för flera klientorganisationer. Appar som distribueras på nivåerna Kostnadsfri och Delad körs i arbetsprocesser på delade virtuella datorer (VM). Appar som distribueras på standard- och Premium-nivåerna körs på virtuella datorer som är särskilt dedikerade för appar som är associerade med en enda kund.
Kommentar
Tjänstplaner för kostnadsfri och delad App Service (förhandsversion) är basnivåer som körs på samma virtuella Azure-datorer som andra App Service-appar. Vissa appar kan tillhöra andra kunder. Dessa nivåer är endast avsedda för utveckling och testning.
Eftersom App Service stöder en sömlös skalningsupplevelse mellan nivåer förblir säkerhetskonfigurationen som tillämpas för App Service-appar densamma. Den här konfigurationen säkerställer att appar inte plötsligt beter sig annorlunda och misslyckas på oväntade sätt när en App Service-plan växlar från en nivå till en annan.
Utveckling av ramverk
Prisnivåerna för App Service styr mängden beräkningsresurser (CPU, disklagring, minne och utgående nätverk) som är tillgängliga för appar. Den bredd av ramverksfunktioner som är tillgängliga för appar förblir dock densamma oavsett skalningsnivåer.
App Service stöder olika utvecklingsramverk, inklusive ASP.NET, klassisk ASP, Node.js, PHP och Python. För att förenkla och normalisera säkerhetskonfigurationen kör App Service-appar vanligtvis utvecklingsramverken med sina standardinställningar. Ramverken och körningskomponenterna som plattformen tillhandahåller uppdateras regelbundet för att uppfylla kraven på säkerhet och efterlevnad. Därför garanterar vi inte specifika delversioner/korrigeringsversioner. Vi rekommenderar att kunderna riktar in sig på större versioner efter behov.
I följande avsnitt sammanfattas de allmänna typerna av operativsystemfunktioner som är tillgängliga för App Service-appar.
Åtkomst till filer
Det finns olika enheter i App Service, inklusive lokala enheter och nätverksenheter.
Lokala enheter
I grunden är App Service en tjänst som körs ovanpå PaaS-infrastrukturen (Azure Platform as a Service). Därför är de lokala enheter som är associerade med en virtuell dator samma enhetstyper som är tillgängliga för alla arbetsroller som körs i Azure. De omfattar:
- En operativsystemenhet (
%SystemDrive%) vars storlek beror på storleken på den virtuella datorn. - En resursenhet (
%ResourceDrive%) som App Service använder internt.
Bästa praxis är att alltid använda miljövariablerna %SystemDrive% och %ResourceDrive% i stället för hårdkodade filsökvägar. Rotsökvägen som returneras från dessa två miljövariabler har över tid flyttats från d:\ till c:\. Äldre program hårdkodade med filsökvägsreferenser fortsätter dock att d:\ fungera eftersom App Service automatiskt mappar d:\ om till punkt .c:\ Som tidigare nämnts rekommenderar vi starkt att du alltid använder miljövariablerna när du skapar filsökvägar och undviker förvirring över plattformsändringar i standardsökvägen för rotfiler.
Det är viktigt att övervaka diskanvändningen när programmet växer. Att nå diskkvoten kan ha negativa effekter på ditt program. Till exempel:
- Appen kan utlösa ett fel som indikerar att det inte finns tillräckligt med utrymme på disken.
- Du kan se diskfel när du bläddrar till Kudu-konsolen.
- Distributionen från Azure DevOps eller Visual Studio kan misslyckas med
ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk). - Din app kan ha långsamma prestanda.
Nätverksenheter (UNC-resurser)
En av de unika aspekterna av App Service som gör appdistribution och underhåll enkelt är att alla innehållsresurser lagras på en uppsättning UNC-resurser. Den här modellen mappar väl till det vanliga mönstret för innehållslagring som används av lokala webbvärdmiljöer som har flera belastningsutjämnade servrar.
I App Service skapas UNC-resurser i varje datacenter. En procentandel av användarinnehållet för alla kunder i varje datacenter allokeras till varje UNC-resurs. Varje kunds prenumeration har en reserverad katalogstruktur på en specifik UNC-resurs i ett datacenter. En kund kan ha flera appar som skapats i ett specifikt datacenter, så alla kataloger som tillhör en enda kundprenumeration skapas på samma UNC-resurs.
På grund av hur Azure-tjänster fungerar ändras den specifika virtuella dator som ansvarar för att vara värd för en UNC-resurs över tid. UNC-resurser monteras av olika virtuella datorer när de tas upp och ned under den normala azure-driften. Därför bör appar aldrig göra hårdkodade antaganden om att datorinformationen i en UNC-filsökväg förblir stabil över tid. I stället bör de använda den praktiska faux absoluta vägen %HOME%\site som App Service tillhandahåller.
Den faux absoluta sökvägen är en bärbar metod för att referera till din egen app. Den är inte specifik för någon app eller användare. Med hjälp %HOME%\siteav kan du överföra delade filer från app till app utan att behöva konfigurera en ny absolut sökväg för varje överföring.
Typer av filåtkomst som beviljas till en app
Katalogen %HOME% i en app mappar till en innehållsresurs i Azure Storage som är dedikerad för den appen. Prisnivån definierar dess storlek. Den kan innehålla kataloger som de för innehåll, fel- och diagnostikloggar och tidigare versioner av appen som källkontrollen skapade. Dessa kataloger är tillgängliga för appens programkod vid körning för läs- och skrivåtkomst. Eftersom filerna inte lagras lokalt är de beständiga för omstarter av appar.
På systemenheten reserverar %SystemDrive%\local App Service för appspecifik tillfällig lokal lagring. Ändringar i filer i den här katalogen är inte beständiga för omstarter av appar. Även om en app har fullständig läs- och skrivåtkomst till sin egen tillfälliga lokala lagring är lagringen inte avsedd för direkt användning av programkoden. Avsikten är snarare att tillhandahålla tillfällig fillagring för IIS- och webbprogramramverk.
App Service begränsar mängden lagringsutrymme i %SystemDrive%\local för varje app för att förhindra att enskilda appar förbrukar stora mängder lokal fillagring. För nivåerna Kostnadsfri, Delad och Förbrukning (Azure Functions) är gränsen 500 MB. I följande tabell visas andra nivåer:
| Nivå | Lokal fillagring |
|---|---|
| B1/S1/P1 | 11 GB |
| B2/S2/P2 | 15 GB |
| B3/S3/P3 | 58 GB |
| P0v3 | 11 GB |
| P1v2/P1v3/P1mv3/Isolated1/Isolated1v2 | 21 GB |
| P2v2/P2v3/P2mv3/Isolated2/Isolated2v2 | 61 GB |
| P3v2/P3v3/P3mv3/Isolated3/Isolated3v2 | 140 GB |
| Isolerad4v2 | 276 GB |
| P4mv3 | 280 GB |
| Isolerad5v2 | 552 GB |
| P5mv3 | 560 GB |
| Isolerad6v2 | 1 104 GB |
Två exempel på hur App Service använder tillfällig lokal lagring är katalogen för tillfälliga ASP.NET filer och katalogen för IIS-komprimerade filer. Det ASP.NET kompileringssystemet använder %SystemDrive%\local\Temporary ASP.NET Files katalogen som en tillfällig cacheplats för kompilering. IIS använder %SystemDrive%\local\IIS Temporary Compressed Files katalogen för att lagra komprimerade svarsutdata. Båda dessa typer av filanvändning (tillsammans med andra) mappas om i App Service till tillfällig lokal lagring per app. Den här ommappningen hjälper till att säkerställa att funktionerna fortsätter som förväntat.
Varje app i App Service körs som en slumpmässig, unik, lågprivilegierad arbetsprocessidentitet som kallas programpoolens identitet. Programkoden använder den här identiteten för grundläggande skrivskyddad åtkomst till operativsystemenheten. Den här åtkomsten innebär att programkod kan lista vanliga katalogstrukturer och läsa vanliga filer på operativsystemenheten. Även om den här åtkomstnivån kan tyckas vara bred är samma kataloger och filer tillgängliga när du etablerar en arbetsroll i en Azure-värdbaserad tjänst och läser enhetens innehåll.
Filåtkomst över flera instanser
Innehållsresurskatalogen (%HOME%) innehåller en apps innehåll och programkoden kan skriva till den. Om en app körs på flera instanser %HOME% delas katalogen mellan alla instanser så att alla instanser ser samma katalog. Om en app till exempel sparar uppladdade filer i %HOME% katalogen är dessa filer omedelbart tillgängliga för alla instanser.
Den tillfälliga lokala lagringskatalogen (%SystemDrive%\local) delas inte mellan instanser. Den delas inte heller mellan appen och dess Kudu-app.
Nätverksåtkomst
Programkod kan använda TCP/IP- och UDP-baserade protokoll för att upprätta utgående nätverksanslutningar till internettillgängliga slutpunkter som exponerar externa tjänster. Appar kan använda samma protokoll för att ansluta till tjänster i Azure , till exempel genom att upprätta HTTPS-anslutningar till Azure SQL Database.
Det finns också en begränsad funktion för appar att upprätta en lokal loopback-anslutning och låta en app lyssna på den lokala loopback-socketen. Den här funktionen gör det möjligt för appar som lyssnar på lokala loopback-socketar som en del av deras funktioner. Varje app har en privat loopback-anslutning. En app kan inte lyssna på en lokal loopback-socket som en annan app har upprättat.
Namngivna rör stöds också som en mekanism för kommunikation mellan processer som tillsammans kör en app. Till exempel förlitar sig IIS FastCGI-modulen på namngivna pipes för att samordna de enskilda processer som kör PHP-sidor.
Kodkörning, processer och minne
Som tidigare nämnts körs appar i lågprivilegierade arbetsprocesser med hjälp av en slumpmässig programpoolsidentitet. Programkoden har åtkomst till det minnesutrymme som är associerat med arbetsprocessen, tillsammans med eventuella underordnade processer som CGI-processer eller andra program kan skapa. En app kan dock inte komma åt minnet eller data i en annan app, även om den finns på samma virtuella dator.
Appar kan köra skript eller sidor som skrivits med ramverk för webbutveckling som stöds. App Service konfigurerar inte några inställningar för webbramverk till mer begränsade lägen. Till exempel körs ASP.NET appar som körs i App Service i fullständigt förtroende i stället för ett mer begränsat förtroendeläge. Webbramverk, inklusive både klassisk ASP och ASP.NET, kan anropa processbaserade COM-komponenter (till exempel ActiveX-dataobjekt) som är registrerade som standard i Windows-operativsystemet. Webbramverk kan inte anropa com-komponenter som inte är processbaserade.
En app kan skapa och köra godtycklig kod, öppna ett kommandogränssnitt eller köra ett PowerShell-skript. Körbara program och skript är dock fortfarande begränsade till de behörigheter som beviljas den överordnade programpoolen. En app kan till exempel skapa ett körbart program som gör ett utgående HTTP-anrop, men det körbara programmet kan inte försöka avbinda IP-adressen för en virtuell dator från nätverkskortet. Att göra ett utgående nätverksanrop är tillåtet för kod med låg behörighet, men för att kunna konfigurera om nätverksinställningarna på en virtuell dator krävs administratörsbehörighet.
Diagnostikloggar och händelser
Logginformation är en annan uppsättning data som vissa appar försöker komma åt. De typer av logginformation som är tillgänglig för kod som körs i App Service innehåller diagnostik- och logginformation som en app genererar och enkelt kan komma åt.
Till exempel är appgenererade W3C HTTP-loggar tillgängliga antingen:
- I en loggkatalog på den nätverksresursplats som du skapade för appen
- I Blob Storage om du konfigurerar W3C-loggning till lagring
Det senare alternativet gör det möjligt för appar att samla in stora mängder loggar utan att överskrida de fillagringsgränser som är associerade med en nätverksresurs.
På samma sätt kan diagnostikinformation i realtid från .NET-appar loggas via infrastrukturen för .NET-spårning och diagnostik. Du kan sedan skriva spårningsinformationen till antingen appens nätverksresurs eller till en bloblagringsplats.
Områden för diagnostikloggning och spårning som inte är tillgängliga för appar är Händelser med Windows-händelsespårning för Windows (ETW) och vanliga Windows-händelseloggar (till exempel system-, program- och säkerhetshändelseloggar). Eftersom ETW-spårningsinformation potentiellt kan visas på en dator (med rätt åtkomstkontrollistor) blockeras läsåtkomst och skrivåtkomst till ETW-händelser. API-anrop för att läsa och skriva ETW-händelser och vanliga Windows-händelseloggar kan verka fungera, men i själva verket har programkoden ingen åtkomst till dessa händelsedata.
Registeråtkomst
Appar har skrivskyddad åtkomst till mycket (men inte alla) av registret för den virtuella datorn som de körs på. Den här åtkomsten innebär att appar kan komma åt registernycklar som tillåter skrivskyddad åtkomst till gruppen Lokala användare. Ett område i registret som för närvarande inte stöds för läs- eller skrivåtkomst är HKEY\_CURRENT\_USER registreringsdatafilen.
Skrivåtkomst till registret blockeras, inklusive åtkomst till registernycklar per användare. Från appens perspektiv kan den inte förlita sig på skrivåtkomst till registret i Azure-miljön eftersom appar kan migreras mellan virtuella datorer. Den enda beständiga skrivbara lagring som en app kan vara beroende av är innehållskatalogstrukturen per app som lagras på App Service UNC-resurser.
Fjärrskrivbordsåtkomst
App Service ger inte fjärrskrivbordsåtkomst till de virtuella datorinstanserna.
Mer information
Den senaste informationen om körningsmiljön för App Service finns i sandbox-miljön för Azure App Service. App Service-utvecklingsteamet underhåller den här sidan.