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

CI/CD ワークフローで Databricks Git フォルダーを使用するテクニックを学習します。 ワークスペースでDatabricks Gitフォルダーを構成すると、 Gitリポジトリ内のプロジェクト ファイルのソース コントロールを使用し、それらをデータエンジニアリング パイプラインに統合できるようになります。

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

Git フォルダーの CI/CD テクニックの概要。

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

開発の流れ

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

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

要件

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

注

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

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

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

  1. 既存の Git リポジトリを Databricks ワークスペースに複製します。

  2. Git フォルダー UI を使用して、メイン ブランチから機能ブランチを作成します。 この例では、わかりやすくするために 1 つのフィーチャ ブランチ feature-b を使用します。 複数の機能ブランチを作成して使用し、作業を行うことができます。

  3. リポジトリ内の Databricks ノートブックやその他のファイルに変更を加えます。

  4. 変更をコミットし、Git プロバイダーにプッシュします。

  5. コントリビューターは、Git リポジトリを自分のユーザー フォルダーに複製できるようになりました。

    1. 新しいブランチで作業している同僚が、Git フォルダー内のノートブックおよびその他のファイルに変更を加えます。

    2. コントリビューターは、 変更をコミットし、Git プロバイダーにプッシュします。

  6. 他のブランチからの変更をマージするか、Databricks のfeature-bブランチをリベースするには、Git フォルダー UI で次のワークフローのいずれかを使用します。

  7. 作業をリモート Git リポジトリとmainブランチにマージする準備ができたら、Git フォルダー UI を使用してfeature-bからの変更をマージします。 必要に応じて、Git フォルダーをバックアップする Git リポジトリに変更を直接マージすることもできます。

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

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

  • オプション 1 : ジョブ定義にリモート Git 参照を指定します。 たとえば、Git リポジトリのmainブランチで特定のノートブックを実行します。

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

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

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

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

「ジョブでの Git の使用」を参照してください。

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

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

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

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

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

最上位の Git フォルダー。

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

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

たとえば、GitHub では、これは GitHub Actions で実現できます。

Databricks Gitフォルダーを使用した自動化にサービスプリンシパルを使用する

Databricks アカウント コンソールまたはDatabricks CLIを使用して、ワークスペースのGitフォルダへのアクセスを許可されたサービスプリンシパルを作成できます。

新しいサービスプリンシパルを作成するには、「 サービスプリンシパルの管理」を参照してください。 ワークスペースにサービスプリンシパルがある場合は、 Git の資格情報をそれにリンクして、自動化の一部としてワークスペースの Git フォルダーにアクセスできるようにすることができます。

サービスプリンシパルに Git フォルダーへのアクセスを許可する

Gitアカウントコンソールを使用して、サービスプリンシパルのDatabricks フォルダへの許可されたアクセスを提供するには:

  1. Databricks ワークスペースにログインします。 これらの手順を完了するには、ワークスペースの管理者権限が必要です。 ワークスペースの管理者権限をお持ちでない場合は、管理者権限をリクエストするか、アカウント管理者にお問い合わせください。

  2. 任意のページの右上隅で、ユーザー名をクリックし、[ 設定]を選択します。

  3. 左側のナビゲーション ウィンドウの [ワークスペース管理] で [ID とアクセス] を選択し、サービスプリンシパルの [管理] ボタンを選択します。

    ワークスペース設定の下のサービスプリンシパルページ

  4. サービスプリンシパルの一覧から、 Git 資格情報で更新するサービスプリンシパルを選択します。 [ サービスプリンシパルの追加] を選択して、新しいサービスプリンシパルを作成することもできます。

    Databricks アカウント コンソールを使用したサービス プリンシパルの作成または追加

  5. [Git 統合] タブを選択します。(サービスプリンシパルを作成していない場合、またはサービスプリンシパル マネージャー権限が割り当てられていない場合は、グレー表示されます。 その下で、資格情報の Git プロバイダー (GitHub など) を選択し、[ Git アカウントのリンク] を選択して、[ リンク] を選択します。

    また、自分の Git 資格情報をリンクしたくない場合は、Git 個人用アクセス トークン (PAT) を使用することもできます。 代わりに PAT を使用するには、[ 個人用アクセス トークン ] を選択し、サービス プリンシパルのアクセスを認証するときに使用する Git アカウントのトークン情報を指定します。 Git プロバイダーから PAT を取得する方法の詳細については、「 Git 資格情報の構成とリモート リポジトリの Databricks への接続」を参照してください。

    Git資格情報をDatabricksサービスプリンシパルにリンクする

  6. リンクする Git ユーザー アカウントを選択するように求められます。 サービスプリンシパルがアクセスに使用する Git user アカウントを選択し、[ 続行] を選択します。 (使用するユーザー アカウントが表示されない場合は、[ 別のアカウントを使用する] を選択します。

  7. 次のダイアログで、 [Databricks の承認] を選択します。 「アカウントにリンクしています」というメッセージが一時的に表示され、その後、更新されたサービスプリンシパルの詳細が表示されます。

    Git認証情報の連携に成功している確認画面

選択したサービスプリンシパルは、自動化の一部としてGit DatabricksワークスペースGit フォルダー リソースにアクセスするときに、リンクされた 資格情報を適用するようになりました。

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など) に関連付けられたリポジトリを更新して、ノートブックの最新バージョンを含めます。

    • アーティファクトをビルドし、ライブラリ パスにコピーします。

    • ジョブ内でアーティファクトのバージョンを手動で更新する必要がないように、ビルド アーティファクトの最新バージョンを置き換えます。

自動化されたCI/CDワークフローを作成する

  1. コードが Databricks ワークスペースにアクセスできるように シークレット を設定します。 次のシークレットを Github リポジトリに追加します。

    • DEPLOYMENT_TARGET_URL: これをワークスペースの URL に設定します。 /?o部分文字列は含めないでください。

    • DEPLOYMENT_TARGET_TOKEN: これを Databricks Personal アクセストークン (PAT) に設定します。 Databricks PAT を生成するには、「個人用アクセストークン認証Databricks」の手順に従います。

  2. 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:
    paths-ignore:
      - .github
    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
    environment: development
    env:
      DATABRICKS_HOST: ${{ secrets.DEPLOYMENT_TARGET_URL }}
      DATABRICKS_TOKEN:  ${{ secrets.DEPLOYMENT_TARGET_TOKEN }}
      REPO_PATH: /Workspace/Users/someone@example.com/workspace-builder
      DBFS_LIB_PATH: dbfs:/path/to/libraries/
      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@v3

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

    # Download the Databricks CLI. See https://github.com/databricks/setup-cli
    - uses: databricks/setup-cli@main

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

    - 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 ${{env.REPO_PATH}} --branch "${{ steps.extract_branch.outputs.branch }}"

    - name: Build Wheel and send to Databricks DBFS workspace 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 フォルダーへのパス。

    • LATEST_WHEEL_NAME : 最後にコンパイルされたPython wheelファイル (.whl) の名前。 これは、Databricks ジョブのホイール バージョンを手動で更新することを避けるために使用されます。 たとえば、 your_wheel-latest-py3-none-any.whlです。

  4. [ コミット changes... ] を選択して、スクリプトを GitHub Actions ワークフローとしてコミットします。 このワークフローのプルリクエストがマージされたら、Git リポジトリの [アクション ] タブに移動し、アクションが成功したことを確認します。