Функциональные возможности операционной системы в Службе приложений Azure

2025-05-20

В этой статье описаны базовые функциональные возможности операционной системы, доступные для всех приложений Windows, работающих в Службе приложений Azure. Эта функция включает доступ к файлам, сети и реестру, а также журналы диагностики и события.

Замечание

Приложения Linux в службе приложений выполняются в собственных контейнерах. У вас есть корневой доступ к контейнеру, но нет доступа к операционной системе узла. Аналогичным образом, для приложений, работающих в контейнерах Windows, у вас есть административный доступ к контейнеру, но нет доступа к операционной системе узла.

Уровни плана службы приложений

Служба приложений запускает клиентские приложения в мультитенантной среде размещения.

Приложения, развернутые на уровнях "Бесплатный" и "Общий", выполняются в рабочих процессах на общих виртуальных машинах.
Приложения, развернутые на уровнях "Стандартный" и "Премиум", выполняются на виртуальных машинах, выделенных специально для приложений, связанных с одним клиентом.

Замечание

Планы обслуживания Службы приложений Azure "Бесплатный" и "Общий" (предварительная версия) — это планы базового уровня, которые выполняются на той же виртуальной машине Azure, что и остальные приложения Службы приложений. Некоторые приложения могут принадлежать другим клиентам. Эти уровни предназначены только для целей разработки и тестирования.

Так как служба приложений поддерживает простое масштабирование между уровнями, конфигурация безопасности, применяемая для приложений службы приложений, остается той же. Эта конфигурация гарантирует, что приложения не будут внезапно вести себя иначе и не выходят из строя неожиданными способами, когда план службы приложений переключается с одного уровня на другой.

Платформы разработки

Ценовые категории службы приложений управляют объемом вычислительных ресурсов (ЦП, дискового хранилища, памяти и исходящего трафика сети), доступных приложениям. Однако функциональность платформы, доступная для приложений, остается одинаковой независимо от уровней масштабирования.

Служба приложений поддерживает различные платформы разработки, включая ASP.NET, классический ASP, Node.js, PHP и Python. Чтобы упростить и нормализовать конфигурацию безопасности, приложения службы приложений обычно выполняют платформы разработки с параметрами по умолчанию. Платформы и компоненты среды выполнения, которые предоставляет платформа, регулярно обновляются для удовлетворения требований к безопасности и соответствию требованиям. По этой причине мы не гарантируем конкретных дополнительных или исправленных версий. Рекомендуется, чтобы клиенты нацелились на основные версии по мере необходимости.

В следующих разделах приведены общие типы функциональных возможностей операционной системы, доступных для приложений службы приложений.

Доступ к файлам

Различные диски существуют в службе приложений, включая локальные диски и сетевые диски.

Локальные диски

В основном служба приложений — это служба, которая работает на вершине инфраструктуры Azure как услуга (PaaS). В результате локальные диски, связанные с виртуальной машиной, являются теми же типами дисков, которые доступны для любой рабочей роли, работающей в Azure. К ним относятся:

Диск операционной системы (%SystemDrive%), размер которого зависит от размера виртуальной машины.
Диск ресурсов (%ResourceDrive%), используемый службой приложений App Service для внутреннего использования.

Рекомендуется всегда использовать переменные %SystemDrive% среды и %ResourceDrive% вместо жестко закодированных путей к файлам. Корневой путь, возвращаемый из этих двух переменных среды, с течением времени сдвинулся с d:\ на c:\. Однако старые приложения, в коде которых жестко прописаны ссылки на путь к файлам d:\, продолжают работать, так как служба приложений автоматически перенаправляет d:\ на c:\. Как отмечалось ранее, настоятельно рекомендуется всегда использовать переменные среды при создании путей к файлам и избегать путаницы по поводу изменений платформы в пути корневого файла по умолчанию.

Важно отслеживать использование дисков по мере роста приложения. Достижение квоты диска может оказать негативное влияние на приложение. Рассмотрим пример.

Приложение может вызвать ошибку, указывающую, что на диске недостаточно места.
При открытии консоли Kudu могут возникать ошибки диска.
Развертывание из Azure DevOps или Visual Studio может завершиться ошибкой ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk).
Ваше приложение может иметь низкую производительность.

Сетевые диски (общие папки UNC)

Одним из уникальных аспектов службы App Service, которые упрощают развертывание и обслуживание приложений, является то, что все общие ресурсы хранятся в наборе общих папок Универсальной схемы именования (UNC). Эта модель хорошо сопоставляется с общим шаблоном хранилища контента, используемого локальными средами размещения веб-сайтов с несколькими серверами с балансировкой нагрузки.

В службе приложений общие папки UNC создаются в каждом центре обработки данных. Процент пользовательского содержимого для каждого клиента в каждом центре обработки данных выделяется каждому UNC-общему ресурсу. У каждой подписки клиента есть выделенная структура каталогов на определенном UNC-ресурсе в центре обработки данных. У клиента может быть несколько приложений, созданных в определенном центре обработки данных, поэтому все каталоги, принадлежащие одной подписке клиента, создаются в одной UNC-папке.

В связи с особенностями работы служб Azure, конкретная виртуальная машина, отвечающая за размещение общего ресурса UNC, со временем меняется. UNC-ресурсы подключаются различными виртуальными машинами во время их подключения и отключения в ходе обычных операций Azure. По этой причине приложения никогда не должны делать жестко закодированные предположения о том, что сведения о компьютере в пути к файлу UNC остаются стабильными со временем. Вместо этого они должны использовать удобный фальшивый абсолютный путь%HOME%\site, который предоставляет служба приложений.

Псевдоабсолютный путь — это переносимый метод для ссылки на собственное приложение. Это не связано с каким-либо конкретным приложением или пользователем. С помощью %HOME%\siteможно передавать общие файлы из приложения в приложение без необходимости настраивать новый абсолютный путь для каждой передачи.

Типы доступа к файлам, предоставленные приложению

Каталог %HOME% в приложении сопоставляется с контентным хранилищем в Azure Storage, выделенным для этого приложения. Ценовая категория определяет его размер. Он может включать каталоги, такие как для контента, журналы ошибок и диагностики, а также более ранние версии приложения, которые были созданы системой контроля версий. Эти каталоги доступны для кода приложения во время выполнения для доступа на чтение и запись. Так как файлы не хранятся локально, они сохраняются во всех перезапусках приложений.

На системном диске служба приложений резервирует %SystemDrive%\local временное локальное хранилище для конкретного приложения. Изменения файлов в этом каталоге не сохраняются во время перезапуска приложения. Хотя приложение имеет полный доступ на чтение и запись к собственному временному локальному хранилищу, это хранилище не предназначено для прямого использования кодом приложения. Скорее, целью является предоставление временного хранилища файлов для платформ IIS и веб-приложений.

Служба приложений ограничивает объем хранилища %SystemDrive%\local для каждого приложения, чтобы предотвратить использование отдельных приложений чрезмерных объемов локального хранилища файлов. Для уровней "Бесплатный", "Общий" и "Потребление" (Функции Azure) ограничение составляет 500 МБ. В следующей таблице перечислены другие уровни:

Ярус	Ограничение локального хранилища
B1/S1/P1	11 ГБ
B2/S2/P2	15 ГБ
B3/S3/P3	58 ГБ
P0v3/P0v4	11 ГБ
P1v2/P1v3/P1mv3/P1mv3/P1mv4/Isolated1v2	21 ГБ
P2v2/P2v3/P2mv3/P2mv4/Isolated2/Isolated2v2	61 ГБ
P3v2/P3v3/P3mv3/P3mv4/Isolated3/Isolated3v2	140 ГБ
Изоляция4v2	276 ГБ
P4mv3/P4mv4	280 ГБ
Изолированный 5v2	552 ГБ
P5mv3/P5mv4	560 ГБ
Изолированный 6v2	1104 ГБ

Каталог для временных ASP.NET файлов и каталога для сжатых файлов IIS является двумя примерами того, как служба приложений использует временное локальное хранилище. Система компиляции ASP.NET использует %SystemDrive%\local\Temporary ASP.NET Files каталог в качестве временного расположения кэша компиляции. IIS использует директорию %SystemDrive%\local\IIS Temporary Compressed Files для хранения сжатых выходных данных ответов. Оба этих типа использования файлов (а также другие) переназначаются в службе приложений на временное локальное хранилище для каждого приложения. Это изменение помогает обеспечить, чтобы функции продолжались должным образом.

Каждое приложение в службе приложений выполняется как случайное, уникальное, низкопривилегированное удостоверение рабочего процесса, называемое удостоверением пула приложений. Код приложения использует этот идентификатор для базового доступа к диску операционной системы в режиме только для чтения. Этот доступ означает, что код приложения может перечислять общие структуры каталогов и читать общие файлы на диске операционной системы. Хотя этот уровень доступа может показаться широким, те же каталоги и файлы доступны при подготовке рабочей роли в расположенной в Azure службе и считывании содержимого диска.

Доступ к файлам в нескольких экземплярах

Каталог общей папки содержимого (%HOME%) хранит содержимое приложения, и код приложения может записывать в него. Если приложение выполняется в нескольких экземплярах, каталог %HOME% предоставляется совместно всем экземплярам, чтобы все экземпляры видели один и тот же каталог. Например, если приложение сохраняет отправленные файлы в %HOME% каталог, эти файлы сразу же доступны всем экземплярам.

Временный локальный каталог хранилища (%SystemDrive%\local) не используется между экземплярами. Это также не делится между приложением и его приложением Kudu.

Доступ к сети

Код приложения может использовать протоколы на основе TCP/IP и UDP, чтобы сделать исходящие сетевые подключения к конечным точкам с доступом к Интернету, предоставляющим внешние службы. Приложения могут использовать эти же протоколы для подключения к службам в Azure, например путем установления подключений HTTPS к Базе данных SQL Azure.

Существует также ограниченная возможность для приложений установить одно локальное подключение обратной петли и прослушивать этот локальный сокет обратной петли. Эта функция позволяет приложениям прослушивать локальные сокеты обратной петли в рамках своей функциональности. Каждое приложение имеет частное подключение через обратную петлю. Одно приложение не может прослушивать сокет локальной обратной связи, установленный другим приложением.

Именованные каналы также поддерживаются в качестве механизма взаимодействия между процессами, которые совместно запускают приложение. Например, модуль IIS FastCGI использует именованные каналы для координации отдельных процессов, выполняющих страницы PHP.

Выполнение кода, процессы и память

Как отмечалось ранее, приложения выполняются в рабочих процессах с низким уровнем привилегий, используя случайно выбранную идентификацию пула приложений. Код приложения имеет доступ к пространству памяти, связанному с рабочим процессом, а также к любым дочерним процессам, которые могут быть созданы процессами CGI или другими приложениями. Однако одно приложение не может получить доступ к памяти или данным другого приложения, даже если оно находится на той же виртуальной машине.

Приложения могут запускать скрипты или страницы, написанные с поддерживаемыми платформами веб-разработки. Служба приложений не настраивает параметры веб-платформы для более ограниченных режимов. Например, приложения ASP.NET, работающие в службе приложений, выполняются с полным доверием, в отличие от более ограниченного режима доверия. Веб-платформы, включая классические ASP и ASP.NET, могут вызывать компоненты COM процесса (например, объекты данных ActiveX), зарегистрированные по умолчанию в операционной системе Windows. Веб-платформы не могут вызывать компоненты COM из процесса.

Приложение может создать и запустить произвольный код, открыть командную оболочку или запустить скрипт PowerShell. Однако исполняемые программы и скрипты по-прежнему ограничены привилегиями, предоставленными родительскому пулу приложений. Например, приложение может создать исполняемую программу, которая выполняет исходящий HTTP-вызов, но эта исполняемая программа не может попытаться отменить привязку IP-адреса виртуальной машины из сетевого адаптера. Выполнение исходящего сетевого вызова допускается для кода с низким уровнем привилегий, но при попытке перенастроить параметры сети на виртуальной машине требуются права администратора.

Журналы диагностики и события

Сведения журнала — это другой набор данных, к которым некоторые приложения пытаются получить доступ. Типы сведений журнала, доступные для кода, выполняемого в службе приложений, включают диагностические данные и журналы, которые приложение создает и к которым имеет легкий доступ.

Например, доступны журналы W3C HTTP, созданные приложением:

В каталоге журнала в расположении сетевого ресурса, созданном для приложения.
В хранилище BLOB-объектов при настройке ведения журнала W3C в хранилище.

Последний вариант позволяет приложениям собирать большие объемы журналов без превышения ограничений хранилища файлов, связанных с сетевым ресурсом.

Аналогичным образом данные диагностики в режиме реального времени из приложений .NET можно регистрировать через инфраструктуру трассировки и диагностики .NET. Затем можно записать сведения трассировки в сетевую папку приложения или в хранилище BLOB-объектов.

Области журналов диагностики и трассировки, недоступные для приложений, — это события трассировки событий Windows (ETW) и распространенные журналы событий Windows (например, журналы событий системы, приложения и безопасности). Так как информация о трассировке ETW при использовании правильных списков управления доступом может быть доступна на всём компьютере, доступ на чтение и запись к событиям ETW заблокирован. Вызовы API для чтения и записи событий ETW и распространенных журналов событий Windows могут работать, но в действительности код приложения не имеет доступа к данным этого события.

Доступ к реестру

Приложения имеют доступ только для чтения ко многим разделам реестра виртуальной машины, на которой они выполняются, но не ко всем. Этот доступ означает, что приложения могут получать доступ к разделам реестра, которые предоставляют группе локальных пользователей доступ только для чтения. Одна из областей реестра, которая в настоящее время не поддерживается для доступа на чтение или запись, — это HKEY_CURRENT_USER раздел.

Доступ на запись в реестр заблокирован, включая доступ к любому пользовательскому разделу реестра. С точки зрения приложения он не может полагаться на доступ на запись в реестр в среде Azure, так как приложения можно перенести на виртуальные машины. Единственное постоянное хранилище, от которое может зависеть приложение, — это структура каталогов содержимого для каждого приложения, хранящуюся в общих папках службы приложений UNC.

Доступ к удаленному рабочему столу

Служба приложений не предоставляет доступа удаленного рабочего стола к экземплярам виртуальных машин.

Наиболее up-to-date сведения о среде выполнения службы приложений см. в песочнице службы приложений Azure. Команда разработчиков службы приложений поддерживает эту страницу.