CI/CD для приложений Databricks с помощью GitHub Actions

На этой странице объясняется, как автоматизировать развертывание приложения Databricks из GitHub с помощью GitHub Actions и Declarative Automation Bundles. Он охватывает федерацию удостоверений рабочей нагрузки, рабочий процесс YAML и проверку работоспособности, которая подтверждает, что приложение обслуживает последний код после каждого развертывания.

Общие рекомендации GitHub Actions для заданий и конвейеров Azure Databricks см. в разделе GitHub Actions. Сведения о настройке федерации удостоверений для рабочей нагрузки см. в статье Включение федерации удостоверений для рабочей нагрузки в GitHub Actions.

Note

Чтобы повторно развернуть приложение автоматически при каждой отправке в ветвь, используйте автоматические развертывания Git (бета-версия). См. статью "Включить автоматическое развертывание Git".

Requirements

Шаг 1. Настройка федерации удостоверений рабочей нагрузки

Федерация удостоверений для рабочей нагрузки позволяет исполнителю GitHub Actions проходить аутентификацию в Azure Databricks с помощью краткоживущего токена OIDC вместо хранения учетных данных в репозитории.

  1. Выполните действия, описанные в разделе Настройка федерации удостоверений рабочей нагрузки для GitHub Actions, чтобы создать политику федерации GitHub Actions в субъекте-службы. Запишите идентификатор приложения субъекта-службы (UUID) и URL-адрес вашей рабочей области. В рабочем процессе требуются обе переменные.
  2. Предоставьте субъекту-службе CAN MANAGE разрешение на приложение или разрешение рабочей области для создания приложений, если приложение еще не существует. См. настройку разрешений для приложения Databricks.

шаг 2. Настройка репозитория GitHub

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

  1. В Параметры>Среды создайте среду с именем prod (или любым именем, на которое ссылается ваш рабочий процесс).
  2. Для переменных среды добавьте следующее:
Variable Value
DATABRICKS_HOST URL-адрес рабочей области, например https://my-workspace.cloud.databricks.com
DATABRICKS_CLIENT_ID Идентификатор приложения субъекта-службы из шага 1

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

Шаг 3. Настройка пакета для рабочих развертываний

В databricks.yml укажите явную рабочую область host и root_path для вашего целевого объекта prod. Это гарантирует, что пакет будет разворачиваться в одном и том же месте при каждом запуске. Для проверки в рабочем режиме требуются оба поля, если только для run_as не задан субъект-служба. См. режимы развертывания декларативных пакетов автоматизации.

Источник Git

Используйте git_source, чтобы при развертывании код загружался напрямую из вашего репозитория Git вместо загрузки файлов в рабочую область. Это позволяет избежать дополнительного sync шага и сохраняет развернутый код в синхронизации с репозиторием.

targets:
  prod:
    mode: production
    workspace:
      host: https://my-workspace.cloud.databricks.com
      root_path: /Workspace/Users/<service-principal-or-owner>/.bundle/${bundle.name}/${bundle.target}
    resources:
      apps:
        my_app:
          name: my-app
          git_repository:
            url: https://github.com/org/repo
          git_source:
            branch: main
            source_code_path: apps/my-app

Замените <service-principal-or-owner> пользователем рабочей области, который владеет артефактами пакета, как правило, идентификатором приложения субъекта-службы. Замените URL-адрес git_repository URL-адресом вашего репозитория GitHub. Если код приложения находится в корневом каталоге репозитория, опустить source_code_path. См. приложение.

Для приватных репозиториев настройте учетные данные Git для сервисного субъекта приложения перед развертыванием. Инструкции cli см. в статье "Развертывание из репозитория Git".

Источник рабочей области

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

targets:
  prod:
    mode: production
    workspace:
      host: https://my-workspace.cloud.databricks.com
      root_path: /Workspace/Users/<service-principal-or-owner>/.bundle/${bundle.name}/${bundle.target}
    resources:
      apps:
        my_app:
          name: my-app
          source_code_path: ./app

Замените <service-principal-or-owner> пользователем рабочей области, который владеет артефактами пакета, как правило, идентификатором приложения субъекта-службы. Замените ./app на путь к исходному коду вашего приложения относительно databricks.yml. См. приложение.

Шаг 4. Добавьте процесс развертывания

Добавьте .github/workflows/deploy.yml в репозиторий:

name: Deploy to Databricks Apps

on:
  workflow_dispatch:
  # Uncomment to deploy on every push to main once the workflow is validated.
  # push:
  #   branches: [main]

permissions:
  id-token: write # required for OIDC federation
  contents: read

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    environment: prod
    env:
      DATABRICKS_AUTH_TYPE: github-oidc
      DATABRICKS_HOST: ${{ vars.DATABRICKS_HOST }}
      DATABRICKS_CLIENT_ID: ${{ vars.DATABRICKS_CLIENT_ID }}
    steps:
      - uses: actions/checkout@v4

      - name: Install Databricks CLI
        uses: databricks/setup-cli@main

      - name: Validate bundle
        run: databricks bundle validate --target prod

      - name: Deploy bundle
        run: databricks bundle deploy --target prod

      - name: Start or restart app
        run: databricks bundle run my_app --target prod

На последнем шаге замените my_app на ключ ресурса, который ваш databricks.yml использует в разделе resources.apps.

Исполнителю требуется разрешение id-token: write для запроса токена OIDC. Действие databricks/setup-cli автоматически считывает DATABRICKS_AUTH_TYPE=github-oidc и обрабатывает проверку подлинности.

Предупреждение

databricks bundle deploy отправляет исходный код и обновляет ресурсы, но не перезапускает процесс приложения. Если пропустить последний databricks bundle run шаг, развертывание в CI проходит успешно, а приложение продолжает работать на предыдущей версии кода. Всегда запускайте ресурсный пакет после развертывания.

Шаг 5. Дождитесь, пока приложение не станет работоспособным

Databricks рекомендует добавить шаг опроса состояния после развертывания. databricks bundle run завершает работу сразу после того, как приложение сигнализирует о начале работы, но приложение еще не запущено. Он по-прежнему может завершиться ошибкой во время запуска из-за проблем, таких как отсутствующие зависимости, отсутствующие переменные среды или конфликт портов. Добавление шага опроса гарантирует, что сбой запуска также завершается сбоем рабочего процесса:

- name: Wait for app to be running
  env:
    APP_NAME: my-app
  run: |
    for i in $(seq 1 20); do
      STATE=$(databricks apps get "$APP_NAME" --output json | jq -r '.app_status.state')
      echo "Attempt $i/20: state=$STATE"
      if [ "$STATE" = "RUNNING" ]; then
        exit 0
      fi
      sleep 15
    done
    echo "App did not reach RUNNING state within 5 minutes" >&2
    exit 1

Установите для APP_NAME значение, которое ваш databricks.yml объявляет в разделе resources.apps.<key>.name, а не ключ ресурса пакета.

Обработка существующего приложения

Имена приложений уникальны в рабочей области. Шаг bundle deploy завершается с ошибкой An app with the same name already exists, когда другой пакет (или приложение, созданное вручную) уже содержит приложение с таким именем. Свяжите сборку с существующим приложением вместо того, чтобы создавать его заново.

Запустите этот файл один раз локально, чтобы подключить пакет к существующему приложению:

databricks bundle deployment bind my_app <existing-app-name> --target prod --auto-approve

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

Если существующее приложение имеет конфигурацию на стороне сервера (например budget_policy_id), которая не находится в вашем databricks.ymlприложении, скопируйте его в файл пакета перед повторной развертыванием. Несоответствия отображаются как ошибка Terraform "непоследовательный результат" во время шага развертывания пакета.

Выбор триггера

Начните с workflow_dispatch, чтобы первое развертывание было ручным. После успешного выполнения нескольких запусков добавьте push: branches: [main] для развертывания при каждом слиянии.

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

Дополнительные ресурсы

  • Last updated on