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

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

備考

実験段階

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

Declarative Automation 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 状態ファイルとは異なります。bundle deployment migrateコマンドは、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 デプロイメント エンジンとほぼ同じように動作しますが、いくつか違いもあります。具体的には、ダイレクト エンジンはリソースのローカルとリモートの状態を個別に追跡し、リソースの置換を 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としてマークされたフィールドは、リモート解決に使用できます。