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