Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Azure Resource Manager — это служба развертывания и управления для Azure. Он предоставляет уровень управления, который помогает создавать, обновлять и удалять ресурсы в учетной записи Azure. Для защиты и упорядочивания ресурсов после развертывания используются такие функции управления, как управление доступом, блокировки и теги.
В следующем видео рассматриваются основные понятия Resource Manager:
Уровень согласованного управления
При отправке запроса с помощью любого API, инструмента или пакета SDK Azure этот запрос будет получен Azure Resource Manager. Azure Resource Manager выполнит проверку подлинности и авторизацию запроса и затем направит его в соответствующую службу Azure. Поскольку все запросы обрабатываются через один API, результаты и возможности будут единообразными во всех различных инструментах.
На следующей схеме показана роль, которую 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 см. в статье "Что такое идентификатор Microsoft Entra?
Вы можете развертывать шаблоны в арендаторы, группы управления ресурсами, подписки или группы ресурсов.
Что такое группа ресурсов?
Группа ресурсов — это контейнер, используемый для управления связанными ресурсами для решения Azure. С помощью группы ресурсов можно координировать изменения между связанными ресурсами. Например, можно развернуть обновление на группе ресурсов и иметь уверенность в том, что ресурсы обновляются в рамках согласованной операции. Или, когда вы закончите работу с решением, вы можете удалить группу ресурсов и знать, что все ресурсы удаляются.
При определении группы ресурсов необходимо учитывать некоторые важные аспекты.
Все ресурсы в вашей ресурсной группе должны иметь одинаковый жизненный цикл. Развертывание, обновление и удаление производится вместе. Например, сервер является одним ресурсом. Если он должен существовать в другом цикле развертывания, он должен находиться в другой группе ресурсов.
Каждый ресурс может существовать только в одной группе ресурсов.
Ресурс можно добавить в группу ресурсов или удалить из нее в любое время.
Ресурс можно перемещать из одной группы ресурсов в другую. Дополнительные сведения см. в статье "Перемещение ресурсов Azure в новую группу ресурсов или подписку".
Ресурсы в группе ресурсов могут находиться в разных регионах, отличных от группы ресурсов, но рекомендуется использовать то же расположение. См. Какое расположение следует выбрать для моей группы ресурсов?
Группу ресурсов можно использовать, чтобы определить область действия управления доступом для административных действий. Политики Azure, роли или блокировки ресурсов можно использовать для управления группой ресурсов.
К группе ресурсов можно применять теги. Ресурсы в группе ресурсов не наследуют эти теги.
Ресурс может подключаться к ресурсам в других группах ресурсов. Этот сценарий является типичным, если два ресурса связаны, но не имеют общего жизненного цикла. Например, веб-приложение может подключаться к базе данных в другой группе ресурсов.
При удалении группы ресурсов также удаляются все ресурсы в ней. Сведения о том, как Resource Manager управляет этими удалениями, см. в группе ресурсов Azure Resource Manager и удалении ресурсов.
В каждой группе ресурсов можно развернуть до 800 экземпляров типа ресурса. Некоторых типов ресурсов ограничение в 800 экземпляров не касается. Дополнительные сведения см. в разделе Ограничения группы ресурсов.
Некоторые ресурсы могут существовать за пределами группы ресурсов. Эти ресурсы развертываются в подписке, группе управления или арендаторе. В этих областях поддерживаются только определенные типы ресурсов.
Чтобы создать группу ресурсов, используйте портал Azure, PowerShell, Azure CLI или шаблон ARM.
Какое расположение следует использовать для моей группы ресурсов?
Когда вы создаете группу ресурсов, необходимо указать ее расположение. Вы можете задаться вопросом, почему группа ресурсов нуждается в расположении и почему расположение группы ресурсов имеет значение, если ресурсы могут иметь расположения за пределами группы ресурсов.
Группа ресурсов хранит метаданные о ресурсах. При указании расположения для группы ресурсов также указывается место хранения метаданных. По соображениям соответствия может потребоваться убедиться, что данные хранятся в определенном регионе.
Маршрутизация операций на плоскости управления, которые нацелены на ресурсы в группе ресурсов через местоположение группы ресурсов, помогает группе ресурсов оставаться в стабильном состоянии. При выборе локации группы ресурсов выбирайте место, близкое к месту запуска ваших управляющих операций — обычно ближайшее к вам. Это требование маршрутизации применяется только к операциям на плоскости управления ARM (например, для создания, обновления или удаления ресурсов через API Azure Resource Manager). Это не влияет на запросы на плоскости данных, отправляемые напрямую на ваши конечные точки ресурса, такие как HTTP-запросы в веб-приложение или операции чтения/записи в аккаунт хранения.
Если регион группы ресурсов временно недоступен, Azure Resource Manager автоматически перенаправляет запросы на плоскость управления ARM в резервную область. Этот отказ прозрачен — вы используете те же API без изменений. Однако этот отказ охватывает только операции ARM-управляющей плоскости, проходящие через группу ресурсов. Это не покрывает доступ к самим ресурсам на плоскости данных. Если регион, в котором развернут ресурс, также недоступен, доступ к этому ресурсу на плоскости данных нарушается независимо от расположения группы ресурсов. Чтобы снизить влияние региональных отключений, разместите ресурсы и группу ресурсов в одном регионе. Ознакомьтесь со списком ссылок на таблицу и тип ресурса Azure Resource Graph, чтобы просмотреть ресурсы и метаданные, которыми управляет Resource Manager.
Высокая доступность управляющей плоскости ARM для ресурсных групп поддерживается до тех пор, пока хотя бы одна из основных или резервных областей ресурсной группы остаётся доступной. Подробнее о том, как Resource Manager достигает этого в разных регионах и зонах доступности, см. раздел Resiliency of Resource Manager.
Для получения дополнительной информации о регионах резервного копирования см. раздел «Azure регионы» и «непарные регионы».
Дополнительные сведения о создании надежных приложений см. в контрольном списке устойчивости для конкретных служб 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 — это одна из служб, которые получают преимущества от этой согласованности.
Для маршрутизации Azure Resource Manager рекомендуется использовать глобальную конечную точку management.azure.com , так как она обеспечивает распределение трафика на основе DNS, автоматическую отработку отказа и оптимальную маршрутизацию в ближайший или наиболее здоровый регион, что повышает задержку и надежность для пользователей по всему миру.
Глобальные конечные точки обычно приводят к более быстрому времени отклика, так как пользователи направляются в ближайший доступный регион, уменьшая сетевые прыжки и задержки.
Устранение параллельных операций
Одновременные обновления ресурсов могут привести к непредвиденным результатам. Если два или более операций пытаются обновить один и тот же ресурс одновременно, Resource Manager обнаруживает конфликт, разрешает успешно выполнять только одну операцию, блокирует другие операции и возвращает ошибку. Это решение гарантирует, что ваши обновления будут окончательными и надёжными. Вы знаете состояние своих ресурсов и избегаете несогласованности или потери данных.
Например, если у вас есть два запроса (A и B), которые пытаются обновить один и тот же ресурс одновременно, и запрос A завершается до запроса B, то запрос A успешно завершится, а запрос B завершится ошибкой. Запрос B возвращает ошибку 409. Получив этот код ошибки, вы можете получить обновленное состояние ресурса и определить, хотите ли вы отправить запрос B еще раз.
Следующие шаги
- Дополнительные сведения об ограничениях, применяемых в службах Azure, см. в статье Подписка Azure, границы, квоты и ограничения службы.
- Чтобы узнать о том, как перемещать ресурсы, ознакомьтесь с разделом Перемещение ресурсов в новую группу ресурсов или подписку.
- Дополнительные сведения о тегах см. в статье "Использование тегов для организации ресурсов Azure и иерархии управления".
- Сведения о блокировке ресурсов см. в статье "Блокировка ресурсов Azure для защиты инфраструктуры".