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

ダイレクトデプロイメントエンジンへの移行

宣言型オートメーションバンドルは元々、デプロイメントを管理するためにDatabricks Terraform プロバイダーの上に構築されました。ただし、Databricks CLIバージョン 0.279.0 以降では、 Terraform と direct という2つの異なるデプロイメント エンジンがサポートされています。ダイレクトデプロイメントエンジンには大きなメリットがあり、Terraformに依存しません。

Databricks CLI バージョン 1.3.0 以降を使用して作成された新しいバンドルは、デフォルトでダイレクトデプロイメントエンジンを使用します。以前のバージョンの CLI を使用して作成されたバンドルは、このページで説明されている移行ステップを使用して、Terraform デプロイメント エンジンからダイレクトデプロイメント エンジンへ移行できます。

重要

Databricks は、Terraform デプロイメントエンジンが間もなく非推奨となり、ダイレクトデプロイメントエンジンがデフォルトになるため、ダイレクトエンジンへの移行を推奨しています。宣言型オートメーションバンドルは、まもなくダイレクトデプロイメント エンジンをデフォルトとして使用しますをご参照ください。

ダイレクトデプロイメントのメリット​

新しいダイレクトデプロイメントエンジンはDatabricks Go SDKを使用し、次のような利点があります。

  • デプロイメントの高速化: バンドルデプロイメントは最大40％高速化されます。
  • より強力で詳細な検証と計画: bundle plan -o jsonレポートを使用した変更の詳細な差分で、特定の操作をTriggerした内容についてフィールドごとに詳細を説明します。
  • リプレイ可能なプラン : bundle deploy --plan plan.json は、以前に作成されたプランを実行し、承認されたアクションのみが本番運用に到達することを保証し、プランの計算がスキップされるため、デプロイが高速化されます。
  • 容易な設定 ：ファイアウォール、プロキシ、カスタムプロバイダーレジストリに関する問題が回避されます。
  • その他のリソース ：カタログ、外部ロケーション、AI Search Endpoint、Genie spacesなどの追加のリソースがサポートされています。
  • 不変フォルダ ：アセットは、改ざん防止とデプロイの整合性のため、任意で不変の読み取り専用フォルダにデプロイできます。「immutable_folder」を参照してください。

ダイレクトデプロイメントの使用を開始する​

新しいダイレクトデプロイメントエンジンの使用を開始するには:

  • 既存のバンドルについては、databricks bundle deployment migrateを使用して移行します。既存のバンドルを移行するを参照してください。
  • 新規または既存のバンドルについては、バンドル構成で engine: direct を設定するか、DATABRICKS_BUNDLE_ENGINE 環境変数を direct に設定します。新しいバンドルを直接デプロイをご覧ください。

既存のバンドルを移行する​

ダイレクトデプロイメントエンジンは独自の JSON 状態ファイルを使用します。スキーマは Terraform JSON 状態ファイルとは異なります。bundle deployment migrateコマンドは、Terrform 状態ファイル ( terraform.tfstate ) を直接デプロイメント状態ファイル ( resources.json ) に変換します。このコマンドは、既存のデプロイメントから ID を読み取ります。

  1. Terraform を使用して完全なデプロイメントを実行します。

    Bash
    databricks bundle deploy -t my_target

  2. デプロイメントを移行します。

    Bash
    databricks bundle deployment migrate -t my_target
注記

Databricks CLI バージョン 0.280.0 から 1.4.x では、bundle deployment migrate は bundle plan を実行し、プランで何らかのアクションが報告された場合は移行を停止します。この場合は、再デプロイして移行を再試行してください。それでも失敗する場合は、--noplancheck を使用してプランチェックをスキップできます。

  1. 移行が成功したことを確認してください。databricks bundle plan をランします。これは成功し、アクションは報告されないはずです。

    Bash
    databricks bundle plan -t my_target
注記

ローカル構成がデプロイされたリソースと一致する場合でも、プランはリソースの変更を報告する可能性があります。これは、以前のTerraform状態ファイルに、デプロイ後にプラットフォームが入力するメタデータフィールドが含まれており、それがバンドル構成に存在しないために発生する可能性があります。これらの違いは、実際の構成driftではなく、ジョブの動作を変更するものではありません。ダイレクトエンジンは、次のbundle deployでそれらを調整します。ダイレクトエンジンがdiffを計算する方法の詳細については、「リソース状態diff計算」を参照してください。

  • 検証に失敗した場合は、新しい状態ファイルを削除します。

    Bash
    rm .databricks/bundle/my_target/resources.json

  • 検証が成功したら、バンドルをデプロイして状態ファイルをワークスペースに同期します。

    Bash
    databricks bundle deploy -t my_target

新規バンドルを直接デプロイ​

状態ファイルが存在しないため、 bundle migrateコマンドはデプロイされていないバンドルでは機能しません。代わりに、以下のいずれかの操作を行ってください。

  • databricks.ymlでbundle.engine設定してください。

    YAML
    bundle:
      engine: direct

  • 環境変数DATABRICKS_BUNDLE_ENGINEを設定してデプロイします。

    Bash
    DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target

設定と環境変数の両方が設定されている場合は、設定が優先されます。

デプロイエンジン比較​

新しい直接デプロイメント エンジンは、Terrform デプロイメント エンジンとほぼ同じように動作しますが、いくつか違いもあります。

リソース状態差分計算​

単一のリソース状態 (ローカル構成とリモート状態の組み合わせ) を維持する Terraform とは異なり、新しいエンジンはこれらを個別に保持し、状態ファイルにローカル構成のみを記録します。

リソースの状態差分の計算は、次の 2 つのステップで実行されます。

  1. ローカル バンドル構成は、最新のデプロイメントに使用されたスナップショット構成と比較されます。リモート状態は役割を果たしません。
  2. リモート状態は、最新のデプロイメントに使用されたスナップショット構成と比較されます。

結果は次のようになります。

  • databricks.yml リソースの変更は無視されることはなく、常に更新がトリガーされます。
  • 実装によって処理されないリソース フィールドでは、矛盾した結果エラーは発生しません。これらのリソースは直接エンジンによって正常にデプロイされますが、ドリフトが発生する可能性があります。デプロイされたリソースは、次の計画またはデプロイ時に更新されます。

削除された構成設定​

2つのエンジンは、バンドル構成から削除する設定を異なる方法で処理します。

  • Terraform エンジンを使用すると、databricks.yml から設定されたフィールドを削除しても、プラットフォーム内の対応する値は変更されません。Terraform は、設定に明示的に存在するフィールドのみを管理するため、削除されたフィールドは、最後のデプロイ時に持っていた値を保持します。
  • ダイレクトエンジンを使用すると、databricks.ymlから設定フィールドを削除すると、値はリソースのdefaultに戻されます。ダイレクトエンジンはローカル構成を以前のスナップショットと比較するため、存在しないフィールドは変更として扱われ、リソースは次のデプロイでdefault値に更新されます。

値を永続化するには、以前にデプロイされた値に依存するのではなく、構成で明示的に設定します。

リソース置換の検索​

リソース置換は、リソース ID を解決するために使用できます (例: ${resources.jobs.my_job.id} )。 「置換」を参照してください。直接デプロイメント エンジンでのリソース置換の解決は、次の 2 つのステップで実行されます。

  1. ローカル構成内に存在するフィールドを指す参照は、ローカル構成で提供される値に解決されます。
  2. ローカル構成に存在しない参照は、リモート状態から解決されます。これは、特定のリソースに対して適切なGETリクエストを使用して取得された状態です。

${resource.*}置換を解決するために使用されるスキーマは、ファイルout.fields.txtにあります。ALLおよびSTATEとしてマークされたフィールドは、ローカル解決に使用できます。ALLまたはREMOTEとしてマークされたフィールドは、リモート解決に使用できます。

リソースの互換性​

以下のリソースはダイレクトデプロイメントエンジンを必要とし、Terraform デプロイメントエンジンではサポートされていません。

さらに、lifecycle.startedフィールドはダイレクトデプロイメントエンジンでのみ利用可能であり、apps、clusters、およびsql_warehousesでのみ利用できます。true に設定すると、リソースは開始モードでデプロイされます。ライフサイクルを参照してください。

このページの見出し