メインコンテンツまでスキップ

Git と Databricks の Git フォルダー (Repos) を使用した CI/CD 手法

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 を使用して、メイン ブランチから 機能ブランチを作成します 。 この例では、わかりやすくするためにフィーチャーブランチ feature-b を1つ使用しています。 複数の機能ブランチを作成して使用して作業を行うことができます。

  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: リモート リポジトリでノートブックを使用してジョブを実行する​

ジョブ定義プロセスを簡素化し、リモートのDatabricks リポジトリにあるノートブックを使用して ジョブを実行することで、単一の真実のソースを維持します。Gitこの Git 参照は、Git コミット、タグ、またはブランチにすることができ、ジョブ定義で提供されます。

これにより、ユーザーが本番運用リポジトリでローカル編集を行ったり、ブランチを切り替えたりするなど、本番運用ジョブに対する意図しない変更を防ぐことができます。 また、 内に別途本番運用Git Databricksフォルダを作成し、そのパーミッションを管理し、常に最新の状態に保つ必要がないため、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 の統合​

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

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 パーソナル アクセス トークン (PAT) に設定します。 Databricks PAT は、「 Databricks 個人用アクセス トークン認証」の手順に従って生成できます。

  2. Git リポジトリの [アクション ] タブに移動し、[ 新しいワークフロー ] ボタンをクリックします。 ページの上部にある [ Set up a workflow yourself ] を選択し、次のスクリプトを貼り付けます。

    GitHub Actions UI の [ワークフローを自分で�設定する] リンク

    YAML
    # 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 リポジトリの [アクション ] タブに移動し、アクションが成功したことを確認します。

に最終更新