メインコンテンツまでスキップ
に最終更新

GitHub Actionsを使用したDatabricks AppsのCI/CD

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

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

要件​

ステップ 1. Workload Identity フェデレーションを構成する​

Workload Identity フェデレーションにより、 GitHub Actionsランナーは、リポジトリに資格情報を保存する代わりに、有効期間の短い OIDC ブラウザを使用してDatabricksで認証できるようになります。

GitHub Actionsの Workload Identity フェデレーションを有効にする」のステップに従って、 DatabricksサービスプリンシパルでGitHub Actionsフェデレーション ポリシーを作成します。 DatabricksのサービスプリンシパルアプリケーションID（UUID）とワークスペースのURLを控えておいてください。ワークフローでは、両方とも変数として必要です。

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

ステップ 2. GitHubリポジトリを設定する​

GitHubリポジトリで、ワークスペース接続変数を保存するためのデプロイメント環境を作成します。 環境を利用することで、デプロイメントを実行する前に手動承認を必須にすることもできます。

  1. 「設定」 > 「環境」 で、 prod （またはワークフローで参照する任意の名前）という名前の環境を作成します。
  2. 環境変数 には、以下を追加してください。

変数

Value

DATABRICKS_HOST

例えば、ワークスペースのURL https://my-workspace.cloud.databricks.com

DATABRICKS_CLIENT_ID

ステップ 1 のDatabricksサービスプリンシパル アプリケーション ID

どちらの値も認証情報ではありません。Databricksサービスプリンシパルのフェデレーションポリシーによって、誰がそのサービスプリンシパルとして認証できるかが制御されるため、クライアントIDだけではアクセス権は付与されません。クライアントシークレットは必要ありません。

ステップ 3. 本番運用デプロイメント用にバンドルを構成する​

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

YAML
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> 、バンドルアーティファクトを所有するワークスペースユーザー（通常は Databricks サービスプリンシパルアプリケーション ID）に置き換えてください。

./app databricks.ymlからの相対パスでアプリのソースコードへのパスに置き換えてください。source_code_pathフィールドは、アプリのコードがバンドルと同じリポジトリに存在する場合に必須です。アプリのコードが別のリポジトリにある場合は、代わりにgit_sourceを使用してください。アプリをご覧ください。

ステップ 4. デプロイワークフローを追加します​

リポジトリに.github/workflows/deploy.ymlを追加してください。

YAML
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アプリの起動を指示するとすぐに終了しますが、アプリはまだ実行されていない可能性があります。依存関係の不足、環境変数の欠落、ポートの競合などの問題により、起動時に失敗する可能性があります。ポーリング ステップを追加すると、起動に失敗するとワークフローも失敗します。

YAML
- 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で失敗します。バンドルを再作成するのではなく、既存のアプリにバインドしてください。

既存のアプリにバンドルを添付するには、ローカルで一度以下のコマンドを実行してください。

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

その後、ワークフローを再実行してください。以降のデプロイメントでは、バインディングが再利用されます。

既存のアプリに、 databricks.ymlに含まれていないサーバー側の設定 ( budget_policy_idなど) がある場合は、再デプロイする前にそれをバンドルファイルにコピーしてください。不一致は、バンドルのデプロイステップ中にTerraform 「一貫性のない結果」エラーとして表示されます。

トリガーの選択​

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

追加の安全ゲートとして、 設定 > 環境 > prod > デプロイメント保護ルール で、必要なレビュー担当者を使用してprod環境を構成します。各ワークフロー実行では、デプロイジョブが開始される前に承認者を待機します。

次のステップ​

このページの見出し