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 プロバイダーの変更をマージすることもできます。

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

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 権限を持つサービス プリンシパルのみを提供することをお勧めします。

最上位の Git フォルダー。

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

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

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

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 の詳細については、「 CI/CD のサービスプリンシパル」を参照してください。 ノートブックから Databricks SDK を使用する方法の詳細については、「Databricks ノートブック内から Databricks SDK for Python を使用する」を参照してください。

Databricks Git フォルダーでサービスプリンシパルを使用する

上記のワークフローをサービスプリンシパルで実行するには:

  1. Databricks を使用してサービスプリンシパルを作成します。

  2. git 資格情報を追加します: サービスプリンシパルの Git プロバイダー PAT です。

サービスプリンシパルを設定し、Git プロバイダーの資格情報を追加するには:

  1. サービスプリンシパル API を使用して、ワークスペースに Databricks サービスプリンシパルを作成します。

  2. トークン管理 API を使用して、Databricks サービスプリンシパルの Databricks アクセストークンを作成します。

  3. Databricks アクセストークンと Git 資格情報 API を使用して、 Git プロバイダーの資格情報をワークスペースに追加します。

Terraform 統合

Terraformdatabricks_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として実行できる簡単な自動化を示します。

要件

  1. Databricks ワークスペースに、マージ先のベース ブランチを追跡する Git フォルダーを作成しました。

  2. DBFS の場所に配置するアーティファクトを作成する Python パッケージがあります。 コードは次の条件を満たす必要があります。

    • 優先ブランチ ( developmentなど) に関連付けられたリポジトリを更新して、ノートブックの最新バージョンを含めます。

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

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

ステップ

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

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

  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:
          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 : ノートブックが更新される Git フォルダーへの Databricks ワークスペース内のパス。 たとえば、 /Repos/Developです。

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

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