Azure 跨订阅迁移资源踩坑记

突然收到微软的邮件，提示我的一个 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