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


Обеспечение аналитики в масштабе облака

Процесс развертывания зоны менеджмента данных

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

Осторожность

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

Процесс развертывания зоны приземления данных

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

Например, операционная команда зоны приземления данных запрашивает новую зону приземления данных с помощью инструмента управления ИТ или Power Apps. После утверждения запроса запустите следующий рабочий процесс с помощью параметров из запроса:

  1. Разверните новую подписку для новой целевой зоны данных.
  2. Создайте форк основной ветки шаблона зоны приземления данных, чтобы создать новый репозиторий.
  3. Создайте подключение службы в новом репозитории.
  4. Обновите параметры в новом репозитории на основе параметров из запроса.
  5. Создайте конвейер развертывания для развертывания служб, активируется путем регистрации обновленных параметров.
  6. Уведомите операционную группу зоны приёма данных о доступности новой зоны.

Теперь команда операций зоны приземления данных может изменять или добавлять шаблоны Azure Resource Manager.

Этот рабочий процесс можно автоматизировать с помощью нескольких наборов служб на платформе Azure. Выполните некоторые действия, такие как переименование параметров в файлах параметров с помощью конвейеров CI/CD. Другие действия можно выполнить с помощью других средств оркестрации рабочих процессов, таких как Logic Apps.

схема разветвлённой модели DevOps.

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

Применяйте лучшие практики для репозиториев, например:

  • Защита основной ветви.
  • Используйте ветви для изменений, обновлений и усовершенствований.
  • Определите владельцев кода, которые одобряют pull-реквесты перед объединением изменений в основную ветвь.
  • Проверка ветвей с помощью автоматизированного тестирования.
  • Ограничить количество действий и лиц в команде, например, которые могут активировать конвейеры сборки и выпуска.

Совет

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

Диаграмма процесса автоматизации зоны приземления данных.

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

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

  • Настройка зоны приземления данных
  • Сделайте форк основного репозитория в Git-репозиторий платформы данных
  • Настройка конфигураций подсети для целевой зоны данных
  • Настройка идентификатора Microsoft Entra

Модули Runbook используют функции Git из модуля PowerShell GitAutomation для работы с репозиториями Git. Установив этот модуль в учетной записи службы автоматизации Azure, пользователи могут создавать, клонировать, запрашивать, отправлять, извлекать и фиксировать операции в репозиториях Git. На следующем рисунке показан модуль GitAutomation, установленный в учетной записи службы автоматизации Azure:

схема модуля GitAutomation для работы с репозиториями Git.

Используйте функцию Copy-GitRepository из модуля GitAutomation, чтобы клонировать основной репозиторий Git из URL-адреса, указанного URL на путь платформы данных Git, указанный DestinationPath.

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

Процесс развертывания приложения данных

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

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

схема автоматизации развертывания приложений данных.

  1. Пользователь запрашивает новые службы приложений данных.
  2. Рабочий процесс запрашивает утверждение от платформы данных или команды операций зоны приземления данных.
  3. Рабочий процесс вызывает API управления ИТ-службами для создания необходимых групп ресурсов и создания подключения службы Azure DevOps. Рабочий процесс назначает команду на проект Azure DevOps.
  4. Рабочий процесс фактически разветвляет исходный репозиторий приложения данных для создания целевого проекта в Azure DevOps.
  5. Рабочий процесс создает файл параметров шаблона Azure Resource Manager и конвейеры.
  6. Затем рабочий процесс запускает конвейер Azure для создания сетевых требований и другого конвейера Azure для развертывания служб приложений данных.
  7. Рабочий процесс уведомляет пользователя о завершении.

Совет

Если вы не знакомы с DataOps, изучите занятие "DataOps для современного хранилища данных" в практической лаборатории Центра архитектуры Azure. Сценарий лаборатории описывает вымышленное бюро городского планирования, которое может использовать это решение для развертывания. Решение развертывания предоставляет комплексный конвейер данных, который следует современному шаблону архитектуры хранилища данных, а также соответствующим процессам DevOps и DataOps, чтобы оценить использование парковки и принять обоснованные бизнес-решения.

Сводка

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

Диаграмма общей модели DataOps.

В начале реализации проекта платформа данных имеет один проект в Azure DevOps с одной или несколькими досками Azure Boards. Отдельные команды DevOps сосредоточены на:

  • Один репозиторий для зоны приземления управления данными, потоков данных и подключения службы к облачной среде.
  • Один репозиторий шаблонов для целевой зоны данных, конвейеры для развертывания экземпляра целевой зоны данных и подключений служб к облачным средам.
  • Один репозиторий шаблонов для служб продуктов данных, конвейеров для развертывания экземпляра продукта данных и подключений служб к облачным средам. Эти подключения форкуются из зоны приземления данных Azure DevOps Projects.

После развертывания целевых зон данных аналитика в масштабе облака предписывает:

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

Чтобы управлять развертыванием приложений данных, выполните следующие действия.

  • Команда операций зоны высадки данных владеет и защищает главную ветку репозитория.
  • Для развертывания в тестовой и производственной средах используется только основная ветвь.
  • Ветви компонентов могут развертываться в средах разработки.
  • Ветви функций принадлежат командам DataOps. Они используются для тестирования новых или измененных функций.
  • Команды DataOps могут объединять ветви компонентов в другие ветви компонентов без утверждения.
  • Команды DataOps создают pull request для объединения фича-веток в основную ветку, а команда по операциям с зоной приземления данных предоставляет утверждение.
  • Новые функции или улучшения исходных шаблонов объединяются в форкнутый репозиторий, чтобы поддерживать их актуальность.

Дальнейшие действия