Руководство по реализации vending подписки

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

Рис. 1. Реализация вендинг по подписке в примере среды Azure.

Мы создали вендинг по подписке модули Bicep и Terraform, которые следует использовать в качестве отправной точки. Необходимо изменить шаблоны в соответствии с потребностями реализации. Дополнительные сведения о процессе вендинг по подписке см. в обзоре виртуальных машин подписки.

Архитектура

Для выполнения трех основных задач следует разработать вендинг по подписке автоматизацию. Автоматизация виртуальных машин подписки должна (1) собирать данные запроса подписки, (2) инициировать автоматизацию платформы и (3) создавать подписку с помощью кода инфраструктуры как кода. Существует несколько подходов для реализации автоматизации вендинг по подписке для выполнения этих трех задач. Пример реализации (рис. 2) показывает один подход, использующий Gitflow. Дизайн Gitflow соответствует декларативному подходу, который многие команды платформы используют для управления платформой.

Рис. 2. Пример реализации автоматизации вендинг по подписке.

В примере реализации (рис. 2) средство сбора данных собирает данные запроса подписки. Когда запрос подписки получает утверждение, он инициирует автоматизацию платформы. Автоматизация платформы состоит из конвейера запросов, управления версиями и конвейера развертывания. Конвейер запроса создает файл параметров подписки JSON или YAML с данными из средства сбора данных. Конвейер запросов также создает новую ветвь, фиксирует файл параметров подписки и открывает запрос на вытягивание в системе управления версиями. Новая ветвь объединяется с основной ветвью в системе управления версиями. Слияние активирует конвейер развертывания для создания подписки с модулями инфраструктуры как кода.

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

Сбор данных

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

Используйте средство сбора данных. Средство управления ИТ-службами (ITSM) можно использовать для сбора данных или создания клиентского портала с низким кодом или средства без кода, например Microsoft PowerApps. Средство сбора данных должно предоставить бизнес-логику для утверждения или запрета запроса на подписку.

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

Проверка данных. Во время процесса сбора данных необходимо проверить данные. Позже на этапах автоматизации платформы сложнее устранить проблемы.

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

Интерфейс с другими внутренними системами. При необходимости средство сбора данных должно интерфейсировать с другими инструментами или системами в вашей организации. Целью является обогащение запроса данными из других систем. Для выполнения автоматизации может потребоваться удостоверение, финансы, безопасность и сетевые данные. Например, автоматизация может использовать средство управления IP-адресами (IPAM), чтобы зарезервировать правильное пространство IP-адресов.

Создайте триггер. Когда запрос подписки получает утверждение, передача данных должна активировать автоматизацию платформы. Лучше всего создать push-уведомление с необходимыми данными из средства сбора данных. Для запуска процесса может потребоваться уровень ПО промежуточного слоя, например Функции Azure или Azure Logic Apps.

Запуск автоматизации платформы

Уведомление и данные из средства сбора данных должны активировать автоматизацию платформы. Цель автоматизации платформы — создать файл параметров подписки JSON/YAML, объединить файл с главной ветвью и развернуть его с модулями инфраструктуры как кода для создания подписки. Команда платформы должна принадлежать и поддерживать автоматизацию платформы. Автоматизация платформы в примере реализации состоит из конвейера запросов, управления версиями и конвейера развертывания (см. рис. 2).

Используйте файлы JSON или YAML. Для хранения данных для создания подписки следует использовать структурированные файлы данных (JSON или YAML). Необходимо задокументировать структуру файла и сделать его расширяемым для поддержки будущих потребностей. Например, следующий фрагмент кода JSON определяет значения параметров подписки для одного из модулей Bicep в GitHub.

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "subscriptionDisplayName": {
      "value": "sub-bicep-lz-vending-example-001"
    },
    "subscriptionAliasName": {
      "value": "sub-bicep-lz-vending-example-001"
    },
    "subscriptionBillingScope": {
      "value": "providers/Microsoft.Billing/billingAccounts/1234567/enrollmentAccounts/123456"
    },
    // Insert more parameters here
  }
}

Просмотрите весь файл. Дополнительные примеры см . в примерах Bicep и Примерах Terraform

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

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

1. Создайте новую ветвь для каждого запроса подписки.
2. Используйте данные, собранные для создания одного файла параметров подписки YAML/JSON для новой подписки в ветви.
3. Создайте запрос на вытягивание из ветви mainв .
4. Обновите средство сбора данных с изменением состояния и ссылкой на этот запрос на вытягивание.

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

Проверьте файл параметров подписки. Запрос на вытягивание должен активировать процесс подкладки для проверки данных запроса. Цель заключается в том, чтобы обеспечить успешное развертывание. Он должен проверить файл параметров подписки YAML/JSON. Он также может убедиться, что диапазон IP-адресов по-прежнему доступен. Кроме того, вам может потребоваться добавить ворота проверки вручную с помощью вмешательства человека. Они могут выполнить окончательную проверку и внести изменения в файл параметров подписки. Выходные данные должны быть файлом параметров подписки JSON/YAML со всеми данными для создания подписки.

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

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

Последняя задача автоматизации вендинг по подписке — создать и настроить новую подписку. Пример реализации использует конвейер развертывания для развертывания модуля инфраструктуры как кода с файлом параметров подписки JSON/YAML (см. рис. 2).

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

Используйте конвейер развертывания. Конвейер развертывания оркеструет создание и настройку новой подписки. Конвейер должен выполнять следующие задачи:

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

Установите удостоверение рабочей нагрузки. Конвейер развертывания должен иметь разрешение на выполнение этих операций со всеми системами, с которыми он взаимодействует. Для проверки подлинности в Azure следует использовать управляемое удостоверение или OpenID Connect (OIDC).

После развертывания

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

Принудительное управление затратами. Бюджеты подписки предоставляют уведомления, критически важные для управления затратами. Развертывание должно создать предварительный бюджет подписки на основе данных запроса подписки. Команда приложений получает подписку. Они должны обновить бюджет в соответствии с потребностями рабочей нагрузки. Дополнительные сведения см. в разделе:

• Создание бюджетов и управление ими
• Управление затратами с помощью API управления бюджетом Azure
• Распределение затрат
• Отслеживание затрат в бизнес-подразделениях, средах или проектах

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

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

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

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

• Модули Bicep
• Модули Terraform
• Общие сведения о подписке
• Создание общих вендинг по подписке продуктов
• Обзор целевой зоны Azure