Databricks Asset Bundle のデプロイ モード
この記事では、 Databricks Asset Bundle デプロイ モードの構文について説明します。 バンドルを使用すると、Databricks ワークフローをプログラムで管理できます。 「Databricks アセット バンドルとは」を参照してください。
CI/CD ワークフローでは、開発者は通常、さまざまなフェーズまたは モードで ソリューションのコーディング、テスト、デプロイ、および実行を行います。 たとえば、最も単純なモードには、本番運用前の検証のための 開発 モードと、検証された成果物のための 本番運用 モードがあります。 Databricks Asset Bundles には、これらの各モードに対応するデフォルトの動作のオプションのコレクションが用意されています。 これらの動作を特定のターゲットに使用するには、targets構成マッピングでターゲットにmodeを設定するか、ターゲットのpresetsを設定します。targetsに関する情報については、バンドル構成ターゲットのマッピングを参照してください。
開発モード
バンドルを開発モードでデプロイするには、まず development に設定された mode マッピングを目的のターゲットに追加する必要があります。 たとえば、dev という名前のこのターゲットは開発ターゲットとして扱われます。
targets:
  dev:
    mode: development
databricks bundle deploy -t <target-name> コマンドを実行して開発モードでターゲットをデプロイすると、次の動作が実装され、プリセットを使用してカスタマイズできます。
- ファイルまたはノートブックとしてデプロイされていないすべてのリソースの先頭にプレフィックス [dev ${workspace.current_user.short_name}]を付け、デプロイされた各ジョブとパイプラインにdevDatabricks タグを付けます。
- デプロイされたすべての関連する Lakeflow 宣言型パイプラインを development: trueとしてマークします。
- bundle deployコマンドの関連呼び出しで- --compute-id <cluster-id>を使用できるようにします。これにより、関連するバンドル構成ファイルで既に指定されているすべての既存のクラスター定義がオーバーライドされます。- bundle deployコマンドの関連呼び出しで- --compute-id <cluster-id>を使用する代わりに、ここで- compute_idマッピングを設定するか、- bundleマッピングの子マッピングとして、使用するクラスターの ID に設定できます。
- デプロイされたリソース (ジョブや品質モニターなど) のすべてのスケジュールとトリガーを停止します。 個々のジョブのスケジュールとトリガーの一時停止を解除するには、 schedule.pause_statusをUNPAUSEDに設定します。
- デプロイされたすべてのジョブで並列実行を有効にして、イテレーションを高速化します。 個々のジョブの並列実行を無効にするには、 max_concurrent_runsを1に設定します。
- デプロイメント・ロックを無効にして、反復処理を高速化します。 このロックにより、開発モードで発生する可能性が低いデプロイの競合が防止されます。 bundle.deployment.lock.enabledをtrueに設定して、ロックを再度有効にします。
本番運用モード
バンドルを本番運用モードでデプロイするには、まず、 mode マッピングを productionに設定して目的のターゲットに追加する必要があります。 たとえば、この prod という名前のターゲットは、本番運用ターゲットとして扱われます。
targets:
  prod:
    mode: production
databricks bundle deploy -t <target-name> コマンドを実行して本番運用モードでターゲットをデプロイすると、次の動作が実装されます。
- 
デプロイされたすべての関連する Lakeflow 宣言型パイプライン が development: falseとしてマークされていることを検証します。
- 
現在の Git ブランチが、ターゲットで指定された Git ブランチと等しいことを検証します。 ターゲットでの Git ブランチの指定はオプションであり、次のように追加の gitプロパティを使用して実行できます。YAMLgit:
 branch: mainこの検証は、デプロイ中に --forceを指定することでオーバーライドできます。
- 
Databricks では、本番運用のデプロイにはサービスプリンシパルを使用することをお勧めします。 これを強制するには、 run_asをサービス プリンシパルに設定します。 サービスプリンシパルおよびDatabricksアセットバンドル ワークフローの実行 ID の指定を参照してください。サービスプリンシパルを使用しない場合は、次の追加の動作に注意してください。- artifact_path、- file_path、- root_path、- state_pathのマッピングが特定のユーザーに上書きされていないことを検証します。
- run_asと- permissionsのマッピングが指定されていることを検証して、どの ID にデプロイ用の特定の権限があるかを確認します。
 
- 
modeマッピングをdevelopmentに設定する前述の動作とは異なり、modeマッピングをproductionに設定しても、関連するバンドル構成ファイルに指定されている既存のクラスター定義 (例えば、--compute-id <cluster-id>オプションやcompute_idマッピングを使用) はオーバーライドできません。
カスタムプリセット
Databricks Asset Bundles は、 ターゲットの構成可能なプリセットをサポートしているため、ターゲットの動作をカスタマイズできます。 使用可能なプリセットを次の表に示します。
次の表で例外が指定されていない限り、 mode と presets の両方が設定されている場合、プリセットはデフォルトのモード動作を上書きし、個々のリソースの設定はプリセットを上書きします。たとえば、ジョブの max_concurrent_runs が 10 で、 jobs_max_concurrent_runs プリセットが 20 に設定されている場合、ジョブの最大並列 実行は 10 になります。
| Preset | 説明 | 
|---|---|
| 
 | デプロイメント中に  | 
| 
 | ジョブに許容される並列 実行の最大数。 | 
| 
 | リソース名の先頭に追加するプレフィックス文字列。 | 
| 
 | パイプラインが開発モードであるかどうか。 有効な値は  | 
| 
 | 将来の使用のために予約されています。 デプロイ中に作成されたリソースが、ワークスペースのコピーではなくワークスペース内のソース ファイルを指すかどうか。 | 
| 
 | キーのセット タグは、タグをサポートするすべてのリソース (ジョブとエクスペリメントを含む) に適用されます。 Databricks アセット バンドルは、  | 
| 
 | すべてのトリガーとスケジュールに適用する停止するステータス。 有効な値は  
 | 
次の例は、 devという名前のターゲットのカスタムプリセット設定を示しています。
targets:
  dev:
    presets:
      name_prefix: 'testing_' # prefix all resource names with testing_
      pipelines_development: true # set development to true for pipelines
      trigger_pause_status: PAUSED # set pause_status to PAUSED for all triggers and schedules
      jobs_max_concurrent_runs: 10 # set max_concurrent runs to 10 for all jobs
      tags:
        department: finance