編輯

共用方式為


基本 Web 應用程式

Azure App Service
Azure 監視器
Azure SQL Database

本文提供一個基本架構,旨在了解如何在單一區域中 Azure App Service 上執行 Web 應用程式。

重要

此架構並非用於生產應用程式。 它是一個簡介架構,讓您可以用於學習和概念證明 (POC) 用途。 設計生產 Azure App Service 應用程式時,請參閱基準高可用性區域備援 Web 應用程式

重要

GitHub 標誌 此指引是由在 Azure 上展示這個基本 App Service 實作的範例實作所支援。 這個實作可當做體驗使用 Azure App Service 的 POC 基礎。

架構

顯示基本 App Service 架構的圖表。

圖 1:基本 Azure App Service 架構

下載此架構的 Visio 檔案

工作流程

  1. 使用者向 azurewebsites.net 上的 App Service 預設網域發出 HTTPS 要求。 此網域會自動指向 App Service 的內建公用 IP。 TLS 連線是從用戶端直接建立到 App Service。 憑證完全由 Azure 管理。
  2. 簡易驗證 (Azure App Service 的功能) 可確保存取網站的使用者會使用 Microsoft Entra ID 進行驗證。
  3. 部署至 App Service 的應用程式程式碼會處理要求。 例如,該程式碼可能會使用在 App Service 中設定為應用程式設定的連接字串,連線到 Azure SQL Database 執行個體。
  4. 對 App Service 的原始要求和對 Azure SQL Database 的呼叫相關資訊都會記錄在 Application Insights 中。

元件

  • Microsoft Entra ID 是雲端式身分識別和存取權管理服務。 它提供單一身分識別控制平面來管理存取 Web 應用程式之使用者的權限和角色。 它會與 App Service 整合,並簡化 Web 應用程式的驗證和授權。
  • App Service 是完全受控的平台,可用於建置、部署和調整 Web 應用程式。
  • Azure 監視器是一項監視服務,可收集、分析及處理整個部署的遙測資料。
  • Azure SQL Database 是適用於關聯式資料的受控關聯式資料庫服務。

建議和考量

此架構中所列的元件會連結至 Azure Well-Architected Framework 服務指南。 服務指南會詳細說明特定服務的建議和考量。 本節藉由強調適用於此架構的重要 Azure Well-Architected Framework 建議和考量,擴充該指引。 如需詳細資訊,請參閱 Microsoft Azure Well-Architected Framework (部分機器翻譯)。

基本架構不適用於生產環境部署。 此架構著重於簡單性和成本效益而非功能,可讓您評估及學習 Azure App Service。 下列各節概述此基本架構的一些缺陷,以及建議和考量。

可靠性

可靠性可確保您的應用程式符合您對客戶的承諾。 如需詳細資訊,請參閱可靠性的設計檢閱檢查清單

由於此架構並非針對生產環境部署所設計,下面將概述此架構中省略的一些重要可靠性功能:

  • App Service 方案設定為 Standard 標準層,沒有 Azure 可用性區域支援。 如果執行個體、機架或裝載執行個體的資料中心發生任何問題,App Service 就會變成無法使用。
  • Azure SQL Database 設定為 Basic 基本層,不支援區域備援。 這表示資料不會在 Azure 可用性區域中複寫,如果發生中斷,可能會遺失已認可的資料。
  • 此架構的部署可能會導致應用程式部署停機,因為大部分的部署技術都需要重新啟動所有執行中的執行個體。 使用者在此程序期間可能會遇到 503 錯誤。 這會透過部署位置在基準架構中處理。 需要謹慎的應用程式設計、結構描述管理和應用程式組態處理,才能支援並行位置部署。 請使用此 POC 來設計和驗證位置型生產環境部署方法。
  • 此基本架構未啟用自動調整。 為了防止由於缺少可用計算資源而產生的可靠性問題,您必須超額佈建,才能一律使用足夠的計算來執行,以處理最大並行容量。

請參閱基準高可用性區域備援 Web 應用程式中的可靠性一節,了解如何克服這些可靠性疑慮。

如果此工作負載最終需要多區域主動-主動或主動-被動架構,請參閱高可用性多區域 Web 應用程式,以取得跨多個區域部署 App Service 裝載工作負載的指引。

安全性

安全性可提供保證,以避免刻意攻擊和濫用您寶貴的資料和系統。 如需詳細資訊,請參閱安全性的設計檢閱檢查清單

由於此架構並非針對生產環境部署所設計,下面將概述此架構中省略的一些重要安全性功能,以及其他可靠性建議和考量:

  • 此基本架構不會實作網路隱私權。 資源的資料和管理平面,例如 Azure App Service 和 Azure SQL Server,可透過公用網際網路連線。 省略私人網路會大幅增加架構的受攻擊面。 若要了解實作私人網路如何確保下列安全性功能,請參閱基準高可用性區域備援 Web 應用程式的網路一節

    • 用戶端流量的單一安全進入點
    • 網路流量會同時在封包層級和 DDoS 層級進行篩選。
    • 使用 Private Link 將流量保持在 Azure 內,讓資料外流降到最低
    • 網路資源會透過網路分割,以邏輯方式分組並彼此隔離。
  • 此基本架構不包含 Azure Web 應用程式防火牆的部署。 Web 應用程式無法防範常見的惡意探索和弱點攻擊。 請參閱基準實作,以了解如何在 Azure App Service 架構中使用 Azure 應用程式閘道實作 Web 應用程式防火牆。

  • 此基本架構會在應用程式設定中儲存秘密,例如 Azure SQL Server 連接字串。 雖然應用程式設定已加密,但移至生產環境時,請考慮將秘密儲存在 Azure Key Vault 中,以提高治理能力。 更好的解決方案是使用受控識別進行驗證,而且不將秘密儲存在連接字串中。

  • 在開發或概念證明階段中,可以讓遠端偵錯和 Kudu 端點保持啟用狀態。 當您移至生產環境時,應該停用不必要的控制平面、部署或遠端存取。

  • 在開發或概念證明階段中,可以讓 FTP 和 SCM 網站部署的本機驗證方法保持啟用狀態。 當您移至生產環境時,應該停用這些端點的本機驗證。

  • 您不需要在概念證明階段中啟用適用於 App Service 的 Microsoft Defender。 移至生產環境時,您應該啟用適用於 App Service 的 Defender 來產生應該實作的安全性建議,以提高安全性態勢並偵測 App Service 面臨的眾多威脅。

  • Azure App Service 包含子網域 azurewebsites.net 上的 SSL 端點,不需額外費用。 HTTP 要求預設會重新導向至 HTTPS 端點。 針對生產環境部署,您通常會在 App Service 部署的前方使用與應用程式閘道或 API 管理相關聯的自訂網域。

  • 請使用 App Service 的整合式驗證機制 ("EasyAuth")。 EasyAuth 可簡化將身分識別提供者整合到 Web 應用程式的程序。 它會在 Web 應用程式外部處理驗證,因此您不需要進行大幅的程式碼變更。

  • 請針對工作負載身分識別使用受控識別。 受控識別可免除開發人員管理驗證認證的需求。 此基本架構會透過連接字串中的密碼向 SQL Server 進行驗證。 請考慮使用受控識別向 Azure SQL Server 進行驗證

如需其他安全性考量,請參閱在 Azure App Service 中保護應用程式

卓越營運

卓越營運涵蓋部署應用程式並使其持續在生產環境中執行的作業流程。 如需詳細資訊,請參閱卓越營運的設計檢閱檢查清單

下列各節提供有關 App Service 應用程式組態、監視和部署的指引。

應用程式組態

因為此基本架構不適用於生產環境,所以它會使用 App Service 組態來儲存組態值和秘密。 對於 PoC 階段,可以在 App Service 組態中儲存秘密。 您不是使用真正的秘密,也不需要生產工作負載所需的秘密治理。

以下是組態建議和考量:

  • 首先,使用 App Service 組態,將組態值和連接字串儲存在概念證明部署中。 應用程式設定和連接字串是在應用程式啟動時插入至應用程式之前進行加密和解密。
  • 當您進入生產階段時,請將秘密儲存在 Azure Key Vault 中。 使用 Azure Key Vault 可透過兩種方式改善秘密的治理:
    • 將秘密的儲存外部化至 Azure Key Vault 可讓您集中儲存秘密。 您可以在同一處管理秘密。
    • 使用 Azure Key Vault 時,您可以記錄與秘密的每個互動,包括每次存取秘密時。
  • 當您移至生產環境時,可以使用 Key Vault 參考來維護 Azure Key Vault 和 App Service 組態的使用狀況。

診斷和監控

在概念證明階段,請務必了解哪些記錄和計量可供擷取。 以下是概念證明階段中監視的建議和考量:

  • 為所有項目記錄來源啟用診斷記錄。 設定使用所有診斷設定可協助您了解現成可用的記錄和計量,以及您需要在應用程式程式碼中使用記錄架構來消弭的任何差距。 當您移至生產環境時,應該排除對工作負載的記錄接收並未增加價值而是增加雜訊和成本的記錄來源。
  • 設定記錄以使用 Azure Log Analytics。 Azure Log Analytics 提供可調整的平台,可集中處理記錄以方便查詢。
  • 使用 Application Insights 或其他應用程式效能管理 (APM) 工具來發出遙測和記錄,以監視應用程式效能。

部署

以下列出有關部署 App Service 應用程式的指引。

  • 遵循適用於 Azure Web Apps 與 Azure Pipelines 的 CI/CD 中的指引,將應用程式的部署自動化。 開始在 PoC 階段建置部署邏輯。 在開發程序中早期實作 CI/CD 可讓您在進入生產環境時,快速且安全地反覆執行應用程式。
  • 使用 ARM 範本部署 Azure 資源及其相依性。 請務必在 PoC 階段啟動此程序。 當您進入生產環境時,您會希望能夠自動部署基礎結構。
  • 使用不同的 ARM 範本,並將其與 Azure DevOps 服務整合。 此設定可讓您建立不同的環境。 例如,您可以僅在需要時才複寫類似生產環境的案例或負載測試環境,並節省成本。

如需詳細資訊,請參閱 Azure Well-Architected Framework 中的 DevOps 章節。

容器

基本架構可用來將支援的程式碼直接部署到 Windows 或 Linux 執行個體。 或者,App Service 也是用來執行容器化 Web 應用程式的容器裝載平台。 App Service 提供各種內建容器。 如果您是使用自訂或多容器應用程式來進一步微調執行階段環境,或支援原生不支援的程式碼語言,則需要引進容器登錄。

控制平面

在 POC 階段,熟悉透過 Kudu 服務公開的 Azure App Service 控制平面。 此服務會公開常見的部署 API,例如 ZIP 部署、公開原始記錄和環境變數。

如果使用容器,請務必了解 Kudu 能夠開啟容器的 SSH 工作階段,以支援進階偵錯功能。

效能效益

效能效率可讓您的工作負載進行調整,以有效率的方式符合使用者對其放置的需求。 有關詳細資訊,請參閱效能效率的設計審核清單

由於此架構並非針對生產環境部署所設計,下面將概述此架構中省略的一些重要效能效率功能,以及其他建議和考量:

概念證明的結果應該是您估計適合工作負載的 SKU 選取項目。 您的工作負載應設計成透過水平調整來有效率地滿足需求,方法是調整 App Service 方案中部署的計算執行個體數目。 請勿將系統設計為相依於變更計算 SKU 以符合需求。

  • 此基本架構中的 App Service 並未實作自動調整。 服務不會動態擴增或縮減,以有效率地與需求保持一致。
    • 標準層支援自動調整設定,可讓您設定以規則為基礎的自動調整。 POC 程序的一部分應該是根據應用程式程式碼的資源需求和預期的使用特性,達到有效率的自動調整設定。
    • 針對生產環境部署,請考慮支援自動調整的進階層,讓平台自動處理調整決策。
  • 如果您需要更高的服務層級或 SQL 資料庫效能等級,請遵循擴大個別資料庫而無需應用程式停機的指引

部署此案例

此指引是由在 Azure 上展示基本 App Service 實作的範例實作所支援。

下一步

產品文件:

Microsoft Learn 模組: