Azure Resource Manager и классическое развертывание: сведения о моделях развертывания и состоянии ресурсовAzure Resource Manager vs. classic deployment: Understand deployment models and the state of your resources

Примечание

Сведения в этой статье применимы только при миграции из классической модели развертывания в развертывание Azure Resource Manager.The information provided in this article is only used when you migrate from the classic deployment to the Azure Resource Manager deployment.

В этой статье содержатся сведения о классической модели развертывания и модели развертывания с помощью Azure Resource Manager.In this article, you learn about Azure Resource Manager and classic deployment models. Модель развертывания с помощью Azure 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 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.If you are new to Resource Manager, you may want to first review the terminology defined in the Azure Resource Manager overview.

Примечание

Эта статья была изменена и теперь содержит сведения о новом модуле Az для Azure PowerShell.This article has been updated to use the new Azure PowerShell Az module. Вы по-прежнему можете использовать модуль AzureRM, исправления ошибок для которого будут продолжать выпускаться как минимум до декабря 2020 г.You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. Дополнительные сведения о совместимости модуля Az с AzureRM см. в статье Introducing the new Azure PowerShell Az module (Знакомство с новым модулем Az для Azure PowerShell).To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. Инструкции по установке модуля Az см. в статье об установке Azure PowerShell.For Az module installation instructions, see Install Azure PowerShell.

История моделей развертывания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.

С появлением Resource Manager (в 2014 г.) было добавлено понятие группы ресурсов.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. Модель развертывания диспетчера ресурсов предоставляет несколько преимуществ.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 are deployed in the correct order.

При появлении диспетчера ресурсов все ресурсы были добавлены в группы ресурсов по умолчанию.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. Однако только принадлежность к группе ресурсов не означает, что ресурс был преобразован в модель диспетчера ресурсов.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. Облачные службы не поддерживают модель развертывания с помощью 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-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          : westus
SubscriptionId    : {guid}

Однако командлет Resource Manager Get-AzVM возвращает только виртуальные машины, развернутые с помощью Resource Manager.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

Теги поддерживаются только ресурсами, созданными с помощью диспетчера ресурсов.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 NIC defined in the Network resource provider (required) and an availability set defined in the Compute resource provider (optional).
  • Сетевая карта ссылается на назначенный виртуальной машине 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).
  • Экземпляр балансировщика нагрузки ссылается на внутренний пул IP-адресов, которые включают сетевую карту виртуальной машины (необязательно), и ссылается на общедоступный или частный 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:

классическая архитектура

Классическое решение для размещения виртуальной машины включает в себя следующие компоненты: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-адрес и конечные точки по умолчанию, чтобы разрешить трафик удаленного рабочего стола и удаленный трафик PowerShell для виртуальных машин на основе Windows, а также трафик Secure Shell (SSH) для виртуальных машин на основе Linux.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 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).

В следующей таблице описаны изменения во взаимодействии поставщиков вычислительных, сетевых ресурсов и ресурсов хранения: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 Для виртуальной машины необходима учетная запись хранения, в которой хранятся виртуальные жесткие диски для операционной системы, а также временные и дополнительные диски данных.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. Для упрощения концепция территориальных групп больше не применяется в интерфейсах API, предоставляемых в диспетчере ресурсов Azure.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-адресов, который включают сетевую карту виртуальной машины (необязательно), и ссылается на общедоступный или частный 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 При добавлении виртуальной машины в облачную службу облачные службы получают виртуальный 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. Их можно защитить с помощью групп безопасности.Public IPs can be secured using Security Groups.
Зарезервированный IP-адресReserved IP Address Вы можете зарезервировать IP-адрес в Azure и связать его с облачной службой, чтобы убедиться, что его можно назначить.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-адрес для каждой виртуальной машиныPublic IP Address (PIP) per VM Общедоступные IP-адреса можно также связать с виртуальной машиной напрямую.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.cloudapp.net.For example: mycoffeeshop.cloudapp.net. DNS-имена являются необязательными параметрами, которые можно указать в ресурсе общедоступного IP-адреса.DNS Names are optional parameters that can be specified on a Public IP Address resource. Формат полного доменного имени — <domainlabel>.<region>.cloudapp.azure.com.The FQDN is in the following format - <domainlabel>.<region>.cloudapp.azure.com.
Сетевые интерфейсы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 ManagerMigrate 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 ManagerTechnical deep dive on platform-supported migration from classic to Azure Resource Manager
  2. Поддерживаемый платформой перенос ресурсов IaaS из классической модели в модель Azure Resource ManagerPlatform supported migration of IaaS resources from Classic to Azure Resource Manager
  3. Перенос ресурсов IaaS из классической модели в модель Azure Resource Manager с помощью Azure PowerShellMigrate IaaS resources from classic to Azure Resource Manager by using Azure PowerShell
  4. Перенос ресурсов IaaS из классического развертывания в развертывание с помощью Azure Resource Manager с использованием Azure CLIMigrate 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.

Могу ли я продолжить использовать свои автоматизированные сценарии для подготовки виртуальных машин, виртуальных сетей и учетных записей хранения с помощью новых интерфейсов API Resource Manager?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 Resource Manager.A comprehensive set of starter templates can be found on Azure Resource Manager Quickstart Templates.

Следующие шагиNext steps