この記事では、宣言型オートメーション バンドル (旧称 Databricks Asset Bundles) を定義するバンドル構成ファイルの構文について説明します。 「宣言型オートメーション バンドルとは」を参照してください。
バンドルを作成して使用するには、「 宣言型オートメーション バンドルの開発」を参照してください。
バンドル構成リファレンスについては、「 構成リファレンス」を参照してください。
databricks.yml
バンドルには、バンドル プロジェクト フォルダーのルートに databricks.yml という名前の構成ファイルが 1 つだけ含まれている必要があります。
databricks.yml はバンドルを定義するメイン構成ファイルですが、リソース構成ファイルなどの他の構成ファイルを include マッピングで参照できます。 バンドル構成は YAML で表されます。 YAML の詳細については、公式の YAML 仕様を参照してください。
最も簡単な databricks.yml では、必要な最上位レベルのマッピングとターゲットのデプロイであるバンドル名を定義します。
bundle:
name: my_bundle
targets:
dev:
default: true
すべての最上位マッピングの詳細については、「 構成リファレンス」を参照してください。
ヒント
宣言型オートメーション バンドルに対する Python のサポートにより、Python でリソースを定義できます。 Python でのバンドル構成を参照してください。
仕様
次の YAML 仕様では、宣言型オートメーション バンドルの最上位レベルの構成キーを提供します。 完全な構成リファレンスについては、「 構成リファレンス 」および 「宣言型オートメーション バンドル」のリソースを参照してください。
# 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 # The only valid value is "complex" if the variable is a complex variable, otherwise do not define this key.
# These are the workspace settings if not otherwise overridden in
# the targets top-level mapping.
workspace:
artifact_path: string
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:
alerts:
<unique-alert-name>:
# alert settings
apps:
<unique-app-name>:
# app settings
catalogs:
<unique-catalog-name>:
# catalog settings
clusters:
<unique-cluster-name>:
# cluster settings
dashboards:
<unique-dashboard-name>:
# dashboard settings
database_catalogs:
<unique-database-catalog-name>:
# database catalog settings
database_instances:
<unique-database-instance-name>:
# database instance settings
experiments:
<unique-experiment-name>:
# experiment settings
jobs:
<unique-job-name>:
# job settings
model_serving_endpoints:
<unique-model-serving-endpoint-name>:
# model_serving_endpoint settings
pipelines:
<unique-pipeline-name>:
# pipeline settings
postgres_branches:
<unique-postgres-branch-name>:
# postgres branch settings
postgres_endpoints:
<unique-postgres-endpoint-name>:
# postgres endpoint settings
postgres_projects:
<unique-postgres-project-name>:
# postgres project settings
quality_monitors:
<unique-quality-monitor-name>:
# quality monitor settings
registered_models:
<unique-registered-model-name>:
# registered model settings
schemas:
<unique-schema-name>:
# schema settings
secret_scopes:
<unique-secret-scope-name>:
# secret scopes settings
sql_warehouses:
<unique-sql-warehouse-name>:
# sql warehouse settings
synced_database_tables:
<unique-synced-database-table-name>:
# synced database table settings
volumes:
<unique-volume-name>:
# volumes settings
# 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:
# artifact build settings for this target
bundle:
# bundle settings for this target
default: boolean
git: Map
mode: string
permissions:
# permissions for this target
presets:
<preset>: <value>
resources:
# resource settings for this target
sync:
# sync settings for this target
variables:
<defined-variable-name>: <non-default-value> # value for this target
workspace:
# workspace settings for this target
run_as:
# run_as settings for this target
例
このセクションでは、バンドルのしくみと構成の構成方法を理解するのに役立つ基本的な例をいくつか示します。
注
バンドル機能と一般的なバンドルのユース ケースを示す構成例については、「バンドルの構成例」と、「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 ターゲット内でこのジョブを検証、デプロイ、および実行します。 バンドルのライフサイクルの詳細については、「 宣言型オートメーション バンドルの開発」を参照してください。
# 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