Общие сведения о областях развертывания
Виртуальные машины, логические серверы и базы данных SQL Azure, учетные записи хранения, виртуальные сети и большинство других ресурсов Azure должны быть помещены в группу ресурсов. Однако некоторые ресурсы могут быть развернуты по-другому. Эти ресурсы обычно используются для управления поведением среды Azure.
В этом уроке вы просмотрите иерархию организации ресурсов Azure, и вы узнаете, как некоторые ресурсы могут быть развернуты в различных областях.
Иерархия ресурсов Azure
Azure имеет иерархическую структуру ресурсов с несколькими уровнями управления. Ниже приведена схема, показывающая, как ваша компания может упорядочивать свою среду Azure:
клиента соответствует экземпляру Microsoft Entra. В организации обычно имеется только один экземпляр Microsoft Entra. Этот экземпляр выступает в качестве корня иерархии ресурсов.
группы управления предоставляют способ упорядочивания подписок Azure. Каждый клиент имеет одну корневую группу управления, и вы можете установить собственную иерархию групп управления в ней. Можно создать отдельные группы управления для различных частей организации или для подписок, имеющих собственные требования к безопасности или управлению. Вы можете применять ограничения политики и контроля доступа к группам управления, а все подписки, находящиеся ниже этой группы в иерархии, наследуют эти ограничения. Группы управления не развертываются в регионах, и они не влияют на расположения ресурсов.
подписки выполняют роль учетных записей для выставления счетов и содержат группы ресурсов и ресурсы. Как и группы управления, подписки не имеют расположения и не ограничивают развертывание ресурсов.
группы ресурсов являются логическими контейнерами для ресурсов. С помощью групп ресурсов можно управлять связанными ресурсами и контролировать их как единой единицей. Ресурсы, такие как виртуальные машины, планы службы приложений Azure, учетные записи хранения и виртуальные сети, должны быть помещены в группу ресурсов. Группы ресурсов создаются в определённом расположении, чтобы Azure может отслеживать метаданные ресурсов в группе, но ресурсы внутри группы могут быть развернуты в других местах.
Ранее иллюстрированный пример — это довольно простой сценарий, в котором показано, как можно использовать группы управления. Ваша организация также может рассмотреть возможность реализации целевой зоны, которая представляет собой набор ресурсов и конфигурации Azure, необходимых для начала работы с рабочей средой Azure. целевой зоны корпоративного масштаба является проверенным подходом к использованию групп управления и подписок для эффективного управления ресурсами Azure:
Какую бы модель вы ни выбрали, понимая различные уровни иерархии, вы можете начать применять гибкие элементы контроля над использованием и управлением средой Azure. С помощью Bicep эти элементы управления можно управлять всеми преимуществами инфраструктуры в виде кода.
Заметка
Существуют также некоторые другие ресурсы, развернутые в определенных областях. ресурсы расширения развертываются в пределах области другого ресурса Azure. Например, блокировка ресурсов — это расширяющий ресурс, который развертывается, например, в ресурсе, таком как учетная запись хранения.
Вы уже знакомы с развертыванием ресурсов в группах ресурсов, поэтому рассмотрим другие области развертывания.
Ресурсы с областью действия подписки
Вы можете развернуть ресурсы в подписке, когда:
- Необходимо создать новую группу ресурсов. Группа ресурсов действительно является только ресурсом с областью подписки.
- Необходимо предоставить доступ ко всем ресурсам в подписке. Например, если у отдела отдела кадров есть подписка Azure, содержащая все ресурсы Azure отдела, можно создать назначения ролей, чтобы позволить всем сотрудникам отдела кадров читать содержимое подписки.
- Вы используете политику Azure и хотите определить или применить политику ко всем ресурсам в подписке. Например, ваш отдел R&D компании по производству игрушек попросил вас внедрить политику, которая ограничивает список виртуальных машин по SKU, которые можно создать в подписке команды.
Ресурсы на уровне группы управления
Вы можете развернуть ресурсы в группе управления, когда:
Необходимо предоставить доступ ко всем ресурсам в любых подписках, которые попадают в иерархию групп управления. Например, группе облачных операций может потребоваться доступ к каждой подписке в организации. Вы можете создать назначение ролей в корневой группе управления, которая предоставляет группе облачных операций доступ ко всему в Azure.
Осторожность
Будьте очень осторожны, когда вы предоставляете доступ к ресурсам с помощью групп управления и особенно корневой группы управления. Помните, что каждый ресурс в группе управления в иерархии наследует назначение роли. Убедитесь, что ваша организация следует рекомендациям по управлению удостоверениями и проверке подлинности, и что она соответствует принципу наименьших привилегий; То есть не предоставляйте доступ, который не требуется.
Необходимо применять политики во всей организации. Например, в вашей организации может существовать политика, согласно которой ресурсы не могут быть созданы в определённых географических регионах ни при каких обстоятельствах. Вы можете применить политику к корневой группе управления, которая будет блокировать создание ресурсов в этом регионе.
Заметка
Прежде чем использовать группы управления в первый раз, настройте их для вашей среды Azure.
Ресурсы, охватывающие область арендатора
Вы можете развернуть ресурсы в клиентском окружении, когда:
Необходимо создать подписки Azure. При использовании групп управления подписки находятся под группами управления в иерархии ресурсов, но подписка развертывается как ресурс в рамках клиента.
Заметка
Не все клиенты Azure могут создавать подписки с помощью инфраструктуры в качестве кода. В зависимости от условий выставления счетов с корпорацией Майкрософт это может быть невозможно. Дополнительные сведения см. в статье Создание подписок Azure программными средствами.
Вы создаете или настраиваете группы управления. Azure создает отдельную корневую группу управления при включении групп управления для клиента и позволяет создавать под ним несколько уровней групп управления. Вы можете использовать Bicep для определения всей иерархии группы управления. Вы также можете назначить подписки группам управления.
С помощью Bicep можно отправлять развертывания в область клиента. развертывания, нацеленные на арендатора, требуют специального разрешения. Однако на практике вам не нужно отправлять развертывания, связанные с арендаторами. Вместо этого проще развертывать ресурсы с областью действия клиента с помощью шаблона в другой области. Вы увидите, как это сделать позже в этом модуле.
Совет
Нельзя создавать политики или назначения ролей на уровне арендатора. Однако если вам нужно предоставить доступ или применить политики во всей организации, эти ресурсы можно развернуть в корневой группе управления.
Идентификаторы ресурсов
К настоящему времени вы знакомы с идентификаторами ресурсов для ресурсов, которые живут внутри подписок. Например, вот идентификатор ресурса, представляющий группу ресурсов, которая является ресурсом с областью подписки:
/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyDevelopment
Ниже приведено визуальное представление одной и той же информации:
У подписок есть собственные идентификаторы, как показано ниже.
/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e
Заметка
Хотя подписки считаются дочерними элементами групп управления, их идентификаторы ресурсов не включают идентификатор группы управления. Azure отслеживает связь между подписками и группами управления таким образом, что отличается от других связей ресурсов. Это обеспечивает гибкость перемещения подписок между группами управления без необходимости изменять все идентификаторы ресурсов.
При работе с ресурсами на уровне группы управления или арендатора идентификаторы ресурсов могут выглядеть немного по-другому, чем обычно. Они в основном следуют стандартному шаблону чередования типа ресурса с информацией о ваших конкретных ресурсах. Однако конкретный формат зависит от ресурса, с которым вы работаете.
Ниже приведен пример идентификатора ресурса для группы управления:
/providers/Microsoft.Management/managementGroups/ProductionMG
Вот как выглядит следующее:
Заметка
Группы управления имеют идентификатор и отображаемое имя. Отображаемое имя — это удобочитаемое пользователем описание группы управления. Отображаемое имя можно изменить, не затрагивая идентификатор группы управления.
При развертывании ресурса в области группы управления его идентификатор ресурса включает идентификатор группы управления. Ниже приведен пример идентификатора ресурса для определения роли, созданного в области группы управления:
/providers/Microsoft.Management/managementGroups/ProductionMG/providers/Microsoft.Authorization/roleDefinitions/00000000-0000-0000-0000-000000000000
Вот визуальное представление того же идентификатора:
Другое определение роли может быть определено в области подписки, поэтому его идентификатор ресурса выглядит немного иначе:
/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Authorization/roleDefinitions/00000000-0000-0000-0000-000000000000
Вот визуальное представление того же идентификатора:
Теперь, когда вы понимаете иерархию ресурсов Azure и типы ресурсов, которые можно развернуть в каждой области, вы можете принимать решения о областях, в которых развертываются ресурсы. Например, вы можете выбрать, следует ли создать определение политики в области группы ресурсов, подписки или группы управления. В следующем уроке вы узнаете, как создать файлы Bicep, предназначенные для каждой из этих областей.