Vending подписки

Статья
10/10/2023

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

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

Почему вендинг по подписке?

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

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

Реализация вендинг по подписке

В подписке включается три команды. Cloud Center of Excellence (CCoE) устанавливает бизнес-логику и процесс утверждения. Когда все готово, команды приложений выполняют запросы на подписку. Команда платформы использует запрос для создания и настройки подписки перед передачой подписки команде приложений. Команда приложений обновляет бюджет, развертывает рабочую нагрузку и устанавливает операции. Ниже приведены дополнительные сведения о каждом шаге процесса вендинг по подписке. Дополнительные сведения см . в руководстве по реализации vending подписки.

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

Установка бизнес-логики и процесса утверждения

Чтобы реализовать модель вендинг по подписке, необходимо установить процесс утверждения, который собирает необходимые сведения о подписке. Cloud Center of Excellence (CCoE) должен программировать процесс утверждения и устанавливать бизнес-правила для сбора информации.

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

Интеграция с существующим инструментом. Необходимо интегрировать процесс утверждения вендинг по подписке в существующее средство управления ИТ-службами (ITSM). Интеграция может упростить процесс утверждения, сократить усилия вручную и повысить эффективность при снижении ошибок. Это также упрощает обслуживание с течением времени и помогает создавать отчеты о соответствии для аудита.

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

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

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

Создание запроса на подписку

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

Настройка сетевых подключений

Автоматизация подписок должна настроить необходимые сетевые компоненты, и она должна быть достаточно гибкой для удовлетворения потребностей каждой команды приложений. В качестве общих рекомендаций никогда не используйте перекрывающиеся IP-адреса в одном домене маршрутизации. Можно добавить или удалить адресное пространство виртуальной сети без простоя при изменении требований к размеру. Дополнительные сведения см. в разделе:

Используйте средство управления IP-адресами (IPAM). Для упрощения назначения IP-адресов следует использовать и интегрировать систему IPAM в процесс vending. Дополнительные сведения и рекомендации по IPAM см. в управление IP-адресами средствах (IPAM).

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

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

Определение размещения подписки

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

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

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

Несколько подписок: для некоторых рабочих нагрузок требуется несколько подписок. Например, некоторые рабочие нагрузки имеют несколько экземпляров, разделенных подпиской. Кроме того, архитектуры SaaS, использующие выделенные ресурсы для каждого клиента, часто используют десятки подписок.
Ограничения службы подписок: у предприятия с несколькими тысячами подписок должна быть автоматизация, которая может развертываться в старой подписке или колокатных рабочих нагрузок в подписке, чтобы избежать ограничений. Дополнительные сведения см. в статье "Часто задаваемые вопросы о целевых зонах Azure".

Вы можете запросить увеличение квоты вручную с помощью портал Azure после подготовки. Проще автоматизировать этот процесс с помощью доступных API. Однако запрос квоты может завершиться ошибкой, поэтому следует запустить скрипт для обработки любых ошибок. Дополнительные сведения см. в разделе Microsoft.Capacity, Microsoft.Quota и Microsoft.Support

Создание и настройка подписки

Теперь вы можете создать и настроить запрошенную подписку. Цель состоит в создании повторяемого, согласованного процесса. Автоматизируйте столько процесса создания и настройки подписки, сколько можно.

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

Существуют примеры вендинг по подписке модулей Bicep и Terraform, которые помогут вам внедрить модель вендинг по подписке независимо от регистрации в коммерческом соглашении. Для оркестрации автоматизации следует использовать действия GitHub или Azure Pipelines.

Используйте теги для управления затратами. Необходимо автоматизировать согласованное назначение тегов каждой подписке для управления затратами и создания отчетов в Microsoft Cost Management. Хотя вы получаете отчеты о выставлении счетов с коммерческими соглашениями, управление затратами обеспечивает большую функциональность. Например, можно создавать отчеты для подписок с определенными тегами. Дополнительные сведения см. в статье "Использование тегов в данных о затратах и использовании" и "Группа" и выделение затрат с помощью наследования тегов

Используйте рабочие и нерабопроизводительные подписки. В запросе на новую подписку необходимо указать, является ли рабочая нагрузка рабочей нагрузкой для Production или DevTest. Среды DevTest приводят к снижению затрат на ресурсы, но имеют другие условия. Примечание. Предложение DevTest недоступно для MPA. Дополнительные сведения см. в разделе:

Настройка удостоверений и управления доступом на основе ролей (RBACs). Управление доступом к ресурсам в подписке Azure крайне важно для обеспечения безопасной и совместимой среды. Для управления доступом необходимо настроить удостоверения и RBACs. Эта настройка включает назначение владельца подписки, создание групп Microsoft Entra для управления доступом и создание учетных записей службы автоматизации для развертывания рабочих нагрузок.

Назначьте владельца подписки. При создании вендинг по подписке автоматизации необходимо назначить владельца подписки. Запрос подписки должен записывать эти сведения при приеме. Владельцы подписок могут быть только пользователями или субъектами-службами в выбранном каталоге подписки. Выбрать пользователей гостевого каталога невозможно. В случае выбора субъекта-службы введите его идентификатор приложения.
Создание групп Microsoft Entra. Помимо владельца подписки, необходимо убедиться, что процесс vending использует структуру группы Microsoft Entra для управления доступом к подписке. Для доступа с повышенными привилегиями (например, для записи) рекомендуется использовать PIM для групп. Автоматизация этого процесса создания не должна нарушать рекомендации, такие как ограничение количества владельцев подписок и использование минимального требуемого уровня доступа.
Установите удостоверения рабочей нагрузки. Удостоверения рабочей нагрузки (принципы службы), используемые для развертывания рабочей нагрузки, часто имеют повышенные разрешения в области подписки. Процесс запроса подписки должен собирать идентификатор рабочей нагрузки при приеме. Процесс обработки виртуальных машин должен создать эти удостоверения и назначить соответствующий доступ к подписке. Важно отметить, что удостоверение рабочей нагрузки не может использовать PIM и получает постоянный доступ к ресурсам. Рекомендуется использовать управляемые удостоверения, чтобы избежать необходимости управления секретами. Дополнительные сведения см . в области конструктора удостоверений.

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

Обновление бюджета подписки

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

Развертывание рабочей нагрузки и работа

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

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

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

Создание общих вендинг по подписке продуктов

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