Functionaliteit van het besturingssysteem in Azure-app Service
In dit artikel wordt de basislijnbesturingssysteemfunctionaliteit beschreven die beschikbaar is voor alle Windows-apps die worden uitgevoerd in Azure-app Service. Deze functionaliteit omvat bestands-, netwerk- en registertoegang, samen met diagnostische logboeken en gebeurtenissen.
Notitie
Linux-apps in App Service worden uitgevoerd in hun eigen containers. U hebt hoofdtoegang tot de container, maar geen toegang tot het hostbesturingssysteem. Voor apps die in Windows-containers worden uitgevoerd, hebt u ook beheerderstoegang tot de container, maar geen toegang tot het hostbesturingssysteem.
App Service-planlagen
App Service voert klant-apps uit in een hostingomgeving met meerdere tenants. Apps die zijn geïmplementeerd in de gratis en gedeelde lagen worden uitgevoerd in werkprocessen op gedeelde virtuele machines (VM's). Apps die zijn geïmplementeerd in de Standard- en Premium-lagen worden uitgevoerd op VM's die specifiek zijn toegewezen voor de apps die zijn gekoppeld aan één klant.
Notitie
App Service Free- en Shared -serviceplannen (preview) zijn basislagen die worden uitgevoerd op dezelfde virtuele Azure-machines als andere App Service-apps. Sommige apps zijn mogelijk het eigendom van andere klanten. Deze lagen zijn alleen bedoeld voor ontwikkelings- en testdoeleinden.
Omdat App Service ondersteuning biedt voor een naadloze schaalervaring tussen lagen, blijft de beveiligingsconfiguratie die wordt afgedwongen voor App Service-apps hetzelfde. Deze configuratie zorgt ervoor dat apps zich niet plotseling anders gedragen en op onverwachte manieren mislukken wanneer een App Service-plan overschakelt van de ene laag naar de andere.
Frameworks voor ontwikkeling
App Service-prijscategorieën bepalen de hoeveelheid rekenresources (CPU, schijfopslag, geheugen en netwerkuitgang) die beschikbaar zijn voor apps. De breedte van frameworkfunctionaliteit die beschikbaar is voor apps blijft echter hetzelfde, ongeacht de schaallagen.
App Service ondersteunt verschillende ontwikkelframeworks, waaronder ASP.NET, klassieke ASP, Node.js, PHP en Python. Om de beveiligingsconfiguratie te vereenvoudigen en te normaliseren, voeren App Service-apps doorgaans de ontwikkelframeworks uit met hun standaardinstellingen. De frameworks en runtime-onderdelen die het platform biedt, worden regelmatig bijgewerkt om te voldoen aan beveiligings- en nalevingsvereisten. Daarom garanderen we geen specifieke secundaire/patchversies. We raden klanten aan om naar behoefte primaire versies te targeten.
In de volgende secties vindt u een overzicht van de algemene soorten besturingssysteemfunctionaliteit die beschikbaar is voor App Service-apps.
Bestandstoegang
Er bestaan verschillende stations in App Service, waaronder lokale stations en netwerkstations.
Lokale stations
In de kern is App Service een service die wordt uitgevoerd boven op de PaaS-infrastructuur (Platform as a Service). Als gevolg hiervan zijn de lokale stations die zijn gekoppeld aan een virtuele machine dezelfde stationstypen die beschikbaar zijn voor elke werkrol die wordt uitgevoerd in Azure. Deze omvatten:
- Een besturingssysteemstation (
%SystemDrive%) waarvan de grootte afhankelijk is van de grootte van de virtuele machine. - Een resourcestation (
%ResourceDrive%) dat App Service intern gebruikt.
Een best practice is om altijd de omgevingsvariabelen en %ResourceDrive% in plaats van in code vastgelegde bestandspaden %SystemDrive% te gebruiken. Het hoofdpad dat wordt geretourneerd van deze twee omgevingsvariabelen, is in de loop van de tijd verschoven van d:\ naar c:\. Oudere toepassingen die in code zijn vastgelegd met bestandspadverwijzingen om d:\ te blijven werken, omdat App Service automatisch opnieuw toewijst d:\ om te verwijzen c:\. Zoals eerder vermeld, raden we u ten zeerste aan om altijd de omgevingsvariabelen te gebruiken bij het bouwen van bestandspaden en verwarring te voorkomen over platformwijzigingen in het standaardpad van het hoofdbestand.
Het is belangrijk om het schijfgebruik te bewaken naarmate uw toepassing groeit. Het bereiken van het schijfquotum kan nadelige gevolgen hebben voor uw toepassing. Voorbeeld:
- De app kan een fout veroorzaken die aangeeft dat er onvoldoende ruimte op de schijf is.
- Mogelijk ziet u schijffouten bij het bladeren naar de Kudu-console.
- Implementatie vanuit Azure DevOps of Visual Studio kan mislukken met
ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk). - Uw app kan trage prestaties hebben.
Netwerkstations (UNC-shares)
Een van de unieke aspecten van App Service die de implementatie en het onderhoud van apps eenvoudig maken, is dat alle inhoudsshares worden opgeslagen op een set UNC-shares. Dit model is geschikt voor het algemene patroon van inhoudsopslag dat wordt gebruikt door on-premises webhostingomgevingen met meerdere servers met gelijke taakverdeling.
In App Service worden UNC-shares gemaakt in elk datacenter. Een percentage van de gebruikersinhoud voor alle klanten in elk datacenter wordt toegewezen aan elke UNC-share. Het abonnement van elke klant heeft een gereserveerde mapstructuur op een specifieke UNC-share in een datacenter. Een klant kan meerdere apps hebben gemaakt in een specifiek datacenter, dus alle mappen die deel uitmaken van één klantabonnement, worden gemaakt op dezelfde UNC-share.
Vanwege de manier waarop Azure-services werken, verandert de specifieke virtuele machine die verantwoordelijk is voor het hosten van een UNC-share in de loop van de tijd. UNC-shares worden gekoppeld door verschillende virtuele machines, omdat ze tijdens de normale uitvoering van Azure-bewerkingen omhoog en omlaag worden gebracht. Daarom mogen apps nooit in code vastgelegde veronderstellingen maken dat de computergegevens in een UNC-bestandspad in de loop van de tijd stabiel blijven. In plaats daarvan moeten ze het handige faux absolute pad %HOME%\site gebruiken dat App Service biedt.
Het faux absolute pad is een draagbare methode voor het verwijzen naar uw eigen app. Het is niet specifiek voor een app of gebruiker. Met behulp van %HOME%\sitekunt u gedeelde bestanden van app naar app overdragen zonder een nieuw absoluut pad voor elke overdracht te hoeven configureren.
Typen bestandstoegang verleend aan een app
De %HOME% map in een app wordt toegewezen aan een inhoudsshare in Azure Storage die is toegewezen voor die app. De prijscategorie definieert de grootte. Het kan mappen bevatten, zoals mappen voor inhoud, fout- en diagnostische logboeken en eerdere versies van de app die door broncodebeheer zijn gemaakt. Deze mappen zijn beschikbaar voor de toepassingscode van de app tijdens runtime voor lees- en schrijftoegang. Omdat de bestanden niet lokaal worden opgeslagen, blijven ze bij het opnieuw opstarten van de app staan.
Op het systeemstation reserveert App Service zich %SystemDrive%\local voor app-specifieke tijdelijke lokale opslag. Wijzigingen in bestanden in deze map zijn niet permanent voor het opnieuw opstarten van de app. Hoewel een app volledige lees- en schrijftoegang heeft tot een eigen tijdelijke lokale opslag, is die opslag niet bedoeld voor direct gebruik door de toepassingscode. In plaats daarvan is het de bedoeling om tijdelijke bestandsopslag te bieden voor IIS- en webtoepassingsframeworks.
App Service beperkt de hoeveelheid opslagruimte %SystemDrive%\local voor elke app om te voorkomen dat afzonderlijke apps overmatige hoeveelheden lokale bestandsopslag gebruiken. Voor de lagen Gratis, Gedeeld en Verbruik (Azure Functions) is de limiet 500 MB. De volgende tabel bevat andere lagen:
| Laag | Lokale bestandsopslag |
|---|---|
| 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/Isolated3/Isolated3v2 | 140 GB |
| Geïsoleerd4v2 | 276 GB |
| P4mv3 | 280 GB |
| Geïsoleerd5v2 | 552 GB |
| P5mv3 | 560 GB |
| Geïsoleerde6v2 | 1104 GB |
Twee voorbeelden van hoe App Service gebruikmaakt van tijdelijke lokale opslag, zijn de map voor tijdelijke ASP.NET bestanden en de map voor gecomprimeerde IIS-bestanden. Het ASP.NET compilatiesysteem maakt gebruik van de %SystemDrive%\local\Temporary ASP.NET Files map als tijdelijke compilatiecachelocatie. IIS gebruikt de %SystemDrive%\local\IIS Temporary Compressed Files map om gecomprimeerde antwoorduitvoer op te slaan. Beide typen bestandsgebruik (samen met andere) worden in App Service opnieuw toegewezen aan tijdelijke lokale opslag per app. Met deze hertoepassing kunt u ervoor zorgen dat de functionaliteit blijft functioneren zoals verwacht.
Elke app in App Service wordt uitgevoerd als een willekeurige, unieke, laaggeprivilegieerde werkprocesidentiteit genaamd de identiteit van de groep van toepassingen. Toepassingscode gebruikt deze identiteit voor eenvoudige alleen-lezentoegang tot het besturingssysteemstation. Deze toegang betekent dat toepassingscode algemene mapstructuren kan vermelden en algemene bestanden op het besturingssysteemstation kan lezen. Hoewel dit toegangsniveau algemeen lijkt te zijn, zijn dezelfde mappen en bestanden toegankelijk wanneer u een werkrol inricht in een door Azure gehoste service en de inhoud van het station leest.
Bestandstoegang tussen meerdere exemplaren
De inhoudssharemap (%HOME%) bevat de inhoud van een app en de toepassingscode kan ernaar schrijven. Als een app wordt uitgevoerd op meerdere exemplaren, wordt de %HOME% map gedeeld tussen alle exemplaren, zodat alle exemplaren dezelfde map zien. Als een app bijvoorbeeld geüploade bestanden opslaat in de %HOME% map, zijn deze bestanden onmiddellijk beschikbaar voor alle exemplaren.
De tijdelijke lokale opslagmap (%SystemDrive%\local) wordt niet gedeeld tussen exemplaren. Het wordt ook niet gedeeld tussen de app en de Bijbehorende Kudu-app.
Netwerktoegang
Toepassingscode kan TCP/IP- en UDP-protocollen gebruiken om uitgaande netwerkverbindingen te maken met internet toegankelijke eindpunten die externe services beschikbaar maken. Apps kunnen dezelfde protocollen gebruiken om verbinding te maken met services binnen Azure, bijvoorbeeld door HTTPS-verbindingen met Azure SQL Database tot stand te brengen.
Er is ook een beperkte mogelijkheid voor apps om één lokale loopback-verbinding tot stand te brengen en een app te laten luisteren op die lokale loopback-socket. Met deze functie kunnen apps die luisteren op lokale loopback-sockets als onderdeel van hun functionaliteit. Elke app heeft een privé-loopback-verbinding. De ene app kan niet luisteren naar een lokale loopback-socket die door een andere app is ingesteld.
Benoemde pijpen worden ook ondersteund als mechanisme voor communicatie tussen processen die gezamenlijk een app uitvoeren. De IIS FastCGI-module is bijvoorbeeld afhankelijk van benoemde pijpen om de afzonderlijke processen met PHP-pagina's te coördineren.
Code-uitvoering, processen en geheugen
Zoals eerder vermeld, worden apps uitgevoerd binnen werkprocessen met beperkte bevoegdheden met behulp van een identiteit van een willekeurige toepassingsgroep. Toepassingscode heeft toegang tot de geheugenruimte die is gekoppeld aan het werkproces, samen met eventuele onderliggende processen die CGI-processen of andere toepassingen kunnen spawnen. De ene app heeft echter geen toegang tot het geheugen of de gegevens van een andere app, zelfs niet als deze zich op dezelfde virtuele machine bevindt.
Apps kunnen scripts of pagina's uitvoeren die zijn geschreven met ondersteunde frameworks voor webontwikkeling. App Service configureert geen webframeworkinstellingen voor meer beperkte modi. ASP.NET apps die in App Service worden uitgevoerd, worden bijvoorbeeld volledig vertrouwd uitgevoerd, in plaats van een beperktere vertrouwensmodus. Webframeworks, waaronder zowel klassieke ASP als ASP.NET, kunnen COM-onderdelen (zoals ActiveX-gegevensobjecten) die standaard zijn geregistreerd op het Windows-besturingssysteem aanroepen. Webframeworks kunnen geen com-onderdelen van het proces aanroepen.
Een app kan willekeurige code spawnen en uitvoeren, een opdrachtshell openen of een PowerShell-script uitvoeren. Uitvoerbare programma's en scripts zijn echter nog steeds beperkt tot de bevoegdheden die zijn verleend aan de bovenliggende groep van toepassingen. Een app kan bijvoorbeeld een uitvoerbaar programma maken dat een uitgaande HTTP-aanroep maakt, maar dat uitvoerbare programma kan het IP-adres van een virtuele machine niet losmaken van de netwerkadapter. Het maken van een uitgaande netwerkaanroep is toegestaan voor code met beperkte bevoegdheden, maar voor het opnieuw configureren van netwerkinstellingen op een virtuele machine zijn beheerdersbevoegdheden vereist.
Diagnostische logboeken en gebeurtenissen
Logboekgegevens zijn een andere set gegevens waartoe sommige apps toegang proberen te krijgen. De typen logboekgegevens die beschikbaar zijn voor code die in App Service wordt uitgevoerd, bevatten diagnostische en logboekgegevens die door een app worden gegenereerd en die eenvoudig toegankelijk zijn.
Zo zijn door de app gegenereerde W3C HTTP-logboeken beschikbaar:
- In een logboekmap op de netwerksharelocatie die u voor de app hebt gemaakt
- In blobopslag als u W3C-logboekregistratie instelt op opslag
Met deze laatste optie kunnen apps grote hoeveelheden logboeken verzamelen zonder de limieten voor bestandsopslag te overschrijden die zijn gekoppeld aan een netwerkshare.
Op dezelfde manier kunnen realtime diagnostische gegevens van .NET-apps worden vastgelegd via de .NET-tracerings- en diagnostische infrastructuur. Vervolgens kunt u de traceringsgegevens schrijven naar de netwerkshare van de app of naar een blobopslaglocatie.
Gebieden van diagnostische logboekregistratie en tracering die niet beschikbaar zijn voor apps, zijn Windows Event Tracing voor Windows-gebeurtenissen (ETW) en algemene Windows-gebeurtenislogboeken (bijvoorbeeld systeem-, toepassings- en beveiligingslogboeken). Omdat ETW-traceringsinformatie mogelijk kan worden weergegeven op een computer (met de juiste toegangsbeheerlijsten), worden leestoegang en schrijftoegang tot ETW-gebeurtenissen geblokkeerd. API-aanroepen voor het lezen en schrijven van ETW-gebeurtenissen en algemene Windows-gebeurtenislogboeken lijken te werken, maar in werkelijkheid heeft de toepassingscode geen toegang tot deze gebeurtenisgegevens.
Registertoegang
Apps hebben alleen-lezentoegang tot veel (hoewel niet alle) register van de virtuele machine waarop ze worden uitgevoerd. Deze toegang betekent dat apps toegang hebben tot registersleutels die alleen-lezentoegang tot de groep Lokale gebruikers toestaan. Een gebied van het register dat momenteel niet wordt ondersteund voor lees- of schrijftoegang, is de HKEY\_CURRENT\_USER component.
Schrijftoegang tot het register wordt geblokkeerd, inclusief toegang tot registersleutels per gebruiker. Vanuit het perspectief van de app kan deze niet vertrouwen op schrijftoegang tot het register in de Azure-omgeving, omdat apps kunnen worden gemigreerd tussen virtuele machines. De enige permanente beschrijfbare opslag waarop een app kan zijn gebaseerd, is de mapstructuur per app die is opgeslagen op de Unc-shares van App Service.
Extern bureaublad-toegang
App Service biedt geen extern bureaublad-toegang tot de VM-exemplaren.
Meer informatie
Zie de Azure-app Service-sandbox voor de meest recente informatie over de uitvoeringsomgeving van App Service. Het ontwikkelteam van App Service onderhoudt deze pagina.