在 Azure App Service 中設定預備環境 \(部分機器翻譯\)
注意
從 2024 年 6 月 1 日起，新建立的 App Service 應用程式可以產生使用命名慣例 <app-name>-<random-hash>.<region>.azurewebsites.net的唯一默認主機名。 現有的應用程式名稱保持不變。 例如：
myapp-ds27dh7271aah175.westus-01.azurewebsites.net
如需詳細資訊，請參閱 App Service 資源的唯一預設主機名。
當您將 Web 應用程式、Linux 上的 Web 應用程式、行動後端或 API 應用程式部署至 Azure App 服務 時，您可以使用個別的部署位置，而不是預設的生產位置。 如果您在標準、進階或隔離的 App Service 方案層中執行，則可以使用此方法。 部署位置為具備自身主機名稱的即時應用程式。 兩個部署位置 (包括生產位置) 之間的應用程式內容與設定元素皆可交換。
將您的應用程式部署至非生產位置具有下列優點:
- 您可以在將應用程式變更交換至生產位置之前，先驗證預備部署位置中的應用程式變更。
- 先將應用程式部署到位置，並將其交換至生產環境，可確保將位置的所有實例都熱身後，再將它交換至生產環境。 當您部署應用程式時，此方法可消除停機時間。 流量重新導向是順暢的。 由於交換作業，因此不會捨棄任何要求。 不需要預先交換驗證時，您可以藉由設定自動交換來自動化整個工作流程。
- 交換之後，先前具有預備應用程式的位置，現在已經有之前的生產應用程式。 如果交換到生產位置的變更不如預期，您可以立即執行相同的交換，以取得您 最後一個已知的良好網站 返回。
每個 App Service 方案階層所支援的部署位置數目都不一樣。 使用部署位置不需要額外費用。 若要找出應用程式層支援的位置個數，請參閱 App Service 限制。
若要將您的應用程式調整到不同層，請確認目標層支援應用程式已使用的位置數。 例如，如果您的應用程式有五個以上的位置，則無法將其縮小至 標準 層。 標準層僅支援五個部署位置。
這段影片說明如何在 Azure App 服務中設定預備環境。
下列章節也會描述影片中的步驟。
必要條件
- 如需執行所需位置作業之許可權的相關信息，請參閱 資源提供者作業。 例如，搜尋 位置。
新增位置
應用程式必須在 [標準]、[進階] 或 [隔離] 層中執行，您才能啟用多個部署位置。
在 Azure 入口網站中，導覽至您應用程式的管理頁面。
在左窗格中，選取 [部署>部署位置>新增]。
注意
如果應用程式尚未在標準、進階或隔離層中，請選取 [升級]。 繼續之前，請移至 您應用程式的 [調整] 索引標籤。
在 [新增位置] 對話方塊中指定位置名稱，然後選取是否要複製其他部署位置的應用程式設定。 選取 [新增] 繼續操作。
您可以從任何現有位置複製設定。 可複製的設定包括應用程式設定、連接字串、語言架構版本、Web 通訊端、HTTP 版本和平台位元。
注意
目前，私人端點不會跨位置複製。
輸入設定之後，請選取 [ 關閉 ] 以關閉對話框。 此時新的位置會顯示在 [部署位置] 頁面中。 根據預設，新位置的 [流量百分比] 會設為 0，且所有客戶流量都會路由至生產位置。
選取新的部署位置，開啟該位置的資源頁面。
預備位置和任何其他 App Service 應用程式一樣，具有管理頁面。 您可以變更位置的組態。 若要提醒您正在檢視部署位置，應用程式名稱會顯示為 app-name/slot-name>。<<> 應用程式類型為 App Service （Slot）。 您也可以將位置視為資源群組中的獨立應用程式，且具有相同的指定名稱。
在位置的資源頁面中選取應用程式 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 回應。 本機快取初始化會致使每個執行個體再次執行重新啟動。
如果使用自定義熱身啟用自動交換，請在來源位置的每個實例上觸發自定義應用程式初始。
若未指定
applicationInitialization，請在每個執行個體上對來源位置的應用程式根目錄觸發 HTTP 要求。執行個體若傳回了任何 HTTP 回應，即會被視為已準備就緒。
如果成功準備來源位置上的所有執行個體，請交換兩個位置的路由規則，交換這兩個位置。 完成此步驟後，目標位置 (例如生產位置) 就會有先前已在來源位置準備就緒的應用程式。
既然來源位置有先前已在目標位置中預先交換的應用程式，請套用所有設定並重新啟動執行個體，藉此執行相同的作業。
在交換作業的任何時間點，所有對交換的應用程式進行初始化的工作都會在來源位置上執行。 無論交換成功還是失敗，來源位置都處於準備和熱身狀態時，目標位置會維持在在線狀態。 若要將預備位置與生產位置交換，請確定生產位置「一律」為目標位置。 如此，交換作業就不會對生產應用程式產生影響。
注意
此交換作業之後，您的先前生產實例會交換成預備環境。 這些實例會在交換程序的最後一個步驟中回收。 如果您的應用程式中有任何長時間執行的作業，當背景工作回收時，系統就會放棄這些作業。 此事實也適用於函式應用程式。 因此，您的應用程式程式代碼應該以容錯方式撰寫。
哪些設定已交換？
在您從另一個部署位置複製設定後，就可以編輯複製的設定。 某些組態元素會遵循跨交換的內容（而非特定位置）。 其他組態專案會在交換之後維持在相同的位置（位置特定）。 以下清單顯示當您交換位置時會變更的設定。
交換的設定：
- 語言堆疊和版本，32/64 位
- 應用程式設定 (可設定為固定在某個位置)
- 連線設定 (可設定為固定在某個位置)
- 掛接的記憶體帳戶 （可設定為堅持位置）
- 處理常式對應
- 公開憑證
- WebJobs 內容
- 混合式連線 *
- 服務端點 *
- Azure 內容傳遞網路 *
- 路徑的對應
標記星號 (*) 的功能計劃為不進行交換。
未交換的設定：
- 交換的設定中 未提及的一般設定
- 正在發行端點
- 自訂網域名稱
- 非公用憑證和 TLS/SSL 設定
- 調整大小設定
- WebJobs 排程器
- IP 限制
- 永遠開啟
- 診斷設定
- 跨原始來源資源分享 (CORS)
- 虛擬網路整合
- 受控識別和相關設定
- 尾碼為 _EXTENSION_VERSION 的設定
- 由服務連接器所建立的設定
注意
若要讓設定可進行交換，請在應用程式的每個位置上新增應用程式設定 WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS，並將其值設定為 0 或 false。 這些設定為全部可交換或完全無法交換。 您無法只讓部分設定可交換，而其他設定無法交換。 永遠不會交換受控識別。 此覆寫應用程式設定不會影響它們。
套用至未交換設定的某些應用程式設定也不會交換。 例如，由於診斷設定未交換，因此即使它們未顯示為位置設定，也會交換和 DIAGNOSTICS_AZUREBLOBRETENTIONDAYS 等WEBSITE_HTTPLOGGING_RETENTION_DAYS相關應用程式設定。
若要設定應用程式設定或 連接字串 以貼附至未交換的特定位置，請移至該位置的 [設定>環境變數] 頁面。 新增或編輯設定，然後選取 [部署位置設定]。 選取此選項會告知 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 上。
如果有任何問題，請參閱針對交換進行疑難排解。
指定自訂準備
某些應用程式在交換之前可能需執行自訂的準備動作。
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 (http://<app_name>.azurewebsites.net) 的所有用戶端要求都會路由至生產位置。 您可以將部分流量路由傳送至其他位置。 如果您需要新更新的使用者意見反應，但尚未準備好將其發行至生產環境，則這項功能會很有用。
若要自動路由傳送生產流量：
移至您的 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 範本是用來自動化 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 位置的 staging ，並在生產位置上設定 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 次。 如果所有重試都會逾時，交換作業就會停止。
當應用程式內容超過為本機快取指定的本機磁碟配額時，本機快取初始化可能會失敗。 如需詳細資訊，請參閱本機快取概觀。
在月臺更新作業期間，可能會發生 下列錯誤：位置無法變更，因為其組態設定已準備好進行交換。 如果 與預覽交換 （多階段交換） 階段 1 的交換完成，但尚未執行階段 2， 就可能發生此錯誤。 如果交換失敗，也可能會發生此情況。 有兩種方式可以解決此問題：
- 取消將月臺重設為舊狀態的交換作業
- 完成將月臺更新為所需新狀態的交換作業
若要瞭解如何取消或完成交換作業，請參閱使用預覽交換交換（多階段交換）。
在自定義熱身期間，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） 應用程式。