Databricks Apps エージェントの CI/CD を設定する

CI/CD パイプラインは、コード レビューと自動デプロイを通じてエージェントに対するすべての変更を実行するため、運用環境のロールアウトは開発者のノート PC に依存しません。 パイプラインが構成されると、メイン ブランチにマージされるたびに、Databricks Apps でエージェントがデプロイされ、再起動されます。

このページでは、エージェント固有の部分について説明します。 CI/CD for Databricks Apps with GitHub Actions では、ワークロード ID フェデレーション、GitHub環境、デプロイ YAML というコア ワークフローのセットアップが文書化されています。 最初にそのページを完了し、エージェント アプリに適用される追加情報をここに戻します。

Requirements

手順 1、 スターター ワークフローを使用する

databricks/app-templates 内のいくつかのエージェント テンプレートには、すぐに使用できる.github/workflows/deploy.ymlが付属しているため、ワークフローを最初から記述する必要はありません。

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

手順 2、 MLflow 実験 ID を事前に入力する

エージェントテンプレートでは、MLFLOW_EXPERIMENT_ID 内の databricks.yml は空欄のままになります。 quickstart スクリプトは初回セットアップ時にローカル環境でそれを補完しますが、新しい CI ランナーでは補完しません。 experiment_idが空の場合、databricks bundle deployは Terraform 型エラー (For input string: "") で失敗します。

これを修正するには、設定された値をコミットします。

  1. エージェントを作成したマシン上で uv run quickstart --profile <your-profile> をローカルで実行します。
  2. databricks.yml内の実験リソース (name: 'experiment'の下にresources.apps.<key>.resourcesが含まれるエントリ) に数値experiment_idがあることを確認します。
  3. 変更をコミットします。

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

Lakebase メモリ テンプレートの Postgres アクセス許可を付与する

高度なエージェント テンプレート (agent-langgraph-advanced、 agent-openai-advanced) では、自動スケールの Lakebase Postgres リソースが databricks.ymlで直接宣言されます。 Databricks CLI v0.295.0 以降では、 databricks bundle deploy はアプリと共にリソースをプロビジョニングします。

DAB postgres リソースは、Lakebase プロジェクトへのアプリのサービス プリンシパル ワークスペース レベルのアクセス権を付与しますが、Lakebase はデータベース アクセス (スキーマ、テーブル、シーケンス) 用に個別の Postgres ロール レイヤーを保持します。 エージェントがメモリ テーブルの読み取りまたは書き込みを行う前に、サービス プリンシパルには適切な特権を持つ Postgres ロールが必要です。 2 層モデルの 認証アーキテクチャ を参照してください。

これらの Postgres レベルの特権を付与することは、 1 回限りセットアップです。 最初の bundle deploy と bundle runの間でローカルに実行します。 サービス プリンシパルの Postgres ロールはアプリの有効期間中保持されるため、CI は標準deployrunパスを通過した後に再デプロイされます。

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

    databricks bundle deploy --target prod

  2. 必要な Postgres レベルの特権をサービス プリンシパルに付与します。

    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 テンプレートの場合は、 --memory-type langgraph渡します。 このスクリプトでは、自動スケールの Lakebase の --project <project> --branch <branch> 、またはプロビジョニングされた Lakebase の --instance-name <name> も受け入れます。

  3. アプリを起動します。

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

手順 3. デプロイされたエージェントをスモークテストする

databricks bundle run は、ランナーがエージェントの起動を通知するとすぐに戻りますが、起動中にエージェント プロセスが失敗する可能性があります。 手順 5. アプリが正常になるまで待機する のヘルスチェックの後、deploy.yml にカナリア リクエストを送信する次のスモークテスト手順を /invocations に追加します。

- 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."

Note

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

その他のリソース

  • Last updated on