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 フォルダー UI を使用して、メイン ブランチから機能ブランチを作成します。 この例では、わかりやすくするために 1 つのフィーチャ ブランチ
feature-b
を使用します。 複数の機能ブランチを作成して使用し、作業を行うことができます。リポジトリ内の Databricks ノートブックやその他のファイルに変更を加えます。
コントリビューターは、Git リポジトリを自分のユーザー フォルダーに複製できるようになりました。
新しいブランチで作業している同僚が、Git フォルダー内のノートブックおよびその他のファイルに変更を加えます。
コントリビューターは、 変更をコミットし、Git プロバイダーにプッシュします。
他のブランチからの変更をマージするか、Databricks のfeature-bブランチをリベースするには、Git フォルダー UI で次のワークフローのいずれかを使用します。
ブランチをマージします。 競合がない場合、マージは
git push
を使用してリモート Git リポジトリにプッシュされます。
作業をリモート 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 権限を持つサービス プリンシパルのみを提供することをお勧めします。
ステップ 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
や Terraform などのツールを使用することもできます。Databricks ユーザー インターフェイスを使用することはできません。
Databricksの サービスプリンシパル の詳細については、 「 サービスプリンシパル の管理」を参照してください。 サービスプリンシパルとCI/CDに関する情報については、 「サービスプリンシパル for CI/CD 」を参照してください。 ノートブックから Databricks SDK を使用する方法の詳細については、 「Databricks ノートブック内から Python 用 Databricks SDK を使用する」を参照してください。
Databricks Git フォルダーでサービスプリンシパルを使用する
上記のワークフローをサービスプリンシパルで実行するには:
Databricks を使用してサービスプリンシパルを作成します。
git 資格情報を追加します: サービスプリンシパルの Git プロバイダー PAT です。
サービスプリンシパルを設定し、Git プロバイダーの資格情報を追加するには:
ワークスペースにDatabricks サービスプリンシパル を作成して、 サービスプリンシパル API.
サービスプリンシパルの DatabrickspersonalDatabricks アクセストークンをAPI で作成します。
Git プロバイダーの資格情報をワークスペースに追加するには、Databricks 個人用アクセストークンと Git 資格情報 APIを使用します。
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ワークフローを作成する
コードが Databricks ワークスペースにアクセスできるように シークレット を設定します。 次のシークレットを Github リポジトリに追加します。
DEPLOYMENT_TARGET_URL: これをワークスペースの URL に設定します。
/?o
部分文字列は含めないでください。DEPLOYMENT_TARGET_TOKEN: これを Databricks Personal アクセストークン (PAT) に設定します。 Databricks PAT を生成するには、「個人用アクセストークン認証Databricks」の手順に従います。
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: 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
次の環境変数の値を独自の値に更新します。
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
です。
[ コミット changes... ] を選択して、スクリプトを GitHub Actions ワークフローとしてコミットします。 このワークフローのプルリクエストがマージされたら、Git リポジトリの [アクション ] タブに移動し、アクションが成功したことを確認します。