本文說明所有在 Azure App Service 中執行的 Windows 應用程式可使用的基準作系統功能。 此功能包括檔案、網路和登錄存取，以及診斷記錄和事件。
備註
App Service 中的 Linux 應用程式會在自己的容器中執行。 您有容器的根存取權，但無法存取主機作系統。 同樣地，對於 在 Windows 容器中執行的應用程式，您具有容器的系統管理存取權，但無法存取主機作系統。
App Service 計劃層
App Service 會在多租用戶裝載環境中執行客戶應用程式。
- 在免費層和共用層中部署的應用程式會在共用虛擬機（VM）的工作進程中執行。
- 部署在標準和進階層中的應用程式會在專用於與單一客戶相關聯之應用程式的 VM 上執行。
備註
App Service 的免費和共用 (預覽) 服務方案均為基本層，在與其他 App Service 應用程式相同的 Azure 虛擬機器上執行。 某些應用程式可能屬於其他客戶。 這些層僅用於開發與測試目的。
因為 App Service 支援階層之間的無縫調整體驗，因此針對 App Service 應用程式強制執行的安全性設定會維持不變。 此設定可確保當 App Service 方案從一層切換到另一層時，應用程式不會突然有不同的行為，並以非預期的方式失敗。
開發架構
App Service 定價層可控制應用程式可用的計算資源數量（CPU、磁碟記憶體、記憶體和網路輸出）。 不過，無論縮放層級為何，應用程式可用的架構功能廣度仍維持不變。
App Service 支援各種開發架構，包括 ASP.NET、傳統 ASP、Node.js、PHP 和 Python。 為了簡化及正規化安全性設定，App Service 應用程式通常會使用其預設設定來執行開發架構。 平臺提供的架構和運行時間元件會定期更新，以滿足安全性和合規性需求。 基於這個理由，我們不保證特定的次要或修補程式版本。 我們建議客戶視需要以主要版本為目標。
下列各節摘要說明 App Service 應用程式可用的一般作系統功能種類。
檔案存取
App Service 中存在各種磁碟，包括本機磁碟和網路磁碟。
本機磁碟機
App Service 的核心是一項服務，可在 Azure 平臺即服務 （PaaS） 基礎結構上執行。 因此，與 VM 相關聯的本機磁碟是任何在 Azure 執行的角色均可用的相同類型。 其中包括：
- 作業系統硬碟（
%SystemDrive%）的大小取決於虛擬機器的大小。 - App Service 內部使用的資源磁碟（
%ResourceDrive%）。
最佳做法是一律使用環境變數 %SystemDrive% ， %ResourceDrive% 而不是硬式編碼的檔案路徑。 從這兩個環境變數傳回的根路徑已隨著時間從 d:\ 移轉至 c:\。 不過，使用 d:\ 檔案路徑參考硬式編碼的較舊應用程式仍可繼續運作，因為 App Service 會自動重新對應 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）共享資源上。 此種模型非常符合一種內容儲存體模式，該模式通常是由具有多個負載平衡伺服器的內部部署虛擬主機所使用。
在 App Service 中，會在每個資料中心建立 UNC 檔案共用。 每個 UNC 共用都會配置每個資料中心內各客戶某個百分比的使用者內容。 在資料中心內的特定 UNC 共用上，每個客戶的訂用帳戶都有一個保留的目錄結構。 客戶可能會在特定數據中心內建立多個應用程式，因此屬於單一客戶訂用帳戶的所有目錄都會建立在相同的 UNC 共用上。
由於 Azure 服務的運作方式，負責裝載 UNC 共用的特定 VM 會隨著時間變更。 UNC 共用會由不同的 VM 掛接，因為其會在 Azure 作業的正常過程中啟動和關閉。 基於這個理由，應用程式絕對不應該進行硬式編碼的假設，即 UNC 檔案路徑中的機器資訊會隨著時間保持穩定。 反之，應該使用 App Service 所提供的方便 faux 絕對路徑 %HOME%\site。
假絕對路徑是參考您自己應用程式的可攜式方法。 它並非任何應用程式或使用者特有的。 藉由使用 %HOME%\site，您可以將共用檔案從應用程式傳送到應用程式，而不需要為每個傳輸設定新的絕對路徑。
授與應用程式之檔案存取的類型
應用程式中的 %HOME% 目錄會對應至 Azure 儲存體中該應用程式專用的內容共用。 您的 定價層 會定義其大小。 這可能包括目錄 (內容、錯誤和診斷記錄的目錄)，以及原始檔控制所建立的舊版應用程式。 這些目錄可在運行時間供應用程式的應用程式程式代碼使用，以便讀取和寫入存取。 因為檔案不會儲存在本機，所以會在應用程式重新啟動時持續存在。
在系統磁碟機上，App Service 保留 %SystemDrive%\local 給應用程式特定的暫存本機儲存體。 此目錄中檔案的變更 不會 在應用程式重新啟動時持續發生。 雖然應用程式具有本身暫存本機記憶體的完整讀取和寫入許可權，但該記憶體並非供應用程式程式代碼直接使用。 相反地，目的是為 IIS 和 Web 應用程式架構提供暫存盤記憶體。
App Service 會限制每個應用程式的記憶體 %SystemDrive%\local 數量，以防止個別應用程式耗用過多的本機檔案記憶體。 針對免費、共用和消耗層（Azure Functions），限制為 500 MB。 下表列出其他層：
| 層 | 本機記憶體限制 |
|---|---|
| B1/S1/P1 | 11 GB |
| B2/S2/P2 | 15 GB |
| B3/S3/P3 | 58 GB |
| P0v3/P0v4 | 11 GB |
| P1v2/P1v3/P1mv3/P1v4/P1mv4/Isolated1/Isolated1v2 | 21 GB |
| P2v2/P2v3/P2mv3/P2v4/P2mv4/Isolated2/Isolated2v2 | 61 GB |
| P3v2/P3v3/P3mv3/P3v4/P3mv4/Isolated3/Isolated3v2 | 140 GB |
| Isolated4v2 | 276 GB |
| P4mv3/P4mv4 | 280 GB |
| Isolated5v2 | 552 GB |
| P5mv3/P5mv4 | 560 GB |
| Isolated6v2 | 1,104 GB |
暫存 ASP.NET 檔案的目錄和 IIS 壓縮文件的目錄是 App Service 如何使用暫存本機記憶體的兩個範例。 ASP.NET 編譯系統會使用 %SystemDrive%\local\Temporary ASP.NET Files 目錄作為暫存編譯快取位置。 IIS 使用 %SystemDrive%\local\IIS Temporary Compressed Files 目錄來儲存壓縮的響應輸出。 這兩種檔案使用方式 (和其他方式) 都會在 App Service 中重新對應至每個應用程式的暫存本機儲存體。 此重新對應可協助確保功能如預期般繼續運作。
App Service 中的每個應用程式都會以隨機、唯一、低許可權的工作進程身分執行，稱為應用程式集區身分識別。 應用程式程式代碼會使用此身分識別來取得作系統磁碟驅動器的基本唯讀存取權。 此存取表示應用程式程式代碼可以列出通用目錄結構，並讀取作系統磁碟驅動器上的一般檔案。 雖然存取層級似乎有點廣泛，但是當您在 Azure 託管服務中佈建背景工作角色和讀取磁碟機內容時，可以存取的目錄和檔案相同。
跨多個實例的檔案存取
內容共用 （%HOME%） 目錄包含應用程式的內容，而應用程式程式代碼可以寫入其中。 如果應用程式在多個實例上執行，則會 %HOME% 在所有實例之間共享目錄，讓所有實例都看到相同的目錄。 例如，如果應用程式將上傳的檔案儲存到 %HOME% 目錄，則所有實例都可以立即使用這些檔案。
暫存本機記憶體 （%SystemDrive%\local） 目錄不會在實例之間共用。 它也不會在應用程式及其 Kudu 應用程式之間共用。
網路存取
應用程式程式代碼可以使用 TCP/IP 和 UDP 型通訊協定，對公開外部服務的因特網可存取端點進行輸出網路連線。 應用程式可以使用這些相同的通訊協議來連線到 Azure 內的服務，例如，建立 Azure SQL Database 的 HTTPS 連線。
此外，應用程式可以在有限的情況下建立一個本機回送連線，並且讓應用程式在該本機回送通訊端上接聽。 此功能可讓應用程式在其功能中接聽本機回送通訊端。 每個應用程式都有自己的回送連線。 一個應用程式無法接聽另一個應用程式所建立的本機回送通訊端。
具名管道也支援作為共同執行應用程式之處理序間通訊的機制。 例如，IIS FastCGI 模組依賴命名管道來協調執行 PHP 頁面的個別進程。
程式代碼執行、進程和記憶體
如先前所述，應用程式會使用隨機應用程式集區身分識別，在低權限工作進程中執行。 應用程式程式代碼可以存取與背景工作進程相關聯的記憶體空間，以及 CGI 進程或其他應用程式可能會繁衍的任何子進程。 不過，即使某個應用程式位於相同的 VM 上，還是無法存取另一個應用程式的記憶體或數據。
應用程式可以執行以支援的 Web 開發架構撰寫的腳本或頁面。 App Service 不會將任何 Web 架構設定設定為受限制的模式。 例如，ASP.NET 在 App Service 中執行的應用程式會以完全信任的方式執行，而不是更受限制的信任模式。 Web 架構，包括傳統 ASP 和 ASP.NET，可以調用 Windows 作業系統上預設註冊的進程中的 COM 元件（例如 ActiveX Data Objects）。 Web 架構無法呼叫跨進程 COM 元件。
應用程式可以繁衍並執行任意程式代碼、開啟命令殼層，或執行PowerShell腳本。 不過，可執行的程式和腳本仍受限於授與父應用程式集區的許可權。 例如，應用程式可以繁衍發出輸出 HTTP 呼叫的可執行程式，但該可執行程式無法嘗試將 VM 的 IP 位址從其網路適配器解除系結。 允許對低許可權程式代碼進行輸出網路呼叫，但嘗試在 VM 上重新設定網路設定需要系統管理許可權。
診斷記錄和事件
記錄資訊是一些應用程式嘗試存取的另一組數據。 App Service 中執行之程式代碼可用的記錄資訊類型包括應用程式產生的診斷和記錄資訊，而且可以輕鬆地存取。
例如，可以使用應用程式產生的 W3C HTTP 記錄：
- 在您為應用程式建立的網路共用位置中的記錄目錄中。
- 如果您設定 W3C 記錄至儲存體，則在 Blob 儲存體中。
後者選項可讓應用程式收集大量的記錄，而不會超過與網路共用相關聯的檔案記憶體限制。
同樣地，來自 .NET 應用程式的實時診斷資訊也可以透過 .NET 追蹤和診斷基礎結構來記錄。 接著，您可以將追蹤資訊寫入應用程式的網路共用或 Blob 儲存體位置。
應用程式無法使用的診斷記錄和追蹤區域是 Windows 事件追蹤（ETW）事件和常見的 Windows 事件記錄檔（例如系統、應用程式和安全性事件記錄）。 由於 ETW 追蹤資訊可能被跨電腦透過適當的存取控制清單進行檢視，因此會封鎖對 ETW 事件的讀取和寫入權限。 API 呼叫來讀取和寫入 ETW 事件和常見的 Windows 事件記錄可能正常運作，但實際上，應用程式程式代碼無法存取此事件數據。
登錄檔存取
應用程式對它們執行之 VM 的登錄具有唯讀存取權，但並非全部。 此存取表示應用程式可以存取允許本機使用者群組唯讀存取的登錄機碼。 目前不支援讀取或寫入存取權的登錄區域之一是 HKEY_CURRENT_USER Hive。
登錄的寫入存取權已遭封鎖，其中包括任何每一使用者登錄機碼的存取。 從應用程式的觀點來看，它無法依賴 Azure 環境中登錄的寫入許可權，因為應用程式可以跨 VM 移轉。 應用程式可依賴的唯一持續性可寫入記憶體是儲存在App Service UNC 共用上的個別應用程式內容目錄結構。
遠端桌面存取
App Service 不提供對 VM 實例的遠端桌面存取。
相關內容
如需有關 App Service 執行環境的最新資訊，請參閱 Azure App Service 沙箱。 App Service 開發小組會維護此頁面。