CI/CD Пайплайны для приложений обработки данных на Azure Часть 1 Контейнерные экземпляры

CI/CD Пайплайны для обработки данных на Azure Часть 1 - Применение контейнерных экземпляров

Изображение, созданное с использованием AI Comic Factory: https://huggingface.co/spaces/jbilcke-hf/ai-comic-factory — Изображение, созданное при помощи AI Comic Factory: https://huggingface.co/spaces/jbilcke-hf/ai-comic-factory

Пошаговое руководство по развертыванию контейнеров Docker с GitHub Actions

Введение

Ручное создание и развертывание ресурсов в Azure и других облачных провайдерах относительно просто и может быть достаточным в некоторых случаях. Однако, чаще всего, развернутые ресурсы будут нуждаться в изменениях со временем, что в свою очередь требует дополнительной работы по обслуживанию и повторному развертыванию ресурсов. Чтобы автоматизировать эти задачи, разработчики и специалисты по данным могут использовать подход инфраструктуры как код (IaC) и создавать конвейеры для непрерывной интеграции и развертывания (CI/CD). Этот подход позволяет разработчикам писать код, который автоматически определяет и повторно разворачивает ресурсы при внесении изменений.

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

Предоставить реестр контейнеров
Создать и загрузить образ Docker в реестр
Создать экземпляр контейнера, который выполняет обработку данных
Включить доступ ‘Управляемой учетной записи’ к Azure Key Vault, что позволяет нашему приложению получать ключи доступа к другим ресурсам, таким как аккаунты хранилища
Развернуть вышеуказанные ресурсы в тестовой и рабочей средах, используя разные триггеры для запуска конвейеров

Начало работы

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

Чтобы начать, вам понадобится учетная запись Azure. Возможно, вам также захочется установить Azure CLI на своей локальной системе. Однако вы также можете выбрать выполнение команд Azure CLI через Cloud Shell, которая находится в портале Azure.

Поскольку наше приложение передает данные в хранилище Azure Blob и возвращает их, вам может быть полезно установить Azure Storage Explorer, что делает загрузку файлов и проверку правильности работы приложения немного проще.

Шаг 1: Клонирование репозитория и настройка статических ресурсов.

Сначала вам нужно склонировать этот репозиторий. В README-файле описано, как это сделать с помощью RStudio, но вы можете использовать свою предпочитаемую среду разработки.

Затем, используя портал Azure, создайте следующие ресурсы:

группу ресурсов, в которую будут включены все остальные ресурсы.
учетную запись хранилища с контейнером blob с двумя папками: одна для входных файлов и другая для выходных файлов. В нашем случае они должны быть названы ‘input’ и ‘output’ соответственно. Сохраните небольшой набор данных в качестве csv-файла с именем ‘input_data.csv’ внутри контейнера input.
хранилище ключей, в котором вам нужно сохранить основной ключ доступа к вашей учетной записи хранилища как секрет.

На шаге 3 вам понадобится имя вашего хранилища ключей, а также имя секрета, содержащего основной ключ доступа.

Шаг 2: соединение GitHub с Azure

Для обновления ресурсов Azure нам нужно предоставить разрешение GitHub.

Сначала войдите в свою учетную запись Azure, используя Azure CLI.

az login

Затем скопируйте значение id из вывода JSON, которое является идентификатором подписки. Вставьте идентификатор подписки в нижеприведенную команду и выполните ее. Это создает ‘сервисного принципала’ с управляемым доступом на основе роли, которую можно рассматривать как пользователя, действующего от вашего имени при развертывании или обновлении ресурсов с помощью рабочего процесса GitHub Actions.

az ad sp create-for-rbac \ --name "your-app-name" \ --role Owner \ --scopes /subscriptions/<your-subscription-id>/resourceGroups/<your-resource-group-name> \ --sdk-auth

Скопируйте весь JSON-вывод и перейдите в свой репозиторий на GitHub, затем перейдите в раздел “Settings” (Настройки), “Secrets and variables” (Секреты и переменные), “Actions” (Действия).

Создайте новый секрет репозитория и назовите его AZURE_CREDENTIALS. Вставьте JSON-вывод из вышеуказанной команды и сохраните.

Шаг 3: модификация скриптов

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

Если вы решите продолжить с текущим R-скриптом (script.R), вам нужно будет только изменить значения {keyvault-name}, {access-key-name} и {storage-account-name} (без скобок).

Затем измените следующие значения в разделе env: в двух файлах рабочего процесса с именами workflow.yml и workflow_release_prod.yml в каталоге .github/workflows/:

env:  RESOURCEGROUP_NAME: my-rg  REGISTRY_NAME: my-cr  SHORT_NAME: mycr  ACI_NAME: my-ci-test  KV_NAME: my-kv  ENVIRONMENT: test  CPU: 1  MEMORY: 1.5

Шаг 4: запуск конвейерной линии и контейнерного экземпляра

Когда все необходимые изменения будут внесены и отправлены в ветвь «main», вы должны увидеть работу вашей конвейерной линии в панели «Actions» (Действия). Это происходит потому, что рабочий процесс настроен на запуск при обновлении ветки «main».

Если у вас не возникает ошибок, ваш экземпляр контейнера должен быть готов к работе через десять минут примерно. Перейдите в портал Azure, найдите ваш новый экземпляр контейнера и нажмите «Start» (Запустить). В панели «Logs» (Журналы) вы можете увидеть, как ваш скрипт выполняется в консоли. После завершения проверьте, что в вашем блоб-контейнере появился новый файл cv с названием output_data.csv в папке «output».

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

Чтобы понять, что происходит в конвейерной линии CI/CD, пожалуйста, прочтите раздел ниже.

Понимание логики рабочего процесса

Файл workflow.yml определяет пять шагов, или задач, в нашей конвейерной линии, которая развертывает ресурсы в тестовой среде.

Сначала мы передаем ранее установленные переменные среды, необходимые для оставшихся шагов, как outputs.

  vars:    runs-on: ubuntu-latest    outputs:      resource_group: ${{ env.RESOURCEGROUP_NAME }}      acr_name: ${{ env.REGISTRY_NAME }}      short_name: ${{ env.SHORT_NAME }}      aci_name: ${{ env.ACI_NAME }}      kv_name: ${{ env.KV_NAME }}      environment: ${{ env.ENVIRONMENT }}      cpu: ${{ env.CPU }}      memory: ${{ env.MEMORY }}    steps:      - run: echo "Предоставление переменных среды"

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

  deploy-acr:    needs: vars    uses: ./.github/workflows/deploy_acr.yml    if: github.ref == 'refs/heads/main'    with:      environment: ${{ needs.vars.outputs.environment }}      resource_group: ${{ needs.vars.outputs.resource_group }}      acr_name: ${{ needs.vars.outputs.acr_name }}    secrets:      azure_credentials: ${{ secrets.AZURE_CREDENTIALS }}

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

on:   workflow_call:    inputs:      environment:        required: true        type: string      resource_group:        required: true        type: string      acr_name:        required: true        type: string    secrets:      azure_credentials:        required: true

В нижней части файла deploy_acr.yml у нас работает многошаговый процесс, выполняющий три предопределенных действия. Первое действие проверяет репозиторий, затем мы выполняем вход в Azure с использованием учетных данных служебного принципала, которые мы создали и сохранили. Наконец, мы используем действие с названием “azure/arm-deploy@v1”, чтобы развернуть контейнерный реестр. Обратите внимание, что этот шаг использует Bicep, популярный язык для настройки и развертывания ресурсов Azure. Внизу этой статьи вы можете найти некоторые отличные ресурсы, чтобы узнать больше о Bicep.

jobs:  deploy-acr:    name: Разворачивание ACR    runs-on: ubuntu-latest    environment: ${{ inputs.environment }}    steps:      - uses: actions/checkout@v2      - uses: azure/login@v1        with:          creds: ${{ secrets.azure_credentials }}      - name: Развернуть Bicep        uses: azure/arm-deploy@v1        with:          resourceGroupName: ${{ inputs.resource_group }}          template: bicep/acr.bicep          parameters:            acrName=${{ inputs.acr_name }}            acrSku=Basic          failOnStdErr: false

Затем на третьем шаге создается и прокладывается образ Docker в реестр с использованием файла build_push_container.yml, который выполняет команды Azure CLI для получения учетных данных для контейнерного реестра, а также команды Docker для создания и прокладки образа Docker.

На четвертом шаге производится доставка контейнерного экземпляра на основе нашего образа Docker. Этот шаг выполняется с помощью файла deploy_aci.yml, который, в свою очередь, использует предопределенное действие с названием ‘azure/aci-deploy@v1’.

На последнем шаге с использованием файла kv_access.yml мы предоставляем контейнерному экземпляру разрешение на доступ к общему секретному хранилищу через “управляемую идентичность”, что означает, что контейнер может получать секреты из общего секретного хранилища напрямую, без использования ключа доступа. Для достижения этого нам необходимо обновить развернутый контейнерный экземпляр, используя команду Azure CLI az container create и предоставить различные параметры, которые мы использовали ранее. Кроме того, мы предоставляем следующую настройку:

— assign-identity — scope ${{ steps.rg_id_step.outputs.rg_id }}

В качестве последнего замечания можно заметить следующие строки в файле workflow.yml:

on:   push:    branches:       - main  workflow_dispatch:

Эти строки указывают, когда и при каких условиях должен запускаться наш конвейер. В нашем сценарии мы хотим, чтобы конвейер запускался при изменении в ветке “main”. Кроме того, мы хотим иметь возможность запускать его вручную. Это делается путем добавления workflow_dispatch:. В рабочем потоке, определенном в workflow_prod_release.yml, вы заметите, что выпуск в продакшен имеет только ручное управление. Есть множество других способов настройки запуска конвейера. Например, вы можете игнорировать изменения в определенных файлах или папках, так что только изменения в коде приложения будут вызывать новые развертывания.