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

宣言型自動化バンドルのデプロイモード

この記事では、宣言型自動化バンドルのデプロイモードの構文について説明します。バンドルを使用すると、 Databricksワークフローをプログラムで管理できます。 「宣言型自動化バンドルとは何か？」を参照してください。

CI/CDワークフローでは、開発者は通常、さまざまなフェーズまたは モード でソリューションのコーディング、テスト、デプロイ、および実行を行います。 たとえば、最も単純なモードのセットには、本番運用前の検証用の 開発 モードと、その後に検証された成果物用の 本番運用 モードが含まれます。 宣言型自動化バンドルは、これらの各モードに対応する、オプションのデフォルト動作のコレクションを提供します。特定のターゲットに対してこれらの動作を使用するには、 targets構成マッピングでターゲットにmodeを設定するか、 presetsを構成します。targets情報については、 「バンドル構成ターゲットのマッピング」を参照してください。

開発モード​

バンドルを開発モードでデプロイするには、まず development に設定された mode マッピングを目的のターゲットに追加する必要があります。 たとえば、dev という名前のこのターゲットは開発ターゲットとして扱われます。

YAML
targets:
  dev:
    mode: development

databricks bundle deploy -t <target-name> コマンドを実行して開発モードでターゲットをデプロイすると、次の動作が実装され、プリセットを使用してカスタマイズできます。

  • ファイルまたはノートブックとしてデプロイされていないすべてのリソースの先頭にプレフィックス [dev ${workspace.current_user.short_name}] を付け、デプロイされた各ジョブとパイプラインに dev Databricks タグを付けます。
  • デプロイされたすべての関連するLakeflow Spark宣言型パイプラインをdevelopment: trueとしてマークします。
  • bundle deploy コマンドの関連呼び出しで --cluster-id <cluster-id> を使用できるようにします。これにより、関連するバンドル構成ファイルで既に指定されているすべての既存のクラスター定義がオーバーライドされます。bundle deploy コマンドの関連呼び出しで --cluster-id <cluster-id> を使用する代わりに、ここで cluster_id マッピングを設定するか、bundle マッピングの子マッピングとして、使用するクラスターの ID に設定できます。
  • デプロイされたリソース (ジョブや品質モニターなど) のすべてのスケジュールとトリガーを停止します。 個々のジョブのスケジュールとトリガーの一時停止を解除するには、 schedule.pause_status を UNPAUSEDに設定します。
  • デプロイされたすべてのジョブで並列実行を有効にして、イテレーションを高速化します。 個々のジョブの並列実行を無効にするには、 max_concurrent_runs を 1に設定します。
  • デプロイメント・ロックを無効にして、反復処理を高速化します。 このロックにより、開発モードで発生する可能性が低いデプロイの競合が防止されます。 bundle.deployment.lock.enabledをtrueに設定して、ロックを再度有効にします。

本番運用モード​

バンドルを本番運用モードでデプロイするには、まず、 mode マッピングを productionに設定して目的のターゲットに追加する必要があります。 たとえば、この prod という名前のターゲットは、本番運用ターゲットとして扱われます。

YAML
targets:
  prod:
    mode: production

databricks bundle deploy -t <target-name> コマンドを実行して本番運用モードでターゲットをデプロイすると、次の動作が実装されます。

  • デプロイされたすべての関連するLakeflow Spark宣言型パイプラインがdevelopment: falseとしてマークされていることを検証します。

  • 現在の Git ブランチが、ターゲットで指定された Git ブランチと等しいことを検証します。 ターゲットでの Git ブランチの指定はオプションであり、次のように追加の git プロパティを使用して実行できます。

    YAML
    git:
      branch: main

    この検証は、デプロイ中に --force を指定することでオーバーライドできます。

  • Databricks 、本番運用デプロイにはサービスプリンパルシを使用することをお勧めします。 サービスプリンシパルにrun_asを設定することで、これを強制できます。「サービスシプリンパル」と「Declarative Automation Bundles ワークフローの実行 ID を指定する」を参照してください。 サービスプリンシパルを使用しない場合は、以下の追加の動作に注意してください。

    • artifact_path、file_path、root_path、state_path のマッピングが特定のユーザーに上書きされていないことを検証します。
    • run_as と permissions のマッピングが指定されていることを検証して、どの ID にデプロイ用の特定の権限があるかを確認します。

  • modeマッピングを developmentに設定する前述の動作とは異なり、modeマッピングを production に設定しても、関連するバンドル構成ファイルに指定されている既存のクラスター定義 (例えば、--compute-id <cluster-id> オプションや compute_id マッピングを使用) はオーバーライドできません。

カスタムプリセット​

宣言型自動化バンドルは、ターゲット用の設定可能なプリセットをサポートしており、ターゲットの動作をカスタマイズできます。利用可能なプリセットについては、設定リファレンスを参照してください。

注記

プリセットに例外が指定されていない限り、 modeとpresets両方が設定されている場合は、プリセットがデフォルト モードの動作をオーバーライドし、個々のリソースの設定がプリセットをオーバーライドします。例えば：

  • ジョブのmax_concurrent_runsが 10 であるが、 jobs_max_concurrent_runsプリセットが 20 に設定されている場合、ジョブの最大実行実行は 10 になります。
  • スケジュールがUNPAUSEDに設定されているが、 trigger_pause_statusプリセットがPAUSEDに設定されている場合、スケジュールは一時停止解除されます。

次の例は、 devという名前のターゲットのカスタムプリセット設定を示しています。

YAML
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