Operációs rendszer funkciói az Azure App Service-ben

Ez a cikk az alapszintű operációsrendszer-funkciókat ismerteti, amelyek az Azure App Service-ben futó összes Windows-alkalmazás számára elérhetők. 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. Root hozzáféréssel rendelkezik a tárolóhoz, de nincs hozzáférése a hoszt 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, 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áljuk a konkrét kisverziókat vagy javítócsomag verziókat. 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 egy szolgáltatás, amely az Azure-platform mint szolgáltatásinfrastruktúra (PaaS) tetején fut. 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 a következők:

• 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%).

Legjobb gyakorlat, ha mindig a %SystemDrive% és %ResourceDrive% környezeti változókat használjuk a rögzített fájlelérési utak helyett. A két környezeti változóból visszaadott gyökérútvonal idővel d:\ értékről c:\ értékre változott. Régebbi alkalmazások, amelyek fájlútvonal-hivatkozásokkal vannak keményként kódolva, továbbra is működnek, mert az App Service automatikusan átirányítja d:\-et, hogy d:\-re mutasson. 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 lehet ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk).
• 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 minden tartalommegosztás univerzális elnevezési konvenció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 hamis 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% könyvtár egy, az adott alkalmazás számára dedikált tartalommegosztási területre mutat az Azure Storage-ben. A méretét a tarifacsomag határozza meg. 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 által felhasználható tárhely mennyiségét, hogy megelőzze az alkalmazások helyi fájltároló túlzott mértékű használatát. 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:

Kategória	Helyi tárterületkorlát
B1/S1/P1	11 GB
B2/S2/P2	15 GB
B3/S3/P3	58 GB
P0v3/P0v4	11 GB
P1v2/P1v3/P1mv3/P1v4/P1mv4/Izolált1/Izolált1v2	21 GB
P2v2/P2v3/P2mv3/P2v4/P2mv4/Izolált2/Izolált2v2	61 GB
P3v2/P3v3/P3mv3/P3v4/P3mv4/Izolált3/Izolált3v2	140 GB
Izolált4v2	276 GB
P4mv3/P4mv4	280 GB
Izolált5v2	552 GB
P5mv3/P5mv4	560 GB
Izolált6v2	1,104 GB

Az ideiglenes ASP.NET fájlok könyvtára és a tömörített IIS-fájlok könyvtára két példa arra, hogyan használja az App Service az ideiglenes helyi tárolót. 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ár (%SystemDrive%\local) könyvtár nincs 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ásoknak szintén korlátozott képességük van egy helyi visszacsatoló kapcsolat létesítésére, és arra, hogy egy alkalmazás figyeljen arra a helyi visszacsatoló socketre. Ez a funkció lehetővé teszi az alkalmazások számára, hogy a helyi loopback aljzatokon hallgassanak, mint a funkcionalitásuk része. Minden alkalmazás privát visszacsatolási kapcsolattal rendelkezik. Az egyik alkalmazás nem tud figyelni a másik alkalmazás által létrehozott helyi visszacsatolási aljzatra.

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 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 kezdeményezése alacsony jogosultságú kód esetén engedélyezett, de a virtuális gép 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 található naplókönyvtárban.
• A Blob Storage-ban, ha W3C-naplózást állít be a tárolóba.

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 a megfelelő hozzáférés-vezérlési listák használatával potenciálisan megtekinthetők egy gépen, 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éhez, bár nem mindegyikhez. 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 rendszerleíró adatbázis egyik olyan része, amely jelenleg nem támogatott sem olvasási, sem írási hozzáférés szempontjából, 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 írási hozzáférésre a beállításjegyzékhez 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.

Kapcsolódó tartalom

Az App Service végrehajtási környezetével kapcsolatos legtöbb up-todátuminformációért tekintse meg az Azure App Service tesztkörnyezetét. Az App Service fejlesztői csapata fenntartja ezt a lapot.