Funkce operačního systému ve službě Aplikace Azure Service

Tento článek popisuje základní funkce operačního systému, které jsou k dispozici pro všechny aplikace pro Windows spuštěné ve službě Aplikace Azure Service. Tato funkce zahrnuje přístup k souborům, síti a registru spolu s diagnostickými protokoly a událostmi.

Poznámka:

Linuxové aplikace ve službě App Service běží ve svých vlastních kontejnerech. Máte ke kontejneru přístup root, ale nemáte přístup k hostitelskému operačnímu systému. Stejně tak pro aplikace spuštěné v kontejnerech Windows máte k kontejneru přístup pro správu, ale nemáte přístup k hostitelskému operačnímu systému.

Úrovně plánu služby App Service

App Service spouští zákaznické aplikace v hostitelském prostředí s více tenanty. Aplikace nasazené na úrovních Free a Shared běží v pracovních procesech na sdílených virtuálních počítačích. Aplikace nasazené na úrovních Standard a Premium běží na virtuálních počítačích vyhrazených speciálně pro aplikace přidružené k jednomu zákazníkovi.

Poznámka:

Plány služby App Service Free a Shared (Preview) jsou základní úrovně, které běží na stejných virtuálních počítačích Azure jako jiné aplikace App Service. Některé aplikace můžou patřit jiným zákazníkům. Tyto úrovně jsou určeny pouze pro účely vývoje a testování.

Vzhledem k tomu, že App Service podporuje bezproblémové škálování mezi vrstvami, konfigurace zabezpečení vynucená pro aplikace App Service zůstává stejná. Tato konfigurace zajišťuje, že se aplikace najednou nechovají jinak a neočekávaně selžou, když se plán služby App Service přepne z jedné vrstvy na jinou.

Vývojové rámce

Cenové úrovně služby App Service řídí množství výpočetních prostředků (procesor, diskové úložiště, paměť a výchozí přenos dat sítě) dostupné pro aplikace. Šířka funkcí architektury dostupných pro aplikace však zůstává stejná bez ohledu na úrovně škálování.

App Service podporuje různé vývojové architektury, včetně ASP.NET, klasického ASP, Node.js, PHP a Pythonu. Aby se zjednodušila a normalizovala konfigurace zabezpečení, aplikace App Service obvykle spouštějí vývojové architektury s výchozím nastavením. Architektury a komponenty modulu runtime, které platforma poskytuje, se pravidelně aktualizují, aby splňovaly požadavky na zabezpečení a dodržování předpisů. Z tohoto důvodu nezaručujeme konkrétní podverze/verze oprav. Zákazníkům doporučujeme podle potřeby cílit na hlavní verze.

Následující části shrnují obecné druhy funkcí operačního systému, které jsou dostupné pro aplikace App Service.

Přístup k souborům

Ve službě App Service existují různé jednotky, včetně místních jednotek a síťových jednotek.

Místní jednotky

App Service je v jádru služba běžící nad infrastrukturou PaaS (Platforma jako služba) Azure. V důsledku toho jsou místní jednotky přidružené k virtuálnímu počítači stejné typy jednotek, které jsou k dispozici pro všechny role pracovního procesu spuštěné v Azure. Patří sem:

• Jednotka operačního systému (%SystemDrive%), jejíž velikost závisí na velikosti virtuálního počítače.
• Jednotka prostředku (%ResourceDrive%), kterou Služba App Service používá interně.

Osvědčeným postupem je vždy používat proměnné %SystemDrive% prostředí a %ResourceDrive% místo pevně zakódovaných cest k souborům. Kořenová cesta vrácená z těchto dvou proměnných prostředí se v průběhu času přesunula na d:\c:\. Starší aplikace jsou ale pevně zakódované s odkazy na cestu k souboru, aby d:\ pokračovaly v práci, protože App Service automaticky mapuje tak, aby ukazovaly d:\ na c:\. Jak jsme si poznamenali dříve, důrazně doporučujeme, abyste při sestavování cest k souborům vždy používali proměnné prostředí a vyhnuli se nejasnostem při změnách platformy ve výchozí kořenové cestě k souboru.

Je důležité monitorovat využití disků při růstu vaší aplikace. Dosažení kvóty disku může mít nepříznivý vliv na vaši aplikaci. Příklad:

• Aplikace může vyvolat chybu, která značí, že na disku není dostatek místa.
• Při procházení konzoly Kudu se můžou zobrazit chyby disku.
• Nasazení z Azure DevOps nebo sady Visual Studio může selhat s chybou ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk).
• Aplikace může mít nízký výkon.

Síťové jednotky (sdílené složky UNC)

Jedním z jedinečných aspektů služby App Service, které usnadňují nasazení a údržbu aplikací, je, že všechny sdílené složky obsahu jsou uložené na sadě sdílených složek UNC. Tento model se dobře mapuje na běžný model úložiště obsahu používaného místními prostředími hostování webů, které mají několik serverů s vyrovnáváním zatížení.

Ve službě App Service se sdílené složky UNC vytvářejí v každém datacentru. Procento uživatelského obsahu pro všechny zákazníky v každém datacentru je přiděleno ke každé sdílené složce UNC. Předplatné každého zákazníka má rezervovanou adresářovou strukturu pro konkrétní sdílenou složku UNC v datacentru. Zákazník může mít v určitém datacentru vytvořeno více aplikací, takže všechny adresáře, které patří do jednoho předplatného zákazníka, se vytvoří ve stejné sdílené složce UNC.

Vzhledem ke způsobu, jakým služby Azure fungují, se konkrétní virtuální počítač zodpovědný za hostování sdílené složky UNC v průběhu času mění. Sdílené složky UNC se připojují pomocí různých virtuálních počítačů, které se během normálního průběhu operací Azure přenesou do provozu. Z tohoto důvodu by aplikace nikdy neměly provádět pevně zakódované předpoklady, že informace o počítači v cestě k souboru UNC zůstanou stabilní v průběhu času. Místo toho by měli použít pohodlnou absolutní cestu%HOME%\site, kterou App Service poskytuje.

Absolutní cesta faux je přenosná metoda pro odkazování na vlastní aplikaci. Není specifický pro žádnou aplikaci ani uživatele. Pomocí aplikace %HOME%\sitemůžete přenášet sdílené soubory z aplikace do aplikace, aniž byste museli konfigurovat novou absolutní cestu pro každý přenos.

Typy přístupu k souborům udělené aplikaci

Adresář %HOME% v aplikaci se mapuje na sdílenou složku obsahu ve službě Azure Storage vyhrazenou pro danou aplikaci. Vaše cenová úroveň definuje její velikost. Může obsahovat například adresáře pro obsah, chybové a diagnostické protokoly a starší verze aplikace, které vytvořila správa zdrojového kódu. Tyto adresáře jsou k dispozici pro kód aplikace za běhu pro přístup pro čtení a zápis. Vzhledem k tomu, že se soubory neukládají místně, jsou trvalé při restartování aplikace.

Na systémové jednotce si App Service vyhrazuje %SystemDrive%\local dočasné místní úložiště specifické pro konkrétní aplikaci. Změnysouborůch I když má aplikace úplný přístup ke čtení a zápisu do svého vlastního dočasného místního úložiště, toto úložiště není určené pro přímé použití kódem aplikace. Cílem je spíše poskytnout dočasné úložiště souborů pro architektury služby IIS a webových aplikací.

App Service omezuje množství úložiště %SystemDrive%\local pro každou aplikaci, aby jednotlivé aplikace nemohly využívat nadměrné množství místního úložiště souborů. U úrovní Free, Shared a Consumption (Azure Functions) je limit 500 MB. Následující tabulka uvádí další úrovně:

Úroveň	Místní úložiště souborů
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
Izolované prostředí 4v2	276 GB
P4mv3	280 GB
Izolované prostředí5v2	552 GB
P5mv3	560 GB
Izolované prostředí6v2	1 104 GB

Dva příklady použití dočasného místního úložiště služby App Service jsou adresář pro dočasné ASP.NET soubory a adresář pro komprimované soubory služby IIS. Systém kompilace ASP.NET používá %SystemDrive%\local\Temporary ASP.NET Files adresář jako dočasné umístění mezipaměti kompilace. Služba IIS používá adresář k uložení výstupu %SystemDrive%\local\IIS Temporary Compressed Files komprimované odpovědi. Oba tyto typy použití souborů (společně s ostatními) se ve službě App Service přemapují na dočasné místní úložiště pro jednotlivé aplikace. Toto přemapování pomáhá zajistit, aby funkce pokračovaly podle očekávání.

Každá aplikace ve službě App Service běží jako náhodná, jedinečná identita pracovního procesu s nízkou úrovní oprávnění označovaná jako identita fondu aplikací. Kód aplikace používá tuto identitu pro základní přístup jen pro čtení k jednotce operačního systému. Tento přístup znamená, že kód aplikace může vypsat běžné adresářové struktury a číst běžné soubory na jednotce operačního systému. I když se tato úroveň přístupu může zdát široká, stejné adresáře a soubory jsou přístupné při zřizování role pracovního procesu ve službě hostované v Azure a čtení obsahu jednotky.

Přístup k souborům napříč několika instancemi

Adresář sdílené složky obsahu (%HOME%) obsahuje obsah aplikace a kód aplikace do něj může zapisovat. Pokud aplikace běží na více instancích, %HOME% adresář se sdílí mezi všemi instancemi, aby všechny instance viděly stejný adresář. Pokud například aplikace uloží nahrané soubory do %HOME% adresáře, budou tyto soubory okamžitě dostupné pro všechny instance.

Dočasný místní adresář úložiště (%SystemDrive%\local) se mezi instancemi nesdílí. Také se nesdílí mezi aplikací a její aplikací Kudu.

Síťový přístup

Kód aplikace může používat protokoly TCP/IP a UDP k vytváření odchozích síťových připojení ke koncovým bodům přístupným z internetu, které zpřístupňují externí služby. Aplikace můžou k připojení ke službám v Azure používat stejné protokoly– například vytvořením připojení HTTPS ke službě Azure SQL Database.

Existuje také omezená schopnost aplikací navázat jedno připojení zpětné smyčky a naslouchat aplikaci na daném soketu zpětné smyčky. Tato funkce umožňuje aplikacím, které v rámci svých funkcí naslouchají na soketech zpětné smyčky místních smyček. Každá aplikace má připojení zpětné smyčky privátní smyčky. Jedna aplikace nemůže naslouchat soketu zpětné smyčky místní smyčky, kterou vytvořila jiná aplikace.

Pojmenované kanály jsou také podporovány jako mechanismus pro komunikaci mezi procesy, které souhrnně spouští aplikaci. Modul IIS FastCGI například spoléhá na pojmenované kanály ke koordinaci jednotlivých procesů, které spouští stránky PHP.

Spouštění, procesy a paměť kódu

Jak už jsme uvedli dříve, aplikace běží uvnitř procesů pracovních procesů s nízkou úrovní oprávnění pomocí náhodné identity fondu aplikací. Kód aplikace má přístup k prostoru paměti přidruženému k pracovnímu procesu a ke všem podřízeným procesům, které mohou zpracovat CGI nebo jiné aplikace. Jedna aplikace ale nemá přístup k paměti nebo datům jiné aplikace, i když je na stejném virtuálním počítači.

Aplikace můžou spouštět skripty nebo stránky napsané s podporovanými vývojovými architekturami pro web. App Service nenakonfiguruje žádná nastavení webové architektury na režimy s větším omezením. Například ASP.NET aplikace spuštěné ve službě App Service běží v plném vztahu důvěryhodnosti, nikoli v režimu omezené důvěryhodnosti. Webové architektury, včetně klasických asp a ASP.NET, mohou volat komponenty modelu COM v procesu (například technologie ActiveX datové objekty), které jsou ve výchozím nastavení zaregistrované v operačním systému Windows. Webové architektury nemohou volat komponenty modelu COM mimo proces.

Aplikace může vytvořit a spustit libovolný kód, otevřít příkazové prostředí nebo spustit skript PowerShellu. Spustitelné programy a skripty jsou však stále omezeny na oprávnění udělená nadřazeným fondům aplikací. Aplikace může například vytvořit spustitelný program, který provádí odchozí volání HTTP, ale tento spustitelný program se nemůže pokusit zrušit vazbu IP adresy virtuálního počítače z jeho síťového adaptéru. Vytvoření odchozího síťového volání je povolené pro kód s nízkou úrovní oprávnění, ale pokus o překonfigurování nastavení sítě na virtuálním počítači vyžaduje oprávnění správce.

Diagnostické protokoly a události

Informace protokolu jsou další sada dat, ke kterým se některé aplikace snaží získat přístup. Typy informací protokolu, které jsou k dispozici pro kód spuštěný ve službě App Service, zahrnují diagnostické a protokolové informace, které aplikace generuje a umožňuje snadný přístup.

K dispozici jsou například protokoly HTTP generované aplikací W3C:

• V adresáři protokolu v umístění sdílené síťové složky, které jste vytvořili pro aplikaci
• Pokud jste v úložišti objektů blob nastavili protokolování W3C do úložiště

Druhá možnost umožňuje aplikacím shromažďovat velké objemy protokolů bez překročení limitů úložiště souborů přidružených ke sdílené síťové složce.

Podobně je možné protokolovat diagnostické informace z aplikací .NET v reálném čase prostřednictvím infrastruktury trasování a diagnostiky .NET. Pak můžete zapsat informace o trasování do sdílené síťové složky aplikace nebo do umístění úložiště objektů blob.

Oblasti protokolování diagnostiky a trasování, které nejsou dostupné pro aplikace, jsou události Windows Event Tracing for Windows (ETW) a běžné protokoly událostí Windows (například systémové, aplikace a protokoly událostí zabezpečení). Vzhledem k tomu, že trasovací informace pro Windows můžou být v počítači (se správnými seznamy řízení přístupu) možné zobrazit, zablokují se přístup pro čtení a zápis k událostem Trasování událostí trasování windows. Může se zdát, že volání rozhraní API pro čtení a zápis událostí pro Windows a běžných protokolů událostí Windows fungují, ale kód aplikace nemá k datům této události přístup.

Přístup k registru

Aplikace mají přístup jen pro čtení k mnoha (i když ne všem) registru virtuálního počítače, na kterém běží. Tento přístup znamená, že aplikace mají přístup ke klíčům registru, které umožňují přístup jen pro čtení ke skupině Místní uživatelé. Jednou z oblastí registru, která není aktuálně podporovaná pro přístup ke čtení nebo zápisu HKEY\_CURRENT\_USER , je podregistr.

Přístup k zápisu do registru je zablokovaný, včetně přístupu k jakýmkoli klíčům registru pro jednotlivé uživatele. Z pohledu aplikace se nemůže spoléhat na přístup k zápisu do registru v prostředí Azure, protože aplikace je možné migrovat napříč virtuálními počítači. Jediným trvalým zapisovatelným úložištěm, na které může aplikace záviset, je adresářová struktura obsahu pro jednotlivé aplikace uložená ve sdílených složkách UNC služby App Service.

Přístup ke vzdálené ploše

App Service neposkytuje ke instancím virtuálních počítačů přístup ke vzdálené ploše.

Více informací

Nejaktuálnější informace o spouštěcím prostředí služby App Service najdete v sandboxu služby Aplikace Azure Service. Tuto stránku udržuje vývojový tým služby App Service.