Azure 应用服务中的操作系统功能

  • 项目

本文介绍了可供在 Azure 应用服务上运行的所有 Windows 应用使用的基准操作系统功能。 这些功能包括文件、网络和注册表访问以及诊断日志和事件。

注意

应用服务中的 Linux 应用在其自己的容器中运行。 你对容器具有根访问权限，但无权访问主机操作系统。 同样，对于在 Windows 容器中运行的应用，你具有对容器的管理访问权限，但无法访问主机操作系统。

应用服务计划层

应用服务在多租户托管环境中运行客户应用。 在“免费”层和“共享”层中部署的应用在会共享虚拟机 (VM) 的工作进程中运行。 在标准层和高级层中部署的应用在专用于与单个客户关联的应用的 VM 上运行。

注意

应用服务免费和共享（预览版）服务计划是基本层，与其他应用服务应用在相同的 Azure 虚拟机上运行。 某些应用可能属于其他客户。 这些层仅旨在用于开发和测试目的。

由于应用服务支持层之间的无缝缩放体验，因此，为应用服务应用实施的安全配置保持不变。 此配置可以确保应用服务计划在切换不同的层时，应用不会突然发生行为上的变化，并且不会以意外的方式失败。

开发框架

应用服务定价层控制可用于应用的计算资源（CPU、磁盘存储、内存和网络出口）的数量。 但是，可用于应用的框架功能范围保持不变，而与缩放层无关。

应用服务支持多种开发框架，包括 ASP.NET、经典 ASP、Node.js、PHP 和 Python。 若要简化和标准化安全配置，应用服务应用通常使用其默认设置运行的开发框架。 平台提供的框架和运行时组件会定期更新，以满足安全性和符合性要求。 因此，我们不能保证特定的次要/修补程序版本。 我们建议客户根据需要选择主要版本。

以下部分概述了可用于应用服务应用的一般类型的操作系统功能。

文件访问

应用服务中存在各种不同的驱动器，包括本地驱动器和网络驱动器。

本地驱动器

就其核心而言，应用服务是在 Azure 平台即服务 (PaaS) 基础结构的基础上运行的服务。 因此，与虚拟机关联的本地驱动器是可用于在 Azure 中运行的任何辅助角色的相同驱动器类型。 它们包括：

  • 操作系统驱动器 (%SystemDrive%)，其大小因 VM 大小而异。
  • 资源驱动器 (%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 共享中。 此模型很好地映射到具有多个负载均衡服务器的本地 Web 托管环境所用内容存储的公共模式。

在应用服务中，在每个数据中心都会创建 UNC 共享。 在每个数据中心针对所有客户的某个百分比的用户内容会分配给各 UNC 共享。 每个客户的订阅都在一个数据中心内的特定 UNC 共享上具有保留的目录结构。 客户可以在特定数据中心内创建多个应用，因此，属于单个客户订阅的所有目录都在同一个 UNC 共享上创建。

由于 Azure 服务的工作方式，负责承载 UNC 共享的特定虚拟机会随着时间而更改。 UNC 共享会由不同虚拟机装载，因为在正常 Azure 操作过程中它们会启动和关闭。 因此，应用不应作出这样的硬编码的假定，即 UNC 文件路径中的计算机信息会在一段时间后保持不变， 而应使用应用服务提供的方便的 faux 绝对路径 %HOME%\site。

伪绝对路径是一种可移植方法，用于引用你自己的应用。 它不特定于任何应用或用户。 通过使用 %HOME%\site，可以在应用之间传输共享文件，而不必为每次传输都配置新的绝对路径。

向应用授予的文件访问的类型

应用中的 %HOME% 目录映射到专用于该应用的 Azure 存储中的内容共享。 其大小由定价层定义。 该共享可以包含目录（例如针对内容、错误和诊断日志的目录）以及源代码管理创建的应用的更早版本。 这些目录可以在运行时供应用的应用程序代码进行读写访问。 由于文件不存储在本地，因此在应用重启后将保持不变。

在系统驱动器上，应用服务会保留 %SystemDrive%\local 作为特定于应用的临时本地存储。 此目录中的文件更改不会在应用重启后保持不变。 尽管应用对自己的临时本地存储具有完全读与写访问权限，但该存储并不旨在直接供应用程序代码使用。 而是用于为 IIS 和 Web 应用程序框架提供临时文件存储。

应用服务会限制每个应用的 %SystemDrive%\local 中的存储量，以免单个应用占用过多的本地文件存储量。 免费层、共享层和消耗层 (Azure Functions) 的限制为 500 MB。 下表列出了其他层：

SKU 系列 B1/S1/etc. B2/S2/etc. B3/S3/etc.
基本、标准、高级 11 GB 15 GB 58 GB
PremiumV2、独立 21 GB 61 GB 140 GB

说明应用服务如何使用临时本地存储的两个示例是针对临时 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 的协议建立与公开外部服务的 Internet 可访问终结点的出站网络连接。 应用可以使用这些相同协议连接到 Azure 中的服务；例如，建立与 Azure SQL 数据库的 HTTPS 连接即是如此。

还有有限容量以便为应用建立一个本地环回连接，并且让应用侦听该本地环回套接字。 此功能使应用能够将侦听本地环回套接字作为其功能的一部分。 每个应用都有一个“专用”环回连接。 一个应用无法侦听另一个应用建立的本地环回套接字。

命名管道也作为一种机制收到支持，用于在共同运行应用的进程之间进行进程间通信。 例如，IIS FastCGI 模块依赖命名管道协调运行 PHP 页的单独进程。

代码执行、进程和内存

如前所述，应用通过使用随机应用程序池标识在低权限辅助进程内运行。 应用程序代码有权访问与辅助进程相关联的内存空间，以及可由 CGI 处理器或其他应用程序生成的任何子进程。 但是，一个应用不能访问另一个应用的内存或数据，即使它们位于同一个虚拟机上。

应用可以运行使用支持的 Web 开发框架编写的脚本或页面。 应用服务不将任何 Web 框架设置配置为更受限制的模式。 例如，在应用服务中运行的 ASP.NET 应用以“完全”信任运行，与更受限制的信任模式相反。 Web 框架（包括经典 ASP 和 ASP.NET）可以调用在 Windows 操作系统上默认注册的进程内 COM 组件（如 ActiveX 数据对象）。 Web 框架无法调用进程外 COM 组件。

应用可以生成并运行任意代码、打开命令行界面或运行 PowerShell 脚本。 但是，可执行程序和脚本仍会被限制为授予父应用程序池的权限。 例如，应用可以生成发出出站 HTTP 调用的可执行程序，但该可执行程序无法尝试从其网络适配器取消绑定虚拟机的 IP 地址。 允许向低权限的代码发出出站网络调用，但尝试在虚拟机上重新配置网络设置要求管理权限。

诊断日志和事件

日志信息是某些应用尝试访问的另外一组数据。 应用服务中运行的代码可用的日志信息类型包括应用生成的诊断和日志信息，可以轻松进行访问。

例如，应用程序生成的 W3C HTTP 日志在以下位置也可以使用：

  • 在为应用程序创建的网络共享位置的日志目录中
  • 如果将 W3C 日志设置为存储，则在 blob 存储中

后者使应用能够收集大量日志，而没有超出与某一网络共享相关联的文件存储限制的风险。

同样，可以通过 .NET 跟踪和诊断基础设施记录 .NET 应用程序的实时诊断信息。 然后，可以将跟踪信息写入应用的网络共享或 Blob 存储位置。

诊断日志记录和跟踪中不可用于应用的领域是 Windows 事件跟踪 (ETW) 事件以及常见的 Windows 事件日志（例如系统、应用程序和安全事件日志）。 由于 ETW 跟踪信息可以跨计算机（需具有正确的访问控制列表）查看，因此会阻止对 ETW 事件的读取访问和写入访问。 对读取和写入 ETW 事件和常见 Windows 事件日志的 API 调用似乎起作用，但实际上，应用程序代码无法访问此事件数据。

注册表访问

应用对于它们在其上运行的虚拟机的注册表的大部分内容（尽管不是全部内容）具有只读访问权限。 此访问权限意味着应用可以访问允许对本地用户组进行只读访问的注册表项。 注册表中当前不支持读写访问的一个区域是 HKEY\_CURRENT\_USER 配置单元。

对注册表的写访问被阻止，包括对任何按用户注册表项的访问。 从应用的角度来看，它无法依赖于对 Azure 环境中的注册表的写入访问权限，因为应用可以跨虚拟机迁移。 应用可依赖的唯一持久可写入存储是在应用服务 UNC 共享上存储的按应用内容目录结构。

远程桌面访问

应用服务不提供对 VM 实例的远程桌面访问。

详细信息

有关应用服务的执行环境的最新信息，请参阅 Azure 应用服务沙盒。 应用服务开发团队会维护此页面。