直接デプロイ エンジンに移行する

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

Databricks CLI バージョン 1.3.0 以降を使用して作成された新しいバンドルでは、既定で直接デプロイ エンジンが使用されます。 Terraformデプロイメントエンジンを使用しているバンドルは自動的にダイレクトエンジンに移行されるため、設定は不要です。 「直接展開を使い始める」を参照してください。

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

Important

Databricks CLIバージョン1.20.0では、Terraformデプロイメントエンジンが削除されました。 DatabricksのCLIはTerraform stateのバンドルを直接エンジンに自動移行できますが、自動移行が失敗するとデプロイは中止されます。 Terraformデプロイメントエンジンの使用を継続するには、Databricks CLI バージョン1.19にピン留めしてください。 「宣言型オートメーション バンドルは、すぐに既定で直接デプロイ エンジンを使用する」を参照してください。

直接展開の利点

新しい直接デプロイ エンジンは Databricks Go SDK を使用し、次の利点があります。

  • より高速なデプロイ: バンドルのデプロイは最大 40% 高速です。
  • より強力で詳細な検証と計画: bundle plan -o json レポートを使用した変更点の詳細な差分表示。各フィールドごとの詳細情報とともに、特定のアクションがどのような要因で発生したかを説明しています。
  • 再生可能なプラン: bundle deploy --plan plan.json は、以前に作成したプランを実行し、プランの計算がスキップされるため、承認されたアクションのみが運用環境に到達し、デプロイを高速化します。
  • 簡単なセットアップ: ファイアウォール、プロキシ、およびカスタム プロバイダー レジストリに関する問題は回避されます。
  • その他のリソース: カタログ、外部の場所、AI 検索エンドポイント、Genie スペースなどのその他のリソースがサポートされています。
  • 不変フォルダー: 資産は、必要に応じて、改ざん防止と展開の一貫性のために、変更できない読み取り専用フォルダーに展開できます。 immutable_folderを参照してください。

直接展開を始めましょう

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

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

新しいバンドルを直接デプロイする

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

  • databricks.ymlで bundle.engine を設定します。

    bundle:
  engine: direct

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

    DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target

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

デプロイ エンジンの比較

新しい直接デプロイ エンジンは、ほとんどの場合、Terrform デプロイ エンジンと同じように動作しますが、いくつかの違いがあります。

リソース状態の差分計算

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

リソース状態の差分計算は、次の 2 つの手順で行われます。

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

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

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

構成設定を削除しました

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

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

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

リソース置換の検索

リソースの置換は、リソース 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に設定すると、開始モードでリソースがデプロイされます。 ライフサイクルを参照してください。

  • 最終更新: