Azure Resource Manager

  • Статья

Azure Resource Manager — это служба развертывания и управления для Azure. Она обеспечивает уровень управления для создания, обновления и удаления ресурсов в учетной записи Azure. Вы можете использовать ее функции управления, такие как управление доступом, блокировка и добавление тегов, чтобы защитить и упорядочить ресурсы после развертывания.

Дополнительные сведения о шаблонах Azure Resource Manager см. в статье с общими сведениями о шаблонах ARM. Сведения о Bicep см. в обзоре Bicep.

В следующем видео рассматриваются основные понятия Azure Resource Manager.

Уровень согласованного управления

При отправке запроса с помощью любого API, инструмента или пакета SDK Azure этот запрос будет получен Azure Resource Manager. Azure Resource Manager выполнит проверку подлинности и авторизацию запроса и затем направит его в соответствующую службу Azure. Так как все запросы обрабатываются через один API, результаты и возможности будут согласованы в различных средствах.

На следующем рисунке показана роль Azure Resource Manager при обработке запросов Azure.

Схема, показывающая роль Azure Resource Manager в обработке запросов Azure.

Все доступные на портале возможности также доступны в PowerShell, Azure CLI, REST API и клиентских пакетах SDK. Функции, первоначально выпущенные через API, представлены на портале в течение 180 дней после первоначального выпуска.

Внимание

Azure Resource Manager будет поддерживать только tls 1.2 или более поздней версии к осенью 2023 года. Дополнительные сведения см. в статье "Миграция на TLS 1.2 для Azure Resource Manager".

Терминология

Если у вас еще нет опыта работы с Azure Resource Manager, возможно, некоторые термины окажутся незнакомыми.

  • Ресурс — управляемый элемент, доступный в Azure. Виртуальные машины, учетные записи хранения, веб-приложения, базы данных и виртуальные сети являются примерами ресурсов. Примеры ресурсов: группы ресурсов, подписки, группы управления и теги.
  • Группа ресурсов — контейнер, содержащий связанные ресурсы для решения Azure. Группа ресурсов содержит ресурсы, которыми вы хотите управлять как группой. Решение о том, что должно входить в группу ресурсов, принимается исходя из нужд организации. См. раздел " Что такое группа ресурсов?".
  • Поставщик ресурсов — служба, которая предоставляет ресурсы Azure. Например, распространенный поставщик ресурсов — это Microsoft.Compute, который предоставляет ресурс виртуальной машины. Microsoft.Storage является еще одним распространенным поставщиком ресурсов. См. дополнительные сведения о поставщиках и типах ресурсов.
  • Декларативный синтаксис позволяет описать объект, который вы собираетесь создать, не используя напрямую последовательность команд создания. В качестве примеров декларативного синтаксиса можно назвать шаблоны ARM и файлы Bicep. В таких файлах вы указываете свойства для инфраструктуры, развертываемой в Azure.
  • Шаблон ARM — это файл в формате JSON (нотация объектов JavaScript), который определяет один или несколько ресурсов для развертывания в группе ресурсов, подписке, группе управления или арендаторе. Шаблон можно использовать для согласованного и многократного развертывания ресурсов. См. общие сведения о развертывании шаблона.
  • Файл Bicep используется для декларативного развертывания ресурсов Azure. Bicep — это язык, разработанный для обеспечения оптимального интерфейса разработки для инфраструктуры в качестве решений кода в Azure. См. Общие сведения о Bicep
  • ресурс расширения — ресурс , добавляющий к возможностям другого ресурса. Например, назначение роли — это ресурс расширения. Назначение роли применяется к любому другому ресурсу, чтобы указать доступ. См. статью "Ресурсы расширения".

Дополнительные определения терминов, связанных с Azure, см. в разделе Основные понятия Azure.

Преимущества использования диспетчера ресурсов

С помощью Resource Manager можно:

  • Управлять своей инфраструктурой с помощью декларативных шаблонов, а не сценариев.

  • Развертывать и отслеживать все ресурсы вашего решения, а также управлять ими как единой группой, а не работать с ними по отдельности.

  • Повторно развертывать решение на протяжении всего цикла разработки и гарантировать, что ресурсы развертываются в согласованном состоянии.

  • Определять зависимости между ресурсами, чтобы их развертывание выполнялось в правильном порядке.

  • Применять управление доступом ко всем службам, так как функция управления доступом на основе ролей в Azure (Azure RBAC) изначально интегрирована в платформу управления.

  • Применять теги в ресурсах для логического упорядочивания всех ресурсов в вашей подписке к ним.

  • Узнать о выставлении счетов для вашей организации, просматривая затраты на группу ресурсов с одним тегом.

Общие сведения об области

В Azure предоставляются четыре уровня области управления: группы управления, подписки, группы ресурсов и ресурсы. Пример этих уровней показан на приведенном ниже изображении.

Схема, демонстрирующая четыре уровня область в Azure: группы управления, подписки, группы ресурсов и ресурсы.

Параметры управления применяются на любом из этих уровней. Выбранный уровень определяет масштаб применения такого параметра. Более низкие уровни наследуют параметры от более высоких уровней. Например, если политика применяется к подписке, она применяется ко всем группам ресурсов и ресурсам в подписке. Если же политика применяется к группе ресурсов, то она применяется ко всем ресурсам в ней. К остальным группам ресурсов эта политика не относится.

Сведения об управлении удостоверениями и доступом см. в разделе "Идентификатор Microsoft Entra".

Вы можете развертывать шаблоны в клиенты, группы управления, подписки или группы ресурсов.

Что такое группа ресурсов?

Группа ресурсов — это контейнер, позволяющий управлять связанными ресурсами для решения Azure. С помощью группы ресурсов можно координировать изменения связанных ресурсов. Например, можно развернуть обновление в группе ресурсов и иметь уверенность в том, что ресурсы обновляются в согласованной операции. Или, когда вы закончите работу с решением, вы можете удалить группу ресурсов и знать, что все ресурсы удаляются.

Существуют некоторые важные факторы, которые необходимо учитывать при определении группы ресурсов:

  • Все ресурсы в группе ресурсов должны совместно использовать один и тот же жизненный цикл. Развертывание, обновление и удаление производится сразу для всех ресурсов. Если один ресурс, например сервер, должен присутствовать в другом цикле развертывания, его следует поместить в другую группу ресурсов.

  • Каждый ресурс может существовать только в одной группе ресурсов.

  • Ресурс можно добавить в группу ресурсов или удалить из нее в любое время.

  • Ресурс можно перемещать из одной группы ресурсов в другую. Дополнительные сведения см. в статье Перемещение ресурсов в новую группу ресурсов или подписку.

  • Ресурсы в группе ресурсов могут находиться в разных регионах, отличных от группы ресурсов, но рекомендуется использовать то же расположение. См. сведения о расположении, в каком расположении следует использовать для моей группы ресурсов?

  • Группу ресурсов можно использовать, чтобы определить область действия управления доступом для административных действий. Для управления группой ресурсов можно назначать Политики Azure, роли Azure или блокировки ресурсов.

  • К группе ресурсов можно применять теги. Ресурсы в группе ресурсов не наследуют эти теги.

  • Ресурс может подключаться к ресурсам в других группах ресурсов. Этот сценарий является типичным, если два ресурса связаны, но не имеют общего жизненного цикла. Например, веб-приложение может подключаться к базе данных в другой группе ресурсов.

  • При удалении группы ресурсов также удаляются все ресурсы в ней. Сведения о том, как Azure Resource Manager управляет этими удалениями, см. в разделе Группа ресурсов Azure Resource Manager и удаление ресурсов.

  • В каждой группе ресурсов можно развернуть до 800 экземпляров типа ресурсов. Некоторых типов ресурсов ограничение в 800 экземпляров не касается. Дополнительные сведения см. в разделе Ограничения группы ресурсов.

  • Некоторые ресурсы могут существовать за пределами группы ресурсов. Эти ресурсы развертываются в подписке, группе управления или арендаторе. В этих областях поддерживаются только определенные типы ресурсов.

  • Чтобы создать группу ресурсов, можно использовать портал, PowerShell, Azure CLI или шаблон Azure Resource Manager.

Какое расположение следует использовать для моей группы ресурсов?

Когда вы создаете группу ресурсов, необходимо указать ее расположение.

У пользователя может возникнуть вопрос, зачем для группы ресурсов нужно расположение. И если ресурсы и группа ресурсов могут находиться в разных расположениях, то какой смысл указывать расположение группы ресурсов?

В группе ресурсов хранятся метаданные о ресурсах. Указывая расположение группы ресурсов, вы определяете расположение метаданных. В целях обеспечения соответствия необходимо убедиться, что данные хранятся в определенном регионе.

Чтобы обеспечить согласованность состояния для группы ресурсов, все операции плоскости управления направляются по расположению группы ресурсов. При выборе расположения группы ресурсов рекомендуется выбрать расположение, близкое к месту происхождения операций управления. Как правило, это расположение является ближайшим к текущему расположению. Это требование маршрутизации применяется только к операциям уровня управления для группы ресурсов. Это не влияет на запросы, отправляемые приложениям.

Если регион группы ресурсов временно недоступен, возможно, вы не сможете обновить ресурсы в группе ресурсов, так как метаданные недоступны. Ресурсы в других регионах по-прежнему работают должным образом, но вы не сможете обновить их. Это условие также может применяться к глобальным ресурсам, таким как Azure DNS, частные зоны Azure DNS, Диспетчер трафика Azure и Azure Front Door. Вы можете просмотреть, какие типы имеют метаданные, управляемые Azure Resource Manager, с помощью списка типов для таблицы ресурсов Azure Resource Graph.

Чтобы снизить влияние региональных сбоев, рекомендуется найти ресурсы в том же регионе, что и группа ресурсов. Если регион группы ресурсов недоступен, Azure Resource Manager не может обновить метаданные ресурса и блокировать вызовы записи. При совместном поиске региона ресурсов и группы ресурсов снижается риск недоступности региона, так как ресурсы и метаданные существуют в одном регионе вместо нескольких регионов.

Дополнительные сведения о создании надежных приложений см. в разделе Разработка надежных приложений Azure.

Устойчивость Azure Resource Manager

Служба Azure Resource Manager предназначена для обеспечения устойчивости и постоянной доступности. Операции Resource Manager и операции уровня управления (запросы, отправленные на management.azure.com) в REST API:

  • Распределяются между регионами. Azure Resource Manager имеет отдельный экземпляр в каждом регионе Azure, что означает, что сбой экземпляра Azure Resource Manager в одном регионе не влияет на доступность Azure Resource Manager или других служб Azure в другом регионе. Хотя Azure Resource Manager распределяется по регионам, некоторые службы являются региональными. Это различие означает, что в то время как начальная обработка операции плоскости управления устойчива, запрос может быть подвержен региональным сбоям при пересылке в службу.

  • Распределяются между зонами доступности (и регионами) в расположениях с несколькими зонами доступности. Это распределение гарантирует, что если регион теряет одну или несколько зон, Azure Resource Manager может выполнить отработку отказа в другую зону или другой регион, чтобы продолжить предоставление возможностей уровня управления для ресурсов.

  • Не зависят от единственного логического центра обработки данных.

  • Никогда не отключаются для операций обслуживания.

Эта устойчивость относится к службам, которые получают запросы через Resource Manager. Например, Key Vault получает преимущества от этой устойчивости.

Разрешение параллельных операций

Если два или более операций пытаются обновить один ресурс одновременно, Azure Resource Manager обнаруживает конфликт и разрешает успешно выполнить только одну операцию. Azure Resource Manager блокирует другие операции и возвращает ошибку.

Одновременные обновления ресурсов могут привести к непредвиденным результатам. Это решение гарантирует, что обновления являются детерминированными и надежными. Вы знаете состояние ресурсов и избегаете несоответствия или потери данных.

Предположим, что у вас есть два запроса (A и B), которые пытаются обновить один и тот же ресурс одновременно. Если запрос A завершается до запроса B, запрос A завершается успешно и запрос B завершается ошибкой. Запрос B возвращает ошибку 409. После получения этого кода ошибки можно получить обновленное состояние ресурса и определить, нужно ли повторно отправить запрос B.

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