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

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

CI/CDパイプラインでは、エージェントへのすべての変更がコードレビューと自動デプロイを経て実行されるため、本番運用でのリリースは特定の開発者のラップトップに依存しません。パイプラインが構成されると、メインブランチへのすべてのマージにより、Databricks Apps 上でエージェントがデプロイされ、再起動されます。

このページでは、エージェント固有の側面について説明します。GitHub Actions を使用した Databricks Apps の CI/CD は、主要なワークフローのセットアップ（ワークロード ID フェデレーション、GitHub 環境、およびデプロイ YAML）について文書化しています。まずそのページを完了し、その後、ここに戻ってエージェントアプリに適用される追加情報を参照してください。

要件​

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

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

  1. databricks/app-templatesから、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を事前入力します。​

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

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

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

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

Lakebaseメモリテンプレートに対するPostgres権限を付与する​

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

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

これらのPostgresレベルの権限の付与は、**1回限りの設定**です。最初のbundle deployとbundle runの間でローカルで実行してください。DatabricksサービスプリンシパルのPostgresロールはアプリの存続期間中持続するため、その後CIは標準のdeployからrunのパスを経て再デプロイされます。

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

    Bash
    databricks bundle deploy --target prod

  2. Databricks サービスプリンシパルに、必要な 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テンプレートの場合は、--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. アプリが正常になるまで待機するによるヘルスチェックの後、deploy.yml に次のスモークテスト ステップを追加します。これは、/invocations にカナリア リクエストを送信します：

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は他のトークンタイプを拒否します。

その他のリソース​

このページの見出し