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

Databricks Apps エージェントの CI/CD をセットアップします。

CI/CDパイプラインは、エージェントへのすべての変更をコードレビューと自動デプロイを介して実行します。そのため、本番運用のロールアウトは特定の開発者のノートパソコンに依存しません。パイプラインが構成されると、メインBranchへのすべてのMergeによって、Databricks Appsでエージェントがデプロイおよび再起動されます。

このページでは、エージェント固有の要素について説明します。CI/CD for Databricks Apps with GitHub Actionsでは、ワークフローの基本設定について説明します。ワークロードIDフェデレーション、GitHub環境、デプロイYAMLです。まずそのページを完了し、その後、エージェントアプリに適用される追加内容についてここに戻ってください。

要件​

ステップ 1: スターター ワークフローを使用します。​

databricks/app-templatesのいくつかのエージェントTemplateには、すぐに使える.github/workflows/deploy.ymlが付属しているため、ワークフローを最初から作成する必要はありません。

  1. databricks/app-templatesから、agent-langgraphやagent-openai-agents-sdkなどのエージェントTemplateを選択してください。
  2. クローンされたTemplateディレクトリで、.github/workflows/deploy.ymlが存在するかどうかを確認します。
  3. ワークフローを設定します：
    • deploy.yml が存在する場合 ：開いて、databricks bundle run ステップが databricks.yml からバンドルのリソースキーを参照していることを確認し、ファイルのヘッダーコメントにある前提条件に従ってください。
    • deploy.ymlが存在しない場合 : 既存のTemplateからコピーするか、またはステップ4. デプロイワークフローを追加するからコピーしてください。次に、databricks bundle run <key>ステップを更新して、バンドルのリソースキーと一致させます。

ステップ2。 MLflowエクスペリメントIDを事前入力します。​

databricks.ymlでは、エージェントTemplateはMLFLOW_EXPERIMENT_IDを空のままにします。quickstartスクリプトは最初のセットアップ時にローカルで設定されますが、新しいCIランナーは設定されません。experiment_idが空の場合、databricks bundle deployはTerraform型のエラー（For input string: ""）で失敗します。

これを修正するには、入力された値をcommit。

  1. エージェントを作成したマシンで、uv run quickstart --profile <your-profile> をローカルで実行してください。
  2. databricks.yml内のエクスペリメントリソース（resources.apps.<key>.resourcesの下のname: 'experiment'のエントリ）に数値experiment_idがあることを確認してください。
  3. 変更をcommitしてください。

エクスペリメントはワークスペース スコープであるため、そのワークスペースを対象とするすべての CI デプロイに対して同じ ID が有効です。複数のワークスペースにデプロイする場合、databricks.yml でターゲットごとのエクスペリメントを宣言するか (targets.<env> ブロックごとに 1 つ)、バンドル変数を使用します。

Lakebase メモリ テンプレートの Postgres 権限を付与します​

高度なエージェント Template（agent-langgraph-advanced, agent-openai-advanced）は、オートスケール Lakebase Postgres リソースをdatabricks.ymlで直接宣言します。Databricks CLI v0.295.0 以降では、databricks bundle deploy はリソースをアプリとともにプロビジョニングします。

DAB postgres リソースは、アプリのDatabricks Service PrincipalにLakebaseプロジェクトへのワークスペースレベルのアクセスを許可しますが、Lakebaseはデータベースアクセス（スキーマ、テーブル、シーケンス）のために個別のPostgresロールレイヤーを保持しています。エージェントがメモリテーブルを読み書きできるようになる前に、Databricks Service Principalには適切な権限を持つPostgresロールが必要です。2層モデルについては、認証アーキテクチャをご覧ください。

これらのPostgresレベルの権限を付与することは、 一度限りのセットアップ です。最初のbundle deployとbundle runの間でローカルで実行します。Databricks Service PrincipalのPostgresロールはアプリの存続期間中永続するため、CIはその後、標準のdeployからrunのパスを経由して再デプロイします。

  1. バンドルをデプロイしてLakebaseリソースをプロビジョニングします：

    Bash
    databricks bundle deploy --target prod

  2. Databricks Service Principalに必要なPostgresレベルの権限を付与します：

    Bash
    uv run python scripts/grant_lakebase_permissions.py \
      "$(databricks apps get <app-name> --output json | jq -r '.service_principal_client_id')" \
      --memory-type openai \
      --autoscaling-endpoint <endpoint>

    LangGraph Templateの場合、--memory-type langgraphを渡します。このスクリプトは、オートスケールLakebaseの場合は--project <project> --branch <branch>を、プロビジョニング済みLakebaseの場合は--instance-name <name>も受け付けます。

  3. アプリを起動：

    Bash
    databricks bundle run <bundle-key> --target prod

ステップ 3. デプロイ済みエージェントのスモークテスト​

databricks bundle run ランナーがエージェントに起動をシグナルするとすぐに返されますが、エージェントプロセスは起動中にまだ失敗する可能性があります。ステップ5. アプリが正常になるのを待つからのヘルスチェックの後、カナリアリクエストを/invocationsにポストする次のスモークテストステップをdeploy.ymlに追加します：

YAML
- name: Smoke test invocations
  env:
    APP_NAME: my-agent
  run: |
    APP_URL=$(databricks apps get "$APP_NAME" --output json | jq -r '.url')
    TOKEN=$(databricks auth token | jq -r '.access_token')
    STATUS=$(curl -sS -o /tmp/canary.json -w "%{http_code}" \
      -X POST "$APP_URL/invocations" \
      -H "Authorization: Bearer $TOKEN" \
      -H "Content-Type: application/json" \
      -d '{"input": [{"role": "user", "content": "ping"}], "stream": false}')
    if [ "$STATUS" != "200" ]; then
      echo "Smoke test failed with status $STATUS:" >&2
      cat /tmp/canary.json >&2
      exit 1
    fi
    echo "Smoke test passed."
注記

Databricks Apps 、呼び出しにOAuthトークンのみを受け入れます。 databricks auth tokenのワークスペースOAuthトークンを使用します。 Databricks Appsは他のトークンタイプを拒否します。

その他のリソース​

このページの見出し