GitHub Actions による Databricks Apps の CI/CD

このページでは、GitHub Actionsと Declarative Automation Bundles を使用して、GitHubから Databricks アプリのデプロイを自動化する方法について説明します。 ワークロード ID フェデレーション、ワークフロー YAML、および各デプロイ後にアプリが最新のコードを提供していることを確認する正常性チェックについて説明します。

Azure Databricksジョブとパイプラインの一般的なGitHub Actionsガイダンスについては、GitHub Actionsを参照してください。 ワークロード ID フェデレーションのセットアップについては、GitHub Actions のワークロード ID フェデレーションを有効にする を参照してください。

Requirements

手順 1、 ワークロード ID フェデレーションの構成

ワークロード ID フェデレーションを使用すると、GitHub Actions ランナーは、リポジトリに資格情報を格納するのではなく、有効期間の短い OIDC トークンを使用してAzure Databricksで認証できます。

GitHub Actions のワークロード ID フェデレーションを有効にする の手順に従って、サービス プリンシパルに GitHub Actions フェデレーション ポリシーを作成します。 サービス プリンシパル アプリケーション ID (UUID) とワークスペースの URL をメモします。 ワークフロー内の変数として両方が必要です。

次に、アプリに対するアクセス許可 CAN MANAGE サービス プリンシパルに付与するか、アプリがまだ存在しない場合は、アプリを作成するためのワークスペースアクセス許可を付与します。 Databricks アプリのアクセス許可の構成を参照してください。

手順 2、 GitHub リポジトリを構成する

GitHub リポジトリで、ワークスペース接続変数を格納するデプロイ環境を作成します。 環境を使用すると、デプロイを実行する前に手動承認を必要とすることもできます。

  1. [設定]>Environments で、prod (またはワークフロー参照の任意の名前) という名前の環境を作成します。
  2. 環境変数の場合は、次を追加します。
Variable Value
DATABRICKS_HOST ワークスペースの URL (例: https://my-workspace.cloud.databricks.com
DATABRICKS_CLIENT_ID 手順 1 のサービス プリンシパル アプリケーション ID

どちらの値も資格情報ではありません。 サービス プリンシパルのフェデレーション ポリシーは、認証できるユーザーを制御するため、クライアント ID だけではアクセス権は付与されません。 クライアント シークレットは必要ありません。

ステップ 3。 運用環境のデプロイ用にバンドルを構成する

databricks.ymlで、host ターゲットで明示的なワークスペースのroot_pathとprodを宣言します。 これにより、すべての実行でバンドルが同じ場所に確実にデプロイされます。 運用モードの検証では、 run_as がサービス プリンシパルに設定されていない限り、両方のフィールドが必要です。 宣言型オートメーション バンドルのデプロイ モードを参照してください。

targets:
  prod:
    mode: production
    workspace:
      host: https://my-workspace.cloud.databricks.com
      root_path: /Workspace/Users/<service-principal-or-owner>/.bundle/${bundle.name}/${bundle.target}
    resources:
      apps:
        my_app:
          name: my-app
          source_code_path: ./app

<service-principal-or-owner>を、バンドル成果物 (通常はサービス プリンシパル アプリケーション ID) を所有するワークスペース ユーザーに置き換えます。

./appを、databricks.ymlを基準としたアプリのソース コードへのパスに置き換えます。 アプリ コードがバンドルと同じリポジトリに存在する場合は、 source_code_path フィールドが必要です。 アプリ コードが別のリポジトリに存在する場合は、代わりに git_source を使用します。 アプリを参照してください。

手順 4、 デプロイ ワークフローを追加する

リポジトリに .github/workflows/deploy.yml を追加します。

name: Deploy to Databricks Apps

on:
  workflow_dispatch:
  # Uncomment to deploy on every push to main once the workflow is validated.
  # push:
  #   branches: [main]

permissions:
  id-token: write # required for OIDC federation
  contents: read

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    environment: prod
    env:
      DATABRICKS_AUTH_TYPE: github-oidc
      DATABRICKS_HOST: ${{ vars.DATABRICKS_HOST }}
      DATABRICKS_CLIENT_ID: ${{ vars.DATABRICKS_CLIENT_ID }}
    steps:
      - uses: actions/checkout@v4

      - name: Install Databricks CLI
        uses: databricks/setup-cli@main

      - name: Validate bundle
        run: databricks bundle validate --target prod

      - name: Deploy bundle
        run: databricks bundle deploy --target prod

      - name: Start or restart app
        run: databricks bundle run my_app --target prod

最後の手順のmy_appを、databricks.ymlの下でresources.appsが使用するリソース キーに置き換えます。

ランナーには、OIDC トークンを要求するための id-token: write アクセス許可が必要です。 databricks/setup-cliアクションは、DATABRICKS_AUTH_TYPE=github-oidcを読み取り、認証を自動的に処理します。

警告

databricks bundle deploy はソース コードをアップロードし、リソースを更新しますが、アプリ プロセスは再起動されません。 最後の databricks bundle run 手順をスキップすると、アプリが前のコードを引き続き提供している間、デプロイは CI で渡されます。 デプロイ後は常にバンドル リソースを実行します。

手順 5、 アプリが正常になるのを待つ

Databricks では、デプロイ後に状態ポーリング手順を追加することをお勧めします。 databricks bundle run は、アプリの起動を通知するとすぐに終了しますが、アプリがまだ実行されていない可能性があります。 依存関係の不足、環境変数の不足、ポートの競合などの問題が原因で、起動中も失敗する可能性があります。 ポーリングステップを追加すると、失敗したスタートアップもワークフローで失敗します。

- name: Wait for app to be running
  env:
    APP_NAME: my-app
  run: |
    for i in $(seq 1 20); do
      STATE=$(databricks apps get "$APP_NAME" --output json | jq -r '.app_status.state')
      echo "Attempt $i/20: state=$STATE"
      if [ "$STATE" = "RUNNING" ]; then
        exit 0
      fi
      sleep 15
    done
    echo "App did not reach RUNNING state within 5 minutes" >&2
    exit 1

APP_NAMEを、バンドル リソース キーではなく、databricks.ymlがresources.apps.<key>.nameで宣言する値に設定します。

既存のアプリの処理

アプリ名はワークスペース全体で一意です。 別のバンドル (または手動で作成されたアプリ) がその名前のアプリを既に所有している場合、 bundle deploy ステップは An app with the same name already exists で失敗します。 バンドルを再作成するのではなく、既存のアプリにバインドします。

これをローカルで 1 回実行して、バンドルを既存のアプリにアタッチします。

databricks bundle deployment bind my_app <existing-app-name> --target prod --auto-approve

次に、ワークフローを再実行します。 後続のデプロイでは、バインディングが再利用されます。

既存のアプリに、budget_policy_idにないサーバー側の構成 (databricks.yml など) がある場合は、再デプロイする前にバンドル ファイルにコピーします。 不一致は、バンドルのデプロイ手順中に Terraform の "一貫性のない結果" エラーとして表示されます。

トリガーの選択

最初のデプロイが手動で行われるように、 workflow_dispatch から始めます。 数回の実行が成功したら、すべてのマージにデプロイする push: branches: [main] を追加します。

追加の安全ゲートとして、prod環境は、Settings>Environments>prod>Deployment protection rules で必須のレビュアーを設定して構成します。 ワークフローの各実行は、デプロイジョブが開始される前に承認者による承認を待機します。

次のステップ

  • Last updated on