Azure Resource Manager とクラシック デプロイ: デプロイ モデルとリソースの状態についてAzure Resource Manager vs. classic deployment: Understand deployment models and the state of your resources

この記事では、Azure Resource Manager デプロイ モデルとクラシック デプロイ モデルについて学習します。In this article, you learn about Azure Resource Manager and classic deployment models. Resource Manager デプロイメント モデルとクラシック デプロイメント モデルは、Azure ソリューションのデプロイと管理における 2 種類の異なる方法です。The Resource Manager and classic deployment models represent two different ways of deploying and managing your Azure solutions. 異なる 2 種類の API セットを使用することで、デプロイしたリソースには重要な相違点が存在する可能性があります。You work with them through two different API sets, and the deployed resources can contain important differences. これらの 2 つのモデルに互換性はありません。The two models are not compatible with each other. この記事では、その相違点について説明します。This article describes those differences.

リソースのデプロイと管理を簡単にするために、すべての新しいリソースに Resource Manager を利用することが推奨されています。To simplify the deployment and management of resources, Microsoft recommends that you use Resource Manager for all new resources. 可能であれば、Resource Manager を使用して既存のリソースを再度デプロイすることをお勧めします。If possible, Microsoft recommends that you redeploy existing resources through Resource Manager.

これまでに Resource Manager を使用したことがない場合は、まず「Azure Resource Manager の概要」で定義されている用語をご確認ください。If you are 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 could not easily apply and update access control policies for related resources. そのうえ、タグをリソースに適用し、リソースの監視と請求の管理に役立つ単語を使ってこれらのリソースにラベル付けすることもできませんでした。Finally, you could not apply tags to resources to label them with terms that help you monitor your resources and manage billing.

2014 年、Azure に 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 Object Notation (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 are 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

次の 3 種類のシナリオに注意してください。There are three scenarios to be aware of:

  1. Cloud Services では、Resource Manager デプロイ モデルはサポートされていません。Cloud Services does not support Resource Manager deployment model.
  2. 仮想マシン、ストレージ アカウント、仮想ネットワークでは、Resource Manager デプロイ モデルとクラシック デプロイ モデルの両方がサポートされています。Virtual machines, storage accounts, and virtual networks support both Resource Manager and classic deployment models.
  3. その他のすべての Azure サービスでは、Resource Manager がサポートされています。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-AzureRmResource -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          : westus
SubscriptionId    : {guid}

ただし、Resource Manager コマンドレット Get-AzureRmVM を実行した場合は、Resource Manager でデプロイされた仮想マシンのみが返されます。However, the Resource Manager cmdlet Get-AzureRmVM only returns virtual machines deployed through Resource Manager. 次のコマンドでは、クラシック デプロイメントで作成された仮想マシンは返されません。The following command does not return the virtual machine created through classic deployment.

Get-AzureRmVM -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 architecture

次に挙げるリソース間の関係を確認してください。Note the following relationships between the resources:

  • すべてのリソースがリソース グループ内に存在します。All the resources exist within a resource group.
  • 仮想マシンは、ディスクを BLOB ストレージ (必須) に保存するために、Storage リソース プロバイダーで定義されている特定のストレージ アカウントに依存します。The virtual machine depends on a specific storage account defined in the Storage resource provider to store its disks in blob storage (required).
  • 仮想マシンは、Network リソース プロバイダー (必須) で定義されている特定の NIC と、Compute リソース プロバイダー (オプション) で定義されている可用性セットを参照します。The virtual machine references a specific NIC defined in the Network resource provider (required) and an availability set defined in the Compute resource provider (optional).
  • NIC は、仮想マシンに割り当てられた IP アドレス (必須)、仮想マシンの仮想ネットワークのサブネット (必須)、ネットワーク セキュリティ グループ (オプション) を参照します。The NIC 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).
  • Load Balancer のインスタンスは、仮想マシンの NIC (オプション) を含む IP アドレスのバックエンド プールと、Load Balancer パブリックまたはプライベート IP アドレス (オプション) を参照します。The 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).

次にコンポーネントと、クラシック デプロイメントにおけるコンポーネントの関係を示します。Here are the components and their relationships for classic deployment:

classic architecture

仮想マシンをホストする従来のソリューションは次のとおりです。The classic solution for hosting a virtual machine includes:

  • 仮想マシンをホストするためのコンテナーとして機能する必須のクラウド サービス (コンピューティング) A required cloud service that acts as a container for hosting virtual machines (compute). 仮想マシンにはネットワーク インターフェイス カード (NIC) が自動的に提供され、IP アドレスは Azure によって割り当てられます。Virtual machines are automatically provided with a network interface card (NIC) 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.
  • オペレーティング システム、一時、および追加のデータ ディスク (ストレージ) を含む、仮想マシンの VHD を格納するのに必要なストレージ アカウント。A required storage account that stores the VHDs 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 designate the subnet on which the virtual machine is located (network).

次の表では、Compute、Network、Storage のリソース プロバイダーの相互作用の変化について説明します。The following table describes changes in how Compute, Network, and Storage resource providers interact:

項目Item クラシックClassic Resource ManagerResource 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. 使用すると、仮想ネットワークは Resource Manager でデプロイできなくなります。If included, the virtual network cannot be deployed with Resource Manager. 仮想マシンには、Resource Manager でデプロイされた仮想ネットワークが必要です。Virtual machine requires a virtual network that has been deployed with Resource Manager.
ストレージ アカウントStorage Accounts 仮想マシンには、オペレーティング システム、一時データ ディスク、追加データ ディスクの VHD を格納するためのストレージ アカウントが必要です。The virtual machine requires a storage account that stores the VHDs 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 was not 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. ロード バランサーのインスタンスは仮想マシンの NIC を含め(オプション)、ロード バランサーのパブリックまたはプライベート IP アドレス (オプション) を参照している 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). 詳細については、こちらを参照してください。Read more.
仮想 IP アドレスVirtual IP Address Cloud Services では、クラウド サービスに 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 IP アドレスを Azure で予約し、クラウド サービスに関連付けることで、その 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.
VM ごとのパブリック 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. 入力エンドポイントを設定することによって仮想マシンに接続する一般的なモードの 1 つ。One of the common modes of connecting to virtual machines done by setting up input endpoints. VM への接続用に特定のポートのエンドポイントを有効にする機能は、ロード バランサーに受信 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. (例:。For example: DNS 名は、パブリック IP アドレス リソースに指定できる省略可能なパラメーターです。DNS Names are optional parameters that can be specified on a Public IP Address resource. FQDN は、<domainlabel>.<region> という形式です。The 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 is not 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 are ready to migrate your resources from classic deployment to Resource Manager deployment, see:

  1. プラットフォームでサポートされているクラシックから Azure Resource Manager への移行に関する技術的な詳細Technical deep dive on platform-supported migration from classic to Azure Resource Manager
  2. プラットフォームでサポートされているクラシックから Azure Resource Manager への IaaS リソースの移行Platform supported migration of IaaS resources from Classic to Azure Resource Manager
  3. Azure PowerShell を使用してクラシックから Azure Resource Manager へ IaaS リソースを移行するMigrate IaaS resources from classic to Azure Resource Manager by using Azure PowerShell
  4. Azure CLI を使用してクラシックから Azure Resource Manager へ IaaS リソースを移行するMigrate IaaS resources from classic to Azure Resource Manager by using Azure CLI

よく寄せられる質問Frequently asked questions

クラシック デプロイで作成された仮想ネットワークにデプロイする仮想マシンを、Resource Manager で作成することはできますか。Can I create a virtual machine using Resource Manager to deploy in a virtual network created using classic deployment?

この構成はサポートされていません。This configuration is not supported. Resource Manager を使用して、クラシック デプロイで作成された仮想ネットワークに仮想マシンをデプロイすることはできません。You cannot use Resource Manager to deploy a virtual machine into a virtual network that was created using classic deployment.

クラシック デプロイ モデルを使用して作成されたユーザー イメージから、Resource Manager を使用して仮想マシンを作成することはできますか。Can I create a virtual machine using Resource Manager from a user image that was created using the classic deployment model?

この構成はサポートされていません。This configuration is not supported. ただし、クラシック デプロイ モデルで作成されたストレージ アカウントから VHD ファイルをコピーし、Resource Manager で作成された新しいアカウントに追加することはできます。However, you can copy the VHD 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 Resource Manager を使用して作成された仮想マシン、仮想ネットワーク、ストレージ アカウントのクォータは、他のクォータとは区別されます。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 Service Management モードで作成された既存の仮想マシンや仮想ネットワークに使用できます。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 Resource Manager のクイックスタート テンプレートに関するページで、広範囲にわたるスターター テンプレートが提供されています。A comprehensive set of starter templates can be found on Azure Resource Manager Quickstart Templates.

次のステップNext steps