踩坑记丨云平台跨订阅迁移资源

也想出现在这里？点击联系我~

原标题：踩坑记丨云平台跨订阅迁移资源

点击上方蓝字

关注我们

（本文阅读时间：15分钟)

大多情况下，我们都使用帐号和 Azure 订阅来订购需要的 Azure 服务，在 Azure 订阅里我们通过组织、资源组来管理我们的资源——直到有一天，可能因为公司并购、资源的跨组织迁移等原因，我们需要给资源们做迁移。

如果跨云迁移，从基础架构即代码的角度，资源迁移首先考虑的不是可以在另一订阅里重构的资源：尽可能遵循这一思想，需要迁移的资源就会尽量的少，将集中在数据库、绑定的公网 IP 等不得不进行迁移、而不是进行重构的资源。实际上，如果是从 Azure 的一个订阅到另一个订阅的迁移，由于使用的是同一家云服务，迁移就会简便快捷很多。

看我这段话写得头头是道的样子，毕竟咱也考过 Azure 云计算的认证嘛。不过我很快就被现实打脸了，哈哈哈。接下来邀请大家围观我踩坑的经过。

微软MVP实验室研究员

//

胡浩

多年从事基础架构相关工作，熟悉全栈虚拟化、终端用户和边缘计算等，对多个技术方向有所涉猎。乐于学习并分享 Azure 和 AI，曾在很多大型研讨会演讲，如微软的 TechEd、MEDC、Tech Summit、Ignite，威睿的 VMworld、vForum、ENPOWER，以及苹果、戴尔等技术会议。同时也是很多社区大会如 Global AI Bootcamp、Global Azure Bootcamp、Global M365 Bootcamp 等活动的组织者和演讲者。

踩坑实录

看着很简单吧？可是迁移一堆资源的时候，我发现报错了…提示貌似是 Web 应用服务和应用服务计划所在的资源组不对。怎么会呢？要迁移的资源不是已经乖乖地待在资源组里吗？那就查查文档吧。

先查一下哪些资源可以迁移。在 Azure 的文档里专门介绍了支持迁移的资源 ，列出了几乎所有 Azure 的资源类型是否支持三种迁移。不过，在文档里各种资源是以资源类型显示的。事后我来查看当然没啥问题，因为资源类型可以通过 Azure 门户里资源概述页面右上角的 JSON 视图查看，可以很明显的看到类似如下的属性描述：

以上仅截取部分属性显示。“type” 属性即为资源类型定义。这里显示的就是 Web 应用服务，其属性为“Microsoft.Web/sites”。在文档中查找“Microsoft.Web ”小节，就能看到对应表格里，有 sites 的资源类型对应的迁移能力为：

当然，列出的“sites”只是一个，对于我来说还需要知道一起捆绑的应用服务计划，也列出如下：

其实相关的资源还有很多，只是这个例子里我只迁移这两类资源。如果您的迁移里涉及到其他资源，可以用这篇文档来进行迁移能力确认。如果不支持直接的迁移，可能就需要做其他搬家方式的计划。例如导出为模板，修改之后在新的订阅或资源组导入。

我们先看看报错长什么样子。

这个报错其实不是原始报错截图啦～是我后面为了研究问题（什么问题先卖个关子）特意复现的。点击“错误详细信息”进去，能看到某资源在某资源组，而不在原来某资源组之类的信息，但确实可读性不高。所以我意识到，Web 应用服务和应用服务计划貌似不像虚拟机一样，直接就一股脑迁移了。似乎有着某种限制要求。

如果此时的我，是当时的我，问题就简单了。其实在我们前面查阅迁移支持的时候，在“Microsoft.Web ”小节就有个重要提示：

那么，怎么知道这些资源的原始资源组是哪个呢？

点击打开准备迁移的 Web 应用服务资源，在左侧的菜单栏找到“诊断并解决问题”，点击之后，在右侧页面找到“配置和管理”（Configuration and Management）。

进入到“配置和管理”页面之后，在左侧菜单栏点击“迁移操作“菜单，Azure 门户将会运行一个报告。等报告生成之后，就可以看到所有涉及需要一并迁移的 Web 应用服务和应用服务计划了。报告中很明显地指出了每一个资源目前和初始的资源组。

将资源移到新的资源组或订阅时，会更改该路径中的一个或多个值。

多问几个为什么？

如果这篇文章在这里结束，其实就一点意义也没有了。因为内容在微软文档站点都能找到。我要问自己一个经典的问题：为什么？

为什么必须将资源迁回原始资源组呢？为什么虚拟机等资源迁移就不需要呢？

Azure 门户里能看到的信息毕竟是有限的，所以我决定用命令行来查看迁移前后 Web 应用服务和应用服务计划资源的不同。于是我又把资源迁回去了……

试了一下，使用如下的 PowerShell 可以获取我最希望得到的资源信息。

可以看到，命令行里使用了资源类型的定义，来输出特定资源的信息。同时，我使用了管道来指定输出格式，使用 format custom 才能够看到“@”开头的全部属性信息。最后我把输出写入到一个文本文件进行比较。

同样，我昨晚迁移之后，又重复了一遍这个操作。

然后我们比较一下，迁移前后的资源，到底哪里不一样。

Web 应用服务资源其实就两个地方不同：serverFarmId 和 resourceGroup，时间相关的不同我们可以忽略。

而应用服务计划就只有一处不同：resourceGroup。

如果您创建 Web 应用服务，就会发现在创建向导中必须指定应用服务计划。这意味着，基于共享资源提供的应用服务，需要首先确定所使用的物理资源的位置。因为多个 Web 应用服务（当然不仅限于 Web 应用服务，所有使用应用服务计划的资源都一样）可以使用相同的应用服务计划，所以应用服务计划的作用对于解答我们的疑问就很重要了。

实际上，应用服务计划概述文档中已经告诉了我们足够的信息。应用服务计划为要运行的 Web 应用定义一组计算资源。这些计算资源类似传统 Web 托管方案中的服务器场。实际上，也就是针对“真实”计算资源的定义：

这使得基于该应用服务计划的 Web 服务资源能够对应到指定资源级别、指定服务价格的硬件来运行。在 Azure PowerShell 的输出信息里查找，确实找到了相关的信息：

那么如果一开始我创建的 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-subion?WT.mc_id=Azure-MVP-33253

应用服务计划概述:

https://docs.microsoft.com/zh-cn/azure/app-service/overview-hosting-plans?WT.mc_id=Azure-MVP-33253

微软最有价值专家（MVP）

微软最有价值专家是微软公司授予第三方技术专业人士的一个全球奖项。29年来，世界各地的技术社区领导者，因其在线上和线下的技术社区中分享专业知识和经验而获得此奖项。

MVP是经过严格挑选的专家团队，他们代表着技术最精湛且最具智慧的人，是对社区投入极大的热情并乐于助人的专家。MVP致力于通过演讲、论坛问答、创建网站、撰写博客、分享视频、开源项目、组织会议等方式来帮助他人，并最大程度地帮助微软技术社区用户使用 Microsoft 技术。

更多详情请登录官方网站：

https://mvp.microsoft.com/zh-cn

谢谢你读完了本文！欢迎在评论区留言分享你的想法，并且转发到朋友圈。

关注微软开发者MSDN

~返回搜狐，查看更多

责任编辑：