Funkcje systemu operacyjnego w usłudze Azure App Service

W tym artykule opisano podstawowe funkcje systemu operacyjnego, które są dostępne dla wszystkich aplikacji systemu Windows działających w usłudze Azure App Service. Ta funkcja obejmuje dostęp do plików, sieci i rejestru wraz z dziennikami diagnostycznymi i zdarzeniami.

Uwaga / Notatka

Aplikacje systemu Linux w usłudze App Service działają we własnych kontenerach. Masz dostęp główny do kontenera, ale nie masz dostępu do systemu operacyjnego hosta. Podobnie w przypadku aplikacji działających w kontenerach systemu Windows masz dostęp administracyjny do kontenera, ale nie masz dostępu do systemu operacyjnego hosta.

Warstwy planu usługi App Service

Usługa App Service uruchamia aplikacje klienta w wielodostępnym środowisku hostingu.

• Aplikacje wdrożone w warstwach Bezpłatna i Współdzielona są uruchamiane w procesach roboczych na udostępnionych maszynach wirtualnych.
• Aplikacje wdrożone w warstwach Standardowa i Premium działają na maszynach wirtualnych dedykowanych specjalnie dla aplikacji skojarzonych z jednym klientem.

Uwaga / Notatka

Plany usługi App Service w wersji bezpłatnej i udostępnionej (wersja zapoznawcza) to warstwy podstawowe, które działają na tych samych maszynach wirtualnych platformy Azure co inne aplikacje usługi App Service. Niektóre aplikacje mogą należeć do innych klientów. Te warstwy są przeznaczone tylko do celów programistycznych i testowych.

Ponieważ usługa App Service obsługuje bezproblemowe skalowanie między warstwami, konfiguracja zabezpieczeń wymuszana dla aplikacji usługi App Service pozostaje taka sama. Ta konfiguracja zapewnia, że aplikacje nie zachowują się nagle inaczej i nie działają w nieoczekiwany sposób, gdy plan usługi App Service przełącza się z jednej warstwy na inną.

Struktury programistyczne

Warstwy cenowe usługi App Service kontrolują ilość zasobów obliczeniowych (procesor CPU, magazyn dysku, pamięć i ruch wychodzący sieci) dostępnych dla aplikacji. Jednak zakres funkcji platformy dostępnych dla aplikacji pozostaje taki sam, niezależnie od warstw skalowania.

Usługa App Service obsługuje różne struktury programistyczne, w tym ASP.NET, klasyczne asp, Node.js, PHP i Python. Aby uprościć i znormalizować konfigurację zabezpieczeń, aplikacje usługi App Service zwykle uruchamiają struktury programistyczne z ich ustawieniami domyślnymi. Struktury i składniki środowiska uruchomieniowego, które udostępnia platforma, są regularnie aktualizowane w celu spełnienia wymagań dotyczących zabezpieczeń i zgodności. Z tego powodu nie gwarantujemy określonych wersji pomocniczych ani poprawek. Zalecamy, aby klienci używali wersji głównych zgodnie z potrzebami.

W poniższych sekcjach przedstawiono ogólne rodzaje funkcji systemu operacyjnego dostępne dla aplikacji usługi App Service.

Dostęp do plików

W usłudze App Service istnieją różne dyski, w tym dyski lokalne i dyski sieciowe.

Dyski lokalne

Usługa App Service, w swojej istocie, to serwis działający na infrastrukturze platformy Azure jako usługi (PaaS). W związku z tym dyski lokalne skojarzone z maszyną wirtualną są tymi samymi typami dysków dostępnymi dla każdej roli procesu roboczego uruchomionej na platformie Azure. To na przykład:

• Dysk systemu operacyjnego (%SystemDrive%), którego rozmiar zależy od rozmiaru maszyny wirtualnej.
• Dysk zasobu (%ResourceDrive%) używany przez usługę App Service wewnętrznie.

Najlepszym rozwiązaniem jest zawsze używanie zmiennych %SystemDrive% środowiskowych i %ResourceDrive% zamiast zakodowanych na stałe ścieżek plików. Ścieżka główna zwrócona z tych dwóch zmiennych środowiskowych zmieniła się z upływem czasu z d:\ na c:\. Jednak starsze aplikacje zawierające odwołania do ścieżek plików z d:\ nadal działają, ponieważ usługa App Service automatycznie remapuje d:\, aby wskazywały na c:\. Jak wspomniano wcześniej, zdecydowanie zalecamy, aby zawsze używać zmiennych środowiskowych podczas tworzenia ścieżek plików i uniknąć pomyłek w przypadku zmian platformy w domyślnej ścieżce pliku głównego.

Ważne jest, aby monitorować wykorzystanie dysku w miarę wzrostu aplikacji. Osiągnięcie limitu przydziału dysku może mieć negatywny wpływ na aplikację. Przykład:

• Aplikacja może zgłosić błąd wskazujący, że na dysku nie ma wystarczającej ilości miejsca.
• Podczas przeglądania konsoli Kudu mogą wystąpić błędy dysku.
• Wdrożenie z usługi Azure DevOps lub programu Visual Studio może zakończyć się niepowodzeniem z użyciem polecenia ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk).
• Aplikacja może mieć niską wydajność.

Dyski sieciowe (udziały UNC)

Jednym z unikatowych aspektów usługi App Service, które ułatwiają wdrażanie i konserwację aplikacji, jest to, że wszystkie udziały zawartości są przechowywane w zestawie udziałów Universal Naming Convention (UNC). Ten model dobrze odpowiada typowemu schematowi przechowywania treści stosowanemu przez lokalne środowiska hostingu sieci Web mające wiele serwerów o zrównoważonym obciążeniu.

W usłudze App Service udziały UNC są tworzone w każdym centrum danych. Procent zawartości użytkownika dla wszystkich klientów w każdym centrum danych jest przydzielany do każdego udziału UNC. Subskrypcja każdego klienta ma zarezerwowaną strukturę katalogów w określonym udziale UNC w centrum danych. Klient może mieć wiele aplikacji utworzonych w określonym centrum danych, więc wszystkie katalogi należące do jednej subskrypcji klienta są tworzone w tym samym udziale UNC.

Ze względu na sposób działania usług Azure, konkretna maszyna wirtualna odpowiedzialna za hostowanie udziału UNC zmienia się w czasie. Udziały UNC są instalowane przez różne maszyny wirtualne w miarę ich tworzenia i wyłączania podczas normalnego przebiegu operacji platformy Azure. Z tego powodu aplikacje nigdy nie powinny zakładać, że informacje o maszynie w ścieżce pliku UNC pozostają stabilne w czasie. Zamiast tego należy użyć wygodnej faux ścieżki %HOME%\site bezwzględnej, którą zapewnia usługa App Service.

Ścieżka pseudo-bezwzględna to przenośna metoda odwoływania się do własnej aplikacji. Nie jest ona specyficzna dla żadnej aplikacji ani użytkownika. Za pomocą programu %HOME%\sitemożna przesyłać pliki udostępnione z aplikacji do aplikacji bez konieczności konfigurowania nowej ścieżki bezwzględnej dla każdego transferu.

Typy dostępu do plików przyznane aplikacji

%HOME% Katalog w aplikacji jest mapowany na udział zawartości w usłudze Azure Storage dedykowany tej aplikacji. Warstwa cenowa definiuje jej rozmiar. Może zawierać katalogi, takie jak katalogi zawartości, błędów i dzienników diagnostycznych oraz wcześniejsze wersje aplikacji utworzonej przez kontrolę źródła. Te katalogi są dostępne dla kodu aplikacji w czasie wykonywania na potrzeby dostępu do odczytu i zapisu. Ponieważ pliki nie są przechowywane lokalnie, są one trwałe podczas ponownego uruchamiania aplikacji.

Na dysku systemowym App Service rezerwuje lokalny magazyn tymczasowy specyficzny dla aplikacji. Zmiany plików w tym katalogu nie są trwałe w przypadku ponownych uruchomień aplikacji. Mimo że aplikacja ma pełny dostęp do odczytu i zapisu do własnego tymczasowego magazynu lokalnego, ten magazyn nie jest przeznaczony do bezpośredniego użycia przez kod aplikacji. Zamiast tego celem jest zapewnienie tymczasowego magazynu plików dla usług IIS i struktur aplikacji internetowych.

Usługa App Service ogranicza ilość miejsca na dane w %SystemDrive%\local każdej aplikacji, aby zapobiec nadmiernemu używaniu lokalnej przestrzeni dyskowej przez aplikacje. W przypadku warstw Bezpłatna, Współdzielona i Zużycie (Azure Functions) limit wynosi 500 MB. W poniższej tabeli wymieniono inne warstwy:

Warstwa	Limit magazynu lokalnego
B1/S1/P1	11 GB
B2/S2/P2	15 GB
B3/S3/P3	58 GB
P0v3/P0v4	11 GB
P1v2/P1v3/P1mv3/P1mv4/Isolated1/Isolated1v2	21 GB
P2v2/P2v3/P2mv3/P2mv4/Isolated2/Isolated2v2	61 GB
P3v2/P3v3/P3mv3/P3mv4/Isolated3/Isolated3v2	140 GB
Izolowany4v2	276 GB
P4mv3/P4mv4	280 GB
Izolowany 5v2	552 GB
P5mv3/P5mv4	560 GB
Izolowany6v2	1104 GB

Katalog tymczasowych plików ASP.NET oraz katalog skompresowanych plików IIS to dwa przykłady tymczasowego przechowywania lokalnego wykorzystywanego przez usługę App Service. System kompilacji ASP.NET używa %SystemDrive%\local\Temporary ASP.NET Files katalogu jako tymczasowej lokalizacji pamięci podręcznej kompilacji. Usługi IIS używają katalogu %SystemDrive%\local\IIS Temporary Compressed Files do przechowywania skompresowanych odpowiedzi. Oba te sposoby używania plików (wraz z innymi) są ponownie mapowane w usłudze App Service do tymczasowego magazynu lokalnego dla aplikacji. To ponowne mapowanie pomaga zagwarantować, że funkcje będą kontynuowane zgodnie z oczekiwaniami.

Każda aplikacja w usłudze App Service działa jako proces roboczy o losowej, unikatowej tożsamości oraz niskim poziomie uprawnień, zwany tożsamością puli aplikacji. Kod aplikacji używa tej tożsamości do podstawowego dostępu do dysku systemu operacyjnego w trybie tylko do odczytu. Ten dostęp oznacza, że kod aplikacji może wyświetlać listę typowych struktur katalogów i odczytywać typowe pliki na dysku systemu operacyjnego. Mimo że ten poziom dostępu może wydawać się szeroki, te same katalogi i pliki są dostępne podczas konfigurowania roli procesu roboczego w usłudze hostowanej na platformie Azure i odczytywania zawartości dysku.

Dostęp do plików w wielu wystąpieniach

Katalog współdzielonej zawartości (%HOME%) zawiera zawartość aplikacji, a kod aplikacji może do niego zapisywać. Jeśli aplikacja działa na wielu wystąpieniach, katalog %HOME% jest współużytkowany między wszystkimi wystąpieniami, aby wszystkie wystąpienia widziały ten sam katalog. Jeśli na przykład aplikacja zapisuje przekazane pliki do katalogu %HOME%, te pliki są natychmiast dostępne dla wszystkich wystąpień.

Tymczasowy katalog lokalnej pamięci (%SystemDrive%\local) nie jest współużytkowany między wystąpieniami. Nie jest ona również udostępniana między aplikacją a aplikacją Kudu.

Dostęp do sieci

Kod aplikacji może używać protokołów TCP/IP i UDP w celu nawiązywania wychodzących połączeń sieciowych z punktami końcowymi dostępnymi z Internetu, które uwidaczniają usługi zewnętrzne. Aplikacje mogą używać tych samych protokołów do łączenia się z usługami na platformie Azure — na przykład przez ustanowienie połączeń HTTPS z usługą Azure SQL Database.

Istnieje również ograniczona możliwość nawiązywania jednego lokalnego połączenia sprzężenia zwrotnego i nasłuchiwania aplikacji w tym lokalnym gniazdie sprzężenia zwrotnego. Ta funkcja umożliwia aplikacjom nasłuchiwanie na lokalnych gniazdach sprzężenia zwrotnego jako część ich funkcjonalności. Każda aplikacja ma prywatne połączenie sprzężenia zwrotnego. Jedna aplikacja nie może nasłuchiwać lokalnego gniazda sprzężenia zwrotnego utworzonego przez inną aplikację.

Nazwane potoki są również obsługiwane jako mechanizm komunikacji międzyprocesowej między procesami, które wspólnie uruchamiają aplikację. Na przykład moduł FASTCGI usług IIS opiera się na nazwanych potokach, aby koordynować poszczególne procesy uruchamiające strony PHP.

Wykonywanie kodu, procesy i pamięć

Jak wspomniano wcześniej, aplikacje działają wewnątrz procesów roboczych o niskich uprawnieniach przy użyciu losowej tożsamości puli aplikacji. Kod aplikacji ma dostęp do przestrzeni pamięci skojarzonej z procesem roboczym wraz ze wszystkimi procesami podrzędnymi, które mogą być tworzone przez procesy CGI lub inne aplikacje. Jednak jedna aplikacja nie może uzyskać dostępu do pamięci lub danych innej aplikacji, nawet jeśli znajduje się na tej samej maszynie wirtualnej.

Aplikacje mogą uruchamiać skrypty lub strony napisane przy użyciu obsługiwanych struktur tworzenia aplikacji internetowych. Usługa App Service nie konfiguruje żadnych ustawień platformy internetowej do bardziej ograniczonych trybów. Na przykład ASP.NET aplikacje uruchomione w usłudze App Service działają w pełnym zaufaniu, w przeciwieństwie do trybu bardziej ograniczonego zaufania. Struktury sieci Web, w tym zarówno klasyczne platformy ASP, jak i ASP.NET, mogą wywoływać składniki COM w procesie (takie jak obiekty danych ActiveX), które są domyślnie rejestrowane w systemie operacyjnym Windows. Struktury sieci Web nie mogą wywoływać składników COM poza procesem.

Aplikacja może uruchomić i wykonać dowolny kod, otworzyć interfejs wiersza poleceń lub uruchomić skrypt PowerShell. Jednak programy wykonywalne i skrypty są nadal ograniczone do uprawnień przyznanych nadrzędnej puli aplikacji. Na przykład aplikacja może uruchomić program wykonywalny, który wykonuje wychodzące wywołanie HTTP, ale ten program wykonywalny nie może spróbować rozłączyć adresu IP maszyny wirtualnej z jej karty sieciowej. Wykonywanie wychodzącego wywołania sieciowego jest dozwolone dla kodu o niskich uprawnieniach, ale próba ponownego skonfigurowania ustawień sieci na maszynie wirtualnej wymaga uprawnień administracyjnych.

Dzienniki diagnostyczne i zdarzenia

Informacje dziennika to kolejny zestaw danych, do których niektóre aplikacje próbują uzyskać dostęp. Rodzaje informacji dziennika dostępne dla kodu uruchamianego w usłudze App Service obejmują informacje diagnostyczne i dzienniki generowane przez aplikację, do których można łatwo uzyskać dostęp.

Na przykład dzienniki HTTP W3C generowane przez aplikację są dostępne:

• W katalogu logów w zasobie udostępnionym w sieci, który utworzyłeś dla aplikacji.
• W magazynie BLOB, jeśli skonfigurujesz rejestrowanie dziennika W3C w magazynie.

Ta ostatnia opcja umożliwia aplikacjom zbieranie dużych ilości dzienników bez przekraczania limitów magazynu plików skojarzonych z udziałem sieciowym.

Podobnie informacje diagnostyczne w czasie rzeczywistym z aplikacji platformy .NET można rejestrować za pośrednictwem infrastruktury śledzenia i diagnostyki platformy .NET. Następnie możesz zapisać informacje śledzenia w udziale sieciowym aplikacji lub lokalizacji magazynu obiektów blob.

Obszary rejestrowania diagnostycznego i śledzenia, które nie są dostępne dla aplikacji, to zdarzenia śledzenia zdarzeń systemu Windows (ETW) i typowe dzienniki zdarzeń systemu Windows (na przykład dzienniki zdarzeń systemu, aplikacji i zabezpieczeń). Ze względu na to, że informacje śledzenia ETW mogą być potencjalnie widoczne na komputerze przy użyciu odpowiednich list kontroli dostępu, dostęp do odczytu i zapisu zdarzeń ETW jest blokowany. Wywołania interfejsu API do odczytu i zapisu zdarzeń ETW i typowych dzienników zdarzeń systemu Windows mogą wydawać się działać, ale w rzeczywistości kod aplikacji nie ma dostępu do tych danych zdarzenia.

Dostęp do rejestru

Aplikacje mają dostęp tylko do odczytu do wielu, choć nie wszystkich, rejestru maszyny wirtualnej, na której są uruchomione. Ten dostęp oznacza, że aplikacje mogą uzyskiwać dostęp do kluczy rejestru, które zezwalają na dostęp tylko do odczytu do grupy Użytkownicy lokalni. Jednym z obszarów rejestru, który nie jest obecnie obsługiwany ani do odczytu, ani do zapisu, jest HKEY_CURRENT_USER gałąź.

Dostęp do zapisu w rejestrze jest zablokowany, w tym dostęp do dowolnych kluczy rejestru poszczególnych użytkowników. Z punktu widzenia aplikacji, nie może ona polegać na dostępie do zapisu w rejestrze w środowisku platformy Azure, ponieważ aplikacje można migrować między maszynami wirtualnymi. Jedyną trwałą pamięcią zapisywalną, od której może zależeć aplikacja, jest struktura katalogu zawartości aplikacji przechowywana w udziałach UNC usługi App Service.

Dostęp do pulpitu zdalnego

Usługa App Service nie zapewnia dostępu pulpitu zdalnego do wystąpień maszyn wirtualnych.

Treści powiązane

Aby uzyskać najbardziej up-to— informacje o środowisku wykonywania usługi App Service, zobacz piaskownicę usługi Azure App Service. Zespół deweloperów usługi App Service utrzymuje tę stronę.