在 Azure App Service 中設定預備環境

發行項
02/10/2023

將 Web 應用程式、Linux 上的 Web 應用程式、行動後端或 API 應用程式部署至 Azure App Service 時，若您在標準、進階或隔離式 App Service 方案層執行，就使用獨立的部署位置，而非預設的生產位置。部署位置為具備自身主機名稱的即時應用程式。兩個部署位置 (包括生產位置) 之間的應用程式內容與設定項目可以互相交換。

將應用程式部署至非生產位置具有下列優點：

您可以先驗證預備部署位置中的應用程式變更，再將它與生產位置進行交換。
先將應用程式部署至某個位置，然後再將它交換到生產位置，可確保該位置的所有執行個體在交換到生產位置之前都已準備就緒。這麼做可以排除部署應用程式時的停機情況。流量能夠順暢地重新導向，且不會因為交換作業而捨棄任何要求。不需要預先交換驗證時，您可以藉由設定自動交換來自動化整個工作流程。
交換之後，先前具有預備應用程式的位置，現在已經有之前的生產應用程式。若交換到生產位置的變更不是您需要的變更，您可以立即執行相同的交換，以恢復「上一個已知的良好網站」。

每個 App Service 方案層所支援的部署位置個數都不一樣。使用部署位置不需額外費用。若要找出應用程式層支援的位置個數，請參閱 App Service 限制。

若要將您的應用程式調整到不同層，請確認目標層支援應用程式已使用的位置數。例如，如果您的應用程式具有五個以上的位置，您無法將其向下調整至標準層，因為標準層只支援五個部署位置。

新增位置

應用程式必須在 [標準]、[進階] 或 [隔離] 層中執行，您才能啟用多個部署位置。

在 Azure 入口網站中，搜尋並選取 [應用程式服務]，再選取您的應用程式。
在左窗格中，選取 [部署位置]>[新增位置]。

注意

如果應用程式尚未處於標準、進階或隔離式層，您將會收到訊息，指出可啟用預備發佈的支援層。此時，您可以選取 [升級]，前往應用程式的 [級別] 索引標籤後再繼續。
在 [新增位置] 對話方塊中指定位置名稱，然後選取是否要複製其他部署位置的應用程式設定。選取 [新增] 繼續操作。

您可以從任何現有位置複製設定。可複製的設定包括應用程式設定、連接字串、語言架構版本、Web 通訊端、HTTP 版本和平台位元。

注意

目前，私人端點不會跨位置複製。

新增位置之後，請選取 [關閉] 以關閉對話方塊。此時新的位置會顯示在 [部署位置] 頁面中。根據預設，新位置的 [流量百分比] 會設為 0，且所有客戶流量都會路由至生產位置。
選取新的部署位置，開啟該位置的資源頁面。

預備位置和任何其他 App Service 應用程式一樣，具有管理頁面。您可以變更位置的組態。為了提醒您目前正在檢視部署位置，應用程式名稱會顯示為 <應用程式名稱>/<位置名稱>，而應用程式類型為 App Service (位置)。您也可以將位置視為資源群組中的獨立應用程式，且具有相同的指定名稱。
在位置的資源頁面中選取應用程式 URL。部署位置有自己的主機名稱，同時也是作用中的應用程式。若要限制公開存取部署位置，請參閱 Azure App Service IP 限制。

新的部署位置中沒有任何內容，即使您複製其他位置的設定，仍是如此。例如，您可以使用 Git 發佈至此位置。您可以從不同的存放庫分支或不同的存放庫部署至位置。從 Azure App 服務取得發行設定檔，可以提供部署至位置的必要資訊。 Visual Studio 可以匯入設定檔，以將內容部署至位置。

位置的 URL 格式為 http://sitename-slotname.azurewebsites.net。為了讓 URL 長度維持在必要的 DNS 限制內，網站名稱會在第 40 個字元截斷，位置名稱則會在第 19 個字元截斷，且會附加額外 4 個隨機字元，以確保產生的網域名稱是唯一的。

交換期間發生的情況

交換作業步驟

將兩個位置交換 (通常從預備位置交換到生產位置) 時，App Service 會執行下列動作，確保目標位置不會發生停機狀況：

將下列設定從目標位置 (如生產位置) 套用至來源位置的所有執行個體：
- 位置專屬應用程式設定及連接字串 (如果適用)。
- 持續部署設定 (如已啟用)。
- App Service 驗證設定 (如已啟用)。
上述任一案例都會致使來源位置中的所有執行個體重新啟動。在使用預覽交換期間，這會指出第一個階段的結尾。交換作業會暫停，您可以驗證來源位置是否能夠與目標位置的設定正確搭配運作。
等候來源位置中的每個執行個體重新啟動。如果有任何執行個體無法重新啟動，交換作業將會還原對來源位置的所有變更，並停止作業。
如果已啟用本機快取，請對來源位置每個執行個體上的應用程式根目錄 (「/」) 發出 HTTP 要求，以觸發本機快取初始化。請等候每個執行個體傳回任何 HTTP 回應。本機快取初始化會致使每個執行個體再次執行重新啟動。
如果啟用自動交換並設定了自訂準備動作，請對來源位置每個執行個體的應用程式根目錄 (「/」) 發出 HTTP 要求，以觸發應用程式初始化。

若未指定 applicationInitialization，請在每個執行個體上對來源位置的應用程式根目錄觸發 HTTP 要求。

執行個體若傳回了任何 HTTP 回應，即會被視為已準備就緒。
如果成功準備來源位置上的所有執行個體，請交換兩個位置的路由規則，交換這兩個位置。完成此步驟後，目標位置 (例如生產位置) 就會有先前已在來源位置準備就緒的應用程式。
既然來源位置有先前已在目標位置中預先交換的應用程式，請套用所有設定並重新啟動執行個體，藉此執行相同的作業。

在交換作業的任何時間點，所有對交換的應用程式進行初始化的工作都會在來源位置上執行。無論交換成功或失敗，在來源位置進行準備和準備就緒時，目標位置都會保持線上狀態。若要交換預備位置與生產位置，請確定生產位置一律為目標位置。如此，交換作業就不會對生產應用程式產生影響。

注意

先前生產位置中的執行個體 (此交換作業之後要交換到預備位置的執行個體) 會在交換程序的最後一個步驟中快速回收。如果您的應用程式中有任何長時間執行的作業，背景工作回收時會捨棄這些作業。這也適用於函數應用程式。因此，您的應用程式程式碼應該以容錯方式撰寫。

哪些設定已交換？

當您複製其他部署位置的組態時，可以編輯複製的組態。某些設定元素在交換時會保有內容 (非位置特定)，而其他組態元素則會在交換之後保留於同一個位置中 (位置特定)。以下清單顯示當您交換位置時會變更的設定。

交換的設定：

一般設定，例如 Framework 版本、32/64 位元、Web 通訊端
應用程式設定 (可以設定為停在某一個位置)
連接字串 (可以設定為停在某一個位置)
處理常式對應
公開憑證
WebJobs 內容
混合式連線 *
服務端點 *
Azure 內容傳遞網路 *
路徑的對應

標記星號 (*) 的功能計劃為不進行交換。

無法交換的設定：

發行端點
自訂網域名稱
非公用憑證與 TLS/SSL 設定
調整大小設定
WebJobs 排程器
IP 限制
永遠開啟
診斷設定
跨原始來源資源分享 (CORS)
虛擬網路整合
受控識別
尾碼為 _EXTENSION_VERSION 的設定

注意

若要將上述設定設為可交換，請在應用程式的每個位置新增應用程式設定 WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS，並將值設為 0 或 false。這些設定為全部可交換或完全無法交換。您無法只讓部分設定可交換，而其他設定無法交換。受控識別一律不會交換，且不受此覆寫應用程式設定的影響。

套用至未交換設定的某些應用程式設定也不會交換。例如，由於診斷設定未交換，因此 WEBSITE_HTTPLOGGING_RETENTION_DAYS 和 DIAGNOSTICS_AZUREBLOBRETENTIONDAYS 等相關應用程式設定也不會交換，即使沒有顯示為位置設定也一樣。

若要將應用程式設定或連接字串設為綁定特定位置 (未交換)，請前往該位置的 [設定] 頁面。新增或編輯設定，然後選取 [部署位置設定]。選取此核取方塊，會向 App Service 指出設定是無法交換的。

位置設定

交換兩個位置

您可以在應用程式的 [部署位置] 頁面和 [概觀] 頁面上交換部署位置。如需位置交換的技術詳細資料，請參閱交換期間發生的情況。

重要

將應用程式從部署位置交換至生產環境之前，請確定生產環境是您的目標位置，且來源位置中的所有設定都完全依照其在生產環境中的預定方式設定。

若要交換部署位置：

移至應用程式的 [部署位置] 頁面，然後選取 [交換]。

[交換] 對話方塊會顯示將要變更的所選來源和目標位置中的設定。
選取所需的 [來源] 和 [目標] 位置。目標通常是生產位置。此外，請選取 [來源變更] 和 [目標變更] 索引標籤，並確認設定變更如預期。完成之後，選取 [交換] 即可立即交換位置。

若要在真正執行交換之前查看您的目標位置在使用新設定時將如何執行，請不要選取 [交換]，而是依照使用預覽進行交換中的指示操作。
完成之後，選取 [關閉] 以關閉對話方塊。

如果有任何問題，請參閱針對交換進行疑難排解。

使用預覽交換 (多階段交換)

在交換到生產環境中當作目標位置前，請驗證應用程式以交換後的設定執行。來源位置也會先進行準備工作再完成交換，這也正是任務關鍵性應用程式所需。

使用預覽執行交換時，App Service 會執行相同的交換作業，但在完成第一個步驟後會先暫停。接著，您可以先確認預備位置上的結果，再完成交換。

如果您取消交換，App Service 會將設定元素重新套用至來源位置。

注意

當其中一個位置已啟用網站驗證時，無法使用與預覽交換。

若要使用預覽交換：

依照交換部署位置中的步驟操作，但選取 [使用預覽執行交換]。

此對話方塊會顯示來源位置中的設定如何在階段 1 變更，以及來源和目標位置如何在階段 2 變更。
準備好開始交換時，請選取 [開始交換]。

階段 1 完成時，您會在對話方塊中收到通知。移至 https://<app_name>-<source-slot-name>.azurewebsites.net 可預覽來源位置中的交換情形。
準備好完成擱置的交換時，請在 [交換動作] 中選取 [完成交換]，然後選取 [完成交換]。

若要取消擱置的交換，請改為選取 [取消交換]。
完成之後，選取 [關閉] 以關閉對話方塊。

如果有任何問題，請參閱針對交換進行疑難排解。

若要自動執行多階段交換，請參閱使用 PowerShell 自動執行。

復原交換

在交換位置後，若目標位置 (例如生產位置) 發生任何錯誤，請立即交換相同的兩個位置，將位置還原成交換前的狀態。

設定自動交換

注意

Linux 和適用於容器的 Web App 不支援自動交換。

如果您希望為應用程式的客戶持續部署您的應用程式，而不需冷啟動和不需關機，「自動交換」將可簡化此類 Azure DevOps 案例。啟用從原來位置自動交換至生產位置後，每當您將程式碼變更推送至該位置時，App Service 就會在於來源位置做好準備後，自動將該應用程式交換至生產位置。

注意

在為生產位置設定自動交換之前，請考慮先在非實際執行目標位置上測試自動交換。

若要設定自動交換：

前往應用程式的資源頁面。選取 [部署位置]><指定來源位置>>[設定]>[一般設定]。
在 [啟用自動交換] 選取 [開啟]。然後為 [自動交換部署位置] 選取所需的目標位置，然後選取命令列上的 [儲存]。
執行推送至來源位置的程式碼。自動交換不久之後就會發生，而更新會反映於目標位置的 URL。

如果有任何問題，請參閱針對交換進行疑難排解。

指定自訂準備

某些應用程式在交換之前可能需執行自訂的準備動作。 web.config 中的 applicationInitialization 設定元素可讓您指定自訂初始化動作。交換作業會等到此自訂準備動作完成後，再與目標位置進行交換。以下是範例 web.config 片段。

<system.webServer>
    <applicationInitialization>
        <add initializationPage="/" hostName="[app hostname]" />
        <add initializationPage="/Home/About" hostName="[app hostname]" />
    </applicationInitialization>
</system.webServer>

如需自訂 applicationInitialization 元素的詳細資訊，請參閱最常見的部署位置交換失敗，以及如何加以修正。

您也可以使用下列一或兩個應用程式設定來自訂準備動作：

WEBSITE_SWAP_WARMUP_PING_PATH：透過 HTTP Ping 此路徑以準備網站。請指定開頭為斜線的自訂路徑作為值，以新增此應用程式設定。例如 /statuscheck。預設值是 /。
WEBSITE_SWAP_WARMUP_PING_STATUSES：準備作業的有效 HTTP 回應碼。請以 HTTP 代碼的逗號分隔清單方式新增此應用程式設定。例如 200,202。如果傳回的狀態碼不在清單中，準備和交換作業就會停止。預設是所有回應碼都有效。
WEBSITE_WARMUP_PATH：每當網站重新啟動 (不只是在位置交換期間) 都應 Ping 的網站相對路徑。範例值包括 /statuscheck，或根路徑 /。

注意

<applicationInitialization> 設定元素屬於每個應用程式啟動作業的一部分，而兩個準備動作應用程式設定只適用於位置交換。

如果有任何問題，請參閱針對交換進行疑難排解。

監視交換作業

如果交換作業耗時很久才完成，您可以在活動記錄中取得交換作業的相關資訊。

在入口網站中的應用程式資源頁面上，選取左窗格中的 [活動記錄]。

交換作業在記錄查詢中會顯示為 Swap Web App Slots。您可以展開它，然後選取其中一個子作業或錯誤，以查看詳細資料。

路由流量

根據預設，對應用程式生產 URL (http://<app_name>.azurewebsites.net) 的所有用戶端要求都會路由至生產位置。您可以將部分流量路由至其他位置。如果您需要使用者針對新的更新提供意見反應，但尚未準備好要將更新發行至生產環境，這項功能將有其效用。

自動路由生產流量

若要自動路由傳送生產流量：

移至應用程式的資源頁面，然後選取 [部署位置]。
針對您要路由到的位置，在其 [流量百分比] 資料行中指定百分比 (介於 0 到 100 之間)，以代表您要路由的總流量。選取 [儲存]。

儲存設定之後，即會將用戶端的指定百分比隨機路由傳送至非生產位置。

用戶端自動路由傳送至特定位置之後，其會「釘選」到該位置一小時，或直到刪除 Cookie 為止。用戶端瀏覽器中，您可以查看 HTTP 標頭中的 x-ms-routing-name Cookie，以確認您的工作階段固定到哪個位置。路由至「預備」位置的要求具有 Cookie x-ms-routing-name=staging。路由至生產位置的要求具有 Cookie x-ms-routing-name=self。

注意

您也可以在 Azure CLI 中使用 az webapp traffic-routing set 命令，從 CI/CD 工具 (例如 GitHub Actions、DevOps 管線或其他自動化系統) 設定路由百分比。

手動路由生產流量

除了自動流量路由以外，App Service 也可以將要求路由至特定位置。您想要讓使用者能夠加入或退出您的搶鮮版 (Beta) 應用程式時，這就很實用。若要手動路由生產流量，您可以使用 x-ms-routing-name 查詢參數。

例如，若要讓使用者選擇退出您的搶鮮版 (Beta) 應用程式，您可以在網頁上放入此連結：

<a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>

字串 x-ms-routing-name=self 會指定生產位置。用戶端瀏覽器在存取該連結之後，即會重新導向至生產位置。每個後續要求都具有 x-ms-routing-name=self Cookie，可將工作階段釘選到生產位置。

若要讓使用者選擇加入您的搶鮮版 (Beta) 應用程式，請將相同的查詢參數設定為非生產位置的名稱。以下為範例：

<webappname>.azurewebsites.net/?x-ms-routing-name=staging

根據預設，系統會提供 0% 的路由規則給新的位置，以灰色顯示。若您明確將此值設為 0% (以黑色文字顯示)，您的使用者就可以使用 x-ms-routing-name 查詢參數來手動存取預備位置。但不會將其自動路由傳送至位置，因為路由傳送百分比設定為 0。這是進階案例，在其中，您可以在允許內部小組測試位置上的變更時，「隱藏」您的預備位置不讓其他人看到。

刪除位置

搜尋並選取您的應用程式。選取 [部署位置]><要刪除的位置>>[概觀]。應用程式類型會顯示為 App Service (位置)，提醒您正在檢視部署位置。刪除位置之前，請務必停止位置，並將位置中的流量設定為零。在命令列上選取 [刪除]。

刪除部署位置

使用 PowerShell 自動執行

注意

建議您使用 Azure Az PowerShell 模組來與 Azure 互動。請參閱安裝 Azure PowerShell 以開始使用。若要瞭解如何遷移至 Az PowerShell 模組，請參閱將 Azure PowerShell 從 AzureRM 遷移至 Az。

Azure PowerShell 模組提供透過 Windows PowerShell 來管理 Azure 的 Cmdlet，包括支援管理 Azure App Service 中的部署位置。

如需安裝與設定 Azure PowerShell，以及使用您的 Azure 訂用帳戶驗證 Azure PowerShell 的詳細資訊，請參閱如何安裝和設定 Microsoft Azure PowerShell(英文)。

建立 Web 應用程式

New-AzWebApp -ResourceGroupName [resource group name] -Name [app name] -Location [location] -AppServicePlan [app service plan name]

建立位置

New-AzWebAppSlot -ResourceGroupName [resource group name] -Name [app name] -Slot [deployment slot name] -AppServicePlan [app service plan name]

啟動使用預覽進行交換 (多階段交換)，並將目的地位置設定套用至來源位置

$ParametersObject = @{targetSlot  = "[slot name – e.g. "production"]"}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action applySlotConfig -Parameters $ParametersObject -ApiVersion 2015-07-01

取消擱置中的交換 (使用預覽進行交換)，並還原來源位置設定

Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action resetSlotConfig -ApiVersion 2015-07-01

交換部署位置

$ParametersObject = @{targetSlot  = "[slot name – e.g. "production"]"}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action slotsswap -Parameters $ParametersObject -ApiVersion 2015-07-01

監視活動記錄中的交換事件

Get-AzLog -ResourceGroup [resource group name] -StartTime 2018-03-07 -Caller SlotSwapJobProcessor

刪除位置

Remove-AzResource -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots –Name [app name]/[slot name] -ApiVersion 2015-07-01

若要從生產位置執行位置交換，身分識別需要 (至少需要) 執行 Microsoft.Web/sites/slotsswap/Action 作業的權限。如需詳細資訊，請參閱資源提供者作業

透過 Resource Manager 範本自動化

Azure Resource Manager 範本是用來自動化 Azure 資源部署和設定的宣告式 JSON 檔案。若要使用 Resource Manager 範本交換位置，需要在 Microsoft.Web/sites/slots 和 Microsoft.Web/sites 資源上設定兩個屬性：

buildVersion：這是字串屬性，代表部署在位置中的應用程式目前版本。例如：「v1」、「1.0.0.1」或「2019-09-20T11:53:25.2887393-07:00」。
targetBuildVersion：這是字串屬性，指定位置應有的 buildVersion。如果 targetBuildVersion 不等於目前的 buildVersion，便會尋找具有指定 buildVersion 的位置來觸發交換作業。

Resource Manager 範本的範例

下列 Resource Manager 範本會更新預備位置的 buildVersion，並在生產位置上設定 targetBuildVersion。如此一來會交換這兩個位置。此範本假設您已經使用名為「staging」的位置建立了一個 Web 應用程式。

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "my_site_name": {
            "defaultValue": "SwapAPIDemo",
            "type": "String"
        },
        "sites_buildVersion": {
            "defaultValue": "v1",
            "type": "String"
        }
    },
    "resources": [
        {
            "type": "Microsoft.Web/sites/slots",
            "apiVersion": "2018-02-01",
            "name": "[concat(parameters('my_site_name'), '/staging')]",
            "location": "East US",
            "kind": "app",
            "properties": {
                "buildVersion": "[parameters('sites_buildVersion')]"
            }
        },
        {
            "type": "Microsoft.Web/sites",
            "apiVersion": "2018-02-01",
            "name": "[parameters('my_site_name')]",
            "location": "East US",
            "kind": "app",
            "dependsOn": [
                "[resourceId('Microsoft.Web/sites/slots', parameters('my_site_name'), 'staging')]"
            ],
            "properties": {
                "targetBuildVersion": "[parameters('sites_buildVersion')]"
            }
        }        
    ]
}

此 Resource Manager 範本是等冪的，表示它可以重複執行，並產生相同的位置狀態。第一次執行後，targetBuildVersion 會比對目前的 buildVersion，因此不會觸發交換。

使用 CLI 進行自動化

如需適用於部署位置的 Azure CLI 命令，請參閱 az webapp deployment slot。

針對交換進行疑難排解

如果在位置交換期間發生任何錯誤，便會記錄在 D:\home\LogFiles\eventlog.xml 中。同時也會記錄在應用程式專屬的錯誤記錄檔中。

以下是一些常見的交換錯誤：

傳至應用程式根目錄的 HTTP 要求逾時。交換作業會為每個 HTTP 要求等候 90 秒，並重試最多 5 次。如果所有重試都會逾時，交換作業就會停止。
當應用程式內容超過為本機快取指定的本機磁碟配額時，本機快取初始化可能會失敗。如需詳細資訊，請參閱本機快取概觀。
執行自訂準備動作期間，HTTP 要求會在內部進行 (不會通過外部 URL)。它們可能會因為 Web.config 中的某些 URL 重寫規則而失敗。例如，重新導向網域名稱或強制執行 HTTPS 的規則，可能會導致準備要求無法傳至應用程式程式碼。若要解決此問題，請新增下列兩個條件來修改重寫規則：
```
<conditions>
  <add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
  <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
  ...
</conditions>
```
如果沒有自訂準備動作，URL 重寫規則仍然可能阻擋 HTTP 要求。若要解決此問題，請新增下列條件來修改重寫規則：
```
<conditions>
  <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
  ...
</conditions>
```
位置交換之後，應用程式可能會發生非預期的重新啟動。這是因為進行交換之後，主機名稱繫結設定停止同步，但這個其況本身並不會造成重新啟動。不過某些基本儲存體事件 (例如儲存體磁碟區容錯移轉) 可能會偵測到這些差異，而強制所有背景工作程序重新啟動。若要盡可能減少這類重新啟動情形發生，請在所有位置上設定 WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 應用程式設定。不過，此應用程式設定不適用於 Windows Communication Foundation (WCF) 應用程式。

下一步

封鎖對非生產位置的存取

在 Azure App Service 中設定預備環境

新增位置

交換期間發生的情況

交換作業步驟

哪些設定已交換？

交換兩個位置

使用預覽交換 (多階段交換)

復原交換

設定自動交換

指定自訂準備

監視交換作業

路由流量

自動路由生產流量

手動路由生產流量

刪除位置

使用 PowerShell 自動執行

建立 Web 應用程式

建立位置

啟動使用預覽進行交換 (多階段交換)，並將目的地位置設定套用至來源位置

取消擱置中的交換 (使用預覽進行交換)，並還原來源位置設定

交換部署位置

監視活動記錄中的交換事件

刪除位置

透過 Resource Manager 範本自動化

Resource Manager 範本的範例

使用 CLI 進行自動化

針對交換進行疑難排解

下一步

其他資源

其他資源