Databricks アセットバンドルの構成

2025-10-08

この記事では、Databricks アセットバンドルを定義する Databricks アセットバンドル構成ファイルの構文について説明します。「Databricks アセットバンドルとは」をご覧ください。

バンドルを作成して使用するには、「 Databricks アセットバンドルの開発」を参照してください。

databricks.yml

バンドルには、バンドルプロジェクトフォルダーのルートに databricks.yml という名前の構成ファイルが 1 つだけ含まれている必要があります。 databricks.yml はバンドルを定義するメイン構成ファイルですが、リソース構成ファイルなどの他の構成ファイルを include マッピングで参照できます。バンドル構成は YAML で表されます。 YAML の詳細については、公式の YAML 仕様を参照してください。

最も簡単な databricks.yml では、必要な最上位レベルのマッピングバンドル内にあるバンドル名とターゲットデプロイを定義します。

bundle:
  name: my_bundle

targets:
  dev:
    default: true

すべての最上位レベルのマッピングの詳細については、「マッピング」を参照してください。

ヒント

Databricks アセットバンドルの Python サポートを使用すると、Python でリソースを定義できます。 Python でのバンドル構成を参照してください。

仕様

次の YAML 仕様では、Databricks アセットバンドルの最上位レベルの構成キーを提供します。構成リファレンスについては、「構成リファレンス」を参照してください。

# This is the default bundle configuration if not otherwise overridden in
# the "targets" top-level mapping.
bundle: # Required.
  name: string # Required.
  databricks_cli_version: string
  cluster_id: string
  deployment: Map
  git:
    origin_url: string
    branch: string

# This is the identity to use to run the bundle
run_as:
  - user_name: <user-name>
  - service_principal_name: <service-principal-name>

# These are any additional configuration files to include.
include:
  - '<some-file-or-path-glob-to-include>'
  - '<another-file-or-path-glob-to-include>'

# These are any scripts that can be run.
scripts:
  <some-unique-script-name>:
    content: string

# These are any additional files or paths to include or exclude.
sync:
  include:
    - '<some-file-or-path-glob-to-include>'
    - '<another-file-or-path-glob-to-include>'
  exclude:
    - '<some-file-or-path-glob-to-exclude>'
    - '<another-file-or-path-glob-to-exclude>'
  paths:
    - '<some-file-or-path-to-synchronize>'

# These are the default artifact settings if not otherwise overridden in
# the targets top-level mapping.
artifacts:
  <some-unique-artifact-identifier>:
    build: string
    dynamic_version: boolean
    executable: string
    files:
      - source: string
    path: string
    type: string

# These are for any custom variables for use throughout the bundle.
variables:
  <some-unique-variable-name>:
    description: string
    default: string or complex
    lookup: Map
    type: string

# These are the default workspace settings if not otherwise overridden in
# the targets top-level mapping.
workspace:
  artifact_path: string
  auth_type: string
  azure_client_id: string # For Azure Databricks only.
  azure_environment: string # For Azure Databricks only.
  azure_login_app_id: string # For Azure Databricks only. Reserved for future use.
  azure_tenant_id: string # For Azure Databricks only.
  azure_use_msi: true | false # For Azure Databricks only.
  azure_workspace_resource_id: string # For Azure Databricks only.
  client_id: string # For Databricks on AWS only.
  file_path: string
  google_service_account: string # For Databricks on Google Cloud only.
  host: string
  profile: string
  resource_path: string
  root_path: string
  state_path: string

# These are the permissions to apply to resources defined
# in the resources mapping.
permissions:
  - level: <permission-level>
    group_name: <unique-group-name>
  - level: <permission-level>
    user_name: <unique-user-name>
  - level: <permission-level>
    service_principal_name: <unique-principal-name>

# These are the resource settings if not otherwise overridden in
# the targets top-level mapping.
resources:
  apps:
    <unique-app-name>:
      # See the REST API create request payload reference for apps.
  clusters:
    <unique-cluster-name>:
      # See the REST API create request payload reference for clusters.
  dashboards:
    <unique-dashboard-name>:
      # See the REST API create request payload reference for dashboards.
  experiments:
    <unique-experiment-name>:
      # See the REST API create request payload reference for experiments.
  jobs:
    <unique-job-name>:
      # See REST API create request payload reference for jobs.
  model_serving_endpoint:
    <unique-model-serving-endpoint-name>:
    # See the model serving endpoint request payload reference.
  models:
    <unique-model-name>:
      # See the REST API create request payload reference for models (legacy).
  pipelines:
    <unique-pipeline-name>:
      # See the REST API create request payload reference for :re[LDP] (pipelines).
  quality_monitors:
    <unique-quality-monitor-name>:
    # See the quality monitor request payload reference.
  registered_models:
    <unique-registered-model-name>:
    # See the registered model request payload reference.
  schemas:
    <unique-schema-name>:
      # See the Unity Catalog schema request payload reference.
  secret_scopes:
    <unique-secret-scope-name>:
      # See the secret scope request payload reference.
  volumes:
    <unique-volume-name>:
    # See the Unity Catalog volume request payload reference.

# These are the targets to use for deployments and workflow runs. One and only one of these
# targets can be set to "default: true".
targets:
  <some-unique-programmatic-identifier-for-this-target>:
    artifacts:
      # See the preceding "artifacts" syntax.
    bundle:
      # See the preceding "bundle" syntax.
    default: boolean
    git: Map
    mode: string
    permissions:
      # See the preceding "permissions" syntax.
    presets:
      <preset>: <value>
    resources:
      # See the preceding "resources" syntax.
    sync:
      # See the preceding "sync" syntax.
    variables:
      <preceding-unique-variable-name>: <non-default-value>
    workspace:
      # See the preceding "workspace" syntax.
    run_as:
      # See the preceding "run_as" syntax.

例

このセクションでは、バンドルのしくみと構成の構成方法を理解するのに役立つ基本的な例をいくつか示します。

注

バンドル機能と一般的なバンドルのユースケースを示す構成例については、「バンドルの構成例」と、「GitHub のバンドル例のリポジトリ」を参照してください。

次のバンドル構成例では、バンドル構成ファイル hello.pyと同じディレクトリにある databricks.yml という名前のローカルファイルを指定します。指定されたクラスター ID を持つリモートクラスターを使用すると、このノートブックがジョブとして実行されます。リモートワークスペースの URL とワークスペース認証資格情報は、という名前の呼び出し元のローカルDEFAULTから読み取られます。

bundle:
  name: hello-bundle

resources:
  jobs:
    hello-job:
      name: hello-job
      tasks:
        - task_key: hello-task
          existing_cluster_id: 1234-567890-abcde123
          notebook_task:
            notebook_path: ./hello.py

targets:
  dev:
    default: true

次の例では、別のリモートワークスペース URL とワークスペース認証資格情報を使用する名前 prod を持つターゲットを追加します。これは、呼び出し元の .databrickscfg ファイルの一致する host エントリから、指定したワークスペース URL で読み取られます。このジョブでは同じノートブックを実行しますが、指定されたクラスター ID を持つ別のリモートクラスターを使用します。

注

バンドル構成ファイルの移植性を高めるために、Databricks では可能な限り host マッピングの代わりに default マッピングを使用することをお勧めします。 hostマッピングを設定すると、Databricks CLI は、.databrickscfg ファイル内で一致するプロファイルを検索し、そのプロファイルのフィールドを使用して、使用する Databricks 認証の種類を決定するように指示します。一致する host フィールドを持つ複数のプロファイルが存在する場合は、バンドルコマンドの --profile オプションを使用して、使用するプロファイルを指定する必要があります。

notebook_task マッピングが明示的に prod マッピング内で、オーバーライドされていない場合は、最上位の notebook_task マッピング内の resources マッピングを使用するようにフォールバックされるため、notebook_task マッピング内の prod マッピングを宣言する必要はありません。

bundle:
  name: hello-bundle

resources:
  jobs:
    hello-job:
      name: hello-job
      tasks:
        - task_key: hello-task
          existing_cluster_id: 1234-567890-abcde123
          notebook_task:
            notebook_path: ./hello.py

targets:
  dev:
    default: true
  prod:
    workspace:
      host: https://<production-workspace-url>
    resources:
      jobs:
        hello-job:
          name: hello-job
          tasks:
            - task_key: hello-task
              existing_cluster_id: 2345-678901-fabcd456

次のバンドルコマンドを使用して、 dev ターゲット内でこのジョブを検証、デプロイ、および実行します。バンドルのライフサイクルの詳細については、「 Databricks アセットバンドルの開発」を参照してください。

# Because the "dev" target is set to "default: true",
# you do not need to specify "-t dev":
databricks bundle validate
databricks bundle deploy
databricks bundle run hello_job

# But you can still explicitly specify it, if you want or need to:
databricks bundle validate
databricks bundle deploy -t dev
databricks bundle run -t dev hello_job

代わりに、prod ターゲット内でこのジョブを検証、デプロイおよび実行するには:

# You must specify "-t prod", because the "dev" target
# is already set to "default: true":
databricks bundle validate
databricks bundle deploy -t prod
databricks bundle run -t prod hello_job

バンドル間での定義と設定のモジュール化と再利用を強化するには、バンドル構成を別のファイルに分割します。

# databricks.yml

bundle:
  name: hello-bundle

include:
  - '*.yml'

# hello-job.yml

resources:
  jobs:
    hello-job:
      name: hello-job
      tasks:
        - task_key: hello-task
          existing_cluster_id: 1234-567890-abcde123
          notebook_task:
            notebook_path: ./hello.py

# targets.yml

targets:
  dev:
    default: true
  prod:
    workspace:
      host: https://<production-workspace-url>
    resources:
      jobs:
        hello-job:
          name: hello-job
          tasks:
            - task_key: hello-task
              existing_cluster_id: 2345-678901-fabcd456

マッピング

次のセクションでは、バンドル構成の最上位レベルのマッピングについて説明します。構成リファレンスについては、「構成リファレンス」を参照してください。

バンドル
run_as
include
スクリプト
同期
成果物
変数
ワークスペース
アクセス許可
リソース
ターゲット

バンドル

バンドル構成ファイルには、バンドルのコンテンツと Azure Databricks ワークスペースの設定を関連付ける最上位レベルの bundle マッピングが 1 つだけ含まれている必要があります。

この bundle マッピングには、バンドルにプログラム (または論理) 名を指定する name マッピングが含まれている必要があります。次の例では、プログラム (または論理) 名 hello-bundle を使用してバンドルを宣言します。

bundle:
  name: hello-bundle

bundle マッピングは、最上位レベルの targets マッピング内の 1 つまたは複数のターゲットの子にすることもできます。これらの各子 bundle マッピングでは、ターゲットレベルで既定以外のオーバーライドが指定されます。ただし、最上位レベルの bundle マッピングの name 値は、ターゲットレベルではオーバーライドできません。

クラスターID

bundle マッピングには、子 cluster_id マッピングを含めることができます。このマッピングを使用すると、バンドル構成ファイル内の他の場所で定義されたクラスターに対するオーバーライドとして使用するクラスターの ID を指定できます。クラスターの ID を取得する方法については、「コンピューティングリソースの URL と ID」を参照してください。

cluster_id オーバーライドは開発専用のシナリオを対象としており、mode マッピングが development に設定されているターゲットでのみサポートされます。 target マッピングの詳細については、「targets」を参照してください。

compute_id

注

この設定は非推奨です。代わりに cluster_id を使用します。

bundle マッピングには、子 compute_id マッピングを含めることができます。このマッピングを使用すると、バンドル構成ファイル内の他の場所で定義されたクラスターに対するオーバーライドとして使用するクラスターの ID を指定できます。

git

バンドルに関連付けられている Git バージョン管理の詳細を取得およびオーバーライドできます。これは、後でリソースを識別するために使用できるデプロイメタデータを伝達するのに役立ちます。たとえば、CI/CD によってデプロイされたジョブのリポジトリの配信元をトレースできます。

bundle、validate、deployなどのrun コマンドを実行するたびに、bundle コマンドによってコマンドの構成ツリーに次の既定の設定が設定されます。

bundle.git.origin_url。リポジトリの元の URL を表します。これは、クローンされたリポジトリからコマンド git config --get remote.origin.url を実行した場合に得られるものと同じ値です。 substitutions を使用して、この値をバンドル構成ファイルで ${bundle.git.origin_url} として参照できます。
bundle.git.branch。リポジトリ内の現在のブランチを表します。これは、クローンされたリポジトリからコマンド git branch --show-current を実行した場合に得られるものと同じ値です。 substitutions を使用して、この値をバンドル構成ファイルで ${bundle.git.branch} として参照できます。

Git 設定を取得またはオーバーライドするには、git clone コマンドを実行して初期化されるローカルディレクトリなど、Git リポジトリに関連付けられているディレクトリ内にバンドルが存在する必要があります。ディレクトリが Git リポジトリに関連付けられていない場合、これらの Git 設定は空です。

次のように、必要に応じて、最上位レベルの origin_url マッピングの branch マッピング内の git と bundle の設定をオーバーライドできます。

bundle:
  git:
    origin_url: <some-non-default-origin-url>
    branch: <some-non-current-branch-name>

databricks_cli_version

bundle マッピングには、バンドルで必要な Databricks CLI バージョンを制約する databricks_cli_version マッピングを含めることができます。これにより、特定のバージョンの Databricks CLI でサポートされていないマッピングを使用することによって発生する問題を回避できます。

Databricks CLI のバージョンは、セマンティックバージョン管理に準拠しており、databricks_cli_version マッピングでは、バージョン制約を指定できます。現在の databricks --version 値がバンドルの databricks_cli_version マッピングで指定された境界内にない場合は、バンドルで databricks bundle validate が実行されるときにエラーが発生します。次の例では、いくつかの一般的なバージョン制約構文を示します:

bundle:
  name: hello-bundle
  databricks_cli_version: '0.218.0' # require Databricks CLI 0.218.0

bundle:
  name: hello-bundle
  databricks_cli_version: '0.218.*' # allow all patch versions of Databricks CLI 0.218

bundle:
  name: my-bundle
  databricks_cli_version: '>= 0.218.0' # allow any version of Databricks CLI 0.218.0 or higher

bundle:
  name: my-bundle
  databricks_cli_version: '>= 0.218.0, <= 1.0.0' # allow any Databricks CLI version between 0.218.0 and 1.0.0, inclusive

run_as

run_as設定では、バンドルの実行に使用するuser_nameまたはservice_principal_nameを指定します。バンドルジョブまたはパイプラインのデプロイに使用される ID と、ジョブまたはパイプラインの実行に使用される ID を分離する機能が提供されます。

「Databricks Asset Bundles ワークフローの実行 ID を指定する」を参照してください。

含める

include 配列では、バンドル内に含める構成ファイルを含むパス glob のリストを指定します。これらのパス glob は、パス glob が指定されているバンドル構成ファイルの場所に対する相対パスです。

Databricks CLI のバンドル内には、既定で構成ファイルは含まれていません。 include 配列を使用して、databricks.yml ファイル自体以外の、バンドル内に含めるすべての構成ファイルを指定する必要があります。

この include 配列は、最上位レベルのマッピングとしてのみ表示できます。

構成の次の例には、3 つの構成ファイルが含まれています。これらのファイルは、バンドル構成ファイルと同じフォルダーにあります。

include:
  - 'bundle.artifacts.yml'
  - 'bundle.resources.yml'
  - 'bundle.targets.yml'

構成の次の例には、bundle で始まり、.yml で終わるファイル名を持つすべてのファイルが含まれています。これらのファイルは、バンドル構成ファイルと同じフォルダーにあります。

include:
  - 'bundle*.yml'

スクリプト

scripts設定では、bundle runを使用して実行できるスクリプトを指定します。 scripts マッピング内の各名前付きスクリプトには、コマンドを含むコンテンツが含まれています。例えば次が挙げられます。

scripts:
  my_script:
    content: uv run pytest -m ${bundle.target}

詳細については、「スクリプトの実行」を参照してください。

同期

sync マッピングを使用すると、どのファイルをバンドルデプロイメントの一部にするかを設定できます。

include (包含) と exclude (除外)

include マッピング内の exclude マッピングと sync マッピングでは、次の規則に応じて、バンドルの展開に含めるファイルまたはフォルダーの一覧を指定します。

バンドルのルートにある .gitignore ファイル内のファイルとパス glob のリストに基づいて、include マッピングには、バンドルのルートを基準とするファイル glob、パス glob、またはその両方を明示的に含めることができます。
バンドルのルート内の .gitignore ファイルにあるファイルおよびパス glob のリストと include マッピングにあるファイルおよびパス glob のリストに基づいて、明示的に除外するために、exclude マッピングには、バンドルのルートに関連するファイル glob やパス glob、またはその両方を含むリストを含めることができます。

指定されたファイルとフォルダへのすべてのパスは、これらが指定されているバンドル構成ファイルの場所に対する相対パスです。

include および exclude ファイルの構文とパスパターンは、標準の .gitignore パターン構文に従います。「gitignore パターン形式」を参照してください。

たとえば、次の .gitignore ファイルに次のエントリが含まれている場合:

.databricks
my_package/dist

また、バンドル構成ファイルには、次の include マッピングが含まれています。

sync:
  include:
    - my_package/dist/*.whl

その後、ファイル拡張子が my_package/dist の *.whl フォルダー内のすべてのファイルが含まれます。 my_package/dist フォルダー内の他のファイルは含まれません。

ただし、バンドル構成ファイルに次の exclude マッピングも含まれている場合:

sync:
  include:
    - my_package/dist/*.whl
  exclude:
    - my_package/dist/delete-me.whl

その後、my_package/dist という名前のファイルを除き、*.whl のファイル拡張子の delete-me.whl フォルダのすべてのファイルが含まれます。 my_package/dist フォルダー内の他のファイルも含まれません。

sync マッピングは、特定のターゲットの targets マッピングで宣言することもできます。ターゲットで宣言された sync マッピングは、最上位レベルの sync マッピング宣言とマージされます。たとえば、引き続き前の例を使用した場合、include レベルの次の targets マッピングは、最上位レベルの include マッピングの sync マッピングとマージされます。

targets:
  dev:
    sync:
      include:
        - my_package/dist/delete-me.whl

パス

sync マッピングは、ワークスペースに同期するローカルパスを指定する paths マッピングを含めることができます。 paths マッピングを使用することで、バンドル間で共通ファイルを共有でき、バンドルルート外にあるファイルを同期するために使用できます。 (バンドルルートは、databricks.yml ファイルの場所です。) これには、複数のバンドルをホストする単一のリポジトリがあり、ライブラリ、コードファイル、または構成を共有したい場合に特に便利です。

指定したパスは、paths マッピングが設定されているフォルダーに固定されているファイルとディレクトリに対する相対パスである必要があります。 1 つ以上のパス値が、バンドルルートの祖先までディレクトリをトラバースする場合、ルートパスは、動的に決定されるため、フォルダ構造はそのまま維持されます。たとえば、バンドルルートフォルダの名前が my_bundle に変更された場合、databricks.yml のこの構成は、バンドルルートとバンドルルート自体の 1 つ上のレベルにある common フォルダを同期します。

sync:
  paths:
    - ../common
    - .

このバンドルをデプロイすると、ワークスペースで次のようなフォルダ構造になります。

common/
  common_file.txt
my_bundle/
  databricks.yml
  src/
    ...

成果物

最上位の artifacts マッピングでは、バンドルのデプロイ中に自動的にビルドされ、後でバンドルの実行で使用できる 1 つまたは複数のアーティファクトを指定します。各子アーティファクトは、次のマッピングをサポートします。

Python ホイールビルドには type が必要です。デプロイする前に Python ホイールファイルをビルドするには、これを whlに設定します。他の成果物をビルドするには、この設定を指定する必要はありません。
path は省略可能なパスです。パスは、バンドル構成ファイルの場所に対する相対パスです。 Python ホイールビルドの場合、これは Python wheel ファイルの setup.py ファイルへのパスです。 pathが含まれていない場合、Databricks CLI は、バンドルのルートで Python ホイールファイルのsetup.py ファイルの検索を試みます。
files は、子 source マッピングを含む省略可能なマッピングです。このマッピングを使用して、ビルドされた成果物を指定できます。パスは、バンドル構成ファイルの場所に対する相対パスです。
build は、デプロイの前にローカルで実行する既定以外のビルドコマンドのオプションのセットです。 Python ホイールビルドの場合、Databricks CLI は、ビルドを実行する Python wheel パッケージのローカルインストールを検出できると想定して、各バンドルのデプロイ中に既定でコマンド python setup.py bdist_wheel を実行します。複数のビルドコマンドを別々の行に指定します。
dynamic_version を使用すると、バンドルは wheel ファイルのタイムスタンプに基づいてホイールのバージョンを更新できます。その後、 setup.py または pyproject.tomlでバージョンを更新しなくても、新しいコードをデプロイできます。この設定は、 type が whl に設定されている場合にのみ有効です。

次の構成例では、テストを実行し、ホイールを構築します。 artifactsを使用してホイールを構築する完全なバンドルチュートリアルについては、「Databricks Asset Bundles を使用して Python ホイールファイルをビルドする」を参照してください。

artifacts:
  default:
    type: whl
    build: |-
      # run tests
      python -m pytest tests/ -v

      # build the actual artifact
      python setup.py bdist_wheel

    path: .

JAR をビルドして Unity カタログにアップロードする構成例については、JAR ファイルを Unity カタログにアップロードするバンドルを参照してください。

ヒント

ターゲット設定でオーバーライドする方法に従って、バンドル内の成果物に対する設定を定義、結合およびオーバーライドできます。

変数

バンドル設定ファイルには、カスタム変数が定義されている最上位レベルの variables マッピングを 1 つ含めることができます。各変数の場合、オプションの説明、既定値、カスタム変数が複合型であるかどうか、または ID 値を取得するための検索を、次の形式で設定します。

variables:
  <variable-name>:
    description: <variable-description>
    default: <optional-default-value>
    type: <optional-type-value> # "complex" is the only valid value
    lookup:
      <optional-object-type>: <optional-object-name>

注

変数は、string が type に設定されていない限り、complex 型であると見なされます。「複合型変数を定義する」を参照してください。

バンドル構成内でカスタム変数を参照するには、代入 ${var.<variable_name>} を使用します。

カスタム変数と代入の詳細については、「Databricks アセットバンドルの代入と変数」を参照してください。

ワークスペース

バンドル構成ファイルには、使用する既定以外の Azure Databricks ワークスペース設定を指定するための最上位レベルの workspace マッピングを 1 つだけ含めることができます。

重要

有効な Databricks ワークスペースパスは、/Workspaceで始まるか、成果物の場合は/Volumesでも始めることができます。カスタムワークスペースのパスには、自動で /Workspace が先頭に追加されるため、${workspace.file_path} などのカスタムパスでワークスペースパス代入を使用する場合は、パスの先頭に /Workspace を付ける必要はありません。

root_path

この workspace マッピングには、デプロイとワークフローの実行の両方にワークスペース内で使用する既定以外のルートパスを指定するための root_path マッピングを含めることができます。以下に例を示します。

workspace:
  root_path: /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/my-envs/${bundle.target}

既定では、root_path の場合、Databricks CLI は、/Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/${bundle.target}を使用するの既定パスを使用します。

artifact_path（アーティファクト_パス）

この workspace マッピングには、デプロイとワークフローの実行の両方にワークスペース内で使用する既定以外のアーティファクトパスを指定するための artifact_path マッピングも含めることができます。以下に例を示します。

workspace:
  artifact_path: /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/my-envs/${bundle.target}/artifacts

既定では、artifact_path の場合、Databricks CLI は、${workspace.root}/artifactsを使用するの既定パスを使用します。

注

artifact_path マッピングでは Databricks File System (DBFS) パスはサポートされていません。

ファイルパス

この workspace マッピングには、デプロイとワークフローの実行の両方にワークスペース内で使用する既定以外のファイルパスを指定するための file_path マッピングも含めることができます。以下に例を示します。

workspace:
  file_path: /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/my-envs/${bundle.target}/files

既定では、file_path の場合、Databricks CLI は、${workspace.root}/filesを使用するの既定パスを使用します。

state_path

state_path マッピングは既定で、${workspace.root}/state の既定パスとなり、デプロイに関する Terraform 状態情報を格納するためのワークスペース内のパスを示します。

その他のワークスペースマッピング

workspace マッピングには、次のオプションのマッピングを含めて、使用する Azure Databricks 認証メカニズムを指定することもできます。この workspace マッピング内で指定されていない場合は、最上位レベルの workspace マッピング内の 1 つまたは複数の targets の子としてマッピングで指定する必要があります。

重要

Azure Databricks 認証のために、次の workspace マッピングの値をハードコーディングする必要があります。たとえば、構文を使用して、これらのマッピングの値に${var.*}を指定することはできません。

profile マッピング (または、Databricks CLI を使用してバンドルの検証、デプロイ、実行、破棄のコマンドを実行するときの --profile または -p オプション) では、Azure Databricks 認証用にこのワークスペースで使用する構成プロファイルの名前を指定します。この構成プロファイルは、Databricks CLI を設定したときに作成したものにマップされます。

注

Databricks では、host マッピングではなく、--profile マッピング (Databricks CLI を使用してバンドルの検証、デプロイ、実行、破棄のコマンドを実行するときの -p または profile オプション) を使用することをお勧めします。これにより、バンドル構成ファイルの移植性が高まります。 hostマッピングを設定すると、Databricks CLI は、.databrickscfg ファイル内で一致するプロファイルを検索し、そのプロファイルのフィールドを使用して、使用する Databricks 認証の種類を決定するように指示します。 host ファイル内にある .databrickscfg フィールドと一致する複数のプロファイルがある場合、profile マッピング (または --profile または -p コマンドラインオプション) を使用して、Databricks CLI にどのプロファイルを使用するか指示する必要があります。例にいては、「prodのターゲット宣言」　を参照してください。

host マッピングでは、Azure Databricks ワークスペースの URL を指定します。「ワークスペース別 URL」を参照してください。
OAuth マシン間 (M2M) 認証の場合、マッピング client_id が使用されます。代わりに、ローカル環境変数 DATABRICKS_CLIENT_ID でこの値を設定することもできます。または、 client_id 値を使用して構成プロファイルを作成し、 profile マッピングを使用してプロファイルの名前を指定することもできます (または、Databricks CLI でコマンドを検証、デプロイ、実行、破棄するバンドルを実行するときに、 --profile または -p オプションを使用します)。 OAuth を使用した Azure Databricks へのサービスプリンシパルアクセスの承認に関するページを参照してください。

注

バンドル構成ファイルで Azure Databricks OAuth シークレット値を指定することはできません。代わりに、ローカル環境変数 DATABRICKS_CLIENT_SECRET を設定します。または、 client_secret 値を構成プロファイルに追加し、 profile マッピングを使用してプロファイルの名前を指定することもできます (または、Databricks CLI でコマンドを検証、デプロイ、実行、破棄するバンドルを実行するときに、 --profile または -p オプションを使用します)。
Azure CLI 認証では、マッピング azure_workspace_resource_id が使用されます。代わりに、ローカル環境変数 DATABRICKS_AZURE_RESOURCE_ID でこの値を設定することもできます。または、 azure_workspace_resource_id 値を使用して構成プロファイルを作成し、 profile マッピングを使用してプロファイルの名前を指定することもできます (または、Databricks CLI でコマンドを検証、デプロイ、実行、破棄するバンドルを実行するときに、 --profile または -p オプションを使用します)。「Azure CLI を使用した認証」を参照してください。
サービスプリンシパルを使用した Azure クライアントシークレット認証の場合、マッピングazure_workspace_resource_id、azure_tenant_id および azure_client_id が使用されます。代わりに、これらの値をそれぞれローカル環境変数 DATABRICKS_AZURE_RESOURCE_ID、ARM_TENANT_ID、および ARM_CLIENT_ID で設定することもできます。または、 azure_workspace_resource_id、 azure_tenant_id、および azure_client_id の値を使用して構成プロファイルを作成し、 profile マッピングを使用してプロファイルの名前を指定することもできます (または、Databricks CLI を使用してコマンドを検証、デプロイ、実行、破棄するバンドルの実行時に --profile または -p オプションを使用します)。 MS Entra サービスプリンシパルによる認証を参照してください。

注

バンドル構成ファイルで Azure クライアントシークレット値を指定することはできません。代わりに、ローカル環境変数 ARM_CLIENT_SECRET を設定します。または、 azure_client_secret 値を構成プロファイルに追加し、 profile マッピングを使用してプロファイルの名前を指定することもできます (または、Databricks CLI でコマンドを検証、デプロイ、実行、破棄するバンドルを実行するときに、 --profile または -p オプションを使用します)。
Azure マネージド ID 認証では、マッピング azure_use_msi、azure_client_id、azure_workspace_resource_id が使用されます。代わりに、これらの値をそれぞれローカル環境変数 ARM_USE_MSI、ARM_CLIENT_ID、および DATABRICKS_AZURE_RESOURCE_ID で設定することもできます。または、 azure_use_msi、 azure_client_id、および azure_workspace_resource_id の値を使用して構成プロファイルを作成し、 profile マッピングを使用してプロファイルの名前を指定することもできます (または、Databricks CLI を使用してコマンドを検証、デプロイ、実行、破棄するバンドルの実行時に --profile または -p オプションを使用します)。「Azure マネージド ID を使用した認証」を参照してください。
azure_environment マッピングでは、特定の API エンドポイントのセットに対して Azure 環境の種類 (Public、UsGov、China、Germany など) を指定します。既定値は PUBLIC です。代わりに、ローカル環境変数 ARM_ENVIRONMENT でこの値を設定することもできます。または、 azure_environment 値を構成プロファイルに追加し、 profile マッピングを使用してプロファイルの名前を指定することもできます (または、Databricks CLI でコマンドを検証、デプロイ、実行、破棄するバンドルを実行するときに、 --profile または -p オプションを使用します)。
azure_login_app_id マッピングは非運用であり、内部使用のために予約されています。

auth_type マッピングでは、特に Databricks CLI で予期しない認証の種類が推測された場合に、使用する Azure Databricks 認証の種類を指定します。 Azure Databricks リソースへのアクセスの承認に関するページを参照してください。

権限

最上位の permissions マッピングでは、バンドルで定義されているすべてのリソースに適用する 1 つ以上のアクセス許可レベルを指定します。特定のリソースにアクセス許可を適用する場合は、「特定のリソースのアクセス許可を定義する」を参照してください。

指定できる最上位のアクセス許可レベルは、CAN_VIEW、CAN_MANAGE、CAN_RUN です。

バンドル構成ファイルの次の例では、ユーザー、グループ、およびサービスプリンシパルのアクセス許可レベルを定義します。このレベルは、バンドル内の resources で定義されているすべてのリソースに適用されます。

permissions:
  - level: CAN_VIEW
    group_name: test-group
  - level: CAN_MANAGE
    user_name: someone@example.com
  - level: CAN_RUN
    service_principal_name: 123456-abcdef

リソース

resources マッピングは、バンドルが使用する Azure Databricks リソースに関する情報を指定します。

この resources マッピングは、最上位レベルのマッピングとして現れることがあります。または、最上位レベルのターゲット内の 1 つ以上のターゲットを持つマッピングの子要素になることもあり、サポートされているリソースの種類が0または1つ含まれることがあります。各リソースの種類マッピングには 1 つ以上の個別のリソース宣言が含まれており、それぞれに一意の名前が必要です。これらの個々のリソース宣言では、対応するオブジェクトの作成操作の要求ペイロード (YAML で表される) を使用してリソースを定義します。リソースでサポートされているプロパティは、対応するオブジェクトのサポートされるフィールドです。

Create 操作要求ペイロードについては、「Databricks REST API リファレンス」で説明されています。databricks bundle schema コマンドはすべてのサポートされているオブジェクトスキーマを出力します。さらに、バンドル構成ファイルで不明なリソースプロパティが見つかった場合、databricks bundle validate コマンドが警告を返します。

次の構成例では、ジョブリソースを定義します。

resources:
  jobs:
    hello-job:
      name: hello-job
      tasks:
        - task_key: hello-task
          existing_cluster_id: 1234-567890-abcde123
          notebook_task:
            notebook_path: ./hello.py

バンドル内でサポートされているリソースの詳細と、一般的な構成および例については「Databricks Asset Bundles リソース」および「バンドル構成の例」を参照してください。

ターゲット

targets マッピングは、Azure Databricks ワークフローを実行する 1 つまたは複数のコンテキストを指定します。各 target は、アーティファクト、Azure Databricks ワークスペース設定、Azure Databricks ジョブまたはパイプライン詳細の固有のコレクションです。

targets マッピングは、1 つまたは複数の target マッピングで構成され、それぞれに一意のプログラム (または論理) 名が必要です。

この targets マッピングは、オプションですが、強くお勧めします。指定されている場合、最上位レベルのマッピングとしてのみ表示できます。

最上位レベルの workspace、artifacts、および resources マッピングは、targets マッピングで指定されていない場合に使用されますが、競合する設定はターゲット内の設定によりオーバーライドされます。

ターゲットでは、最上位の変数の値をオーバーライドすることもできます。

デフォルト

バンドルコマンドのターゲット既定値の指定には、default マッピングを true に設定します。たとえば、dev という名前のこのターゲットは既定のターゲットです。

targets:
  dev:
    default: true

既定のターゲットが構成されていない場合、または特定のターゲット内でジョブまたはパイプラインを検証、配置、実行する場合は、バンドルコマンドの -t オプションを使用します。

次のコマンドは、my_job および dev 内で prod を検証、デプロイ、実行します。

databricks bundle validate
databricks bundle deploy -t dev
databricks bundle run -t dev my_job

databricks bundle validate
databricks bundle deploy -t prod
databricks bundle run -t prod my_job

次の例では、2 つのターゲットを宣言しています。最初のターゲットには dev という名前があり、バンドルコマンドにターゲットが指定されていない場合に使用される既定のターゲットです。 2 番目のターゲットには prod という名前があり、バンドルコマンドにターゲットが指定されている場合のみ使用されます。

targets:
  dev:
    default: true
  prod:
    workspace:
      host: https://<production-workspace-url>

モードとプリセット

開発と CI/CD のベストプラクティスを容易にするために、Databricks アセットバンドルには、運用前ワークフローと運用ワークフローの既定の動作を設定するターゲットのデプロイモードが用意されています。一部の動作も構成可能です。詳細については、「Databricks アセットバンドルのデプロイモード」を参照してください。

ヒント

バンドルに実行 ID を設定するには、run_asで説明されているとおり、各ターゲットにを指定できます。

ターゲットを開発ターゲットとして扱うように指定するには、mode に設定された development マッピングを追加します。ターゲットを運用ターゲットとして扱うように指定するには、mode に設定された production マッピングを追加します。たとえば、prod という名前のこのターゲットは、運用ターゲットとして扱われます。

targets:
  prod:
    mode: production

presets マッピングを使用すると、一部の動作をカスタマイズできます。使用可能なプリセットの一覧は、「カスタムプリセット」を参照してください。次の例は、すべての運用リソースにプレフィックスを付けてタグ付けするカスタマイズされた運用ターゲットを示します。

targets:
  prod:
    mode: production
    presets:
      name_prefix: 'production_' # prefix all resource names with production_
      tags:
        prod: true

mode と presets の両方が設定されている場合には、プリセットは既定モードの動作をオーバーライドします。個々のリソースの設定は、プリセットをオーバーライドします。たとえば、スケジュールが UNPAUSED に設定されていても、trigger_pause_status プリセットが PAUSED に設定されている場合には、スケジュールは一時停止されません。

フィードバック

このページはお役に立ちましたか?