Управление средами разработки приложений в целевых зонах Azure

В этой статье описывается, как команды облачной платформы могут реализовать guardrail для управления средами приложений в целевых зонах Azure. В нем также объясняется, как выровнять различные среды разработки приложений с их платформой. Ключевым аспектом создания соответствующей среды является размещение подписок в соответствующих группах управления.

Заложить основу

Командам разработчиков требуется возможность быстро выполнять итерацию, а команды по управлению облачными и платформами должны управлять организационными рисками, соответствием и безопасностью в масштабе. Вы можете правильно управлять средами приложений, фокусируясь на двух ключевых принципах проектирования целевой зоны Azure: управление на основе политик и демократизация подписок. Эти принципы обеспечивают основные направления и описывают, как делегировать управление командам разработки приложений. Команды приложений используют руководство по Azure Well-Architected Framework для разработки рабочей нагрузки. Они развертывают и управляют собственными ресурсами посадочной зоны, а команда платформы контролирует ресурсы, назначая политики Azure.

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

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

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

На практике можно использовать любое количество и любой тип среды с поэтапным развитием. В этой статье приводятся ссылки на следующие поэтапные среды.

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

Среды, подписки и группы управления

Предварительные требования к этому разделу см. в разделе "Область разработки организации ресурсов".

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

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

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

Используйте одну подписку для нескольких сред приложений, если:

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

• Эти среды имеют одинаковые команды, назначенные функциональным ролям, например, сетевым операторам.

• Среды могут использовать те же правила.

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

• Создайте новую группу управления, соответствующую архетипу, под группой управления входными зонами. Дополнительные сведения см. в разделе иерархии групп управления в этой статье.

• Используйте подписки песочницы для задач разработки. Песочницы имеют менее строгий набор политик.

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

  Политики можно назначать в процессе создания подписки в рамках автоматического предоставления подписок.

  Для политик, которые вы реализуете для управления затратами, примените определение политики на уровне подписки, где это необходимо. Или вы можете сделать владельца посадочной зоны ответственным за затраты, что обеспечивает настоящую автономию. Дополнительные сведения см. в разделе "Автоматизация платформы" и "DevOps".

Иерархия групп управления

Избегайте сложных иерархий групп управления. Они могут требовать частых изменений, неэффективно масштабироваться и не представлять ценности. Чтобы избежать этих потенциальных проблем, группы управления целевой зоной Azure соответствуют архетипу рабочей нагрузки. Дополнительные сведения см. в разделе "Группа управления" и организация подписки.

Соответствующий архетипу означает, что группы управления создаются только для определенных архетипов рабочих нагрузок. Например, в концептуальной архитектуре группа управления зонами высадки имеет дочерние группы управления corp и online. Эти группы управления ресурсами соответствуют определённым архетипным шаблонам для рабочих нагрузок, которые они обрабатывают. Дочерние группы управления сосредоточены на требованиях к гибридному подключению (VPN/Azure ExpressRoute), таким как внутренние только и общедоступные приложения и службы.

За исключением сред песочницы различные среды приложений должны использовать один и тот же архетип для развертывания. Даже если среды разделены между несколькими подписками, они хранятся в одной группе управления (corp или online), на основе архетипа группы управления и требований.

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

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

Дополнительные сведения можно найти здесь

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

Вызовы группы управления, основанной на управлении окружающей средой

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

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

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

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

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

Например, представьте, что организация определяет политику, требующую настройки учетных записей хранения с определенными правилами брандмауэра, чтобы предотвратить входящий трафик из общедоступных сетей. Вместо этого учетные записи хранения используют частные конечные точки в сетях целевой зоны Azure для обмена данными. Если в среде разработки нет такой политики, проверка рабочей нагрузки не находит неправильной конфигурации учетной записи хранения, которая разрешает общедоступный доступ. Тестовые развертывания работают в среде разработки и итерируются. Если решение перемещается в другую среду, в которой действует политика учетной записи хранения, развертывание терпит неудачу из-за строгой политики.

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

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

Некоторые политики можно включить как политики аудита на уровне группы управления. Команды приложений определяют, как реализовать элемент управления. Этот метод не предотвращает развертывание, но создает осведомленность и позволяет командам приложений управлять своими уникальными потребностями. Затем они могут создавать субуровневые политики или включать эти требования в модули развертывания инфраструктуры как кода (IaC).

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

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

Сценарий. Рабочие нагрузки на основе виртуальных машин

Ранние рабочие нагрузки в целевых зонах Azure часто состоят из виртуальных машин Azure. Вы можете развернуть эти рабочие нагрузки в Azure или перенести их из существующих центров обработки данных.

Вместо развертывания виртуальных машин в нескольких средах в одной подписке можно:

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

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

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

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

Сценарий. Служба приложений Azure

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

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

В этом примере оптимальным вариантом является одна подписка для рабочей нагрузки приложения или службы. Владельцы приложений могут использовать управление доступом на основе ролей Azure (RBAC) с PIM на уровне группы ресурсов для повышения безопасности.

Дальнейшие шаги

• Настройка архитектуры целевой зоны Azure в соответствии с требованиями
• подход тестирования для посадочных зон Azure
• Песочница среды зоны приземления