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

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

Примечание.

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

Рекомендуется всегда использовать переменные %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-ресурсы)

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

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

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

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

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

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

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

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

Уровень	Локальное хранилище файлов
B1/S1/P1	11 ГБ
B2/S2/P2	15 ГБ
B3/S3/P3	58 ГБ
P0v3	11 ГБ
P1v2/P1v3/P1mv3/Isolated1/Isolated1v2	21 GB
P2v2/P2v3/P2mv3/Isolated2/Isolated2v2	61 ГБ
P3v2/P3v3/P3mv3/Isolated3/Isolated3v2	140 ГБ
Изоляция4v2	276 ГБ
P4mv3	280 ГБ
Изолированный 5v2	552 ГБ
P5mv3	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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложения имеют доступ только для чтения к многому (хотя и не всем) реестра виртуальной машины, на которую они работают. Этот доступ означает, что приложения могут получать доступ к разделам реестра, разрешающим доступ только для чтения к группе локальных пользователей. Одна из областей реестра, которая в настоящее время не поддерживается для доступа на чтение или запись, является HKEY\_CURRENT\_USER кустом.

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

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

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

Дополнительные сведения

Актуальные сведения о среде выполнения Служба приложений см. в песочнице службы приложение Azure. Команда разработчиков Служба приложений поддерживает эту страницу.