Operációsrendszer-funkciók a Azure-alkalmazás szolgáltatásban

Ez a cikk a Azure-alkalmazás Szolgáltatásban futó összes Windows-alkalmazás számára elérhető alapszintű operációsrendszer-funkciókat ismerteti. Ez a funkció magában foglalja a fájl-, hálózati és beállításjegyzék-hozzáférést, valamint a diagnosztikai naplókat és eseményeket.

Megjegyzés:

Az App Service-ben futó Linux-alkalmazások a saját tárolóikban futnak. Gyökérszintű hozzáféréssel rendelkezik a tárolóhoz, de nincs hozzáférése a gazdagép operációs rendszeréhez. Hasonlóképpen, a Windows-tárolókban futó alkalmazások esetében rendszergazdai hozzáféréssel rendelkezik a tárolóhoz, de nincs hozzáférése a gazdagép operációs rendszeréhez.

App Service-csomagszintek

Az App Service több-bérlős üzemeltetési környezetben futtatja az ügyfélalkalmazásokat. Az ingyenes és megosztott szinteken üzembe helyezett alkalmazások munkavégző folyamatokban futnak megosztott virtuális gépeken (virtuális gépeken). A Standard és a Prémium szinten üzembe helyezett alkalmazások kifejezetten az egyetlen ügyfélhez társított alkalmazásokhoz dedikált virtuális gépeken futnak.

Megjegyzés:

Az App Service ingyenes és megosztott (előzetes verziójú) szolgáltatáscsomagjai olyan alapszintek, amelyek ugyanazon az Azure-beli virtuális gépen futnak, mint más App Service-alkalmazások. Egyes alkalmazások más ügyfelekhez tartozhatnak. Ezek a szintek csak fejlesztési és tesztelési célokra szolgálnak.

Mivel az App Service támogatja a rétegek közötti zökkenőmentes skálázást, az App Service-alkalmazásokhoz kikényszerített biztonsági konfiguráció változatlan marad. Ez a konfiguráció biztosítja, hogy az alkalmazások ne viselkedjenek hirtelen másként, és váratlan módon hiúsuljanak meg, amikor egy App Service-csomag egyik rétegről a másikra vált.

Fejlesztési keretrendszerek

Az App Service tarifacsomagjai szabályozzák az alkalmazások számára elérhető számítási erőforrások (CPU, lemeztároló, memória és hálózati kimenő forgalom) mennyiségét. Az alkalmazások számára elérhető keretrendszerfunkciók azonban a méretezési szintektől függetlenül változatlanok maradnak.

Az App Service különböző fejlesztési keretrendszereket támogat, például ASP.NET, klasszikus ASP-t, Node.js-t, PHP-t és Pythont. A biztonsági konfiguráció egyszerűsítése és normalizálása érdekében az App Service-alkalmazások általában az alapértelmezett beállításokkal futtatják a fejlesztési keretrendszereket. A platform által biztosított keretrendszereket és futtatókörnyezeti összetevőket rendszeresen frissítik, hogy megfeleljenek a biztonsági és megfelelőségi követelményeknek. Ezért nem garantálunk bizonyos alverziókat/javításokat. Azt javasoljuk, hogy az ügyfelek igény szerint célba válassza a főverziókat.

Az alábbi szakaszok összefoglalják az App Service-alkalmazások számára elérhető operációsrendszer-funkciók általános típusait.

Fájlhozzáférés

Az App Service-ben különböző meghajtók léteznek, beleértve a helyi meghajtókat és a hálózati meghajtókat.

Helyi meghajtók

Az App Service az Azure-platform mint szolgáltatásinfrastruktúra (PaaS) tetején futó szolgáltatás. Ennek eredményeképpen a virtuális géphez társított helyi meghajtók ugyanazok a meghajtótípusok, amelyek az Azure-ban futó feldolgozói szerepkörök számára elérhetők. Ezek közé tartoznak például az alábbiak:

• Egy operációsrendszer-meghajtó (%SystemDrive%), amelynek mérete a virtuális gép méretétől függ.
• Az App Service által belsőleg használt erőforrás-meghajtó (%ResourceDrive%).

Ajánlott eljárás a környezeti változók %SystemDrive% használata, és %ResourceDrive% nem a rögzített fájlelérési utak használata. A két környezeti változóból visszaadott gyökérútvonal idővel d:\ áttért a következőre c:\: . A fájlútvonal-hivatkozásokat tartalmazó régebbi alkalmazások azonban továbbra is működni fognak d:\ , mert az App Service automatikusan újraképezi d:\ , hogy a következőre mutasson c:\. Ahogy korábban már említettük, javasoljuk, hogy mindig használja a környezeti változókat a fájlelérési utak létrehozásakor, és kerülje az alapértelmezett gyökérfájl elérési útjának platformmódosításokkal kapcsolatos keveredését.

Fontos, hogy az alkalmazás növekedésével figyelje a lemezkihasználtságot. A lemezkvóta elérése kedvezőtlen hatással lehet az alkalmazásra. Például:

• Az alkalmazás hibát jelezhet, amely azt jelzi, hogy nincs elegendő hely a lemezen.
• Lemezhibák jelenhetnek meg a Kudu-konzolra való böngészéskor.
• Az Azure DevOpsból vagy a Visual Studióból történő üzembe helyezés sikertelen ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk)lehet.
• Előfordulhat, hogy az alkalmazás teljesítménye lassú.

Hálózati meghajtók (UNC-megosztások)

Az App Service egyik egyedi aspektusa, amely megkönnyíti az alkalmazások üzembe helyezését és karbantartását, az, hogy az összes tartalommegosztás UNC-megosztásokon van tárolva. Ez a modell jól megfelel a több elosztott terhelésű kiszolgálóval rendelkező helyszíni web hosting környezetek által használt tartalomtárolási mintának.

Az App Service-ben az UNC-megosztások minden adatközpontban létrejönnek. Az egyes adatközpontokban lévő összes ügyfél felhasználói tartalmának százalékos aránya minden UNC-megosztáshoz van lefoglalva. Minden ügyfél előfizetése fenntartott címtárstruktúrával rendelkezik egy adott UNC-megosztáson egy adatközpontban. Előfordulhat, hogy egy ügyfél több alkalmazást is létrehoz egy adott adatközpontban, így az egyetlen ügyfél-előfizetéshez tartozó összes címtár ugyanazon UNC-megosztáson jön létre.

Az Azure-szolgáltatások működése miatt az UNC-megosztás üzemeltetéséért felelős konkrét virtuális gép idővel megváltozik. Az UNC-megosztásokat különböző virtuális gépek csatlakoztatják, mivel azok az Azure normál működése során fel- és le vannak hozva. Ezért az alkalmazások soha nem tehetnek szigorúan kódolt feltételezéseket arról, hogy az UNC-fájl elérési útjának gépi információi idővel stabilak maradnak. Ehelyett az App Service által biztosított kényelmes ál-abszolút elérési utat %HOME%\site kell használniuk.

A halvány abszolút elérési út egy hordozható módszer a saját alkalmazásra való hivatkozáshoz. Ez nem vonatkozik semmilyen alkalmazásra vagy felhasználóra. A használatával %HOME%\siteátviheti a megosztott fájlokat az alkalmazásból az alkalmazásba anélkül, hogy minden átvitelhez új abszolút elérési utat kellene konfigurálnia.

Az alkalmazás számára biztosított fájlhozzáférés típusai

Az %HOME% alkalmazás könyvtára az adott alkalmazás számára dedikált Azure Storage-tartalommegosztásra képez le. A tarifacsomag határozza meg a méretét. Tartalmazhat könyvtárakat, például a tartalomhoz, a hiba- és diagnosztikai naplókhoz, valamint az alkalmazás korábbi verzióihoz, amelyeket a forrásvezérlő létrehozott. Ezek a könyvtárak futásidőben érhetők el az alkalmazás alkalmazáskódjához olvasási és írási hozzáféréshez. Mivel a fájlok nincsenek helyben tárolva, az alkalmazás újraindítása során állandóak.

A rendszermeghajtón az App Service fenntartja %SystemDrive%\local az alkalmazásspecifikus ideiglenes helyi tárolást. A címtárban lévő fájlok módosításai nem állandóak az alkalmazás újraindítása során. Bár egy alkalmazás teljes olvasási és írási hozzáféréssel rendelkezik a saját ideiglenes helyi tárolóhoz, ez a tároló nem az alkalmazáskód közvetlen használatára szolgál. A cél inkább az, hogy ideiglenes fájltárolást biztosítson az IIS- és webalkalmazás-keretrendszerekhez.

Az App Service korlátozza az egyes alkalmazások tárterületének %SystemDrive%\local mennyiségét, hogy az egyes alkalmazások túlzott mennyiségű helyi fájltárolót használjanak fel. Az ingyenes, megosztott és használati (Azure Functions) szintek esetében a korlát 500 MB. Az alábbi táblázat az egyéb szinteket sorolja fel:

Szint	Helyi fájltároló
B1/S1/P1	11 GB
B2/S2/P2	15 GB
B3/S3/P3	58 GB
P0v3	11 GB
P1v2/P1v3/P1mv3/Izolált1/Izolált1v2	21 GB
P2v2/P2v3/P2mv3/Izolált2/Izolált2v2	61 GB
P3v2/P3v3/P3mv3/Izolált3/Izolált3v2	140 GB
Izolált4v2	276 GB
P4mv3	280 GB
Izolált5v2	552 GB
P5mv3	560 GB
Izolált6v2	1,104 GB

Két példa arra, hogy az App Service hogyan használja az ideiglenes helyi tárolót, az ideiglenes ASP.NET fájlok könyvtára, valamint az IIS-tömörített fájlok könyvtára. A ASP.NET fordítási rendszer a %SystemDrive%\local\Temporary ASP.NET Files címtárat használja ideiglenes fordítási gyorsítótár-helyként. Az IIS a címtár használatával tárolja a %SystemDrive%\local\IIS Temporary Compressed Files tömörített válaszkimenetet. Mindkét fájlhasználati típus (másokkal együtt) az App Service-ben alkalmazásonkénti ideiglenes helyi tárolóra van leképezve. Ez az újrakészítés segít biztosítani, hogy a funkciók a várt módon folytatódhassanak.

Az App Service-ben minden alkalmazás egy véletlenszerű, egyedi, alacsony jogosultságú feldolgozói folyamat identitásaként fut, amelyet az alkalmazáskészlet-identitásnak hívnak. Az alkalmazáskód ezt az identitást használja az operációsrendszer-meghajtóhoz való egyszerű írásvédett hozzáféréshez. Ez a hozzáférés azt jelenti, hogy az alkalmazáskód listázhatja a gyakori címtárstruktúrákat, és beolvassa a közös fájlokat az operációs rendszer meghajtóján. Bár ez a hozzáférési szint tágnak tűnhet, ugyanazok a könyvtárak és fájlok érhetők el, amikor feldolgozói szerepkört épít ki egy Azure-ban üzemeltetett szolgáltatásban, és beolvassa a meghajtó tartalmát.

Fájlhozzáférés több példányon

A tartalommegosztási (%HOME%) könyvtár egy alkalmazás tartalmát tartalmazza, és az alkalmazáskód írhat hozzá. Ha egy alkalmazás több példányon fut, a %HOME% címtár minden példány között meg van osztva, így minden példány ugyanazt a könyvtárat látja. Ha például egy alkalmazás menti a feltöltött fájlokat a %HOME% könyvtárba, ezek a fájlok azonnal elérhetők lesznek az összes példány számára.

Az ideiglenes helyi tárolókönyvtár (%SystemDrive%\local) nem lesz megosztva a példányok között. Az alkalmazás és a Kudu-alkalmazás között sincs megosztva.

Hálózati hozzáférés

Az alkalmazáskód TCP/IP- és UDP-alapú protokollok használatával kimenő hálózati kapcsolatokat létesíthet a külső szolgáltatásokat elérhetővé tevő, internetkapcsolattal elérhető végpontokkal. Az alkalmazások ugyanazokat a protokollokat használhatják az Azure-beli szolgáltatásokhoz való csatlakozáshoz – például HTTPS-kapcsolatok létrehozásával az Azure SQL Database-hez.

Az alkalmazások korlátozottan képesek egy helyi visszacsatolási kapcsolatot létesíteni, és egy alkalmazás figyeli a helyi visszacsatolási szoftvercsatornát. Ez a funkció lehetővé teszi a helyi visszacsatolási szoftvercsatornákat figyelő alkalmazásokat a funkciójuk részeként. Minden alkalmazás privát visszacsatolási kapcsolattal rendelkezik. Az egyik alkalmazás nem tudja meghallgatni a másik alkalmazás által létrehozott helyi visszacsatolási szoftvercsatornát.

A nevesített csövek az alkalmazásokat együttesen futtató folyamatok közötti kommunikáció folyamatközi kommunikációjának mechanizmusaként is támogatottak. Az IIS FastCGI modul például nevesített csövekre támaszkodik a PHP-oldalakat futtató egyes folyamatok koordinálásához.

Kódvégrehajtás, folyamatok és memória

Ahogy korábban már említettük, az alkalmazások alacsony jogosultságú feldolgozói folyamatokban futnak véletlenszerű alkalmazáskészlet-identitás használatával. Az alkalmazáskód hozzáféréssel rendelkezik a feldolgozó folyamathoz társított memóriaterülethez, valamint minden olyan gyermekfolyamathoz, amelyet a CGI-folyamatok vagy más alkalmazások hozhatnak el. Az egyik alkalmazás azonban nem tudja elérni egy másik alkalmazás memóriáját vagy adatait, még akkor sem, ha ugyanazon a virtuális gépen található.

Az alkalmazások támogatott webfejlesztési keretrendszerekkel írt szkripteket vagy lapokat futtathatnak. Az App Service nem konfigurálja a webes keretrendszer beállításait korlátozottabb módokra. Például ASP.NET App Service-ben futó alkalmazások teljes megbízhatóságban futnak, nem pedig korlátozottabb megbízhatósági módban. A webes keretrendszerek, beleértve a klasszikus ASP-t és a ASP.NET is, meghívhatják a folyamat közbeni COM-összetevőket (például ActiveX-adatobjektumokat), amelyek alapértelmezés szerint regisztrálva vannak a Windows operációs rendszeren. A webes keretrendszerek nem hívhatják meg a folyamaton kívüli COM-összetevőket.

Az alkalmazások tetszőleges kódot hozhatnak létre és futtathatnak, parancshéjat nyithatnak meg vagy PowerShell-szkriptet futtathatnak. A végrehajtható programok és szkriptek azonban továbbra is a szülőalkalmazás-készlet számára biztosított jogosultságokra korlátozódnak. Egy alkalmazás például létrehozhat egy végrehajtható programot, amely kimenő HTTP-hívást indít, de ez a végrehajtható program nem tudja leválasztani a virtuális gép IP-címét a hálózati adapterről. A kimenő hálózati hívás alacsony jogosultságú kód esetén engedélyezett, de a virtuális gépek hálózati beállításainak újrakonfigurálásához rendszergazdai jogosultságokra van szükség.

Diagnosztikai naplók és események

A naplóadatok egy másik adatkészlet, amelyet egyes alkalmazások megpróbálnak elérni. Az App Service-ben futó kódhoz elérhető naplóadatok típusai közé tartoznak az alkalmazások által létrehozott és könnyen elérhető diagnosztikai és naplóadatok.

Az alkalmazás által létrehozott W3C HTTP-naplók például a következők:

• Az alkalmazáshoz létrehozott hálózati megosztási helyen lévő naplókönyvtárban
• A Blob Storage-ban, ha a W3C-naplózást tárolóra állítja be

Az utóbbi lehetőség lehetővé teszi az alkalmazások számára, hogy nagy mennyiségű naplót gyűjtsenek anélkül, hogy túllépik a hálózati megosztáshoz társított fájltárolási korlátokat.

Hasonlóképpen, a .NET-alkalmazások valós idejű diagnosztikai információi naplózhatók a .NET nyomkövetési és diagnosztikai infrastruktúrán keresztül. Ezután megírhatja a nyomkövetési információkat az alkalmazás hálózati megosztására vagy egy blobtároló helyre.

Az alkalmazások számára nem elérhető diagnosztikai naplózási és nyomkövetési területek a Windows-eseménykövetés windowsos (ETW) eseményei és gyakori Windows-eseménynaplók (például rendszer-, alkalmazás- és biztonsági eseménynaplók). Mivel az ETW nyomkövetési információi megtekinthetők egy gépen (a megfelelő hozzáférés-vezérlési listákkal), a rendszer letiltja az olvasási és írási hozzáférést az ETW-eseményekhez. Úgy tűnhet, hogy az ETW-események és a gyakori Windows-eseménynaplók olvasására és írására irányuló API-hívások működnek, de a valóságban az alkalmazáskódnak nincs hozzáférése ezekhez az eseményadatokhoz.

Beállításjegyzék-hozzáférés

Az alkalmazások írásvédett hozzáféréssel rendelkeznek az általuk futtatott virtuális gép beállításjegyzékének nagy részének (bár nem mindegyikéhez). Ez a hozzáférés azt jelenti, hogy az alkalmazások hozzáférhetnek a beállításkulcsokhoz, amelyek írásvédett hozzáférést biztosítanak a Helyi felhasználók csoporthoz. A beállításjegyzék egyik területe, amely jelenleg nem támogatott olvasási vagy írási hozzáféréshez, a HKEY\_CURRENT\_USER kaptár.

A beállításjegyzék írási hozzáférése le van tiltva, beleértve a felhasználónkénti beállításkulcsok elérését is. Az alkalmazás szempontjából nem támaszkodhat a beállításjegyzék írási hozzáférésére az Azure-környezetben, mert az alkalmazások áttelepíthetők virtuális gépekre. Az egyetlen állandó írható tároló, amelytől egy alkalmazás függhet, az App Service UNC-megosztásokon tárolt alkalmazásonkénti tartalomkönyvtár-struktúra.

Távoli asztali hozzáférés

Az App Service nem biztosít távoli asztali hozzáférést a virtuálisgép-példányokhoz.

További információ

Az App Service végrehajtási környezetével kapcsolatos legfrissebb információkért tekintse meg a Azure-alkalmazás Szolgáltatás tesztkörnyezetét. Az App Service fejlesztői csapata fenntartja ezt a lapot.