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

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

Databricks CLI バージョン 1.3.0 以降を使用して作成された新しいバンドルでは、既定で直接デプロイ エンジンが使用されます。 以前のCLIバージョンで作成されたバンドルは、Terraformデプロイメントエンジンからダイレクトデプロイメントエンジンへ移行可能です。 「既存のバンドルを移行する」を参照してください。

Databricks CLI バージョン 1.14.0以降、引き続きTerraformエンジンを使用しているバンドルは、ドライラン変換の結果に問題がないデプロイの後、自動的にダイレクトエンジンに移行されます。 オプトアウトするには、 bundle.engine: terraform または DATABRICKS_BUNDLE_ENGINE=terraformを設定します。 「新しいバンドルを直接デプロイする」を参照してください。

Important

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

直接展開の利点

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

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

直接デプロイの使用を開始する

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

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

直接デプロイ エンジンは、独自の 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

    Note

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

  3. 移行が成功したことを確認します。 databricks bundle planを実行し、成功し、何のアクションも報告しないはずです。

    databricks bundle plan -t my_target

    Note

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

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

      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 デプロイ エンジンと同じように動作しますが、いくつかの違いがあります。

リソース状態の差分計算

単一のリソース状態 (ローカル構成とリモート状態の組み合わせ) を維持する 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に設定すると、開始モードでリソースがデプロイされます。 ライフサイクルを参照してください。

  • Last updated on