この記事では、Databricks アセット バンドルのデプロイ モードの構文について説明します。 バンドルを使用すると、Azure Databricks ワークフローをプログラムで管理できます。 「Databricks アセット バンドルとは」を参照してください
CI/CD ワークフローでは、開発者は通常、さまざまなフェーズまたは "モード" でソリューションをコーディング、テスト、デプロイ、実行します。 一連のモードのもっとも単純な例としては、運用前の検証のための "開発" モードに検証後の成果物のための "運用" モードが続くというものがあります。 Databricks アセット バンドルには、これらの各モードに対応する既定の動作のオプション コレクションが用意されています。 特定のターゲットに対してこれらのビヘイビアーを使用するには、modeを設定するか、presetsを構成し、targets構成マッピングでターゲット用に設定します。 targetsの詳細については、バンドル構成ターゲットのマッピングを参照してください。
開発モード
開発モードでバンドルをデプロイするには、まず、mode に設定された development マッピングを目的のターゲットに追加する必要があります。 たとえば、dev という名前のこのターゲットは開発ターゲットとして扱われます。
targets:
dev:
mode: development
databricks bundle deploy -t <target-name> コマンドを実行して開発モードでターゲットをデプロイすると、次のビヘイビアーが実装されます。これは、presets を使用してカスタマイズできます：
- ファイルまたはノートブックとしてデプロイされていないすべてのリソースの前にプレフィックス
[dev ${workspace.current_user.short_name}]が付き、デプロイされたそれぞれのジョブとパイプラインにdevAzure Databricks タグが付きます。 - デプロイされたすべての関連する Lakeflow 宣言パイプラインを
development: trueとしてマークします。 --compute-id <cluster-id>コマンドの関連する呼び出しでbundle deployを使用できるようにします。これにより、関連するバンドル構成ファイルで既に指定されているすべての既存のクラスター定義がオーバーライドされます。--compute-id <cluster-id>コマンドの関連する呼び出しでbundle deployを使用する代わりに、ここで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> コマンドを実行して運用MODEのターゲットをデプロイすると、次のビヘイビアーが実装されます：
デプロイされたすべての関連する Lakeflow 宣言パイプラインが
development: falseとしてマークされていることを検証します。ターゲットで指定されている Git ブランチと現在の Git ブランチが等しいことを検証します。 ターゲットでの Git ブランチの指定は省略可能です。次のように
gitプロパティを追加して指定できます。git: 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 では、 targets の構成可能なプリセットがサポートされています。これにより、ターゲットのビヘイビアーをカスタマイズできます。 利用可能プリセットを次のテーブルにまとめて示します:
注記
次の表で例外が指定されていない限り、 mode と presets の両方が設定されている場合、プリセットは既定のモード動作をオーバーライドし、個々のリソースの設定はプリセットをオーバーライドします。 たとえば、ジョブの max_concurrent_runs が 10 で、 jobs_max_concurrent_runs プリセットが 20 に設定されている場合、ジョブの同時実行の最大数は 10 になります。
| プリセット | 説明 |
|---|---|
artifacts_dynamic_version |
デプロイ中に whl 成果物のバージョンを動的に更新するかどうか。 有効な値は true または falseです。 最上位レベル のartifacts.dynamic_version構成設定 を指定すると、このプリセットがオーバーライドされます。 |
jobs_max_concurrent_runs |
ジョブの同時実行の最大許容数。 |
name_prefix |
リソース名の先頭に付加するプレフィックス文字列。 |
pipelines_development |
パイプラインが開発モードであるかどうか。 有効な値は true または falseです。 |
source_linked_deployment |
将来の使用のために予約されています。 デプロイ中に作成されたリソースがワークスペース内のソースファイルを指しているか、それともワークスペースのコピーを指しているか。 |
tags |
ジョブとテストを含む、タグをサポートするすべてのリソースに適用されるキーと値のタグのセット。 Databricks Asset Bundlesは、 schema リソースのタグをサポートしていません。 |
trigger_pause_status |
すべてのトリガーとスケジュールに適用する一時停止状態。 有効な値は PAUSED または UNPAUSEDです。modeが development に設定されている場合、trigger_pause_statusは常にPAUSED。 |
次の例では、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