Управление средами разработки приложений в целевых зонах Azure
В этой статье описывается, как команды облачной платформы могут реализовать guardrail для управления средами приложений в целевых зонах Azure. В нем также объясняется, как выровнять различные среды разработки приложений с их платформой. Ключевым аспектом создания соответствующей среды является размещение подписок в соответствующих группах управления.
Настройка основы
Командам разработчиков требуется возможность быстро выполнять итерацию, а команды по управлению облачными и платформами должны управлять организационными рисками, соответствием и безопасностью в масштабе. Вы можете правильно управлять средами приложений, фокусируясь на двух ключевых принципах проектирования целевой зоны Azure: управление на основе политик и демократизация подписок. Эти принципы обеспечивают базовые охранники и описывают, как делегировать элементы управления командам приложений. Команды приложений используют руководство по Azure Well-Architected Framework для разработки рабочей нагрузки. Они развертывают собственные ресурсы целевой зоны и управляют ими, а команда платформы управляет ресурсами, назначая политики Azure.
Важно предоставить изолированные ресурсы для полууправляемых ресурсов, чтобы команды приложений могли экспериментировать с технологиями и возможностями.
Когда владельцы приложений используют вендинг по подписке или другие процессы создания подписок, они должны знать, как запрашивать подписки для нескольких сред разработки.
В этой статье описывается целевая зона Azure, включая группы управления, политики и архитектуру общей платформы, а также рабочую нагрузку или целевую зону приложения.
Примечание.
Руководство в этой статье предназначено только для рабочих нагрузок или целевых зон приложений. Сведения о тестировании и сегрегации среды для самой платформы целевой зоны Azure см. в статье "Тестирование для целевых зон Azure", описывающий канарной подход.
На практике можно использовать любое число и тип поэтапной среды. В этой статье приводятся ссылки на следующие поэтапные среды.
| Environment | Description | Группа управления |
|---|---|---|
| Песочница | Среда, используемая для быстрых инноваций прототипов, но не связанных с рабочей средой конфигураций | Группа управления песочницей |
| Разработка | Среда, используемая для создания потенциальных кандидатов на выпуск | Группа управления архетипа, например corp или online |
| Тестирование | Среда, используемая для тестирования, включая модульное тестирование, приемочное тестирование пользователей и тестирование качества | Группа управления архетипа, например corp или online |
| Рабочая среда | Среда, используемая для предоставления ценности клиентам | Группа управления архетипа, например corp или online |
Дополнительные сведения см. в разделе о разработке, тестировании и рабочих средах для рабочих нагрузок приложений и сколько подписок следует использовать в Azure?
Среды, подписки и группы управления
Предварительные требования к этому разделу см . в разделе "Область разработки организации ресурсов".
При внедрении методик целевой зоны Azure необходимо правильно упорядочить подписки. В идеале каждая среда приложения должна иметь собственную подписку. Этот метод предоставляет элементы управления безопасностью и политикой, которые обеспечивают изоляцию сред. Он содержит потенциальные проблемы в одной среде.
Отдельные подписки имеют те же политики на уровне архетипа. При необходимости владельцы приложений могут назначать политики, относящиеся к подписке, для применения поведения приложений и среды.
Для некоторых архитектур приложений требуется совместное использование служб между средами. Если это так, можно использовать одну подписку для нескольких сред. Рекомендуется, чтобы владельцы рабочих нагрузок работали с командами облачной платформы, чтобы определить, нужна ли одна подписка для нескольких сред.
Используйте одну подписку для нескольких сред приложений, если:
Среды не могут быть изолированы в собственных подписках.
Среды имеют те же команды, назначенные функциональным ролям, например сетевым операторам.
Среды могут использовать те же политики.
Если рабочая нагрузка приложения или службы должна находиться в одной подписке, и необходимо внести изменения в политики, применяемые к каждой среде, можно:
Создайте новую группу управления, выровненную по архетипу, под группой управления целевыми зонами. Дополнительные сведения см . в разделе иерархии групп управления в этой статье.
Используйте подписки "песочницы" для действий разработки. Для "песочниц" установлен менее строгий набор политик.
Используйте политики, которые применяются на уровне подписки вместо уровня группы управления. Теги можно добавить в определения политик, чтобы помочь фильтровать и применять политики к правильной среде. Вы также можете назначить политики или исключить их из определенных групп ресурсов.
Политики можно назначить во время процесса создания подписки в рамках вендинг по подписке.
Для политик, которые вы реализуете для управления затратами, примените определение политики на уровне подписки, где это необходимо. Или вы можете сделать владельца целевой зоны ответственным за затраты, что обеспечивает истинную автономию. Дополнительные сведения см. в разделе "Автоматизация платформы" и "DevOps".
Предупреждение
В отличие от политик и элементов управления на уровне группы управления, политики и теги на основе подписки могут быть изменены пользователями с повышенными разрешениями на подписку. Администратор istrator с соответствующими ролями может обойти эти элементы управления, исключив политики, изменив политики или изменив теги на ресурсах.
В результате не следует применять теги в определениях политик, ориентированных на безопасность. Кроме того, не назначайте разрешения, как всегда активные для следующих действий:
Microsoft.Authorization/policyAssignments/*Microsoft.Authorization/policyDefinitions/*Microsoft.Authorization/policyExemptions/*Microsoft.Authorization/policySetDefinitions/*
Эти действия можно управлять с помощью управление привилегированными пользователями (PIM).
Иерархия групп управления
Избегайте сложных иерархий групп управления. Они могут требовать частой поправки, масштабирования неэффективно и отсутствия ценности. Чтобы избежать этих потенциальных проблем, группы управления целевой зоной Azure соответствуют архетипу рабочей нагрузки. Дополнительные сведения см. в разделе Организация групп управления и подписок.
Архетип с выравниванием означает, что группы управления создаются только для определенных архетипов рабочей нагрузки. Например, в концептуальной архитектуре группа управления целевыми зонами имеет корпоративные и сетевые группы управления дочерними клиентами. Эти дочерние группы управления соответствуют отдельным шаблонам архетипа для рабочих нагрузок, которые они удерживают. Дочерние группы управления сосредоточены на требованиях к гибридному подключению (VPN/Azure ExpressRoute), таким как внутренние только и общедоступные приложения и службы.
За исключением сред песочницы различные среды приложений должны использовать один и тот же архетип для развертывания. Даже если среды разделены между несколькими подписками, они хранятся в одной группе управления (corp или online), на основе архетипа группы управления и требований.
Вы можете использовать подписки песочницы для неструктурированной разработки, например личных лабораторий или рабочей нагрузки, которая не имеет архетипа. Команда рабочей нагрузки приложений или служб использует группу управления песочницей для тестирования различных служб Azure, чтобы определить, что лучше всего подходит для своих требований. После принятия решения о службах они могут подготовить целевую зону (в правильной группе управления, выровненной по архетипу рабочей нагрузки в иерархии групп управления целевыми зонами ) для команды.
Среды песочницы можно использовать для определенных приложений, или команда рабочей нагрузки может использовать их для экспериментирования.
Дополнительные сведения см. в разделе:
- Группы управления.
- Область разработки организации ресурсов.
- Настройка архитектуры целевой зоны Azure в соответствии с требованиями.
Проблемы группы управления на основе среды
Группы управления для сред в архетипах могут добавлять затраты на управление и предоставлять минимальное значение.
Группа управления целевыми зонами должна иметь универсальные политики, которые обеспечивают защиту как для корпоративных, так и для групп управления дочерними клиентами в Сети. Корпорация и интернет имеют уникальные политики, которые применяют рекомендации компании, связанные с общедоступными и частными рабочими нагрузками.
Многие организации создают отдельные группы управления для сред жизненного цикла разработки программного обеспечения рабочей нагрузки (SDLC) для назначения экологических политик и элементов управления. На практике этот метод создает больше проблем для рабочих нагрузок, чем решение. Среды SDLC не должны иметь разные политики, поэтому мы не рекомендуем отдельные группы управления.
Владельцы приложений могут изменить топологию или конфигурацию ресурсов рабочей нагрузки, чтобы соответствовать политикам в нескольких средах SDLC, которые он продвигает. Этот метод повышает риск. Правила, относящиеся к каждой среде, могут привести к плохому опыту разработки для разработчиков и команд по обеспечению качества. Проблемы также могут возникнуть, если у приложения есть один набор политик guardrail, работающих в одной среде, и приложение предоставляется другому набору политик позже в своем цикле продвижения. При изменении элементов управления может потребоваться внести изменения в приложение.
Чтобы предотвратить эту дополнительную работу, создайте согласованные политики во время продвижения кода в средах SDLC. Вы не должны создавать политики для каждой среды, а вместо этого предоставлять согласованный набор для всех сред разработки, за исключением сред песочницы.
Например, представьте, что организация определяет политику, требующую настройки учетных записей хранения с определенными правилами брандмауэра, чтобы предотвратить входящий трафик из общедоступных сетей. Вместо этого учетные записи хранения используют частные конечные точки в сетях целевой зоны Azure для обмена данными. Если в среде разработки нет такой политики, проверка рабочей нагрузки не находит неправильной конфигурации учетной записи хранения, которая разрешает общедоступный доступ. Тестовые развертывания работают в среде разработки и итерируются. Если решение повышено до другой среды, которая имеет политику учетной записи хранения, развертывание завершается сбоем из-за принудительной политики.
В результате команда разработчиков приложений должна переработать развертывание и архитектуру, после того как уже инвестировала значительные усилия. В этом примере показано, как различные политики в различных средах могут создавать проблемы.
Примечание.
В следующем уравнении показано, почему отдельная группа управления для каждой среды или рабочей нагрузки не масштабируется хорошо: N рабочие нагрузки x Z группы управления = общие группы управления.
Если у организации есть 30 рабочих нагрузок, для которых требуется группа управления и дочерняя группа управления для разработки, тестирования и рабочей среды, организация остается с:
N = количество рабочих нагрузок и приложений = 30
Z = количество групп управления для рабочей нагрузки и сред (1 для рабочей нагрузки + 3 для сред) = 4
N (30) x Z (4) = 120 общих групп управления
Владельцам приложений может потребоваться применение политик по-разному к нескольким средам. Например, владельцы приложений могут требовать конфигурации резервного копирования для рабочих сред, но не для других сред.
Некоторые политики можно включить как политики аудита на уровне группы управления. Команды приложений определяют, как реализовать элемент управления. Этот метод не предотвращает развертывание, но создает осведомленность и позволяет командам приложений управлять своими уникальными потребностями. Затем они могут создавать политики вложенных версий или включать эти требования в инфраструктуру в виде модулей развертывания кода (IaC).
В этой модели общей ответственности методы аудита группы платформы и команда приложений управляет реализацией. Эта модель может повысить гибкость развертываний.
Операторы платформы должны работать с каждой командой рабочей нагрузки приложения или службы (владельцы целевой зоны), чтобы понять свои требования. Операторы платформы могут предоставлять подписки на основе требований и планов приложения. Операторы платформы также могут решить назначить линии продуктов для различных типов рабочих нагрузок, чтобы они могли создавать процессы и средства создания подписок на основе общих требований команд приложений или рабочих нагрузок служб.
Сценарий. Рабочие нагрузки на основе виртуальных машин
Ранние рабочие нагрузки в целевых зонах Azure часто состоят из виртуальных машин Azure. Вы можете развернуть эти рабочие нагрузки в Azure или перенести их из существующих центров обработки данных.
Вместо развертывания виртуальных машин в нескольких средах в одной подписке можно:
Создайте подписки для каждой среды приложения и поместите их в одну и ту же группу управления архетипами.
Разверните виртуальную сеть для каждой среды приложения в соответствующей подписке. Размер виртуальной сети можно определить на основе размера среды приложения.
Разверните виртуальные машины в соответствующей подписке. При необходимости виртуальные машины могут использовать разные номера SKU и разные конфигурации доступности для каждой среды.
Различные ресурсы среды приложения защищены различными элементами управления доступом. В результате, когда разработчики приложений настраивают конвейеры развертывания, удостоверение каждого конвейера может быть ограничено средой. Эта конфигурация помогает защитить среды от случайных развертываний.
Сценарий: служба приложение Azure
Рабочая нагрузка с подписками на окружающую среду, использующую Служба приложений, может создавать проблемы. Для разработчиков приложений рекомендуется Служба приложений использовать слоты развертывания для управления изменениями и обновлениями веб-приложения.
Однако эту функцию можно использовать только с приложением, которое находится в плане Служба приложений, которое может жить только в одной подписке. Если операторы платформы предписывают владельцам приложений использовать отдельные подписки для разработки, тестирования и рабочей среды, жизненный цикл развертывания приложения может оказаться более сложным.
В этом примере оптимальным вариантом является одна подписка для рабочей нагрузки приложения или службы. Владельцы приложений могут использовать управление доступом на основе ролей Azure (RBAC) с PIM на уровне группы ресурсов для повышения безопасности.