Поделиться через

Что такое Azure Resource Manager?

  • Статья

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

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

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

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

На следующей схеме показана роль, которую Resource Manager играет во время запросов Azure:

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

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

Внимание

Resource Manager перестанет поддерживать протоколы, старше TLS 1.2 1 марта 2025 г. Дополнительные сведения см. в статье "Миграция на TLS 1.2 для Azure Resource Manager".

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

Если вы не знакомы с Resource Manager, возможно, вы не знакомы со следующими терминами:

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

  • Группа ресурсов — контейнер, содержащий связанные ресурсы для решения Azure. Группа ресурсов содержит ресурсы, которыми вы хотите управлять как группой. Решение о том, что должно входить в группу ресурсов, принимается исходя из нужд организации. См. раздел " Что такое группа ресурсов?".

  • Поставщик ресурсов — служба, которая предоставляет ресурсы Azure. Например, распространенный поставщик ресурсов — это Microsoft.Compute, который предоставляет ресурс виртуальной машины. Microsoft.Storage является еще одним распространенным поставщиком ресурсов. Ознакомьтесь с разделом Поставщики и типы ресурсов Azure.

  • декларативный синтаксис — синтаксис, позволяющий указать сообщение "Вот что я намерен создать", не записывая последовательность команд программирования для ее создания. В качестве примеров декларативного синтаксиса можно назвать шаблоны ARM и файлы Bicep. В таких файлах вы указываете свойства для инфраструктуры, развертываемой в Azure.

  • Шаблон ARM — это файл в формате JSON (нотация объектов JavaScript), который определяет один или несколько ресурсов для развертывания в группе ресурсов, подписке, группе управления или арендаторе. Используйте шаблон для последовательного и многократного развертывания ресурсов. Ознакомьтесь с общими сведениями о развертывании шаблонов ARM.

  • Файл Bicep используется для декларативного развертывания ресурсов Azure. Bicep — это язык, разработанный для обеспечения оптимальной разработки решений инфраструктуры как кода в Azure. Дополнительные сведения о Bicep см. в статье "Что такое Bicep?"

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

Дополнительные определения терминологии Azure см . в основных понятиях Azure.

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные сведения об управлении удостоверениями и доступом в Azure см. в статье "Что такое идентификатор Microsoft Entra?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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