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

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

Databricks CLI バージョン 1.3.0 以降を使用して作成された新しいバンドルでは、既定で直接デプロイ エンジンが使用されます。 以前のバージョンの CLI を使用して作成されたバンドルは、このページで説明する移行手順を使用して、Terraform デプロイ エンジンから直接デプロイ エンジンに移行できます。

Important

Databricks では、Terraform デプロイ エンジンが間もなく非推奨になり、直接デプロイ エンジンが既定になるため、直接エンジンへの移行をお勧めします。 「宣言型オートメーション バンドルは、すぐに既定で直接デプロイ エンジンを使用する」を参照してください。

直接展開の利点は何ですか?

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

  • ファイアウォール、プロキシ、およびカスタム プロバイダー レジストリに関する問題を回避します
  • bundle plan -o json を使用して利用できる変更の詳細な差分
  • 迅速なデプロイ
  • デプロイ前に Terraform と terraform-provider-databricks をダウンロードする必要はありません
  • Terraform プロバイダーのリリースに合わせる必要がないため、新しいバンドル リソースを解放する時間が短縮されました

直接デプロイの使用を開始するにはどうすればよいですか?

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

  • 既存のバンドルの場合は、 databricks bundle deployment migrateを使用してそれらを移行します。
  • 新しいバンドルの場合は、 DATABRICKS_BUNDLE_ENGINE 環境変数を direct に設定してデプロイします。

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

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

  1. Terraform を使用して完全なデプロイを実行する:

    databricks bundle deploy -t my_target

  2. 展開を移行します。

    databricks bundle deployment migrate -t my_target

  3. 移行が成功したことを確認します。 databricks bundle plan コマンドは成功し、変更は表示されません。

    databricks bundle plan -t my_target

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

      rm .databricks/bundle/my_target/resources.json

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

      databricks bundle deploy -t my_target

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

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

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

    bundle:
  engine: direct

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

    DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target

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

ダイレクト デプロイ エンジンの変更点

新しい直接デプロイ エンジンは、ほとんどの場合、Terrform デプロイ エンジンと同じように動作しますが、いくつかの違いがあります。 具体的には、ダイレクト エンジンはリソースのローカル状態とリモート状態を個別に追跡し、2 つの手順でリソースの置換を解決します。

リソース状態の差分計算

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

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

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

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

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

リソース置換の検索

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

  • Last updated on