共用方式為

管理 App Service 環境

  • 發行項

重要

本文說明隔離式 App Service 方案搭配使用的 App Service 環境 v2 相關資訊。 App Service 環境 v1 和 v2 自 2024 年 8 月 31 日起已淘汰 (英文)。 有較新版本的 App Service 環境，其更易於使用，並且是在更強大的基礎結構上執行。 若要深入了解新版本，請從 App Service 環境簡介開始。 如果您目前使用 App Service 環境 v1，請遵循此文章中的步驟來移轉至新版本。

自 2024 年 8 月 31 日起，服務等級協定 (SLA) 和服務點數 (英文) 將不再適用於繼續在生產環境中的 App Service 環境 v1 和 v2 工作負載，因為其是已淘汰的產品。 App Service 環境 v1 和 v2 硬體的解除委任已經開始，而這可能會影響您的應用程式和資料的可用性和效能。

您必須立即完成移轉至 App Service 環境 v3，否則您的應用程式和資源可能會被刪除。 我們會嘗試使用就地移轉功能，自動移轉任何剩餘的 App Service 環境 v1 和 v2，但 Microsoft 對自動移轉後應用程式的可用性不做任何聲明或保證。 您可能需要執行手動設定來完成移轉，並最佳化您的 App Service 方案 SKU 選擇，以符合您的需求。 如果自動移轉不可行，您的資源和相關聯的應用程式資料將被刪除。 我們強烈敦促您立即採取行動，以避免上述任一極端案例。

如果您需要額外的時間，我們可以提供一次性 30 天的寬限期，讓您完成移轉。 如需詳細資訊和申請寬限期，請檢閱寬限期概觀 (英文)，然後移至 Azure 入口網站，造訪每個 App Service 環境的窗格。

如需 App Service 環境 v1/v2 淘汰的最新資訊，請參閱 App Service 環境 v1 和 v2 淘汰更新。

App Service 環境 (ASE) 是將 Azure App Service 部署至客戶的 Azure 虛擬網路執行個體中的子網路。 ASE 包含:

  • 前端：App Service 環境中 HTTP/HTTPS 終止的位置
  • 背景工作角色：裝載應用程式的資源
  • 資料庫：存放定義環境的資訊
  • 儲存體：用來裝載客戶發佈的應用程式

您可以使用外部或內部虛擬 IP (VIP) 來部署 ASE，以存取應用程式。 具有外部 VIP 的部署通常稱為 外部 ASE。 具有內部 VIP 的部署稱為 ILB ASE，因為它使用內部負載平衡器 (ILB)。 若要深入了解 ILB ASE，請參閱建立和使用 ILB ASE。

在 ASE 中建立應用程式

若要在 ASE 中建立應用程式，請使用與一般建立應用程式時相同的程序，但有一些小差異。 當您建立新的 App Service 方案時:

  • 不選擇部署應用程式的地理位置，而是選擇 ASE 作為位置。
  • 在 ASE 中建立的所有 App Service 方案只能位於隔離式定價層中。

如果您沒有 ASE，則可以遵循建立 App Service Environment 中的指示來建立一個 ASE。

若要在 ASE 中建立應用程式:

  1. 選取 [建立資源]> [Web + 行動]> [Web 應用程式]。

  2. 輸入應用程式的名稱。 如果您已在 ASE 中選取 App Service 方案，則應用程式的網域名稱會反映 ASE 的網域名稱:

    選取應用程式名稱

  3. 選取訂閱。

  4. 輸入新資源群組的名稱，或選取 [使用現有] 並從下拉式清單中挑選一個。

  5. 選取您的作業系統。

  6. 在 ASE 中選取現有的 App Service 方案，或依照下列步驟建立新的方案:

    a. 從 Azure 入口網站的左側功能表中，選取 [建立資源 > Web 應用程式]。

    b. 選取訂用帳戶。

    c. 選取或建立資源群組。

    d. 輸入您 Web 應用程式的名稱。

    e. 選取 [程式碼] 或 [DockerContainer]。

    f. 選取執行階段堆疊。

    .g 選取 [Linux] 或 [Windows]。

    h. 在 [區域] 下拉式清單中選取您的 ASE。

    i. 選取或建立新的 App Service 方案時。 如果建立的是新 App Service方案，請選取適當的隔離 SKU 大小。

    隔離定價層

    注意

    Linux 應用程式和 Windows 應用程式不能在相同的 App Service 方案中，但兩者可位於相同的 App Service 環境中。

  7. 選取 [檢閱 + 建立]、確定資訊正確無誤，然後選取 [建立]。

規模調整的運作方式

每個 App Service 應用程式都會在一個 App Service 方案中執行。 App Service 環境會保留 App Service 方案，而 App Service 方案則保留應用程式。 當您調整應用程式的大小時，您也會調整 App Service 方案和相同方案中的所有應用程式的大小。

當您調整 App Service 方案的大小時，系統會自動新增所需的基礎結構。 當系統新增基礎結構時，調整作業會有時間延遲。 如果您依序執行數個調整作業，則系統會處理第一個基礎結構調整要求，而其他的基礎結構調整要求則會排入佇列。 第一次調整作業完成時，其他基礎結構會要求全部一起作業。 新增基礎結構時，系統會視需要指派 App Service 方案。 建立新的 App Service 方案本身是調整作業，因為它會要求額外的硬體。 調整作業通常需要 30-60 分鐘才能完成。 進行中的升級作業也會封鎖調整動作。

在多租用戶 App Service 中，調整為立即作業，因為資源集區可隨時提供支援。 在 ASE 中，沒有這類緩衝區，而且系統會根據需求配置資源。

在 ASE 中，您可以調整 App Service 方案多達 100 個執行個體。 ASE 在該 ASE 的所有 App Service 方案中，最多可以有 201 個執行個體總數。

IP 位址

App Service 可以將專用的 IP 位址設定給應用程式。 設定以 IP 為基礎的 TLS/SSL 繫結之後，就可以使用這項功能，如將現有的自訂 TLS/SSL 憑證繫結至 Azure App Service 中所述。 在 ILB ASE 中，您無法新增更多要用於以 IP 為基礎 TLS/SSL 繫結的 IP 位址。

使用外部 ASE，您可以設定應用程式的 IP 型 TLS/SSL 繫結，就像在多租用戶 App Service 中一樣。 ASE 中一律有一個備用位址，最多 30 個 IP 位址。 每次您使用一個位址時，系統都會新增另一個位址，以便位址隨時都可供使用。 配置另一個 IP 位址需要時間延遲。 該延遲可以防止快速連續新增 IP 位址。

前端調整

當您相應擴增 App Service 方案時，系統會自動新增背景工作角色以支援這些方案。 每個 ASE 都會使用兩個前端來建立。 前端會依據每一組 15 個 App Service 方案執行個體搭配一個前端的比例自動擴增。 例如，如果您的 App Service 方案各有五個執行個體，則總共有 15 個執行個體和三個前端。 如果您調整為共 30 個執行個體，則有四個前端。 隨著您相應擴增，系統會繼續進行此模式。

預設配置的前端數目適合適中的負載。 您可以針對每五個執行個體將比例降低為一個前端。 您也可以變更前端的大小。 根據預設，它們是單一核心。 在 Azure 入口網站中，您可以改為將其大小變更為兩或四個核心。

變更比例或前端大小會收取費用。 如需詳細資訊，請參閱 Azure App Service 價格。 如果您想要改善 ASE 的負載容量，請先調整為兩核心前端，再調整縮放比例，以取得更多改善。 變更前端的核心大小會導致 ASE 升級，而且應在一般上班時間外的時間進行。

前端資源是 ASE 的 HTTP/HTTPS 端點。 使用預設前端設定時，每個前端的記憶體使用量一致為 60% 左右。 調整前端的主要原因是 CPU 使用量，這主要由 HTTPS 流量所驅動。

應用程式存取

在外部 ASE 中，用於應用程式建立的網域後綴為 .<asename>.p.azurewebsites.net。 如果您的 ASE 名為 external-ase，而且您在該 ASE 中裝載名為 contoso 的應用程式，則這些 URL 將可連至該應用程式：

  • contoso.external-ase.p.azurewebsites.net
  • contoso.scm.external-ase.p.azurewebsites.net

如需關於如何建立外部 ASE 的資訊，請參閱建立 App Service 環境。

在 ILB ASE 中，用於應用程式建立的網域尾碼為 .<asename>.appserviceenvironment.net。 如果您的 ASE 名為 ilb-ase，而且您在該 ASE 中裝載名為 contoso 的應用程式，則這些 URL 將可連至該應用程式：

  • contoso.ilb-ase.appserviceenvironment.net
  • contoso.scm.ilb-ase.appserviceenvironment.net

如需關於如何建立 ILB ASE 的資訊，請參閱建立並使用 ILB ASE。

SCM URL 用來存取 Kudu 主控台，或可利用 Web Deploy 發佈您的應用程式。 Kudu 控制台提供 Web UI 以進行偵錯、上傳檔案、編輯檔案等等。

DNS 組態

當您使用外部 ASE 時，在 ASE 中建立的應用程式會使用 Azure DNS 註冊。 然後，外部 ASE 中沒有任何其他步驟可供您的應用程式公開使用。 使用 ILB ASE 時，您必須管理您自己的 DNS。 您可以在自己的 DNS 伺服器中或使用 Azure DNS 私人區域執行此動作。

若要使用 ILB ASE 在您自己的 DNS 伺服器中設定 DNS:

  1. 建立 <ASE 名稱>.appserviceenvironment.net 的區域
  2. 在該區域中建立將 * 指向 ILB IP 位址的 A 記錄
  3. 在該區域中建立將 @ 指向 ILB IP 位址的 A 記錄
  4. 在名為 scm 的 <ASE name>.appserviceenvironment.net 中建立區域
  5. 在 scm 區域中建立將 * 指向 ILB IP 位址的 A 記錄

若要在 Azure DNS 私人區域中設定 DNS:

  1. 建立名為 <ASE name>.appserviceenvironment.net 的 Azure DNS 私人區域
  2. 在該區域中建立將 * 指向 ILB IP 位址的 A 記錄
  3. 在該區域中建立將 @ 指向 ILB IP 位址的 A 記錄
  4. 在該區域中建立將 *scm 指向 ILB IP 位址的 A 記錄

ASE 預設網域後綴的 DNS 設定不會限制您的應用程式只能由這些名稱存取。 您可以在 ILB ASE 中設定自訂網域名稱，而無需對您的應用程式進行任何驗證。 如果您想要建立名為 contoso.net 的區域，則可以這麼做，並將其指向 ILB IP 位址。 自訂網域名稱適用於應用程式要求，但不適用於 scm 網站。 SCM 網站僅在 <appname>.scm.<asename>.appserviceenvironment.net 上提供使用。

名為 .<asename>.appserviceenvironment.net 的區域是全域唯一的。 在 2019 年 5 月之前，客戶能夠指定 ILB ASE 的網域後綴。 如果想要使用 .contoso.com 作為網域尾碼，您可以這麼做，但將會包含 SCM 網站。 該模型存在挑戰，包括: 管理預設 TLS/SSL 憑證、使用 scm 網站缺乏單一登錄，以及使用萬用字元憑證的需求。 ILB ASE 預設憑證升級程序也會造成干擾，並導致應用程式重新啟動。 為了解決這些問題，ILB ASE 行為已變更為根據 ASE 的名稱和使用 Microsoft 擁有的後綴使用網域後綴。 ILB ASE 行為的變更只會影響 2019 年 5 月之後進行的 ILB ASE。 預先存在的 ILB ASE 仍必須管理 ASE 及其 DNS 設定的預設憑證。 如果您的 ILB ASE V2 是在 2019 年 5 月之後建立的，您就不需要管理 ILB 預設憑證，因為其是由 Microsoft 管理。

發佈

在 ASE 中，如同多租用戶 App Service，您可以透過下列方法發佈:

  • Web 部署
  • FTP
  • 持續整合 (CI)
  • 在 Kudu 主控台中拖放
  • IDE，例如 Visual Studio、Eclipse 或 IntelliJ IDEA

使用外部 ASE 時，這些發佈選項的運作方式都相同。 如需詳細資訊，請參閱在 Azure App Service 中部署。

使用 ILB ASE 時，發佈端點只能透過 ILB 取得。 ILB 位於虛擬網路中 ASE 子網路的私人 IP 上。 如果您沒有 ILB 的網路存取權，就無法在該 ASE 上發佈任何應用程式。 如建立和使用 ILB ASE 中所述，您必須在系統中設定應用程式的 DNS。 該需求包括 SCM 端點。 如果端點未正確定義，則無法發佈。 您的 IDE 也必須具有 ILB 的網路存取權，才能直接發佈至 ILB。

如果沒有其他變更，GitHub 和 Azure DevOps 之類的網際網路型 CI 系統將無法使用 ILB ASE，因為發佈端點無法存取網際網路。 您可以在包含 ILB ASE 的虛擬網路中安裝自我裝載發行代理程式，以從 Azure DevOps 發佈至 ILB ASE。 或者，您也可以使用使用提取模型的 CI 系統，例如 Dropbox。

ILB ASE 中應用程式的發佈端點會使用 ILB ASE 建立的網域。 您可以在應用程式的發行設定檔，以及應用程式的入口網站窗格中看到 (在 [概觀] > [基本資訊]，以及 [屬性] 中)。

儲存體

ASE 針對 ASE 中的所有應用程式都提供 1 TB 的記憶體。 隔離式定價 SKU 中的 App Service 方案限製為 250 GB。 在 ASE 中，每個 App Service 方案最多會新增 250 GB 的記憶體，上限為 1 TB。 您可以擁有超過四個 App Service 方案，但針對超過 1 TB 限制的記憶體，則不會再新增更多記憶體。

監視

身為客戶，您應該監視 App Service 方案和執行中的個別應用程式，並採取適當的動作。 針對 App Service 環境 v2，您也應該注意平台基礎結構周圍的計量。 這些計量可讓您深入瞭解平台基礎結構和前端伺服器 (multiRole) 的運作方式，而且如果大量使用，同時您未獲得最大輸送量，則您可以採取動作。

透過 Azure 入口網站和 CLI，您可以為每個前端伺服器設定 5 到 15 (預設為 15) 個 App Service 方案執行個體之間的縮放比例。 App Service 環境一律至少有兩部前端伺服器。 您也可以增加前端伺服器的大小。

用來監視平台基礎結構的 計量範圍 稱為 Microsoft.Web/hostingEnvironments/multiRolePools。

您會看到名為 Microsoft.Web/hostingEnvironments/workerPools 的範圍。 此處的計量僅適用於 App Service 環境 v1。

記錄

您可以將 ASE 與 Azure 監視器整合，以將 ASE 的相關記錄傳送至 Azure 儲存體、Azure 事件中樞或 Log Analytics。 今天會記錄這些項目:

情況 訊息
ASE 狀況不良 由於虛擬網路設定無效，指定的 ASE 狀況不良。 如果狀況不良狀態繼續，系統將會暫止 ASE。 請確定這裡定義的指導方針已遵循：App Service 環境的網路考量。
ASE 子網路的空間幾乎不足 指定的 ASE 位於空間幾乎不足的子網路中。 還有 {0} 個剩餘的位址。 一旦這些位址耗盡，系統將無法調整 ASE 的大小。
ASE 即將接近總執行個體限制 指定的 ASE 即將接近 ASE 的總執行個體限制。 它目前包含最多 201 個執行個體的 {0} 個 App Service 方案執行個體。
ASE 無法連線到相依性 指定的 ASE 無法連線到 {0}。 請確定這裡定義的指導方針已遵循：App Service 環境的網路考量。
已暫止 ASE 指定的 ASE 已暫止。 ASE 暫停可能是因為帳戶短缺或虛擬網路設定無效所致。 解決根本原因並恢復 ASE 以繼續服務流量。
ASE 升級已啟動 已開始將平台升級至指定的 ASE。 預期調整作業發生延遲。
ASE 升級已完成 已完成將平台升級至指定的 ASE。
已啟動調整作業 已開始調整 App Service 方案 ({0})。 所需狀態:{1} I{2} 背景工作角色。
調整作業已完成 已完成調整 App Service 方案 ({0})。 目前的狀態:{1} I{2} 背景工作角色。
調整作業已失敗 無法調整 App Service 方案 ({0})。 目前的狀態:{1} I{2} 背景工作角色。

若要在您的 ASE 上啟用記錄:

  1. 在入口網站中，移至 [診斷設定]。
  2. 選取 [新增診斷設定]。
  3. 提供記錄整合的名稱。
  4. 選取並設定您想要的記錄目的地。
  5. 選取 [AppServiceEnvironmentPlatformLogs]。

ASE 診斷記錄設定

如果您與 Log Analytics 整合，則可以從 ASE 入口網站選取 [記錄]，然後針對 AppServiceEnvironmentPlatformLogs 建立查詢，以查看記錄。 只有當 ASE 有觸發記錄的事件時，才會發出記錄。 如果您的 ASE 沒有這類事件，就不會有任何記錄。 若要快速查看 Log Analytics 工作區中的記錄範例，請使用 ASE 中的其中一個 App Service 方案來執行調整作業。 然後，您可以針對 AppServiceEnvironmentPlatformLogs 執行查詢，以查看這些記錄。

建立警示

若要針對您的記錄建立警示，請遵循使用 Azure 監視器建立、檢視和管理記錄警示中的指示。 簡言之:

  • 在 ASE 入口網站中開啟 [警示] 頁面
  • 選取 [新增警示規則]
  • 選取您的 [資源] 作為 Log Analytics 工作區
  • 使用自訂記錄搜尋來設定條件，以使用類似 「AppServiceEnvironmentPlatformLogs」 的查詢 |其中 ResultDescription 包含「已開始調整」或您想要的任何項目。 適當地設定閾值。
  • 視需要新增或建立動作群組。 動作群組是您定義警示的回應之處，例如傳送電子郵件或簡訊
  • 為您的警示命名並加以儲存。

升級喜好設定

如果您有多個 ASE，您可能會想要先升級部分 ASE，再升級其他 ASE。 您可以透過 ASE 入口網站啟用此行為。 在 [設定] 下方，您可以選擇設定 [升級喜好設定]。 三個可能的值為:

  • 無：Azure 不會以任何特定批次升級您的 ASE。 這是預設值。
  • 早期:您的 ASE 將在 App Service 進行升級的上半部分升級。
  • 晚期:您的 ASE 將在 App Service 進行升級的下半部分升級。

選取所需的值，然後選取 [儲存]。 任何 ASE 的預設值為 [無]。

ASE 設定入口網站

當您有多個 ASE 時，[升級喜好設定] 功能最為適合，因為您的「早期」ASE 將在「晚期」ASE 之前升級。 當您有多個 ASE 時，應該將開發和測試 ASE 設定為「早期」，並將生產 ASE 設定為「晚期」。

定價

名稱為「隔離」的定價 SKU 僅供與 ASE 搭配使用。 裝載於 ASE 的所有 App Service 方案都位於隔離式定價 SKU 中。 App Service 方案的隔離式費率可能會因區域而異。

除了 App Service 方案的價格之外，ASE 本身還有一個一般費率。 一般費率不會隨著 ASE 的大小而變更。 它會針對每 15 個 App Service 方案執行個體，一個額外的前端之預設規模比例，為 ASE 基礎結構支付費用。

如果針對每 15 個 App Service 方案執行個體，一個前端之預設規模比例不夠快，您可以調整新增前端的比例或前端大小的比例。 當您調整比例或大小時，您需支付預設不會新增的前端核心。

例如，如果您將規模比例調整為 10，則 App Service 方案中每 10 個執行個體便會新增一個前端。 一般費用涵蓋每 15 個執行個體一個前端的規模比例。 規模比例為 10 時，您需為 10 個 App Service 方案執行個體新增的第三個前端支付費用。 當您達到 15 個執行個體時，您不需要支付費用，因為它會自動新增。

如果您將前端的大小調整為兩個核心，但不調整比例，則需支付額外的核心費用。 ASE 會建立兩個前端，因此，如果您將大小增加到兩核心前端，即使低於自動調整閾值，您也需支付兩個額外的核心費用。

如需詳細資訊，請參閱 Azure App Service 價格。

刪除 ASE

若要刪除 ASE:

  1. 請使用 [App Service Environment] 窗格頂端的 [刪除]。

  2. 輸入 ASE 的名稱，以確認您想要刪除它。 當您刪除 ASE 時，也會刪除其中的所有內容。

    ASE 刪除

  3. 選取 [確定]。

ASE CLI

有命令列功能可管理 ASE。 下方會說明 Azure CLI 命令。

C:\>az appservice ase --help

Group
    az appservice ase : Manage App Service Environments v2.
        This command group is in preview. It may be changed/removed in a future release.
Commands:
    create         : Create app service environment.
    delete         : Delete app service environment.
    list           : List app service environments.
    list-addresses : List VIPs associated with an app service environment.
    list-plans     : List app service plans associated with an app service environment.
    show           : Show details of an app service environment.
    update         : Update app service environment.

For more specific examples, use: az find "az appservice ase"