將 Azure App Services 重新放置到另一個區域

發行項
10/17/2024

本文描述如何將 App Service 資源移至不同的 Azure 區域。

有各種原因讓您想要將現有的 Azure 資源從某個區域移至另一個區域。您可能想要：

利用新的 Azure 區域。
只部署特定區域中可用的功能或服務。
符合內部原則和治理需求。
與公司合併和收購保持一致
符合容量規劃需求。

App Service 資源有區域限定，無法跨區域移動。您必須在目標區域中建立現有 App Service 資源的複本，然後將內容重新放置到新的應用程式。如果您的來源應用程式使用自訂網域，您可以在重新配置完成後，將其移轉至目標區域中的新應用程式。

若要更輕鬆地複製應用程式，您可以將個別的 App Service 應用程式備份和還原至另一個區域中的 App Service 方案。

必要條件

請確定 App Service 應用程式位在想要從中移動的 Azure 區域中。
請確定目標區域支援您想移動其資源的 App Service 及任何相關服務。
驗證是否有足夠的權限將 App Service 資源部署至目標訂用帳戶和區域。
驗證是否有任何 Azure 原則指派了區域限制。
請考慮任何作業成本，因為計算資源價格可能會因區域而異。若要預估可能的成本，請參閱定價計算機。

準備

識別您目前使用的所有 App Service 資源。例如：

某些資源 (例如匯入的憑證或混合式連線) 會包含與其他 Azure 服務的整合。如需如何跨區域移動這些資源的詳細資訊，請參閱個別服務的文件。

計畫

本節是下列區域的規劃檢查清單：

狀態、儲存體和下游相依性
憑證
組態
VNet 連線能力/自訂名稱/DNS
身分識別
服務端點

狀態、儲存體和下游相依性

判斷 App Service 應用程式是具狀態或無狀態。 雖然我們建議 App Service 應用程式是無狀態的，且 %HOME%\site 磁碟機上的檔案應僅限於執行已部署應用程式所需的文件和任何暫存檔案，但仍可能在 %HOME%\site 虛擬磁碟機上儲存執行階段應用程式狀態。如果您的應用程式在應用程式共用儲存體路徑上寫入狀態，請務必規劃如何在資源移動期間管理該狀態。

提示

您可以使用 Kudu 搭配入口網站存取，提供檔案存取 API (虛擬檔案系統 (VFS))，以讀取/寫入 %HOME%\site 目錄下的檔案。如需詳細資訊，請參閱 Kudu Wiki。
檢查應用程式程式碼中的內部快取和狀態。
停用工作階段親和性設定。 可能的話，建議您停用工作階段親和性設定。停用工作階段親和性可改善水平向外延展的負載平衡。任何內部狀態都可能會影響完全移轉工作負載的規劃，特別是要求零停機時間的狀況。可能的話，將任何應用程式狀態重構為無狀態應用程式，以為移動做好準備，可能是有用的。
分析資料庫連接字串。 您可以在應用程式設定中找到資料庫連接字串。不過，它們也可能被硬式編碼或在隨附於應用程式的組態檔中進行管理。分析及規劃資料移轉/複寫，作為移動工作負載的較高層級規劃的一部分。對於多對話或延遲關鍵的應用程式，目標區域中的應用程式回到來源區域中的資料來源的效能不佳。
分析外部快取 (例如 Redis)。 應用程式快取的部署應該盡可能地接近應用程式。分析快取的填入方式、到期/收回原則，以及冷快取對第一個使用者在完全移轉後存取工作負載的影響。
分析及規劃 API (或應用程式) 相依性。如果目標區域中的應用程式回到仍在來源區域中的相依性，跨區域通訊的效能會顯著降低。建議您將所有下游相依性重新放置為工作負載重新配置的一部分。不過，*內部部署*資源是例外狀況，特別是那些地理位置更接近目標區域的資源 (如回復案例的情況)。

Azure Container Registry 可以是 App Service 的下游 (執行階段) 相依性，其設定為針對自訂容器映像執行。 Azure Container Registry 與應用程式本身位於相同的區域中更合理。請考慮將所需的映像上傳至目標取得區域中的新 ACR。否則，如果您打算將映像保留在來源區域中，請考慮使用異地複寫功能。
分析和規劃區域服務。 Application Insights 和 Log Analytics 資料是區域服務。請考慮在目標區域中建立新的 Application Insights 和 Log Analytics 儲存體。針對 App Insights，新的資源也會影響必須作為應用程式組態變更的一部分進行更新的連接字串。

憑證

App Service 憑證資源可以移至新的資源群組或訂用帳戶，但無法跨區域移動。可以匯出的憑證也可以匯入到新區域中的應用程式或 Key Vault。此匯出和匯入流程相當於在區域之間移動。

在規劃服務重新放置時，需要考慮不同類型的憑證：

憑證類型	Exportable	註解
受 App Service 管理 (部分機器翻譯)	No	在新區域中重新建立這些憑證。
受 Azure Key Vault 管理 (部分機器翻譯)	Yes	這些憑證可以從 Key Vault 匯出，然後在新區域中匯入到 Key Vault。
私密金鑰 (自我管理)	Yes	您在 Azure 外部取得的憑證可以從 App Service 匯出，然後匯入到新區域中的新應用程式或 Key Vault。
公開金鑰	No	您的應用程式可能會有只有公開金鑰且沒有秘密的憑證，以用來存取其他受保護的端點。請取得所需的公開金鑰憑證檔案，並將其匯入到新區域中的應用程式。

要進一步考慮的考慮事項：

應用程式指派的位址 (其中 App Service 應用程式的 SSL 連線繫結至特定應用程式指派的 IP) 可用於允許將來自第三方網路的呼叫列入 App Service。例如，網路/IT 系統管理員可能需要鎖定來自內部部署網路或 VNet 的輸出呼叫，以使用靜態已知的位址。因此，如果「應用程式指派的位址」功能正在使用中，應檢查進入應用程式呼叫者的上游防火牆規則 (例如內部、外部或第三方)，並通知新的位址。防火牆規則可以是內部、外部或第三方，例如合作夥伴或知名客戶。
請考慮任何上游網路虛擬設備 (NVA) 或反向 Proxy。如果要重寫主機標頭和/或 SSL 終止，則 NVA 組態可能需要變更。

注意

App Service 環境是唯一允許透過 SSL 對下游應用程式相依性進行下游呼叫的 App Service 供應項目，其中 SSL 依賴自我簽署/使用非標準根 CA 憑證建置的 PKI。多租用戶服務不提供客戶上傳至受信任憑證儲存的存取權。

App Service 環境目前不允許購買 SSL 憑證，只允許攜帶您自己的憑證。 IP-SSL 是不可能的 (而且沒有意義)，但 SNI 是可以的。內部 App Service 環境不會與公用網域相關聯，因此所使用的 SSL 憑證必須由客戶提供，因此該憑證是可傳輸的，例如使用 PKI 所產生供內部使用的憑證。外部模式中的 App Service 環境 v3 與一般多租用戶 App Service 共用相同的功能。

組態

您可以從 Azure 入口網站擷取現有應用程式設定和連接字串的快照集。展開 [設定]>[環境變數]，選取 [應用程式設定] 或 [連接字串] 底下的 [進階編輯]，然後儲存包含現有設定或連線的 JSON 輸出。您必須在新區域中重新建立這些設定，但值本身可能會因為已連線的服務中的後續區域變更而有所變更。
現有的 Key Vault 參考 (部分機器翻譯) 無法跨 Azure 地理邊界匯出。您必須在新區域中重新建立任何所需的參考。
您的應用程式組態可能由 Azure 應用程式組態管理，或從其他一些中央 (下游) 資料庫相依性進行管理。請檢閱任何應用程式組態存放區或類似的存放區，以取得可能需要修改的環境和區域特定設定。

務必檢查任何磁碟檔案設定，該設定或許可能會被應用程式設定覆寫。

VNet 連線能力/自訂名稱/DNS

App Service 環境是 VNet 插入的單一租用戶服務。 App Service 環境網路與多租用戶 App Service 不同，後者需要一個或兩個「私人端點」或「區域 VNet 整合」。其他可能正在播放的選項包括舊版 P2S VPN 型 VNet 整合和混合式連線 (Azure 轉送服務)。

注意

ASEv3 網路已簡化 - 客戶虛擬網路看不到 Azure 管理流量和 App Service 環境自身的下游相依性，這可大幅簡化客戶對所有流量使用強制通道，或透過網路虛擬設備/防火牆傳送輸出流量子集所需的設定。

混合式連線 (Azure 轉送) 是區域性連線。如果使用混合式連線，雖然 Azure 轉送命名空間可以移至另一個區域，但重新部署混合式連線 (確定在部署目標資源的新區域中設定混合式連線)，並將其重新連結至混合式連線管理員會更簡單。應仔細考慮混合式連線管理員位置。
遵循暖待命區域的策略。 請確定核心網路和連線能力、中樞網路、網域控制站、DNS、VPN 或 Express Route 等，在資源重新配置之前已存在並進行測試。
驗證任何上游或下游網路 ACL 和設定。例如，考慮一個僅將應用程式流量列入允許清單的外部下游服務。針對多租用戶 App Service 的新應用程式方案加以重新配置，也會是輸出 IP 位址的變更。
在大部分情況下，最好確保目標區域 VNet 具有唯一的位址空間。例如，如果需要複製資料，唯一的位址空間有助於實現 VNet 連線。因此，在這些案例中，有一個要變更的隱含需求：
- 私人 DNS
- 以 IP 位址 (不含主機名稱) 參考資源的任何硬式編碼或外部設定
- 網路 ACL，包括網路安全性群組和防火牆設定 (此處也考慮對任何內部部署 NVA 的影響)
- 任何路由規則、使用者定義路由表
此外，如果繼續使用現有的 DevOps 部署資源，請務必檢查包含區域特定 IP 範圍/服務標籤的設定。
對於已設定為轉接至 Azure 的 Azure 網域和 Azure DNS 私人區域的客戶部署私人 DNS，需要的變更較少。不過，由於私人端點是以資源 FQDN 為基礎，這通常也是資源名稱 (預期在目標區域中可能有所不同)，請記得交叉檢查設定，以確保在設定中參考的 FQDN 會相應更新。
在目標區域中重新建立私人端點 (如果使用)。這同樣適用於區域 VNet 整合。
App Service 環境的 DNS 通常是透過客戶私人自訂 DNS 解決方案來管理 (每個應用程式基本都有一個可用的手動設定覆寫)。 App Service 環境提供輸入/輸出的負載平衡器，而 App Service 本身則會對主機標頭進行篩選。因此，多個自訂名稱可以指向相同的 App Service 環境輸入端點。 App Service 環境不需要網域驗證。

注意

App Service 環境 v3 的 Kudu 端點僅於 {resourcename}.scm.{asename}.appserviceenvironment.net 提供。如需 App Service 環境 v3 DNS 和網路等的詳細資訊，請參閱 App Service 環境網路。

對於 App Service 環境，客戶擁有路由，因此擁有用於完全移轉的資源。只要從外部啟用對 App Service 環境的存取權 (通常透過第 7 層 NVA 或反向 Proxy)，就可以使用流量管理員或 Azure Front Door/其他 L7 全域負載平衡服務。
對於服務的公用多租用戶版本，為資料平面端點會佈建預設名稱 {resourcename}.azurewebsites.net，並為 Kudu (SCM) 端點佈建一個預設名稱。由於服務預設提供公用端點，因此必須驗證繫結以證明網域擁有權。不過，一旦繫結就緒，就不需要重新驗證，也不需要公用 DNS 記錄指向 App Service 端點。
如果您使用自訂網域，請先將其預先繫結至目標應用程式。在目標應用程式中驗證並啟用網域。

身分識別

您必須在新的目標區域中重新建立任何系統指派的受控識別以及您的應用程式。一般來說，EasyAuth 使用的自動建立 Microsoft Entra ID 應用程式會預設為應用程式資源名稱。
使用者指派的受控識別也無法跨區域移動。若要將使用者指派的受控識別保留在與您的應用程式相同的資源群組中，您必須在新區域中重新建立這些受控識別。如需詳細資訊，請參閱將 Azure 資源的受控識別重新放置到另一個區域。
向受控識別授與重新放置的服務中，與其所取代的原始身分識別相同的權限，包括群組成員資格。

規劃將識別提供者 (IDP) 重新配置至目標區域。雖然 Microsoft Entra ID 是全域服務，但某些解決方案依賴於本機 (或內部部署下游) IDP。
將任何資源更新至可能依賴於 Kudu FTP 認證的 App Service。

服務端點

Azure App Service 的虛擬網路服務端點會限制對指定虛擬網路的存取。端點也可以限制對 IPv4 (網際網路通訊協定第 4 版) 位址範圍的存取。任何從這些來源之外連線到事件中樞的使用者都會被拒絕存取。如果服務端點是在事件中樞資源的來源區域中設定的，則必須在目標區域中完成相同的動作。

若要成功將 Azure App Service 重新建立至目標區域，必須事先建立 VNet 和子網路。如果是使用 Azure Resource Mover 工具進行這兩個資源的移動，則不會自動設定服務端點。因此，您必須手動設定，這可以透過 Azure 入口網站、Azure CLI或 Azure PowerShell 來完成。

重新放置

若要重新配置 App Service 資源，您可以使用 Azure 入口網站或基礎結構即程式碼 (IaC)。

使用 Azure 入口網站重新放置

使用 Azure 入口網站重新放置最大優勢是其簡單性。應用程式、方案和內容以及許多設定都會複製到新的 App Service 資源和方案中。

請記住，對於 App Service 環境 (隔離式) 層，首先需要在另一個區域中重新部署整個 App Service 環境，然後便可以開始在新區域中的新 App Service 環境中重新部署個別方案。

使用 Azure 入口網站將 App Service 資源重新放置到新區域：

建立來源應用程式的備份。
在目標區域中的新 App Service 方案中建立應用程式。
還原目標應用程式中的備份
如果您使用自訂網域，請先透過 asuid. 將其繫結至目標應用程式，並在目標應用程式中啟用網域。
將目標應用程式中的其他項目設定成與來源應用程式一樣，並驗證您的設定。
當您準備好讓自訂網域指向目標應用程式時，請重新對應網域名稱。

使用 IaC 重新放置

當現有的持續整合和持續傳遞/部署 (CI/CD) 管線存在或可以建立時，請使用 IaC。有了 CI/CD 管線，便可透過部署動作或 Kudu zip 部署，在目標區域中建立 App Service 資源。

SLA 需求應確定需要多少額外的工作。例如：這是一次停機時間有限的重新部署，或是否需要近乎即時的完全移轉，而且停機時間最少到甚至沒有？

包含外部、全域流量路由邊緣服務 (例如流量管理員或 Azure Front Door) 有助於促進外部使用者和應用程式進行完全移轉。

提示

在私人端點後方對 App Services 進行容錯移轉時，可以使用流量管理員 (ATM)。雖然流量管理員探查無法連線私人端點，但如果所有端點都降級，則 ATM 允許路由。如需詳細資訊，請參閱使用 Azure 流量管理員來控制 Azure App Service 流量。

Validate

重新配置完成後，請使用建議的指導方針來測試和驗證 Azure App Service：

將 Azure App Service 重新放置到目標區域之後，請執行煙霧測試和整合測試。您可以手動測試或透過指令碼執行測試。請務必驗證所有設定和相依資源都已正確連結，且所有已設定的資料都可以存取。
驗證所有 Azure App Service 元件和整合。
對目標區域部署執行整合測試，包括所有正式迴歸測試。整合測試應與適用於工作負載的商務部署和測試流程的一般節奏保持一致。
在某些情況下，特別是重新配置包含更新、應用程式或 Azure 資源變更，或是使用設定檔中的變更，請使用負載測試來驗證新的工作負載是否符合用途。負載測試也是驗證作業和監視涵蓋範圍的機會。例如，使用負載測試來驗證所需的基礎結構和應用程式記錄是否正確產生。負載測試應根據已建立的工作負載效能基準來進行測量。

提示

App Service 重新配置也是重新評估可用性和災害復原規劃的機會。 App Service 和 App Service 環境 (App Service 環境 v3) 支援可用性區域，建議使用可用性區域設定進行設定。請記住部署、定價和限制的必要條件，並將這些條件納入資源移動規劃。如需可用性區域和 App Service 的詳細資訊，請參閱 Azure App Service 中的可靠性。

清理

刪除來源應用程式和 App Service 方案。非免費層中的 App Service 方案會收取費用，即使沒有任何應用程式在其中執行也一樣。

下一步

使用 PowerShell 複製 Azure App Service App

共用方式為