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

直接展開エンジンへの移行

備考

実験段階

この機能は実験的なものです。

Databricks Asset Bundles は元々、デプロイメントを管理するためにDatabricks Terraform プロバイダー上に構築されました。ただし、この依存関係を回避するために、 Databricks CLIバージョン 0.279.0 以降では、 Terraform と direct という 2 つの異なるデプロイメント エンジンがサポートされています。 直接デプロイメント エンジンは Terraform に依存せず、すぐにデフォルトになります。Terraform デプロイメント エンジンは最終的には廃止される予定です。

直接導入の利点は何ですか?​

新しい直接展開エンジンはDatabricks Go SDKを使用し、次のような利点があります。

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

直接展開の使用を開始するにはどうすればよいですか?​

新しい直接展開エンジンの使用を開始するには:

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

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

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

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

    Bash
    databricks bundle deploy -t my_target

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

    Bash
    databricks bundle deployment migrate -t my_target

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

    Bash
    databricks bundle plan -t my_target

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

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

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

      Bash
      databricks bundle deploy -t my_target

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

状態ファイルがないため、 bundle migrateコマンドは一度もデプロイされていないバンドルでは機能しません。代わりに、 DATABRICKS_BUNDLE_ENGINE環境変数を設定してデプロイします。

Bash
DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target

直接展開エンジンの変更点は何ですか?​

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

リソース状態の差分計算​

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

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

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

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

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

$resources 置換検索​

$resourcesの最も一般的な用途は、Terraform エンジンと直接デプロイメント エンジン間で同じように動作する置換 ID (たとえば、 $resources.jobs.my_job.id ) を解決することです。

ただし、直接デプロイメント エンジンでの$resources置換の解決 (例: $resources.pipelines.my_pipeline.name ) は、次の 2 つのステップで実行されます。

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

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