Azure App Service 中的作業系統功能
本文說明在 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) 基礎結構之上執行的服務。 因此，與虛擬機器相關聯的本機磁碟機就是任何在 Azure 中所執行背景工作角色可用的相同磁碟機類型。 其中包含：
- 作業系統磁碟機 (
%SystemDrive%) 的大小取決於 VM 的大小。 - 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 共用的特定虛擬機器會隨著時間而改變。 UNC 共用會由不同的虛擬機掛接，因為它們會在 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 | 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 |
App Service 對於暫存本機儲存體的兩種使用方式範例：暫存 ASP.NET 檔案的目錄和 IIS 壓縮檔案的目錄。 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 處理序或其他應用程式可能繁衍的任何子處理序。 但是，即使是位於相同的虛擬機器上，某個應用程式無法存取其他應用程式的記憶體或資料。
應用程式可以執行利用支援的 Web 開發架構撰寫的指令碼或頁面。 App Service 不會將任何 Web 應用程式架構設定設定為比較受限的模式。 例如，在 App Service 上執行的 ASP.NET 應用程式會以完全信任模式 (相對於比較受限的信任模式) 執行。 Web 架構 (包括傳統 ASP 和 ASP.NET) 可以呼叫處理序內預設在 Windows 作業系統上註冊的 COM 元件 (例如 ActiveX Data Objects)。 Web 架構無法呼叫跨處理序 COM 元件。
應用程式可以繁衍並執行任意程式碼、開啟命令殼層，或執行 PowerShell 指令碼。 不過，可執行的程式和指令碼仍受限於授與父應用程式集區的權限。 例如，應用程式可以繁衍發出輸出 HTTP 呼叫的可執處理序程式，但該可執處理序程式無法嘗試從其網路介面卡解除繫結虛擬機的 IP 位址。 低權限的程式碼允許進行輸出網路呼叫，但嘗試在虛擬機器上重新設定網路設定則需要有系統管理權限。
診斷記錄和事件
記錄資訊是某些應用程式嘗試存取的另一組資料。 App Service 中所執行程式碼可用的記錄資訊類型包括應用程式產生的診斷和記錄資訊，且可以輕鬆地存取。
例如，應用程式產生的 W3C HTTP 記錄提供於：
- 在您為應用程式所建立網路共用位置的記錄目錄中
- 如果您設定 W3C 記錄至儲存體，則在 Blob 儲存體中
後者選項可讓應用程式收集大量的記錄，而不會超過與網路共用相關聯的檔案儲存體限制。
同樣地，來自 .NET 應用程式的即時診斷資訊也可以透過 .NET 追蹤和診斷基礎結構來進行記錄。 接著，您可以將追蹤資訊寫入應用程式的網路共用或 Blob 儲存體位置。
應用程式無法使用的診斷記錄和追蹤區域包括 Windows 事件追蹤 (ETW) 和一般 Windows 事件記錄 (例如 System、Application 和 Security 事件記錄)。 由於 ETW 追蹤資訊可能可以會跨電腦檢視 (具有正確的存取控制清單)，因此會封鎖對 ETW 事件的讀取存取和寫入存取。 API 呼叫以讀取和寫入 ETW 事件和常見的 Windows 事件記錄可能正常運作，但實際上，應用程式程式碼無法存取此事件資料。
登錄存取
應用程式對於其執行所在的虛擬機器，具有大部分 (雖然並非全部) 登錄的唯讀存取權。 此存取表示應用程式可以存取允許本機使用者群組唯讀存取的登錄機碼。 目前不支援讀取或寫入存取的其中一個登錄區域為 HKEY\_CURRENT\_USER 登錄區。
登錄的寫入存取權已遭封鎖，其中包括任何每一使用者登錄機碼的存取。 從應用程式的觀點來看，它無法依賴 Azure 環境中登錄的寫入存取，因為應用程式可以跨虛擬機器移轉。 應用程式可依賴的唯一持續性可寫入儲存體，就是儲存在 App Service UNC 共用上每個應用程式內容的目錄結構。
遠端桌面存取
App Service 並未提供對 VM 執行個體的遠端桌面存取。
其他相關資訊
如需有關 App Service 執行環境的最新資訊，請參閱 Azure App Service 沙箱。 App Service 開發小組會維護此頁面。