你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure App 服务中的操作系统功能
本文介绍可用于Azure App 服务中运行的所有 Windows 应用的基线操作系统功能。 此功能包括文件、网络和注册表访问权限，以及诊断日志和事件。
注意
应用服务中的 Linux 应用在其自己的容器中运行。 你对容器具有根访问权限，但无权访问主机操作系统。 同样，对于在 Windows 容器中运行的应用，你具有对容器的管理访问权限，但无法访问主机操作系统。
应用服务计划层
App 服务在多租户托管环境中运行客户应用。 在“免费”层和“共享”层中部署的应用在共享虚拟机（VM）的工作进程中运行。 在标准层和高级版层中部署的应用在专用于与单个客户关联的应用的 VM 上运行。
注意
应用服务免费和共享（预览版）服务计划是基本层，与其他应用服务应用在相同的 Azure 虚拟机上运行。 某些应用可能属于其他客户。 这些层仅用于开发和测试目的。
由于App 服务支持层之间的无缝缩放体验，因此为App 服务应用强制实施的安全配置保持不变。 此配置可确保当App 服务计划从一个层切换到另一层时，应用的行为不会突然不同，并且以意外的方式失败。
开发框架
应用服务定价层控制可用于应用的计算资源（CPU、磁盘存储、内存和网络出口）的数量。 但是，可用于应用的框架功能范围保持不变，而与缩放层无关。
App 服务支持各种开发框架，包括 ASP.NET、经典 ASP、Node.js、PHP 和 Python。 为了简化和规范安全配置，App 服务应用通常使用默认设置运行开发框架。 平台提供的框架和运行时组件会定期更新，以满足安全性和符合性要求。 因此，我们不能保证特定的次要/修补程序版本。 我们建议客户根据需要面向主要版本。
以下部分概述了可用于应用服务应用的一般类型的操作系统功能。
文件访问
应用服务中存在各种不同的驱动器，包括本地驱动器和网络驱动器。
本地驱动器
App 服务的核心是一项在 Azure 平台即服务（PaaS）基础结构上运行的服务。 因此，与虚拟机关联的本地驱动器是可用于 Azure 中运行的任何辅助角色的相同驱动器类型。 它们包括：
- 其大小取决于 VM 大小的操作系统驱动器（
%SystemDrive%）。 - App 服务内部使用的资源驱动器（
%ResourceDrive%）。
最佳做法是始终使用环境变量 %SystemDrive% 和 %ResourceDrive%，而不是硬编码文件路径。 从这两个环境变量返回的根路径已逐渐从 d:\ 移动到 c:\。 但是，使用文件路径引用进行硬编码的较旧应用程序将继续d:\工作，因为App 服务会自动重新映射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 服务的独特方面之一是所有内容共享都存储在一组 UNC 共享上。 此模型很好地映射到具有多个负载均衡服务器的本地 Web 托管环境所用内容存储的公共模式。
在App 服务中，在每个数据中心创建 UNC 共享。 每个数据中心内所有客户的用户内容百分比分配给每个 UNC 共享。 每个客户的订阅在数据中心的特定 UNC 共享上都有保留的目录结构。 客户可能在特定数据中心创建了多个应用，因此属于单个客户订阅的所有目录都在同一 UNC 共享上创建。
由于 Azure 服务的工作方式，负责托管 UNC 共享的特定虚拟机会随时间推移而更改。 UNC 共享由不同的虚拟机装载，因为它们在正常 Azure 操作过程中启动和关闭。 因此，应用不应作出这样的硬编码的假定，即 UNC 文件路径中的计算机信息会在一段时间后保持不变， 而应使用应用服务提供的方便的 faux 绝对路径 %HOME%\site。
假绝对路径是一种可移植的方法，用于引用自己的应用。 它不特定于任何应用或用户。 通过使用 %HOME%\site，可以将共享文件从应用传输到应用，而无需为每个传输配置新的绝对路径。
向应用授予的文件访问的类型
应用中的%HOME%目录映射到专用于该应用Azure 存储中的内容共享。 定价 层 定义其大小。 它可能包括目录，例如用于内容、错误和诊断日志的目录，以及源代码管理创建的应用的早期版本。 这些目录可以在运行时供应用的应用程序代码进行读写访问。 由于文件不存储在本地，因此在应用重启后将保持不变。
在系统驱动器上，应用服务会保留 %SystemDrive%\local 作为特定于应用的临时本地存储。 此目录中的文件更改不会在应用重启后保持不变。 尽管应用对其自己的临时本地存储具有完全读取和写入访问权限，但该存储不适合直接供应用程序代码使用。 而是用于为 IIS 和 Web 应用程序框架提供临时文件存储。
App 服务限制每个应用的存储%SystemDrive%\local量，以防止单个应用消耗过多的本地文件存储。 免费层、共享层和消耗层 (Azure Functions) 的限制为 500 MB。 下表列出了其他层：
| 层 | 本地文件存储 |
|---|---|
| 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 |
| Isolated4v2 | 276 GB |
| P4mv3 | 280 GB |
| Isolated5v2 | 552 GB |
| P5mv3 | 560 GB |
| Isolated6v2 | 1,104 GB |
说明应用服务如何使用临时本地存储的两个示例是针对临时 ASP.NET 文件的目录和针对 IIS 压缩文件的目录。 ASP.NET 编译系统使用 %SystemDrive%\local\Temporary ASP.NET Files 目录作为临时编译缓存位置。 IIS 使用 %SystemDrive%\local\IIS Temporary Compressed Files 目录存储压缩的响应输出。 这两种类型的文件使用情况（以及其他）都重新映射到每个应用临时本地存储App 服务。 此重新映射有助于确保功能按预期继续。
App 服务中的每个应用都以随机、唯一、低特权的工作进程标识（称为应用程序池标识）运行。 应用程序代码将此标识用于对操作系统驱动器的基本的只读访问。 此访问权限意味着应用程序代码可以列出通用目录结构，并读取操作系统驱动器上的常见文件。 尽管这种访问级别可能很广泛，但在 Azure 托管服务中预配辅助角色并读取驱动器内容时，可以访问相同的目录和文件。
跨多个实例的文件访问
内容共享 (%HOME%) 目录包含应用的内容，应用程序代码可以将内容写入该目录。 如果应用在多个实例上运行，则 %HOME% 目录会在所有实例间共享，因此所有实例都会看到同一个目录。 例如，如果应用将上传的文件 %HOME% 保存到目录中，则这些文件立即可供所有实例使用。
临时本地存储 （%SystemDrive%\local） 目录不会在实例之间共享。 它也不会在应用与其 Kudu 应用之间共享。
网络访问
应用程序代码可以使用基于 TCP/IP 和 UDP 的协议来建立与公开外部服务的 Internet 可访问的终结点建立出站网络连接。 应用可以使用这些相同的协议连接到 Azure 中的服务，例如，通过建立与Azure SQL 数据库的 HTTPS 连接。
应用还可以建立一个本地环回连接，并让应用侦听该本地环回套接字。 此功能使应用能够侦听本地环回套接字作为其功能的一部分。 每个应用都有专用环回连接。 一个应用无法侦听另一个应用建立的本地环回套接字。
命名管道也支持作为一种机制，用于在共同运行应用的进程之间进行进程间通信。 例如，IIS FastCGI 模块依赖命名管道协调运行 PHP 页的单独进程。
代码执行、进程和内存
如前所述，应用使用随机应用程序池标识在低特权工作进程内运行。 应用程序代码可以访问与工作进程关联的内存空间，以及 CGI 进程或其他应用程序可能生成的任何子进程。 但是，一个应用无法访问另一个应用的内存或数据，即使它位于同一虚拟机上也是如此。
应用可以运行使用支持的 Web 开发框架编写的脚本或页面。 应用服务不将任何 Web 框架设置配置为更受限制的模式。 例如，ASP.NET 在App 服务中运行的应用完全信任运行，而不是更受限的信任模式。 Web 框架（包括经典 ASP 和 ASP.NET）可以调用在 Windows 操作系统上默认注册的进程内 COM 组件（如 ActiveX 数据对象）。 Web 框架无法调用进程外 COM 组件。
应用可以生成并运行任意代码、打开命令行界面或运行 PowerShell 脚本。 但是，可执行程序和脚本仍仅限于授予父应用程序池的权限。 例如，应用可以生成发出出站 HTTP 调用的可执行程序，但该可执行程序无法尝试从其网络适配器取消绑定虚拟机的 IP 地址。 允许对低特权代码进行出站网络调用，但尝试在虚拟机上重新配置网络设置需要管理权限。
诊断日志和事件
日志信息是一些应用尝试访问的另一组数据。 App 服务中运行的代码可用的日志信息类型包括应用生成的诊断和日志信息，并且可以轻松访问。
例如，可以使用应用生成的 W3C HTTP 日志：
- 在为应用创建的网络共享位置的日志目录中
- 如果将 W3C 日志记录设置为存储，请在 Blob 存储中
后一个选项使应用能够收集大量日志，而不会超过与网络共享关联的文件存储限制。
同样，可以通过 .NET 跟踪和诊断基础结构记录来自 .NET 应用的实时诊断信息。 然后，可以将跟踪信息写入应用的网络共享或 Blob 存储位置。
诊断日志记录和跟踪的区域不适用于应用是 Windows 事件跟踪（ETW）事件和常见的 Windows 事件日志（例如系统、应用程序和安全事件日志）。 由于 ETW 跟踪信息可能跨计算机（具有正确的访问控制列表）查看，因此会阻止对 ETW 事件的读取访问和写入访问。 对读取和写入 ETW 事件和常见 Windows 事件日志的 API 调用似乎起作用，但实际上，应用程序代码无法访问此事件数据。
注册表访问
应用对运行它们的虚拟机注册表的很多（虽然不是全部）具有只读访问权限。 此访问权限意味着应用可以访问允许对本地用户组进行只读访问的注册表项。 当前不支持读取或写入访问的注册表的一个区域是 HKEY\_CURRENT\_USER hive。
阻止对注册表的写入访问，包括对任何每个用户注册表项的访问。 从应用的角度来看，它不能依赖于对 Azure 环境中的注册表的写入访问权限，因为应用可以跨虚拟机迁移。 应用可依赖的唯一持久性可写存储是存储在 App 服务 UNC 共享上的每应用内容目录结构。
远程桌面访问
应用服务不提供对 VM 实例的远程桌面访问。
详细信息
有关App 服务执行环境的最新信息，请参阅Azure App 服务沙盒。 App 服务开发团队维护此页面。