Управление аналитикой в масштабе облака
Сегодня DevOps изменила культуру того, как люди думают и работают, ускорив темпы, с которыми компании реализуют ценность, помогая отдельным лицам и организациям разрабатывать и поддерживать устойчивые методы работы. Методология DevOps сочетает в себе разработку и операции, и ее часто ассоциируют со средствами программной инженерии, которые поддерживают методики непрерывной интеграции (CI) и непрерывной поставки (CD). В число этих средств и методик входят диспетчеры исходного кода (например, Git, Apache Subversion или система управления версиями Team Foundation) и диспетчеры автоматической сборки и доставки (Azure Pipelines или GitHub Actions).
DevOps в сочетании с наблюдаемостью является ключевым фактором для обеспечения гибкой и масштабируемой платформы. DevOps предоставляет командам возможность реализовать систему управления версиями, конвейеры CI/CD, инфраструктуру как код, рабочие процессы и автоматизацию. В то время как наблюдаемость позволяет владельцам бизнеса, инженерам DevOps, архитекторам данных, инженерам данных и инженерам по надежности сайта обнаруживать, прогнозировать, предотвращать и устранять проблемы автоматически и избегать простоев, которые в противном случае могли бы нарушить рабочую аналитику и искусственный интеллект.
Система управления версиями
Система управления версиями гарантирует сохранение кода и конфигураций, а также отслеживание изменений и управление их версиями. Большинство систем управления версиями также имеют встроенные процессы проверки и работы в различных ветвях репозитория кода. В настоящее время самый популярный тип системы управления версиями — Git. Это распределенная система управления версиями, которая позволяет пользователям работать в автономном режиме и выполнять синхронизацию с центральными репозиториями. Поставщики Git, как правило, также используют ветви и следуют инструкциям по запросу на вытягивание для поддержки потока изменения и проверки.
Ветви изолируют изменения или разработку функций, не влияя на другую работу, которую осуществляют в то же время. Использование ветвей необходимо повысить до разработки функций, исправления ошибок и безопасного экспериментирования с новыми идеями. Запросы на вытягивание объединяют изменения, внесенные из одной ветви, в ветвь по умолчанию, и поддерживают процесс контролируемой проверки. В целях безопасности главная ветвь должна использовать запросы на вытягивание для проверки кода.
Важно!
Следуйте этим рекомендациям для репозиториев аналитики облачного масштаба.
- Обеспечьте безопасность главной ветви репозитория за счет применения ветвей и запросов на вытягивание, чтобы обеспечить процессы контролируемой проверки.
- Для управления исходным кодом следует использовать репозитории Azure DevOps или GitHub. Это позволит контролировать изменения в исходном коде и разрешать разрабатывать код одновременно нескольким участникам команды.
- Конфигурации кода приложения и инфраструктуры необходимо возвращать в репозиторий.
Конвейеры CI/CD
CI позволяет командам автоматически тестировать исходный код и выполнять его сборку, а также делает возможным быстрое выполнение итераций и циклов обратной связи для обеспечения высокого качества кода в CD. Конвейеры — это способы настройки непрерывной интеграции изменений (программного кода или кода инфраструктуры) и непрерывного развертывания упакованных или скомпилированных изменений. Этот процесс называется также сборкой и выпуском. Непрерывное развертывание описывает автоматическое развертывание приложений в одной или нескольких средах. Как правило, при непрерывном развертывании выполняется процесс непрерывной интеграции и используются интеграционные тесты для проверки всего приложения.
Конвейеры могут содержать несколько этапов с различными задачами, а также иметь простые и сложные потоки утверждения для обеспечения соответствия и проверки. В зависимости от предпочтений конвейеры можно также настраивать с помощью различных автоматических триггеров. Для развертывания в масштабах предприятия и развертывания с использованием ИИ на производственных этапах всегда следует использовать предварительное утверждение человеком — это встроено в модель операций. При создании конвейеров CI/CD необходимо использовать GitHub Actions или Azure Pipelines, и они должны представлять собой автоматические триггеры.
Инфраструктура как код
Термин "код " в IaC часто вызывает озабоченность у ИТ-сотрудников без опыта разработки, но IaC не относится к написанию кода так, как это делают типичные разработчики программного обеспечения. Впрочем, здесь используются многие средства и принципы процессов разработки программного обеспечения. Это необходимо для поставки инфраструктуры в предсказуемом формате.
IaC помогает подготавливать, настраивать и администрировать инфраструктуру как часть конвейера DevOps с полным управлением изменениями, журналом аудита, тестами, проверками и процессами утверждения, гарантируя возможность делегирования задач соответствующим ролям для проекта без ущерба для безопасности и соответствия.
Существует два подхода к IaC: декларативный и императивный.
При применении декларативного подхода указывается требуемое состояние инфраструктуры, а подсистема оркестрации выполняет действия, необходимые для достижения требуемого состояния. В Azure для этого используются шаблоны Azure Resource Manager. Для этого подхода также доступны такие слои абстрагирования, как Terraform.
При применении императивного подхода определенные команды выполняются в заданном порядке. Для Azure это можно сделать с помощью интерфейса командной строки или PowerShell, однако, если требуются интегрированные решения, доступны также пакеты средств разработки программного обеспечения для собственного языка программирования, например, .NET, Python и Java.
Основная подготовка к работе в шаблонах Azure Resource Manager выполняется в разделе ресурсов, а конфигурация отдельных ресурсов определяется в разделе свойств. Для Azure Data Lake Storage 2-го поколения конфигурация выглядит следующим образом:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources": [
{
"type": "Microsoft.MachineLearningServices/workspaces/datastores",
"name": "[concat(parameters('workspaceName'), '/', parameters('datastoreName'))]",
"apiVersion": "2020-05-01-preview",
"location": "[parameters('location')]",
"properties": {
"DataStoreType": "adls-gen2",
"SkipValidation": "[parameters('skipValidation')]",
"ClientId": "[parameters('clientId')]",
"ClientSecret": "[parameters('clientSecret')]",
"FileSystem": "[parameters('fileSystem')]",
"AccountName": "[parameters('accountName')]",
"TenantId": "[parameters('tenantId')]",
"ResourceUrl": "[parameters('resourceUrl')]",
"AuthorityUrl": "[parameters('authorityUrl')]"
}
}
]
}
Важно!
Каждый уровень аналитики облачного масштаба, такой как целевая зона управления данными, целевые зоны данных или приложения данных (создающие продукты данных), должен быть определен с помощью декларативного языка, например Azure Resource Manager или Terraform, возвращен в репозиторий и развернут с помощью конвейеров CI/CD. Это позволяет командам отслеживать изменения в инфраструктуре и конфигурации области Azure, а также управлять их версиями, одновременно поддерживая гибкую автоматизацию различных уровней архитектуры. Это руководство позволяет командам использовать репозитории Git, чтобы всегда видеть состояние конкретных областей Azure.
Рабочие процессы и автоматизация
Чтобы обеспечить отсутствие в коде ошибок и его готовность к использованию в рабочей среде, команды должны применять конвейеры CI/CD на нескольких этапах. Помимо прочего, рекомендуется иметь среду разработки, тестовую среду и рабочую среду. Эти этапы также необходимо отразить в Azure с помощью отдельных служб для каждой среды.
Команда платформы несет ответственность за предоставление и поддержание шаблонов развертывания для быстрого масштабирования в рамках организации и упрощения развертываний для команд, не знакомых с IaC. Эти шаблоны служат основой для новых артефактов в рамках сценария. Их необходимо поддерживать с течением времени, чтобы они отражали лучшие методики и общие стандарты, принятые в компании.
Управлять развертываниями для тестовой и рабочей сред следует только с помощью конвейера CI/CD и подключения к службе с повышенными разрешениями в целях принудительного применения общих рекомендаций (например, шаблонов Azure Resource Manager).
Внимание!
Группы приложений данных должны иметь доступ на чтение только к тестовой и рабочей средам, а развертывания в этих средах должны выполняться только через конвейеры CI/CD и подключения служб с повышенными разрешениями. Чтобы ускорить путь к рабочей среде, команды приложений данных должны иметь доступ на запись в среду разработки.