Azure 资源管理器与经典部署:了解部署模型和资源状态Azure Resource Manager vs. classic deployment: Understand deployment models and the state of your resources


仅当从经典部署迁移到 Azure 资源管理器部署时,才会使用本文中提供的信息。The information provided in this article is only used when you migrate from the classic deployment to the Azure Resource Manager deployment.

本文介绍 Azure 资源管理器和经典部署模型。In this article, you learn about Azure Resource Manager and classic deployment models. Resource Manager 和经典部署模型表示部署和管理 Azure 解决方案的两种不同方式。The Resource Manager and classic deployment models represent two different ways of deploying and managing your Azure solutions. 通过两个不同的 API 集来处理它们,且部署的资源可能包含重要差异。You work with them through two different API sets, and the deployed resources can contain important differences. 这两个模型互不兼容。The two models aren't compatible with each other. 本文介绍这些差异。This article describes those differences.

为了简化资源部署和管理,Azure 建议对所有新资源使用 Resource Manager。To simplify the deployment and management of resources, Azure recommends that you use Resource Manager for all new resources. Azure 建议在可能情况下,通过 Resource Manager 重新部署现有资源。If possible, Azure recommends that you redeploy existing resources through Resource Manager.

如果不熟悉 Resource Manager,请先查看 Azure Resource Manager 概述中定义的术语。If you're new to Resource Manager, you may want to first review the terminology defined in the Azure Resource Manager overview.

部署模型的历史History of the deployment models

Azure 最初只提供经典部署模型。Azure originally provided only the classic deployment model. 在此模型中,每个资源彼此独立;无法将相关的资源组合在一起。In this model, each resource existed independently; there was no way to group related resources together. 因此,必须手动跟踪构成解决方案或应用程序的资源 ,并记得以协调的方式管理。Instead, you had to manually track which resources made up your solution or application, and remember to manage them in a coordinated approach. 部署解决方案有两种方式:通过门户单独创建每个资源;或创建一个脚本,以正确的顺序部署所有资源。To deploy a solution, you had to either create each resource individually through the portal or create a script that deployed all the resources in the correct order. 若要删除解决方案,必须逐个删除每个资源。To delete a solution, you had to delete each resource individually. 无法轻松应用和更新相关资源的访问控制策略。You couldn't easily apply and update access control policies for related resources. 最后,无法将标记应用到资源,因此无法使用有助于监视资源和管理计费的术语来标记资源。Finally, you couldn't apply tags to resources to label them with terms that help you monitor your resources and manage billing.

Azure 在 2014 年引入了 Resource Manager,增加了资源组这一概念。In 2014, Azure introduced Resource Manager, which added the concept of a resource group. 资源组是一种容器,专门容纳共享同一生命周期的资源。A resource group is a container for resources that share a common lifecycle. Resource Manager 部署模型具有几大优点:The Resource Manager deployment model provides several benefits:

  • 用户可以采用群组形式部署、管理和监视解决方案的所有服务,无需单独处理。You can deploy, manage, and monitor all the services for your solution as a group, rather than handling these services individually.
  • 可以在解决方案的整个生命周期内重复部署该解决方案,确保以一致的状态部署资源。You can repeatedly deploy your solution throughout its lifecycle and have confidence your resources are deployed in a consistent state.
  • 可以将访问控制应用到资源组中的所有资源。将新资源添加到资源组时,会自动应用这些策略。You can apply access control to all resources in your resource group, and those policies are automatically applied when new resources are added to the resource group.
  • 可以将标记应用到资源,以逻辑方式组织订阅中的所有资源。You can apply tags to resources to logically organize all the resources in your subscription.
  • 可以使用 JavaScript 对象表示法 (JSON) 来定义解决方案的基础结构。You can use JavaScript Object Notation (JSON) to define the infrastructure for your solution. JSON 文件称为 Resource Manager 模板。The JSON file is known as a Resource Manager template.
  • 可以定义各资源之间的依赖关系,使其按正确的顺序进行部署。You can define the dependencies between resources so they're deployed in the correct order.

添加 Resource Manager 时,所有资源都追溯性地添加到默认资源组。When Resource Manager was added, all resources were retroactively added to default resource groups. 如果现在通过经典部署创建资源,无论部署时指定资源组与否,资源都会在该服务默认的资源组中自动创建。If you create a resource through classic deployment now, the resource is automatically created within a default resource group for that service, even though you did not specify that resource group at deployment. 但是,资源位于资源组内并不意味着其已转换为 Resource Manager 模型。However, just existing within a resource group does not mean that the resource has been converted to the Resource Manager model.

了解对模型的支持Understand support for the models

下面是需要了解的三种情况:There are three scenarios to be aware of:

  1. 云服务不支持资源管理器部署模型。Cloud Services does not support Resource Manager deployment model.
  2. 虚拟机、存储帐户和虚拟网络同时支持资源管理器和经典部署模型。Virtual machines, storage accounts, and virtual networks support both Resource Manager and classic deployment models.
  3. 其他所有 Azure 服务都支持资源管理器。All other Azure services support Resource Manager.

对于虚拟机、存储帐户和虚拟网络,如果资源是通过经典部署创建的,则必须继续通过经典操作对其进行操作。For virtual machines, storage accounts, and virtual networks, if the resource was created through classic deployment, you must continue to operate on it through classic operations. 如果虚拟机、存储帐户或虚拟网络是通过 Resource Manager 部署创建的,则必须继续使用 Resource Manager 操作。If the virtual machine, storage account, or virtual network was created through Resource Manager deployment, you must continue using Resource Manager operations. 如果订阅包含通过 Resource Manager 和经典部署创建的各种资源,则可能不容易进行这种区分。This distinction can get confusing when your subscription contains a mix of resources created through Resource Manager and classic deployment. 此资源组合会产生意外的结果,因为资源不支持相同的操作。This combination of resources can create unexpected results because the resources do not support the same operations.

在某些情况下,Resource Manager 命令可以检索通过经典部署创建的资源信息,或者执行管理任务,例如将经典资源移到另一个资源组。In some cases, a Resource Manager command can retrieve information about a resource created through classic deployment, or can perform an administrative task such as moving a classic resource to another resource group. 但这些情况并不意味着该类型支持 Resource Manager 操作。But, these cases should not give the impression that the type supports Resource Manager operations. 例如,假设某个资源组包含使用经典部署创建的虚拟机。For example, suppose you have a resource group that contains a virtual machine that was created with classic deployment. 如果运行以下 Resource Manager PowerShell 命令:If you run the following Resource Manager PowerShell command:

Get-AzResource -ResourceGroupName ExampleGroup -ResourceType Microsoft.ClassicCompute/virtualMachines

这会返回虚拟机:It returns the virtual machine:

Name              : ExampleClassicVM
ResourceId        : /subscriptions/{guid}/resourceGroups/ExampleGroup/providers/Microsoft.ClassicCompute/virtualMachines/ExampleClassicVM
ResourceName      : ExampleClassicVM
ResourceType      : Microsoft.ClassicCompute/virtualMachines
ResourceGroupName : ExampleGroup
Location          : chinanorth
SubscriptionId    : {guid}

但是,资源管理器 cmdlet Get-AzVM 仅返回通过资源管理器部署的虚拟机。However, the Resource Manager cmdlet Get-AzVM only returns virtual machines deployed through Resource Manager. 以下命令不返回通过经典部署创建的虚拟机。The following command does not return the virtual machine created through classic deployment.

Get-AzVM -ResourceGroupName ExampleGroup

只有通过 Resource Manager 创建的资源才支持标记。Only resources created through Resource Manager support tags. 不能将标记应用到经典资源。You cannot apply tags to classic resources.

有关计算、网络和存储的更改Changes for compute, network, and storage

下图显示通过 Resource Manager 部署的计算、网络和存储资源。The following diagram displays compute, network, and storage resources deployed through Resource Manager.

Resource Manager 体系结构

请注意资源之间的以下关系:Note the following relationships between the resources:

  • 所有资源都存在于资源组中。All the resources exist within a resource group.
  • 虚拟机依赖在存储资源提供程序中定义的特定存储帐户,以将其磁盘存储在 Blob 存储中(必需)。The virtual machine depends on a specific storage account defined in the Storage resource provider to store its disks in blob storage (required).
  • 虚拟机引用在网络资源提供程序中定义的特定网络接口卡(必需)和在计算资源提供程序中定义的可用性集(可选)。The virtual machine references a specific network interface card defined in the Network resource provider (required) and an availability set defined in the Compute resource provider (optional).
  • 网络接口卡引用虚拟机的分配 IP 地址(必需)、虚拟机虚拟网络的子网(必需)和网络安全组(可选)。The network interface card references the virtual machine's assigned IP address (required), the subnet of the virtual network for the virtual machine (required), and to a Network Security Group (optional).
  • 虚拟网络内的子网引用网络安全组(可选)。The subnet within a virtual network references a Network Security Group (optional).
  • 负载均衡器实例引用后端 IP 地址池,包括虚拟机的网络接口卡(可选),并引用负载均衡器的公共或专用 IP 地址(可选)。The load balancer instance references the backend pool of IP addresses that include the network interface card of a virtual machine (optional) and references a load balancer public or private IP address (optional).

以下是经典部署的组件及其关系:Here are the components and their relationships for classic deployment:


托管虚拟机的经典解决方案包括:The classic solution for hosting a virtual machine includes:

  • 一项必不可少的云服务,用作宿主虚拟机的容器(计算)。A required cloud service that acts as a container for hosting virtual machines (compute). 虚拟机自动配备一个网络接口卡以及由 Azure 分配的 IP 地址。Virtual machines are automatically provided with a network interface card and an IP address assigned by Azure. 此外,云服务包含一个外部负载均衡器实例、一个公共 IP 地址以及若干默认终结点,以支持远程桌面、针对 Windows 虚拟机的远程 PowerShell 流量和针对 Linux 虚拟机的 Secure Shell (SSH) 流量。Additionally, the cloud service contains an external load balancer instance, a public IP address, and default endpoints to allow remote desktop and remote PowerShell traffic for Windows-based virtual machines and Secure Shell (SSH) traffic for Linux-based virtual machines.
  • 一个必不可少的存储帐户,它用于存储虚拟机的虚拟硬盘,包括操作系统、临时文件和附加的数据磁盘(存储)。A required storage account that stores the virtual hard disks for a virtual machine, including the operating system, temporary, and additional data disks (storage).
  • 一个可选的虚拟网络,用作额外的容器,可以在其中创建子网结构并选择虚拟机所在的子网(网络)。An optional virtual network that acts as an additional container, in which you can create a subnetted structure and choose the subnet on which the virtual machine is located (network).

下表介绍了计算、网络和存储资源提供程序交互方式的更改:The following table describes changes in how Compute, Network, and Storage resource providers interact:

ItemItem 经典Classic 资源管理器Resource Manager
面向虚拟机的云服务Cloud Service for Virtual Machines 云服务是一个容器,用于容纳要求平台可用性和负载均衡的虚拟机。Cloud Service was a container for holding the virtual machines that required Availability from the platform and Load Balancing. 使用新模型,云服务不再是创建虚拟机所必需的对象。Cloud Service is no longer an object required for creating a Virtual Machine using the new model.
虚拟网络Virtual Networks 可以选择将虚拟机用于虚拟网络。A virtual network is optional for the virtual machine. 虚拟网络(如果包括)不能通过资源管理器进行部署。If included, the virtual network can't be deployed with Resource Manager. 虚拟机需要已使用 Resource Manager 部署的虚拟网络。Virtual machine requires a virtual network that has been deployed with Resource Manager.
存储帐户Storage Accounts 虚拟机需要一个存储帐户,用于存储操作系统、临时文件和附加数据磁盘的虚拟硬盘。The virtual machine requires a storage account that stores the virtual hard disks for the operating system, temporary, and additional data disks. 虚拟机需要一个用于将其磁盘存储在 Blob 存储中的存储帐户。The virtual machine requires a storage account to store its disks in blob storage.
可用性集Availability Sets 通过在虚拟机上配置相同的“AvailabilitySetName”来指出平台的可用性。Availability to the platform was indicated by configuring the same "AvailabilitySetName" on the Virtual Machines. 容错域的最大数量为 2。The maximum count of fault domains was 2. 可用性集是 Microsoft.Compute 提供程序提供的一个资源。Availability Set is a resource exposed by Microsoft.Compute Provider. 要求高可用性的虚拟机必须包含在可用性集中。Virtual Machines that require high availability must be included in the Availability Set. 现在,容错域的最大数量为 3。The maximum count of fault domains is now 3.
地缘组Affinity Groups 创建虚拟网络需要地缘组。Affinity Groups were required for creating Virtual Networks. 但是,随着区域虚拟网络的引入,不再需要地缘组了。However, with the introduction of Regional Virtual Networks, that wasn't required anymore. 为了简单起见,地缘组概念不再存在于通过 Azure Resource Manager 提供的 API 中。To simplify, the Affinity Groups concept doesn't exist in the APIs exposed through Azure Resource Manager.
负载均衡Load Balancing 云服务的创建为部署的虚拟机提供了一个隐式负载均衡器。Creation of a Cloud Service provides an implicit load balancer for the Virtual Machines deployed. 负载均衡器是 Microsoft.Network 提供程序提供的一个资源。The Load Balancer is a resource exposed by the Microsoft.Network provider. 需要负载均衡的虚拟机的主网络接口应该引用负载均衡器。The primary network interface of the Virtual Machines that needs to be load balanced should be referencing the load balancer. 负载均衡器既可以是内部的,也可以是外部的。Load Balancers can be internal or external. 负载均衡器实例引用后端 IP 地址池,包括虚拟机的 NIC(可选),引用负载均衡器的公共或专用 IP 地址(可选)。A load balancer instance references the backend pool of IP addresses that include the NIC of a virtual machine (optional) and references a load balancer public or private IP address (optional).
虚拟 IP 地址Virtual IP Address 将 VM 添加到云服务后,云服务会获得默认 VIP(虚拟 IP 地址)。Cloud Services gets a default VIP (Virtual IP Address) when a VM is added to a cloud service. 虚拟 IP 地址是与隐式负载均衡器相关联的地址。The Virtual IP Address is the address associated with the implicit load balancer. 公共 IP 地址是 Microsoft.Network 提供程序提供的一个资源。Public IP address is a resource exposed by the Microsoft.Network provider. 公共 IP 地址既可以是静态(保留)的,也可以是动态的。Public IP address can be static (reserved) or dynamic. 可以将动态公共 IP 分配给一个负载均衡器。Dynamic public IPs can be assigned to a Load Balancer. 可以使用安全组保护公共 IP。Public IPs can be secured using Security Groups.
保留 IP 地址Reserved IP Address 可以在 Azure 中保留一个 IP 地址并将其与一个云服务关联在一起,以确保该 IP 地址具有粘性。You can reserve an IP Address in Azure and associate it with a Cloud Service to ensure that the IP Address is sticky. 可以在“静态”模式下创建公共 IP 地址,并且该地址提供与“保留 IP 地址”相同的功能。Public IP Address can be created in static mode and it offers the same capability as a reserved IP address.
每个虚拟机一个公共 IP 地址 (PIP)Public IP Address (PIP) per VM 公共 IP 地址也可以直接关联到 VM。Public IP Addresses can also be associated to a VM directly. 公共 IP 地址是 Microsoft.Network 提供程序提供的一个资源。Public IP address is a resource exposed by the Microsoft.Network provider. 公共 IP 地址既可以是静态(保留)的,也可以是动态的。Public IP Address can be static (reserved) or dynamic.
终结点Endpoints 需要在虚拟机上配置输入终结点,用于打开某些端口的连接。Input Endpoints needed to be configured on a Virtual Machine to be open up connectivity for certain ports. 这是通过设置输入终结点来连接到虚拟机的一个常见模式。One of the common modes of connecting to virtual machines done by setting up input endpoints. 可以在负载均衡器上配置入站 NAT 规则,实现在具体端口上启用终结点以连接到虚拟机的相同功能。Inbound NAT Rules can be configured on Load Balancers to achieve the same capability of enabling endpoints on specific ports for connecting to the VMs.
DNS 名称DNS Name 云服务会得到一个隐式的全局唯一 DNS 名称。A cloud service would get an implicit globally unique DNS Name. 例如:mycoffeeshop.chinacloudapp.cnFor example: DNS 名称是可在一个公共 IP 地址资源中指定的可选参数。DNS Names are optional parameters that can be specified on a Public IP Address resource. FQDN 采用以下格式 - <domainlabel>.<region>.cloudapp.chinacloudapi.cnThe FQDN is in the following format - <domainlabel>.<region>
网络接口Network Interfaces 作为虚拟机的网络配置定义主网络接口和辅助网络接口及其属性。Primary and Secondary Network Interface and its properties were defined as network configuration of a Virtual machine. 网络接口是 Microsoft.Network 提供程序提供的一个资源。Network Interface is a resource exposed by Microsoft.Network Provider. 网络接口的生命周期与虚拟机无关。The lifecycle of the Network Interface isn't tied to a Virtual Machine. 它引用虚拟机的分配 IP 地址(必需)、虚拟机虚拟网络的子网(必需)和网络安全组(可选)。It references the virtual machine's assigned IP address (required), the subnet of the virtual network for the virtual machine (required), and to a Network Security Group (optional).

若要了解如何从不同部署模型连接虚拟网络,请参阅从门户中的不同部署模型中连接虚拟网络To learn about connecting virtual networks from different deployment models, see Connect virtual networks from different deployment models in the portal.

从经典部署迁移到 Resource Manager 部署Migrate from classic to Resource Manager

如果已准备好将资源从经典部署迁移到 Resource Manager 部署,请参阅:If you're ready to migrate your resources from classic deployment to Resource Manager deployment, see:

  1. 有关平台支持的从经典部署模型到 Azure 资源管理器部署模型的迁移的技术深入探讨Technical deep dive on platform-supported migration from classic to Azure Resource Manager
  2. 平台支持的从经典部署模型到 Azure 资源管理器部署模型的 IaaS 资源迁移Platform supported migration of IaaS resources from Classic to Azure Resource Manager
  3. 使用 Azure PowerShell 将 IaaS 资源从经典部署模型迁移到 Azure 资源管理器部署模型Migrate IaaS resources from classic to Azure Resource Manager by using Azure PowerShell
  4. 使用 Azure CLI 将 IaaS 资源从经典部署模型迁移到 Azure 资源管理器部署模型Migrate IaaS resources from classic to Azure Resource Manager by using Azure CLI

常见问题Frequently asked questions

我能使用资源管理器创建虚拟机,以将其部署到使用经典部署创建的虚拟网络中吗?Can I create a virtual machine using Resource Manager to deploy in a virtual network created using classic deployment?

此配置不受支持。This configuration isn't supported. 不能使用资源管理器将虚拟机部署到使用经典部署创建的虚拟网络中。You can't use Resource Manager to deploy a virtual machine into a virtual network that was created using classic deployment.

我能使用资源管理器从使用经典部署模型创建的用户映像创建虚拟机吗?Can I create a virtual machine using Resource Manager from a user image that was created using the classic deployment model?

此配置不受支持。This configuration isn't supported. 但是,可以从使用经典部署模型创建的存储帐户中复制虚拟硬盘文件,并将其添加到通过资源管理器创建的新帐户中。However, you can copy the virtual hard disk files from a storage account that was created using the classic deployment model, and add them to a new account created through Resource Manager.

对我的订阅的配额有何影响?What is the impact on the quota for my subscription?

通过 Azure 资源管理器创建的虚拟机、虚拟网络和存储帐户的配额与其他配额是分开的。The quotas for the virtual machines, virtual networks, and storage accounts created through the Azure Resource Manager are separate from other quotas. 每个订阅都将获取配额,以使用新的 API 创建资源。Each subscription gets quotas to create the resources using the new APIs. 可以在 此处了解有关额外配额的详细信息。You can read more about the additional quotas here.

我能通过 Resource Manager API 继续使用自动化脚本来预配虚拟机、虚拟网络和存储帐户资源吗?Can I continue to use my automated scripts for provisioning virtual machines, virtual networks, and storage accounts through the Resource Manager APIs?

所构建的所有自动化和脚本将继续适用于在 Azure 服务管理模式下创建的现有虚拟机和虚拟网络。All the automation and scripts that you've built continue to work for the existing virtual machines, virtual networks created under the Azure Service Management mode. 然而,必须更新这些脚本以使用新的架构,通过 Resource Manager 模式来创建相同的资源。However, the scripts have to be updated to use the new schema for creating the same resources through the Resource Manager mode.

在哪里可以找到 Azure 资源管理器模板的示例?Where can I find examples of Azure Resource Manager templates?

可以在 Azure 资源管理器快速入门模板中找到一系列综合的初学者模板。A comprehensive set of starter templates can be found on Azure Resource Manager Quickstart Templates.

后续步骤Next steps