當您將 Web 應用程式、Linux 上的 Web 應用程式、行動後端或 API 應用程式部署至 Azure App Service 時，您可以使用個別的部署位置，而不是預設的生產位置。 如果您在 App Service 方案的標準、進階或隔離層中執行，則可以使用此方法。 部署位置是具有專屬主機名稱的即時應用程式。 兩個部署位置 (包括生產位置) 之間的應用程式內容與設定項目可以互相交換。
將您的應用程式部署至非生產位置具有下列優點:
您可以先驗證應用程式變更，再將位置交換至生產環境。
您可以先確定位置的所有執行個體已準備就緒，再將位置交換至生產環境。 此方法可以排除部署應用程式時的停機情況。 流量可以順暢地重新導向。 不會有任何要求因為交換作業遭到捨棄。
不需要預先交換驗證時，您可以藉由設定自動交換來自動化整個工作流程。
交換之後，先前具有預備應用程式的位置，現在已經有之前的生產應用程式。 若交換到生產位置的變更不是您需要的變更，您可以立即執行相同的交換，以恢復「上一個已知的良好網站」。
使用部署位置不會額外收費。 每個 App Service 方案層所支援的部署位置個數都不一樣。 若要瞭解應用程式層所支援的位置數目，請參閱 App Service 限制。
若要將應用程式調整為不同的層級，請確定目標層支援您的應用程式已使用的位置數目。 例如，如果您的應用程式有五個以上的位置，則無法將其縮小至標準層。 標準層僅支援五個部署位置。
下列影片說明如何在 Azure App Service 中設定預備環境，以補充本文中的步驟。
先決條件
- 用來執行所需位置作業的權限。 如需必要許可權的資訊，請參閱 資源提供者作業。 例如，搜尋位置。
新增位置
若要啟用多個部署位置，應用程式必須在標準、進階或隔離層中執行。
在 Azure 入口網站中，移至您應用程式的管理頁面。
在左側功能表上，選取 [部署>部署位置]。 然後選取 新增。
附註
如果應用程式尚未在標準、進階或隔離層中，請選取 [升級]。 繼續之前，請移至您應用程式的 [調整] 索引標籤。
在 [ 新增位置] 對話框中，為位置指定名稱，然後選取是否要從另一個部署位置複製應用程式組態。 選取 [新增] 繼續操作。
您可以從任何現有位置複製設定。 可複製的設定包括應用程式設定、連接字串、語言架構版本、Web 通訊端、HTTP 版本和平台位元。
附註
目前，私人端點不會跨位置複製。
輸入設定之後，請選取 [關閉 ] 以關閉對話框。 新的槽位現在會出現在 [ 部署槽位 ] 頁面上。 根據預設，新位置的 [流量百分比] 會設為 [0]，且所有客戶流量都會路由至生產位置。
選取新的部署位置以開啟其資源頁面。
預備位置和任何其他 App Service 應用程式一樣，具有管理頁面。 您可以變更位置的組態。 為了提醒您正在檢視部署插槽，應用程式名稱和插槽名稱會出現在網址中。 應用程式類型為 App Service (位置)。 您也可以將位置視為資源群組中的獨立應用程式，且具有相同的指定名稱。
在位置的資源頁面上，選取應用程式 URL。 部署位置有自己的主機名稱，同時也是作用中的應用程式。 若要限制對部署位置的公用存取，請參閱 設定 Azure App Service 存取限制。
新的部署位置中沒有任何內容，即使您複製其他位置的設定，仍是如此。 例如，您可以使用 Git 發佈至此位置。 您可以從不同的存放庫分支或不同的存放庫部署至位置。 從 Azure App Service 取得發行設定檔 (部分機器翻譯) 一文可以提供用於部署至位置的必要資訊。 Visual Studio 可以匯入設定檔，以將內容部署至位置。
位置的 URL 格式為 http://sitename-slotname.azurewebsites.net。 為了將 URL 長度保持在必要的 DNS 限制內，網站名稱會截斷為 40 個字元。 網站名稱及位置名稱的組合必須少於 59 個字元。
瞭解交換期間會發生什麼事
交換作業步驟
當您交換兩個位置時，App Service 會執行下列動作，以確保目標位置不會發生停機情況：
將目標位置 (例如生產位置) 的下列設定套用至來源位置的所有執行個體：
- 如果適用，位置特定的應用程式設定和連接字串
- 連續部署 設定，如果已啟用
- App Service 驗證設定，如果已啟用
當任何設定套用至來源位置時，變更會觸發來源位置中的所有執行個體以重新啟動。 在以預覽版交換期間，此動作標志著第一個階段的結束。 交換作業已暫停。 您可以驗證來源位置是否能與目標位置的設定正確搭配運作。
等候來源位置中的每個執行個體完成重新啟動。 如果有任何執行個體無法重新啟動，交換作業會還原來源位置的所有變更，並停止作業。
如果啟用 本機快取，請對來源插槽的每個實例在應用程式根目錄發出
/HTTP 要求，以觸發本機快取初始化。 等待每個執行個體傳回任何 HTTP 回應。 本機快取初始化會造成每個執行個體再重新啟動一次。如果使用 [自訂準備] 來啟用 [自動交換]，請在來源位置的每個執行個體上觸發自訂應用程式初始化。
如果未指定
applicationInitialization，請對來源位置每個執行個體上的應用程式根目錄觸發 HTTP 要求。如果執行個體傳回任何 HTTP 回應，則會將其視為已準備完畢。
如果來源位置上的所有執行個體都成功準備就緒，請切換這兩個位置的路由規則來交換這兩個位置。 完成此步驟後，目標位置 (例如生產位置) 會擁有先前在來源位置準備就緒的應用程式。
由於來源位置具有先前位於目標位置的預先交換應用程式，因此可套用所有設定並重新啟動執行個體來執行相同的作業。
在交換作業的任何時間點，初始化被交換應用程式的所有工作都在來源插槽上進行。 不論交換成功或失敗，來源位置在進行準備並準備就緒的期間，目標位置都會保持線上狀態。 若要將預備位置與生產位置交換，請確定生產位置一律為目標位置。 這樣交換作業才不會影響您的實際執行應用程式。
附註
經此交換作業後，您先前的生產執行個體會交換到預備環境。 系統會在交換流程的最後一個步驟回收這些執行個體。 如果您的應用程式中有任何長時間執行的作業，當背景工作角色回收時，系統會放棄這些作業。 此情況也適用於函數應用程式。 請確定您的應用程式程式代碼是以容錯方式撰寫。
用於將位置設定為無法交換的步驟
當您複製其他部署位置的組態時，可以編輯複製的組態。 某些設定元素會遵循交換中的內容 (這些元素「並非位置專屬」元素)。 交換之後，其他組態元素會保留在相同的位置中（它們為 特定位置）。
當你交換插槽時，會交換這些設定：
- 語言堆疊和版本、32 位和64位
- 應用程式設定 (可以設定為停在某一個位置)
- 連接字串 (可以設定為停在某一個位置)
- 掛接的儲存體帳戶 (可設定為固定在某個位置)
- 處理常式對應
- 公開憑證
- WebJobs 內容
- 混合式連線（目前）
- 服務端點（目前）
- Azure 內容傳遞網路 （目前）
- 路徑對應
- 虛擬網路整合
當您交換插槽時，不會交換這些設定：
- 上一個清單中未提及的一般設定
- 發行端點
- 自訂網域名稱
- 非公用憑證和 TLS/SSL 設定
- 調整大小設定
- WebJobs 排程器
- IP 限制
- Always On
- 診斷設定
- 跨原點資源共用 (CORS)
- 受控識別和相關設定
- 結尾為尾碼
_EXTENSION_VERSION的設定 - Service Connector 建立的設定
附註
若要讓設定可交換，請在應用程式的每個位置中新增應用程式設定 WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS 。 將設定為 0 或 false。 這些設定可以是所有可交換或全部不可交換。 您無法只將部分設定設為可交換，同時將其他設定設為不可交換。 永遠不會交換受控識別。 此覆寫應用程式設定不會影響受控識別。
套用至未交換設定的某些應用程式設定也不會交換。 例如，由於診斷設定未交換，因此 WEBSITE_HTTPLOGGING_RETENTION_DAYS 和 DIAGNOSTICS_AZUREBLOBRETENTIONDAYS 等相關應用程式設定也不會交換，即使沒有顯示為位置設定也一樣。
若要將應用程式設定或連接字串設定為固定在某個未交換的特定位置：
移至該位置的 [設定]>[環境變數]。
新增或編輯設定，然後選取 [部署位置設定]。 選取此複選框會告知 App Service 無法交換設定。
選取 ，然後套用。
交換部署位置
您可以在應用程式的 [部署位置] 頁面和 [概觀] 頁面上交換部署位置。
將應用程式從部署位置交換至實際執行環境之前，請確定實際執行環境是您的目標位置，而且來源位置中的所有設定，都與您想在實際執行環境中設定的完全一致。
移至應用程式的 [部署位置] 頁面，然後選取 [交換]。
[交換] 對話方塊會顯示要變更的所選來源和目標位置中的設定。
選取所需的 [來源] 和 [目標] 位置。 目標通常是生產位置。 此外，選取 [來源位置變更 ] 和 [ 目標位置變更 ] 索引卷標，並確認組態變更是預期的。 當您完成時，您可以選取 [開始交換] 來立即交換位置。
若要查看您的目標位置在交換發生之前如何以新的設定執行，請勿選取 [開始交換]。 請遵循本文稍後的 Swap with preview 中的指示。
選取 [關閉] 以關閉該對話方塊。
如果有任何問題，請參閱本文稍後的針對交換進行疑難排解。
以預覽版交換 (多階段交換)
交換到實際執行環境中作為目標位置之前，請先確認應用程式會先以交換後的設定執行。 來源位置也會先進行準備工作再完成交換，這正是任務關鍵性應用程式所需要的。
使用預覽執行交換時，App Service 會執行相同的交換作業，但在完成第一個步驟後會先暫停。 接著您可在預備位置上確認結果，再完成交換。
如果您取消交換，App Service 會將設定元素重新套用至來源位置。
附註
當其中一個位置啟用了網站驗證時，就無法使用以預覽版交換。
請遵循 [交換部署位置] 區 段中的步驟，但選取 [ 使用預覽執行交換]。
對話框會顯示來源位置中的設定在第一個階段中的變更方式，以及來源和目標位置在第二個階段中的變更方式。
準備好開始進行交換時，選取 [開始交換]。
當第一個階段完成時，對話框會通知您。
當您準備好完成擱置交換時，請在 [交換] 動作中選取 [完成交換]，然後選取 [完成交換] 按鈕。
若要取消擱置的交換，請改為選取 [ 取消交換 ]，然後選取 [ 取消交換 ] 按鈕。
當您完成時，請選取 [關閉 ] 以關閉對話框。
如果有任何問題，請參閱本文稍後的針對交換進行疑難排解。
復原交換
在交換位置後，若目標位置 (例如生產位置) 發生任何錯誤，請立即交換相同的兩個位置，將位置還原成交換前的狀態。
設定自動交換
如果您希望為應用程式的客戶持續部署您的應用程式，而不需冷啟動和不需關機，「自動交換」將可簡化此類 Azure DevOps 案例。 啟用從原來位置自動交換至生產位置後，每當您將程式碼變更推送至該位置時，App Service 就會在於來源位置做好準備後，自動將該應用程式交換至生產位置。
附註
Linux 上的 Web 應用程式和適用於容器的 Web 應用程式中不支援自動交換。
在為生產位置設定自動交換之前，請考慮先在非生產目標位置上測試自動交換。
前往應用程式的資源頁面。 選取 [部署>部署插槽]，然後選取所需的來源插槽。
在左側功能表上，選取 [設定>組態>一般設定]。
在 [啟用自動交換] 選取 [開啟]。 針對 [自動交換部署位置]，選取目標位置。 然後選取命令行上的 [ 儲存 ]。
執行程式碼推送，推送目的地為來源位置。 自動交換會在短時間內發生。 更新會反映在目標位置的 URL 上。
如果有任何問題，請參閱本文稍後的針對交換進行疑難排解。
指定自訂準備動作
某些應用程式在交換之前可能需執行自訂的準備動作。 您可以使用applicationInitialization中的Web.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 Ping 此路徑以準備網站。 請指定開頭為斜線的自訂路徑作為值，以新增此應用程式設定。 例如/statuscheck。 預設值是/。WEBSITE_SWAP_WARMUP_PING_STATUSES：準備作業的有效 HTTP 回應碼。 請以 HTTP 代碼的逗號分隔清單方式新增此應用程式設定。 例如200,202。 如果傳回的狀態代碼不在清單中，則會停止熱身和交換作業。 預設是所有回應碼都有效。WEBSITE_WARMUP_PATH：每當網站重新啟動 (不只是在位置交換期間) 都應 Ping 的網站相對路徑。 範例值包括/statuscheck，或根路徑/。
<applicationInitialization> 設定元素是每個應用程式啟動的一部分，而準備行為的應用程式設定只適用於位置交換。
如果有任何問題，請參閱本文稍後的針對交換進行疑難排解。
監視交換作業
如果交換作業耗時很久才完成，您可以在活動記錄中取得交換作業的相關資訊。
在入口網站的應用程式資源頁面上，於左側功能表上，選取 [ 活動記錄]。
交換作業在記錄查詢中會顯示為
Swap Web App Slots。 若要檢視詳細資訊，您可以展開它，然後選取其中一個子操作或錯誤。
自動路由生產流量
根據預設，對應用程式生產 URL 的所有用戶端要求都會路由至生產位置。 您可以將部分流量路由至其他位置。 如果您需要新更新的使用者意見反應，但尚未準備好將它發行至生產環境，這項功能就很有用。
移至 Web 應用程式的資源頁面，然後選取 [部署>部署位置]。
在您要路由至的插槽中的 流量 % 列中，指定百分比（介於0到100之間），以表示您希望路由的流量總量。 然後選擇 儲存。
儲存設定之後，指定的用戶端百分比會隨機路由至非生產位置。
用戶端自動路由至特定位置之後，其會「固定」到該位置一小時，或直到刪除 Cookie 為止。 用戶端瀏覽器中，您可以查看 HTTP 標頭中的 x-ms-routing-name Cookie，以確認您的工作階段固定到哪個位置。 路由至預備位置的要求具有 Cookie x-ms-routing-name=staging。 路由至生產位置的要求具有 Cookie x-ms-routing-name=self。
手動路由生產流量
除了自動流量路由以外，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 （位置） ，提醒您正在檢視部署位置。
停止該槽，並將槽內流量設定為零。
在命令列上，選取刪除。
透過 Resource Manager 範本自動化
Azure Resource Manager 範本 是宣告式 JSON 檔案，可自動化 Azure 資源的部署和設定。 若要使用 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 範本會藉由更新 staging 位置的 buildVersion 值，並在生產位置上設定 targetBuildVersion 值來交換兩個位置。 您必須有一個名為 staging 的位置。
{
"$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 範本具有等冪性。 您可以重複執行此範本，並產生相同的位置狀態。 若未變更範本，則相同範本的後續執行不會觸發任何位置交換，因為位置已處於所需的狀態。
針對交換進行疑難排解
如果在 位置交換期間發生任何錯誤，錯誤會出現在D:\home\LogFiles\eventlog.xml。 同時也會記錄在應用程式專屬的錯誤記錄檔中。
以下是一些常見的交換錯誤：
傳至應用程式根目錄的 HTTP 要求逾時。 交換作業會等候每個 HTTP 要求的 90 秒，而且最多重試五次。 如果所有重試都會逾時，交換作業就會停止。
當應用程式內容超過針對本機快取指定的本機磁碟配額時，本機快取初始化可能會失敗。 如需詳細資訊，請參閱 Azure App Service 本機快取概觀。
在月臺更新作業期間，可能會發生下列錯誤：「位置無法變更，因為其組態設定已備妥供交換使用。如果多階段交換中的第一個階段完成，但第二個階段尚未發生，就可能發生此錯誤。 如果交換失敗，也可能會發生此情況。 有兩種方式可以解決此問題：
- 取消交換作業，將網站重設為舊狀態。
- 完成交換作業，以將月臺更新為所需的新狀態。
若要瞭解如何取消或完成交換作業，請參閱本文稍早的預覽交換（多階段交換）。
執行自訂準備動作期間，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) 應用程式。