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

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

Databricks CLI バージョン 1.3.0 以降を使用して作成された新しいバンドルでは、defaultでダイレクトデプロイメントエンジンが使用されます。Terraform デプロイメントエンジンを引き続き使用しているバンドルは、ダイレクトエンジンに自動的に移行されるため、設定は必要ありません。ダイレクトデプロイメントの使用を起動を参照してください。

自動移行を防ぐには、bundle.engine: terraform または DATABRICKS_BUNDLE_ENGINE=terraform を設定します。これにより、すべての Databricks CLI バージョンでの自動移行が防止されます。バージョン 1.19 までの Databricks CLI では、引き続き Terraform エンジンが使用されます。Databricks CLI バージョン 1.20.0 以降では、エラーになります。新しいバンドルの直接デプロイを参照してください。

重要

Databricks CLIバージョン 1.20.0 では、Terraform デプロイメントエンジンが削除されました。Databricks CLI では、Terraform の状態を持つバンドルをダイレクトエンジンに自動移行することができますが、自動移行が失敗した場合、デプロイは中断されます。Terraform デプロイメントエンジンを引き続き使用するには、Databricks CLIバージョン 1.19 にピン留めします。See Declarative Automation Bundles will soon default to use the direct deployment engine.

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

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

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

ダイレクトデプロイメントの起動を使用する

ダイレクトデプロイメントエンジンは、Databricks CLI バージョン 1.3.0 以降で作成された新しいバンドルの default となります。Databricks CLI バージョン 1.14 以降では、Terraform エンジンを使用するバンドルは、デプロイ時にダイレクトエンジンに自動的に移行されます。

Databricks CLIバージョン1.8以降では、engine: directを設定することでバンドルを直接エンジンに移行できます。新しいバンドルの直接デプロイを参照してください。

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

ダイレクトデプロイメントエンジンを明示的に設定するには、次のいずれかを実行します。

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 つのステップで実行されます。

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

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

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

削除された構成設定

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

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

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

リソース置換の検索

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

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

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

リソースの互換性

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

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

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

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

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

デプロイエンジン比較​

リソース状態差分計算​

削除された構成設定​

リソース置換の検索​

リソースの互換性​