Git および Databricks を使用した CI/CD テクニック Git フォルダー ( Repos )

CI/CD ワークフローで Databricks Git フォルダーを使用するためのテクニックを学びます。 Databricks の構成ワークスペース内の Git フォルダーは、Git リポジトリ内のプロジェクトファイルのソース管理を提供します。

次の図は、手法とワークフローの概要を示しています。

Databricksを使用した CI/CD の概要については、「 Databricksの CI/CD とは」を参照してください。

開発の流れ

Databricks Git フォルダーにはユーザーレベルのフォルダーがあります。ユーザーレベルのフォルダーは、ユーザーが最初にリモートリポジトリのクローンを作成するときに自動的に作成されます。ユーザーフォルダー内の Databricks Git フォルダーは、ユーザーごとに個別であり、ユーザーがコードを変更する場所である「ローカルチェックアウト」と考えることができます。

Databricks Git フォルダー内のユーザーフォルダーで、リモートリポジトリのクローンを作成します。ベストプラクティスは、変更をメインブランチに直接コミットしてプッシュするのではなく、新しい機能ブランチを作成するか、以前に作成したブランチを作業用に選択することです。そのブランチで変更を加え、コミットし、変更をプッシュすることができます。コードをマージする準備ができたら、Git フォルダー UI でマージできます。

要件

このワークフローでは、 Git 統合をすでに設定しておく必要があります。

注

Databricks では、各開発者が独自の機能ブランチで作業することをお勧めします。マージの競合を解決する方法については、「マージの競合を解決する」を参照してください。

Git フォルダー内で共同作業する

次のワークフローでは、メインブランチに基づくfeature-bというブランチを使用します。

既存の Git リポジトリを Databricks ワークスペースに複製します。
Git フォルダー UI を使用して、メインブランチから機能ブランチを作成します。この例では、わかりやすくするために 1 つのフィーチャブランチ feature-b を使用します。複数の機能ブランチを作成して使用し、作業を行うことができます。
リポジトリ内の Databricks ノートブックやその他のファイルに変更を加えます。
変更をコミットし、Git プロバイダーにプッシュします。
コントリビューターは、Git リポジトリを自分のユーザーフォルダーに複製できるようになりました。
1. 新しいブランチで作業している同僚が、Git フォルダー内のノートブックおよびその他のファイルに変更を加えます。
2. コントリビューターは、変更をコミットし、Git プロバイダーにプッシュします。
他のブランチからの変更をマージするか、Databricks のfeature-bブランチをリベースするには、Git フォルダー UI で次のワークフローのいずれかを使用します。
- ブランチをマージします。競合がない場合、マージはgit pushを使用してリモート Git リポジトリにプッシュされます。
- 別のブランチにリベースします。
作業をリモート Git リポジタとmainブランチにマージする準備ができたら、Git フォルダー UI を使用してfeature-bからの変更をマージします。必要に応じて、Git プロバイダーの変更をマージすることもできます。

本番運用ジョブのワークフロー

Databricks Git フォルダーには、本番運用ジョブを実行するための 2 つのオプションがあります。

オプション 1 : ジョブ定義にリモート Git 参照を指定します。たとえば、Git リポジトリのmainブランチで特定のノートブックを実行します。
オプション 2 : 本番運用 Git リポジトリをセットアップし、 Repos APIs呼び出してプログラム的に更新します。このリモートリポジトリのクローンを作成する Databricks Git フォルダーに対してジョブを実行します。 Repos API 呼び出しはジョブの最初のタスクである必要があります。

オプション 1: リモートリポジトリのノートブックを使用してジョブを実行する

ジョブ定義プロセスを簡素化し、リモート Git リポジトリにあるノートブックを使用して Databricks ジョブを実行することで、信頼できる唯一の情報源を保持します。この Git 参照は、Git コミット、タグ、またはブランチにすることができ、ジョブ定義でユーザーによって提供されます。

これは、ユーザーが本番運用リポジトリでローカル編集を行ったり、ブランチを切り替えたりする場合など、本番運用ジョブに対する意図しない変更を防ぐのに役立ちます。また、Databricks で別の本番運用 Git フォルダーを作成し、そのフォルダーのアクセス許可を管理し、更新し続ける必要がないため、CD ステップも自動化されます。

「 Databricks ジョブでバージョン管理されたソースコードを使用する」を参照してください。

オプション 2: 本番運用 Git フォルダーと Git オートメーションをセットアップする

このオプションでは、本番運用 Git フォルダーと、マージ時に Git フォルダーを更新する自動化を設定します。

ステップ 1: 最上位フォルダを設定する

管理者は、ユーザー以外の最上位フォルダーを作成します。これらの最上位フォルダーの最も一般的な使用例は、開発、ステージング、および本番運用に適切なバージョンまたはブランチの Databricks Git フォルダーを含む、開発、ステージング、および本番運用フォルダーを作成することです。たとえば、会社が本番運用にmainブランチを使用している場合、「本番運用」Git フォルダにはmainブランチがチェックアウトされている必要があります。

通常、これらの最上位フォルダーに対するアクセス許可は、ワークスペース内のすべての非管理ユーザーに対して読み取り専用です。このような最上位フォルダーの場合は、ワークスペースユーザーによる本番運用コードの誤った編集を避けるために、CAN EDIT および CAN MANAGE 権限を持つサービスプリンシパルのみを提供することをお勧めします。

ステップ 2: Git フォルダー API を使用して Databricks Git フォルダーへの自動更新をセットアップする

Databricks の Git フォルダーを最新バージョンに保つために、 Repos APIを呼び出すように Git オートメーションを設定できます。 Git プロバイダーで、メインブランチへの PR のマージが成功するたびに、適切な Git フォルダー上の Repos API エンドポイントを呼び出して最新バージョンに更新する自動化をセットアップします。

たとえば、GitHub では、これは GitHub Actions で実現できます。詳細については、「 repo API」を参照してください。

Databricks ノートブックセル内から Databricks REST API を呼び出すには、まず %pip install databricks-sdk --upgrade を使用して Databricks SDK をインストールし (最新の Databricks REST APIs用)、databricks.sdk.core からApiClientインポートします。

注

%pip install databricks-sdk --upgrade が "パッケージが見つかりませんでした" というエラーを返す場合、databricks-sdk パッケージは以前にインストールされていません。--upgrade フラグを付けずにコマンドを再実行します: %pip install databricks-sdk。

ノートブックから Databricks SDK APIsを実行して、ワークスペースのサービスプリンシパルを取得することもできます。次に、Python とDatabricks SDK for Pythonを使用した例を示します。

curl、Postman、Terraform などのツールを使用することもできます。Databricks ユーザーインターフェイスは使用できません。

Databricksのサービスプリンシパルの詳細については、「サービスプリンシパルの管理」を参照してください。サービスプリンシパルとCI/CDに関する情報については、「サービスプリンシパル for CI/CD 」を参照してください。ノートブックから Databricks SDK を使用する方法の詳細については、「Databricks ノートブック内から Python 用 Databricks SDK を使用する」を参照してください。

Terraform 統合

Terraformとdatabricks_repoを使用して、完全に自動化されたセットアップで Databricks Git フォルダーを管理することもできます。

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"
  }

Databricks Git フォルダーを使用して自動化された CI/CD パイプラインを構成する

ここでは、 GitHub Actionsとして実行できる簡単な自動化を示します。

要件

Databricks ワークスペースに、マージ先のベースブランチを追跡する Git フォルダーを作成しました。
DBFS の場所に配置するアーティファクトを作成する Python パッケージがあります。コードは次の条件を満たす必要があります。
- 優先ブランチ ( developmentなど) に関連付けられたリポジトリを更新して、ノートブックの最新バージョンを含めます。
- アーティファクトをビルドし、ライブラリパスにコピーします。
- ジョブ内でアーティファクトのバージョンを手動で更新する必要がないように、ビルドアーティファクトの最新バージョンを置き換えます。

ステップ

注

ステップ 1 は、Git リポジトリの管理者が実行する必要があります。

コードが Databricks ワークスペースにアクセスできるようにシークレットを設定します。次のシークレットを Github リポジトリに追加します。
- DEPLOYMENT_TARGET_URL : ワークスペース URL に設定しますが、 /?o部分文字列は含めないでください。
- DEPLOYMENT_TARGET_TOKEN : Databricks Personal アクセスウイルス (PAT) 値を指定します。「Git 資格情報の構成とリモートリポジトリの Databricks への接続」の手順に従って、Databricks PAT を生成できます。

Git リポジトリの[アクション]タブに移動し、 [新しいワークフロー]ボタンをクリックします。ページの上部で、 [ワークフローを自分で設定する]を選択し、次のスクリプトを貼り付けます。

GitHub Actions UI の「ワークフローを自分でセットアップする」リンク

# 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

次の環境変数の値を独自の値に更新します。
- DBFS_LIB_PATH : この自動化で使用するライブラリ (ホイール) への DBFS 内のパス ( dbfs:で始まります)。たとえば、dbfs:/mnt/myproject/librariesです。
- REPO_PATH : ノートブックが更新される Git フォルダーへの Databricks ワークスペース内のパス。たとえば、 /Repos/Developです。
- LATEST_WHEEL_NAME : 最後にコンパイルされたPython wheelファイル (.whl) の名前。これは、Databricks ジョブのホイールバージョンを手動で更新することを避けるために使用されます。たとえば、 your_wheel-latest-py3-none-any.whlです。
[変更をコミット…]を選択して、スクリプトを GitHub Actions ワークフローとしてコミットします。このワークフローのプルリクエストがマージされたら、Git リポジトリの[アクション]タブに移動し、アクションが成功したことを確認します。