? ?突然收到微軟的郵件，提示我的一個 Azure 訂閱已經到期，所以轉為“禁用”狀態，只能進行數據的導出和處理。在這個訂閱里有不少較重要的資源在跑，直接關了可不行…

? ?于是開啟了一個支持事件，臺灣美眉的態度和聲線真的沒話說～于是給了我24小時時間來遷移這個訂閱中的資源到另外一個訂閱。

? ?我以為這是個很簡單的過程，畢竟咱都考過認證了不是嘛？于是，很打臉的踩坑了…哈哈哈… 這就很值得記錄一下了～

? ?遷移的訂閱里有很多種不同的資源，有虛擬機，也有各種認知服務，有WebApp服務，也有對應的應用服務計劃。遷移的方式也很簡單，登錄到 Azure 門戶，打開需要遷移的資源所在資源組，勾選需要遷移的資源，然后在上端找到“移動”下拉菜單，選擇“移動到另一個訂閱”。Azure 門戶會開啟一個遷移向導，在這個向導里，你需要指定目標訂閱和目標資源組，然后點擊“下一步”，Azure 會驗證是否能夠完成遷移。

? ?看著很簡單吧？可是遷移一堆資源的時候，我發現報錯了…提示貌似是Web應用服務和應用服務計劃所在的資源組不對。怎么會呢？要遷移的資源不是已經乖乖地待在資源組里嗎？那就查查文檔吧。

? ?翻翻文檔，還真有發現。Azure 其實支持特定的資源進行三種遷移：遷移到另一個資源組，遷移到另一個訂閱和遷移到另一個區域。比較容易理解的是資源之間具有依存關系，所以需要整合到一個資源組一起遷移——這都是我已經特別注意的，但為什么會報錯呢？難道是不支持遷移嗎？報錯信息不像啊…

? ?先查一下哪些資源可以遷移。在 Azure 的文檔里專門介紹了支持遷移的資源 ，列出了幾乎所有 Azure 的資源類型是否支持三種遷移。不過，在文檔里各種資源是以資源類型顯示的。事后我來查看當然沒啥問題，因為資源類型可以通過 Azure 門戶里資源概述頁面右上角的 JSON 視圖查看，可以很明顯的看到類似如下的屬性描述：

"name": "modoo","type":?"Microsoft.Web/sites",????"kind":?"app",????"location":?"West?US",

? ? 以上僅截取部分屬性顯示。“type” 屬性即為資源類型定義。這里顯示的就是Web應用服務，其屬性為“Microsoft.Web/sites”。在文檔中查找“Microsoft.Web"小節，就能看到對應表格里，有sites的資源類型對應的遷移能力為：

資源類型	資源組	訂閱	區域移動
sites	是	是	否

? ?當然，列出的“sites”只是一個，對于我來說還需要知道一起捆綁的應用服務計劃，也列出如下：

資源類型	資源組	訂閱	區域移動
serverfarms	是	是	否

? ?其實相關的資源還有很多，只是這個例子里我只遷移這兩類資源。如果您的遷移里涉及到其他資源，可以用這篇文檔來進行遷移能力確認。如果不支持直接的遷移，可能就需要做其他搬家方式的計劃。例如導出為模板，修改之后在新的訂閱或資源組導入。

? ?好了，現在確認了Web應用和應用服務計劃都可以進行跨訂閱的遷移。那為什么會報錯呢？

? ?我們先看看報錯長什么樣子。

? ?這個報錯其實不是原始報錯截圖啦～是我后面為了研究問題（什么問題先賣個關子）特意復現的。點擊“錯誤詳細信息”進去，能看到某資源在某資源組，而不在原來某資源組之類的信息，但確實可讀性不高。所以我意識到，Web應用服務和應用服務計劃貌似不像虛擬機一樣，直接就一股腦遷移了。似乎有著某種限制要求。

? ?如果此時的我，是當時的我，問題就簡單了。其實在我們前面查閱遷移支持的時候，在“Microsoft.Web"小節就有個重要提示：

? ?這說明，應用服務遷移和其他類型的資源遷移操作是不同的。而在文檔 “跨資源組/訂閱移動” 中，也相當明確的給出了描述——跨訂閱移動 Web 應用時，應遵循以下指導：

• 將資源移動到新的資源組或訂閱屬于元數據更改，不應影響資源的任何運作方式。例如，移動應用服務時，應用服務的入站 IP 地址不會更改。（所以我并不需要調整自己域名的DNS記錄了）

• 目標資源組中不能有任何現有的應用服務資源。應用服務資源包括：

  • Web 應用（這次我想遷移的）

  • 應用服務計劃（也是這次我想遷移的）

  • 上傳或導入的 TLS/SSL 證書（這次遷移的環境沒啟用SSL）

  • 應用服務環境

• 資源組中的所有應用服務資源必須一起移動。（這個好理解，否則依存關系檢查估計不能通過）

• 應用服務環境不能移到新資源組，也不能移到新訂閱。但是，可以將某個 Web 應用和應用服務計劃轉移到新訂閱，而無需移動應用服務環境。

• 只要將證書與資源組中的所有其他資源一起移動，就可以將綁定的證書移到 Web，而無需刪除 TLS 綁定。但是，無法移動免費的應用服務托管證書。對于該情況，請參閱移動免費托管證書 。（其實就是刪除免費應用服務托管證書遷移之后再重新創建）

• 含專用終結點的 Azure 應用服務應用無法移動。刪除專用終結點，并在移動后重新創建。(如果采用專用終結點保護應用服務訪問，需要遷移之前記錄并刪除，遷移之后重建)

• 只能從最初創建應用服務資源的資源組中移動它們。如果應用服務資源不再位于其原始資源組中，請將其移回其原始資源組。然后，在訂閱之間移動資源。（這就是報錯的原因了！）

? ?那么，怎么知道這些資源的原始資源組是哪個呢？

? ?點擊打開準備遷移的Web應用服務資源，在左側的菜單欄找到“診斷并解決問題”，點擊之后，在右側頁面找到“配置和管理”（Configuration and Management）。

? ?進入到“配置和管理”頁面之后，在左側菜單欄點擊“遷移操作“菜單，Azure門戶將會運行一個報告。等報告生成之后，就可以看到所有涉及需要一并遷移的Web應用服務和應用服務計劃了。報告中很明顯地指出了每一個資源目前和初始的資源組。

? ?依據這個指示，將資源遷回原始的資源組，然后再一并遷移到新的訂閱就可以了。除了使用Azure門戶的UI界面，還可以使用Azure PowerShell、Azure CLI 或Azure的 REST API來移動資源。資源遷移之后，其對應的資源ID將發生變化。資源ID的標準格式為：

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}。

? ?將資源移到新的資源組或訂閱時，會更改該路徑中的一個或多個值。

------------ 并不華麗的分割線 ------------

? ?如果這篇文章在這里結束，其實就一點意義也沒有了。因為內容在微軟文檔站點都能找到。我要問自己一個經典的問題：為什么？

? ?為什么必須將資源遷回原始資源組呢？為什么虛擬機等資源遷移就不需要呢？

? ?Azure門戶里能看到的信息畢竟是有限的，所以我決定用命令行來查看遷移前后Web應用服務和應用服務計劃資源的不同。于是我又把資源遷回去了……

? ?試了一下，使用如下的PowerShell可以獲取我最希望得到的資源信息。

Get-AzResource -Name modoo -ResourceGroupName modoo.top -ResourceType Microsoft.Web/sites | fc -Property properties > modoo.site.1.txtGet-AzResource -Name modoo -ResourceGroupName modoo.top -ResourceType Microsoft.Web/serverfarms | fc -Property properties > modoo.plan.1.txt

? ?可以看到，命令行里使用了資源類型的定義，來輸出特定資源的信息。同時，我使用了管道來指定輸出格式，使用 format custom 才能夠看到“@”開頭的全部屬性信息。最后我把輸出寫入到一個文本文件進行比較。

? ?同樣，我昨晚遷移之后，又重復了一遍這個操作。

Get-AzResource -Name modoo -ResourceGroupName Test.Lab.US -ResourceType Microsoft.Web/sites | fc -Property properties > modoo.site.2.txtGet-AzResource -Name modoo -ResourceGroupName Test.Lab.US -ResourceType Microsoft.Web/serverfarms | fc -Property properties > modoo.plan.2.txt

? ?然后我們比較一下，遷移前后的資源，到底哪里不一樣。

? ?Web應用服務資源其實就兩個地方不同：serverFarmId和resourceGroup，時間相關的不同我們可以忽略。

? ?而應用服務計劃就只有一處不同：resourceGroup。

? ?這也就驗證了前文文檔里提及的，遷移其實只是修改了元數據，并未“真的”修改我們的資源。那為什么一定要遷移回“原始資源組”才能跨訂閱遷移呢？

? ?如果您創建Web應用服務，就會發現在創建向導中必須指定應用服務計劃。這意味著，基于共享資源提供的應用服務，需要首先確定所使用的物理資源的位置。因為多個Web應用服務（當然不僅限于Web應用服務，所有使用應用服務計劃的資源都一樣）可以使用相同的應用服務計劃，所以應用服務計劃的作用對于解答我們的疑問就很重要了。

? ?實際上，應用服務計劃概述 文檔中已經告訴了我們足夠的信息。應用服務計劃為要運行的Web應用定義一組計算資源。這些計算資源類似傳統Web托管方案中的服務器場。實際上，也就是針對“真實”計算資源的定義：

• 操作系統（Windows、Linux）

• 區域（美國西部、美國東部，等等）

• VM 實例數

• VM 實例大小（“小型”、“中型”、“大型”）

• 定價層（“免費”、“共享”、“基本”、“標準”、“高級”、“高級 V2”、“高級 V3”、“獨立”、“獨立 V2”）

? ?這使得基于該應用服務計劃的Web服務資源能夠對應到指定資源級別、指定服務價格的硬件來運行。在Azure PowerShell的輸出信息里查找，確實找到了相關的信息：

• webSpace。我的例子里為”modoo.top-WestUSwebspace"。實際上我有理由猜測，這就是原始資源組信息的來源。也就是創建應用服務計劃時，所在的資源組信息。

• subscrition。訂閱的ID號。當我完成跨訂閱的遷移時，我看到這個訂閱ID確實改成了目標訂閱的訂閱ID。

• mdmId。我猜測這是管理硬件需要的信息。我的例子里這是以“waws-prod-bay-"開始的一串字符，我覺得這有可能就是硬件相關資源的標識。在跨資源組遷移、跨訂閱遷移過程中，這個值一直沒有變化。

? ?正是由于一系列Web應用必須關聯到某一特定應用服務計劃，而應用服務計劃又關聯到邏輯上的應用服務場，所以跨訂閱遷移才要求把所有的資源挪回原始資源組一并遷移吧。這時遷移動作會一并修改“webSpace”屬性的值，從而讓應用服務計劃在新的訂閱里可以有一個新的“原始資源組”，然后再將這個應用服務計劃，也就是應用服務場關聯的所有應用服務進行元數據的修改，完成遷移工作。

? ?那么如果一開始我創建的Web應用服務和應用服務計劃就不在一個資源組呢？（這就是文章開始賣的那個關子）那遷移的時候以誰為準呢？于是我又動手試了一下，實際上即使在其他資源組創建應用服務，應用服務仍然會以創建應用服務計劃的資源組作為所有這些資源的“原始資源組”。

? ? 我們終于搞清楚了Web應用服務和應用服務計劃遷移的細節，這更堅定了我使用應用服務而不是虛擬機放置我的網站的信心～畢竟，應用服務可省錢多了～

參考鏈接微信防吞：

遷移的資源: https://docs.microsoft.com/zh-cn/azure/azure-resource-manager/management/move-support-resources?WT.mc_id=Azure-MVP-33253

跨資源組/訂閱移動: https://docs.microsoft.com/zh-cn/azure/azure-resource-manager/management/move-resource-group-and-subscription?WT.mc_id=Azure-MVP-33253

應用服務計劃概述: https://docs.microsoft.com/zh-cn/azure/app-service/overview-hosting-plans?WT.mc_id=Azure-MVP-33253