在 Azure App Service 中設定預備環境 \(部分機器翻譯\)
將 Web 應用程式、Linux 上的 Web 應用程式、行動後端或 API 應用程式部署至 Azure App Service 時，若您在標準、進階或隔離式 App Service 方案層執行，就使用獨立的部署位置，而非預設的生產位置。 部署位置為具備自身主機名稱的即時應用程式。 兩個部署位置 (包括生產位置) 之間的應用程式內容與設定元素皆可交換。
將您的應用程式部署至非生產位置具有下列優點:
- 您可以先驗證預備部署位置中的應用程式變更，再與生產位置交換。
- 先將應用程式部署至某個位置，然後再將它交換到生產位置，可確保該位置的所有執行個體在交換到生產位置之前都已準備就緒。 這麼做可以排除部署應用程式時的停機情況。 流量可以無縫重新導向，也不會因交換作業而捨棄任何要求。 不需要預先交換驗證時，您可以藉由設定自動交換來自動化整個工作流程。
- 交換之後，先前具有預備應用程式的位置，現在已經有之前的生產應用程式。 若交換到生產位置的變更不是您需要的變更，您可以立即執行相同的交換，以恢復「上一個已知的良好網站」。
每個 App Service 方案階層所支援的部署位置數目都不一樣。 使用部署位置不需要額外費用。 若要找出應用程式層支援的位置個數，請參閱 App Service 限制。
若要將您的應用程式調整到不同層，請確認目標層支援應用程式已使用的位置數。 例如，如果您的應用程式具有五個以上的位置，您無法將其向下調整至標準層，因為標準層只支援五個部署位置。
這段影片說明如何在 Azure App 服務中設定預備環境。
下列章節也會描述影片中的步驟。
必要條件
如需執行所需位置作業之權限的相關資訊，請參閱 資源提供者作業 (例如，搜尋 位置)。
新增位置
應用程式必須在 [標準]、[進階] 或 [隔離] 層中執行，您才能啟用多個部署位置。
在 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 個字元，且合併的網站名稱和位置名稱必須少於 59 個字元。
交換期間發生的情況
交換作業步驟
將兩個位置交換時 (通常從預備位置為來源交換到生產位置為目標)，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可預覽來源位置中的交換情形。準備好完成擱置的交換時，請在 [交換動作] 中選取 [完成交換]，然後選取 [完成交換]。
若要取消擱置中的交換，請改為選取 [取消交換]，然後選取下方的 [取消交換]。
完成之後，選取 [關閉] 以關閉對話方塊。
如果有任何問題，請參閱針對交換進行疑難排解。
復原交換
如果目標位置發生任何錯誤 (例如生產位置) 在位置交換之後，請立即交換相同的兩個位置，將位置還原至其交換前狀態。
設定自動交換
注意
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。
手動路由傳送生產流量
除了自動流量路由之外，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 範本是用來自動化 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 範本會藉由更新 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 秒，並重試最多 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) 應用程式。