Funkcje systemu operacyjnego w usłudze aplikacja systemu Azure

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

Uwaga

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

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ą.

Ramy rozwoju

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 platformy programistyczne, w tym ASP.NET, klasyczne platformy 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/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 jest usługą działającą w oparciu o infrastrukturę Platformy jako usługi (PaaS) platformy Azure. 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 zakodowane na stałe przy użyciu odwołań do ścieżki pliku, aby d:\ nadal działać, ponieważ usługa App Service automatycznie ponownie mapuje d:\ się tak, aby wskazywała wartość .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ę. Na 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 UNC. Ten model jest dobrze mapowany na typowy wzorzec magazynu zawartości używanego przez lokalne środowiska hostingu sieci Web, które mają 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 platformy Azure określona maszyna wirtualna odpowiedzialna za hostowanie zmian udziału UNC 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 pozostaną stabilne w czasie. Zamiast tego należy użyć wygodnej ścieżki %HOME%\site bezwzględnej faux, którą zapewnia usługa App Service.

Ścieżka bezwzględna faux 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 mapowy na udział zawartości w usłudze Azure Storage przeznaczony dla 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 usługa App Service rezerwuje %SystemDrive%\local magazyn lokalny 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 do magazynowania dla %SystemDrive%\local każdej aplikacji, aby zapobiec nadmiernemu używaniu przez poszczególne aplikacje ilości lokalnego magazynu plików. W przypadku warstw Bezpłatna, Współdzielona i Zużycie (Azure Functions) limit wynosi 500 MB. W poniższej tabeli wymieniono inne warstwy:

Warstwa	Lokalny magazyn plików
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
Izolowany4v2	276 GB
P4mv3	280 GB
Izolowany 5v2	552 GB
P5mv3	560 GB
Izolowany6v2	1104 GB

Dwa przykłady użycia tymczasowego magazynu lokalnego usługi App Service to katalog tymczasowych plików ASP.NET i katalog skompresowanych plików usług IIS. 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ą %SystemDrive%\local\IIS Temporary Compressed Files katalogu do przechowywania skompresowanych danych wyjściowych odpowiedzi. Oba te typy użycia 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 jest uruchamiana jako losowa, unikatowa tożsamość procesu roboczego o niskim poziomie uprawnień nazywana tożsamością puli aplikacji. Kod aplikacji używa tej tożsamości do podstawowego dostępu tylko do odczytu na dysku systemu operacyjnego. 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 aprowizowania 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 udziału zawartości (%HOME%) zawiera zawartość aplikacji, a kod aplikacji może go zapisywać. Jeśli aplikacja działa na wielu wystąpieniach, katalog jest współużytkowany między wszystkimi wystąpieniami, %HOME% aby wszystkie wystąpienia widziały ten sam katalog. Jeśli na przykład aplikacja zapisuje przekazane pliki do %HOME% katalogu, te pliki są natychmiast dostępne dla wszystkich wystąpień.

Tymczasowy katalog magazynu lokalnego (%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, które nasłuchują lokalnych gniazd sprzężenia zwrotnego w ramach ich funkcji. 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 zbiorczo 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 zduplikować i uruchomić dowolny kod, otworzyć powłokę poleceń lub uruchomić skrypt programu PowerShell. Jednak programy wykonywalne i skrypty są nadal ograniczone do uprawnień przyznanych nadrzędnej puli aplikacji. Na przykład aplikacja może zduplikować program wykonywalny, który wykonuje wychodzące wywołanie HTTP, ale ten program wykonywalny nie może spróbować usunąć powiązania adresu IP maszyny wirtualnej z 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. Typy informacji dziennika dostępnych dla kodu uruchomionego w usłudze App Service obejmują informacje diagnostyczne i dzienniki generowane przez aplikację i mogą łatwo uzyskać do nich dostęp.

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

• W katalogu dziennika w lokalizacji udziału sieciowego utworzonej dla aplikacji
• W magazynie obiektów blob w przypadku skonfigurowania rejestrowania 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 i śledzenia diagnostyki, 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 maszynie (z odpowiednimi listami kontroli dostępu), dostęp do odczytu i dostęp do zapisu do zdarzeń ETW są blokowane. 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 w przypadku dostępu do odczytu lub 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 perspektywy aplikacji nie może polegać na dostępie do zapisu w rejestrze w środowisku platformy Azure, ponieważ aplikacje można migrować między maszynami wirtualnymi. Jedynym trwałym magazynem zapisywalnym, od którego może zależeć aplikacja, jest struktura katalogów zawartości dla 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.

Więcej informacji

Aby uzyskać najbardziej aktualne informacje o środowisku wykonywania usługi App Service, zobacz piaskownicę usługi aplikacja systemu Azure Service. Zespół deweloperów usługi App Service utrzymuje tę stronę.