Databricks アセット バンドルのデプロイ モード

この記事では、Databricks アセット バンドルのデプロイ モードの構文について説明します。 バンドルを使用すると、Azure Databricks ワークフローをプログラムで管理できます。 「Databricks アセット バンドルとは」を参照してください

CI/CD ワークフローでは、開発者は通常、さまざまなフェーズまたは "モード" でソリューションをコーディング、テスト、デプロイ、実行します。 一連のモードのもっとも単純な例としては、運用前の検証のための "開発" モードに検証後の成果物のための "運用" モードが続くというものがあります。 Databricks アセット バンドルには、これらの各モードに対応する既定の動作のオプション コレクションが用意されています。 特定のターゲットに対してこれらのビヘイビアーを使用するには、modeを設定するか、presetsを構成し、targets構成マッピングでターゲットにします。 targetsの詳細については、バンドル構成ターゲットのマッピングを参照してください。

開発モード

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

targets:
  dev:
    mode: development

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

• ファイルまたはノートブックとしてデプロイされていないすべてのリソースの前にプレフィックス [dev ${workspace.current_user.short_name}] が付き、デプロイされたそれぞれのジョブとパイプラインに dev Azure Databricks タグが付きます。
• すべての関連するデプロイされた Delta Live Tables パイプラインを 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 に設定して、ロックを再度有効にします。

運用モード

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

targets:
  prod:
    mode: production

databricks bundle deploy -t <target-name> コマンドを実行して運用MODEのターゲットをデプロイすると、次のビヘイビアーが実装されます：

• 関連するすべてのデプロイ済み Delta Live Tables パイプラインに 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 の構成可能なプリセットがサポートされています。これにより、ターゲットのビヘイビアーをカスタマイズできます。 利用可能プリセットを次のテーブルにまとめて示します:

次の例では、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