在 Azure 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 服務IP限制。
即使您從不同的位置複製設定,新的部署位置也沒有任何內容。 例如,您可以使用 Git 發佈至此位置。 您可以從不同的存放庫分支或不同的存放庫部署到位置。 從 Azure App 服務 取得發行配置檔,可以提供部署至位置的必要資訊。 Visual Studio 可以匯入配置檔,將內容部署至位置。
位置的網址格式 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 的設定
- 建立的 設定服務 連線 or
注意
若要讓上述設定可交換,請在應用程式的每個位置新增應用程式設定 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 應用程式和適用於容器的 Web 應用程式不支援自動交換。
如果您希望為應用程式的客戶持續部署您的應用程式,而不需冷啟動和不需關機,「自動交換」將可簡化此類 Azure DevOps 案例。 當您將程式代碼變更推送至該位置時,每次將程式代碼變更推送至該位置時,App Service 會在來源位置中熱身後自動 將應用程式交換至生產 環境。
注意
設定生產位置的自動交換之前,請考慮在非生產目標位置上測試自動交換。
若要設定自動交換:
如果您有任何問題,請參閱 針對交換進行疑難解答。
指定自訂準備
某些應用程式在交換之前可能需執行自訂的準備動作。 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
) 的所有用戶端要求都會路由至生產位置。 您可以將部分流量路由傳送至其他位置。 如果您需要新更新的使用者意見反應,但尚未準備好將其發行至生產環境,則這項功能會很有用。
若要自動路由傳送生產流量:
儲存設定之後,指定的用戶端百分比會隨機路由至非生產位置。
在客戶端自動路由傳送至特定位置之後,它會「釘選」到該位置一小時,或直到刪除 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 (Slot), 提醒您正在檢視部署位置。 刪除位置之前,請務必停止位置,並將位置中的流量設定為零。 選取命令列上的 [ 刪除 ]。
使用 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 樣本會藉由更新 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 秒,並重試最多五次。 如果所有重試逾時,交換作業就會停止。
當應用程式內容超過為本機快取指定的本機磁碟配額時,本機快取初始化可能會失敗。 如需詳細資訊,請參閱 本機快取概觀。
在自定義熱身期間,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) 應用程式。