Методы CI/CD с папками Git и Databricks Git (Repos)

  • Статья

Узнайте, как использовать папки Databricks Git в рабочих процессах CI/CD. Настройка папок Databricks Git в рабочей области обеспечивает управление версиями для файлов проекта в репозиториях Git.

На следующем рисунке показан обзор методов и рабочих процессов.

Общие сведения о методах CI/CD для папок Git.

Общие сведения о CI/CD с Azure Databricks см. в статье "Что такое CI/CD в Azure Databricks?".

Поток разработки

Папки Databricks Git имеют папки уровня пользователя. Папки уровня пользователя создаются автоматически при первом клонировании удаленного репозитория. Вы можете рассматривать папки Databricks Git в пользовательских папках как локальные проверка outs, которые являются отдельными для каждого пользователя и где пользователи вносят изменения в свой код.

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

Требования

Для этого рабочего процесса требуется ранее настроенная интеграция с Git.

Примечание.

Databricks рекомендует каждому разработчику работать на собственных ветвь компонента. Дополнительные сведения об устранении конфликтов слияния см. в статье Разрешение конфликтов слияния.

Совместная работа в папках Git

Следующий рабочий процесс использует вызываемую feature-b ветвь на основе основной ветви.

  1. Клонируйте существующий репозиторий Git в рабочую область Databricks.
  2. Используйте пользовательский интерфейс папок Git для создания ветвь компонента из основной ветви. В этом примере для простоты используется один ветвь компонентаfeature-b. Для выполнения работы можно создать и использовать несколько ветвей функций.
  3. Внесите изменения в записные книжки Azure Databricks и другие файлы в репозитории.
  4. Зафиксируйте и отправьте изменения в поставщик Git.
  5. Участники теперь могут клонировать репозиторий Git в собственную папку пользователя.
    1. Работая с новой ветвью, сотрудник вносит изменения в записные книжки и другие файлы в папке Git.
    2. Участник фиксирует и отправляет изменения поставщику Git.
  6. Чтобы объединить изменения из других ветвей или перебазировать ветвь feature-b в Databricks, в пользовательском интерфейсе папок Git используйте один из следующих рабочих процессов:
  7. Когда вы будете готовы объединить работу с удаленным репозиторием Git и main ветвью, используйте пользовательский интерфейс папок Git для объединения изменений из feature-b. Если вы предпочитаете, вы можете вместо этого объединить изменения в поставщике Git.

Рабочий процесс рабочего задания

Папки Databricks Git предоставляют два варианта выполнения рабочих заданий:

  • Вариант 1. Укажите удаленную ссылку на Git в определении задания. Например, запустите определенную записную книжку в main ветви репозитория Git.
  • Вариант 2. Настройка рабочего репозитория Git и вызов API Repos для программного обновления. Запустите задания в папке Databricks Git, которая клонирует этот удаленный репозиторий. Вызов API Repos должен быть первой задачей в задании.

Вариант 1. Выполнение заданий с помощью записных книжек в удаленный репозиторий

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

Это помогает предотвратить непреднамеренные изменения в рабочем задании, например, когда пользователь вносит локальные изменения в рабочий репозиторий или переключает ветви. Он также автоматизирует шаг CD, так как вам не нужно создавать отдельную рабочую папку Git в Databricks, управлять разрешениями для него и поддерживать его обновление.

См. раздел "Использование управляемого версиями исходного кода в задании Azure Databricks".

Вариант 2. Настройка рабочей папки Git и автоматизации Git

В этом случае вы настроили рабочую папку Git и автоматизацию для обновления папки Git при слиянии.

Шаг 1. Настройка папок верхнего уровня

Администратор создает папки верхнего уровня, не являющиеся пользователями. Наиболее распространенным вариантом использования этих папок верхнего уровня является создание папок разработки, промежуточного хранения и рабочих папок, содержащих папки Databricks Git для соответствующих версий или ветвей для разработки, промежуточного хранения и рабочей среды. Например, если ваша компания использует main ветвь для рабочей среды, папка Git "production" должна иметь ветвь, проверка в нейmain.

Обычно разрешения для этих папок верхнего уровня доступны только для чтения для всех пользователей, не являющихся администраторами в рабочей области. Для таких папок верхнего уровня рекомендуется предоставлять только субъекты-службы с разрешениями CAN EDIT и CAN MANAGE, чтобы избежать случайных изменений в рабочем коде пользователями рабочей области.

Папки Git верхнего уровня.

Шаг 2. Настройка автоматических обновлений для папок Git Databricks с помощью API папок Git

Чтобы сохранить папку Git в Databricks в последней версии, можно настроить автоматизацию Git для вызова API Repos. В поставщике Git настройте автоматизацию, которая после каждого успешного слияния PR в главную ветвь вызывает конечную точку API Repos в соответствующей папке Git, чтобы обновить ее до последней версии.

Например, в GitHub это можно сделать с помощью GitHub Actions. Дополнительные сведения см. в статье Repos API.

Чтобы вызвать любой REST API Databricks из ячейки записной книжки Databricks, сначала установите пакет SDK Databricks с %pip install databricks-sdk --upgrade (для последних REST API Databricks), а затем импортируйте ApiClient из databricks.sdk.core.

Примечание.

Если %pip install databricks-sdk --upgrade возвращается сообщение об ошибке "Не удалось найти пакет", пакет databricks-sdk не был установлен ранее. Повторно выполните команду без флага--upgrade: %pip install databricks-sdk

Вы также можете запустить API пакета SDK Databricks из записной книжки, чтобы получить субъекты-службы для рабочей области. Ниже приведен пример использования Python и пакета SDK Databricks для Python.

Вы также можете использовать такие инструменты, как curlPostman или Terraform. Но вы не можете использовать пользовательский интерфейс Azure Databricks.

Дополнительные сведения о субъектах-службах в Azure Databricks см. в статье "Управление субъектами-службами". Сведения о субъектах-службах и CI/CD см. в статье Субъекты-службы для CI/CD. Дополнительные сведения об использовании пакета SDK Databricks из записной книжки см. в статье Об использовании пакета SDK Databricks для Python из записной книжки Databricks.

Использование субъекта-службы с папками Databricks Git

Чтобы запустить приведенные выше упоминание рабочие процессы с субъектами-службами:

  1. Создайте субъект-службу с помощью Azure Databricks.
  2. Добавьте учетные данные Git: используйте поставщик Git PAT для субъекта-службы.

Чтобы настроить субъекты-службы, а затем добавить учетные данные поставщика Git, сделайте следующее:

  1. Создание субъекта-службы. См. статью Выполнение заданий с помощью субъекта-службы.
  2. Создайте маркер идентификатора Microsoft Entra для субъекта-службы.
  3. После создания субъекта-службы вы добавите его в рабочую область Azure Databricks с помощью API субъектов-служб.
  4. Добавьте учетные данные поставщика Git в рабочую область с маркером идентификатора Microsoft Entra и API учетных данных Git.

Интеграция Terraform

Вы также можете управлять папками Databricks Git в полностью автоматизированной настройке с помощью Terraform и databricks_repo:

resource "databricks_repo" "this" {
  url = "https://github.com/user/demo.git"
}

Чтобы использовать Terraform для добавления учетных данных Git в субъект-службу, добавьте следующую конфигурацию:

  provider "databricks" {
    # Configuration options
  }

  provider "databricks" {
    alias = "sp"
    host = "https://....cloud.databricks.com"
    token = databricks_obo_token.this.token_value
  }

  resource "databricks_service_principal" "sp" {
    display_name = "service_principal_name_here"
  }

  resource "databricks_obo_token" "this" {
    application_id   = databricks_service_principal.sp.application_id
    comment          = "PAT on behalf of ${databricks_service_principal.sp.display_name}"
    lifetime_seconds = 3600
  }

  resource "databricks_git_credential" "sp" {
    provider = databricks.sp
    depends_on = [databricks_obo_token.this]
    git_username          = "myuser"
    git_provider          = "azureDevOpsServices"
    personal_access_token = "sometoken"
  }

Настройка автоматизированного конвейера CI/CD с помощью папок Databricks Git

Ниже приведена простая автоматизация, которую можно запустить как действие GitHub.

Требования

  1. Вы создали папку Git в рабочей области Databricks, которая отслеживает объединение базовая ветвь.
  2. У вас есть пакет Python, который создает артефакты для размещения в расположении DBFS. Код должен:
    • Обновите репозиторий, связанный с предпочитаемой ветвью (например development), чтобы содержать последние версии записных книжек.
    • Создайте все артефакты и скопируйте их в путь библиотеки.
    • Замените последние версии артефактов сборки, чтобы избежать необходимости вручную обновлять версии артефактов в задании.

Шаги

Примечание.

Шаг 1 должен выполняться администратором репозитория Git.

  1. Настройте секреты, чтобы код смог получить доступ к рабочей области Databricks. Добавьте следующие секреты в репозиторий Github:

  2. Перейдите на вкладку "Действия " репозитория Git и нажмите кнопку "Создать рабочий процесс ". В верхней части страницы выберите "Настроить рабочий процесс самостоятельно " и вставьте его в этот скрипт:

    Ссылка 

    # This is a basic automation workflow to help you get started with GitHub Actions.

name: CI

  # Controls when the workflow will run
  on:
    # Triggers the workflow on push for main and dev branch
    push:
      branches:
        # Set your base branch name here
        - your-base-branch-name

  # A workflow run is made up of one or more jobs that can run sequentially or in parallel
  jobs:
    # This workflow contains a single job called "deploy"
    deploy:
      # The type of runner that the job will run on
      runs-on: ubuntu-latest
      env:
        DBFS_LIB_PATH: dbfs:/path/to/libraries/
        REPO_PATH: /Repos/path/here
        LATEST_WHEEL_NAME: latest_wheel_name.whl

      # Steps represent a sequence of tasks that will be executed as part of the job
      steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      - name: Setup Python
        uses: actions/setup-python@v2
        with:
        # Version range or exact version of a Python version to use, using SemVer's version range syntax.
          python-version: 3.8

      - name: Install mods
        run: |
          pip install databricks-cli
          pip install pytest setuptools wheel

      - name: Configure CLI
        run: |
          echo "${{ secrets.DEPLOYMENT_TARGET_URL }} ${{ secrets.DEPLOYMENT_TARGET_TOKEN }}" | databricks configure --token

      - name: Extract branch name
        shell: bash
        run: echo "##[set-output name=branch;]$(echo ${GITHUB_REF#refs/heads/})"
        id: extract_branch

      - name: Update Databricks Git folder
        run: |
          databricks repos update --path ${{env.REPO_PATH}} --branch "${{ steps.extract_branch.outputs.branch }}"

      - name: Build Wheel and send to Databricks workspace DBFS location
        run: |
          cd $GITHUB_WORKSPACE
          python setup.py bdist_wheel
          dbfs cp --overwrite ./dist/* ${{env.DBFS_LIB_PATH}}
          # there is only one wheel file; this line copies it with the original version number in file name and overwrites if that version of wheel exists; it does not affect the other files in the path
          dbfs cp --overwrite ./dist/* ${{env.DBFS_LIB_PATH}}${{env.LATEST_WHEEL_NAME}} # this line copies the wheel file and overwrites the latest version with it

  3. Обновите следующие значения переменных среды собственными:

    • DBFS_LIB_PATH. Путь в DBFS к библиотекам (колесам) будет использоваться в этой автоматизации, которая начинается сdbfs:. Например: dbfs:/mnt/myproject/libraries.
    • REPO_PATH. Путь к рабочей области Databricks в папку Git, в которой будут обновлены записные книжки. Например, /Repos/Develop.
    • LATEST_WHEEL_NAME: имя последнего скомпилированного колесика Python (.whl). Это позволяет избежать ручного обновления версий колес в заданиях Databricks. Например, your_wheel-latest-py3-none-any.whl.

  4. Выберите "Зафиксировать изменения", чтобы зафиксировать скрипт как рабочий процесс GitHub Actions. После объединения запроса на вытягивание для этого рабочего процесса перейдите на вкладку "Действия " репозитория Git и убедитесь, что действия будут успешными.