在 Azure App Service 中設定預備環境

當您在 Linux、行動後端或 API 應用程式上部署 Web 應用程式以Azure App 服務時,您可以在標準、進階版隔離式App Service方案層中執行時,使用個別部署位置,而不是預設生產位置。 部署位置是具有自己主機名稱的即時應用程式。 兩個部署位置 (包括生產位置) 之間的應用程式內容與設定項目可以互相交換。

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

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

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

若要將應用程式調整為不同的層級,請確定目標層支援您的應用程式已使用的位置數目。 例如,如果您的應用程式有五個以上的位置,則您無法將其縮減為 標準 層,因為 標準 層僅支援五個部署位置。

新增位置

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

  1. Azure 入口網站中,搜尋並選取 [應用程式服務],然後選取您的應用程式。

    Search for App Services

  2. 在左窗格中,選取[部署位置新增位置> ]。

    Add a new deployment slot

    注意

    如果應用程式尚未在標準進階版隔離層中,您會收到一則訊息,指出啟用分段發行的支援層。 此時,您可以選擇選取 [ 升級 ],然後移至應用程式的 [ 調整 ] 索引標籤,再繼續進行。

  3. 在 [ 新增位置 ] 對話方塊中,為位置指定名稱,然後選取是否要從另一個部署位置複製應用程式組態。 選取 [新增 ] 以繼續。

    Configuration source

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

注意

目前,VNET 和私人端點不會跨位置複製。

  1. 新增位置之後,選取 [ 關閉 ] 以關閉對話方塊。 新的位置現在會顯示在 [ 部署位置 ] 頁面上。 根據預設,新位置的 流量 % 會設定為 0,且所有客戶流量都會路由傳送至生產位置。

  2. 選取新的部署位置以開啟該位置的資源頁面。

    Deployment slot title

    預備位置和任何其他 App Service 應用程式一樣,具有管理頁面。 您可以變更位置的組態。 若要提醒您正在檢視部署位置,應用程式名稱會顯示為< app-name > / < slot-name >,而應用程式類型App Service (Slot) 。 您也可以在資源群組中將位置視為個別的應用程式,並指定相同的名稱。

  3. 選取位置資源頁面上的應用程式 URL。 部署位置有自己的主機名稱,也是即時應用程式。 若要限制對部署位置的公用存取,請參閱Azure App 服務 IP 限制

新的部署位置中沒有任何內容,即使您複製其他位置的設定,仍是如此。 例如,您可以使用 Git 發佈至此位置。 您可以從不同的存放庫分支或不同的存放庫部署至位置。

位置的 URL 的格式為 http://sitename-slotname.azurewebsites.net 。 為了在必要的 DNS 限制內保留 URL 長度,網站名稱會截斷為 40 個字元,位置名稱將會截斷為 19 個字元,並附加額外的 4 個隨機字元,以確保產生的功能變數名稱是唯一的。

交換期間會發生什麼事

交換作業步驟

當您將兩個位置交換 (通常從預備位置交換到生產位置) 時,App Service會執行下列動作,以確保目標位置不會發生停機時間:

  1. 例如,將下列設定從目標位置套用 (,生產位置) 到來源位置的所有實例:

    上述任一情況都會觸發來源位置中的所有實例重新開機。 在與預覽交換期間,這會標示第一個階段的結尾。 交換作業已暫停,而且您可以驗證來源位置是否可正確搭配目標位置的設定運作。

  2. 等候來源位置中的每個執行個體重新開機。 如果有任何實例無法重新開機,交換作業會將所有變更還原到來源位置,並停止作業。

  3. 如果已啟用 本機快取 ,請在來源位置的每個實例上對應用程式根目錄發出 HTTP 要求,以觸發本機快取初始化 (「/」) 。 等候每個實例傳回任何 HTTP 回應。 本機快取初始化會導致每個實例上的另一個重新開機。

  4. 如果使用自訂準備啟用自動交換,請在來源位置的每個實例上對應用程式根目錄發出 HTTP 要求,以觸發應用程式初始化 (「/」) 。

    如果未 applicationInitialization 指定,請針對每個實例上來源位置的應用程式根目錄觸發 HTTP 要求。

    如果實例傳回任何 HTTP 回應,則會將其視為已準備。

  5. 如果成功準備來源位置上的所有執行個體,請交換兩個位置的路由規則,交換這兩個位置。 此步驟之後,目標位置 (例如,生產位置) 具有先前在來源位置中準備的應用程式。

  6. 既然來源位置有先前已在目標位置中預先交換的應用程式,請套用所有設定並重新啟動執行個體,藉此執行相同的作業。

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

注意

您先前生產實例中的實例 (交換作業之後將交換到暫存的實例,) 會在交換程式的最後一個步驟中快速回收。 如果您的應用程式中有任何長時間執行的作業,則會在背景工作角色回收時放棄這些作業。 這也適用于函式應用程式。 因此,您的應用程式程式碼應該以容錯方式撰寫。

哪些設定已交換?

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

已交換的設定

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

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

未交換的設定

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

注意

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

套用至未交換設定的特定應用程式設定也不會交換。 例如,由於診斷設定未交換,因此,和 之類的 WEBSITE_HTTPLOGGING_RETENTION_DAYSDIAGNOSTICS_AZUREBLOBRETENTIONDAYS 相關應用程式設定也不會交換,即使它們未顯示為位置設定也一樣。

若要設定應用程式設定或連接字串以黏附至特定位置, (未交換) ,請移至該位置的 [設定] 頁面。 新增或編輯設定,然後選取 部署位置設定。 選取此核取方塊會告知App Service無法交換設定。

Slot setting

交換兩個位置

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

重要

將應用程式從部署位置交換至生產環境之前,請確定生產環境是您的目標位置,而且來源位置中的所有設定都完全符合您想要在生產環境中設定。

若要交換部署位置:

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

    Swap button

    [ 交換 ] 對話方塊會顯示所選來源和目標位置中將會變更的設定。

  2. 選取所需的 [來源 ] 和 [ 目標 位置]。 目標通常是生產位置。 此外,請選取 [來源變更 ] 和 [ 目標變更 ] 索引標籤,並確認設定變更是預期的。 完成後,您可以選取 [ 交換],立即交換位置。

    Complete swap

    若要查看您的目標位置在交換實際發生之前如何使用新設定執行,請勿選取 [交換],但請遵循 [交換與預覽]中的指示。

  3. 當您完成時,請選取 [ 關閉] 以關閉對話方塊。

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

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

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

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

如果您取消交換,App Service將組態元素重新套用至來源位置。

若要使用預覽交換:

  1. 請遵循 交換部署位置 中的步驟,但選取 [ 使用預覽執行交換]。

    Swap with preview

    此對話方塊會顯示來源位置中的設定如何在階段 1 變更,以及來源和目標位置如何在階段 2 變更。

  2. 當您準備好開始交換時,請選取 [ 開始交換]。

    階段 1 完成時,您會在對話方塊中收到通知。 移至 ,以預覽來源位置 https://<app_name>-<source-slot-name>.azurewebsites.net 中的交換。

  3. 當您準備好完成擱置的交換時,請選取 [交換] 動作中的 [完成交換],然後選取 [完成交換]。

    若要解除擱置的交換,請改為選取 [ 取消交換 ]。

  4. 當您完成時,請選取 [ 關閉] 以關閉對話方塊。

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

若要自動化多階段交換,請參閱 使用 PowerShell 自動化

回復交換

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

設定自動交換

注意

Linux 上的 Web 應用程式和適用于容器的 Web 應用程式不支援自動交換。

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

注意

設定生產位置的自動交換之前,請考慮在非生產目標位置上測試自動交換。

若要設定自動交換:

  1. 移至您應用程式的資源頁面。 選取 [部署位置所需的來源位置 <>>> 組>一般設定]。

  2. 針對 [啟用自動交換],選取 [ 開啟]。 然後選取 [ 自動交換部署位置] 所需的目標位置,然後選取命令列上的 [ 儲存 ]。

    Selections for configuring auto swap

  3. 執行推送至來源位置的程式碼。 自動交換會在短時間內發生,更新會反映在目標位置的 URL 上。

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

指定自訂準備

某些應用程式可能需要自訂的準備動作,才能進行交換。 applicationInitializationweb.config中的組態專案可讓您指定自訂初始化動作。 交換作業會等候這個自訂準備完成,再與目標位置交換。 以下是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 偵測以準備網站的路徑。 請指定開頭為斜線的自訂路徑作為值,以新增此應用程式設定。 例如 /statuscheck。 預設值是 /
  • WEBSITE_SWAP_WARMUP_PING_STATUSES:準備作業的有效 HTTP 回應碼。 請以 HTTP 代碼的逗號分隔清單方式新增此應用程式設定。 例如 200,202 。 如果傳回的狀態碼不在清單中,準備和交換作業就會停止。 預設是所有回應碼都有效。
  • WEBSITE_WARMUP_PATH:月臺上應偵測的相對路徑,每當月臺重新開機 (時,不僅在位置交換期間) 。 範例值包括 /statuscheck 或根路徑 。 /

注意

<applicationInitialization> 態專案是每個應用程式啟動的一部分,而兩個準備行為應用程式設定只適用于位置交換。

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

監視交換

如果 交換作業 需要很長的時間才能完成,您可以在 活動記錄中取得交換作業的相關資訊。

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

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

路由流量

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

自動路由生產流量

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

  1. 移至應用程式的資源頁面,然後選取 [部署位置]。

  2. 在您要路由傳送之位置的 [流量 %] 資料行中,指定介於 0 到 100) 之間的百 (分比,以代表您想要路由的流量總數。 選取 [儲存]。

    Setting a traffic percentage

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

在用戶端自動路由傳送至特定位置之後,該用戶端會在該用戶端會話的存留期間「釘選」到該位置。 用戶端瀏覽器中,您可以查看 HTTP 標頭中的 x-ms-routing-name Cookie,以確認您的工作階段固定到哪個位置。 路由至「預備」位置的要求具有 Cookie x-ms-routing-name=staging。 路由至生產位置的要求具有 Cookie x-ms-routing-name=self

注意

您也可以使用 az webapp traffic-routing set Azure CLI 中的 命令,從 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 (Slot) ,提醒您正在檢視部署位置。 選取命令列上的 [刪除 ]。

Delete a deployment slot

使用 PowerShell 自動執行

注意

本文使用 Azure Az PowerShell 模組,這是與 Azure 互動時建議使用的 PowerShell 模組。 若要開始使用 Az PowerShell 模組,請參閱安裝 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

使用Resource Manager範本自動化

Azure Resource Manager範本是用來自動化 Azure 資源的部署和設定的宣告式 JSON 檔案。 若要使用Resource Manager範本交換位置,您會在Microsoft.Web/sites/slotsMicrosoft.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」 的位置建立 Webapp。

{
    "$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) 應用程式。

後續步驟

封鎖對非生產位置的存取