宣言型自動化バンドルを使用してLakebaseを管理する

このガイドは、宣言型自動化バンドルを使用して Lakebase を管理する方法を学ぶのに役立ちます。 インフラストラクチャをコードとして使用します。 Lakebaseプロジェクトを作成し、開発ブランチとエンドポイントを追加し、これらのリソースを宣言的に管理する方法を学びます。これは、開発環境およびテスト環境でDatabricksリソースをプログラムで管理するための一般的なワークフローです。

バンドル リソースの完全なリファレンスと利用可能なすべての構成オプションについては、 「バンドル リソース」を参照してください。

注記

postgres_projects LakebaseオートスケールのDABリソースです。 database_instancesを使用した既存のオートメーションがある場合、それは引き続き機能しますが、新しいインスタンスはLakebase Lakebaseスケール プロジェクトとして作成されます。 オートスケール by 自信を参照してください。

前提条件

始める前に、次のものが必要です。

• Databricks CLIバージョン0.287.0以降。インストールされているバージョンを確認するには、databricks -vを実行します。Databricks CLI をインストールするには、「Databricks CLI のインストールまたは更新」を参照してください。postgres_catalogsおよびpostgres_synced_tablesのリソースはDatabricks CLIバージョン1.0.0以上が必要です。
• Databricks ワークスペース用に構成された認証。このガイドでは、OAuth ユーザー対マシン (U2M) 認証を使用します。Databricks CLI チュートリアルの「ワークスペースへのアクセスの構成」を参照してください。
• Lakebase プロジェクトの権限CAN MANAGE 。 「プロジェクト権限の管理」を参照してください。

リソース階層

Lakebaseのリソースは親子関係の階層構造になっています。つまり、子リソースを作成する前に親リソースを作成します。完全なリソース モデル (プロジェクト、ブランチ、コンピュート、データベースなど) については、 「プロジェクト」を参照してください。

このガイドの操作順序: プロジェクト → ブランチ → エンドポイント

1. バンドル構成を作成する

デフォルトの最小限のテンプレートを使用してバンドルを初期化します。これにより、 databricks.ymlを含むバンドル フォルダーが作成され、CLI 構成 (ワークスペース ホストを含む) が取得されます。

Bash

databricks bundle init default-minimal

プロンプトが表示されたら、バンドル プロジェクトの名前を入力します (例: lakebase-bundle )。CLI はその名前のディレクトリを作成します。バンドル ディレクトリに切り替えます。

Bash

cd lakebase-bundle

databricks.ymlファイルを変更して、Lakebase プロジェクト、ブランチ、エンドポイントを定義します。resourcesセクション (および必要に応じてバンドル名) を追加または更新します。例えば：

YAML

bundle:
  name: lakebase-app

resources:
  postgres_projects:
    my_app:
      project_id: 'my-app'
      display_name: 'My Application'
      pg_version: 17

  postgres_branches:
    dev_branch:
      parent: ${resources.postgres_projects.my_app.id}
      branch_id: 'dev'
      no_expiry: true

  postgres_endpoints:
    dev_endpoint:
      parent: ${resources.postgres_branches.dev_branch.id}
      endpoint_id: 'primary'
      endpoint_type: 'ENDPOINT_TYPE_READ_WRITE'
      autoscaling_limit_min_cu: 0.5
      autoscaling_limit_max_cu: 2
      replace_existing: true

注記

enable_pg_native_login: false 新しいプロジェクトのデフォルトです。ネイティブのPostgresロールが静的パスワードで接続できるようにするには、trueに設定してください。パスワード接続の管理を参照してください。

注意

デフォルトでは、Lakebaseプロジェクトを削除すると論理削除されます。プロジェクトは7日間保持され、その後Lakebaseによって完全に削除されます。プロジェクトをすぐに完全に削除するには、--purge を delete-project CLI コマンドに渡します (--purge フラグのない bundle destroy ではありません)。詳細については、ステップ6 を参照してください。

エンドポイントについて : Lakebase プロジェクトを作成すると、 Databricks読み取り/書き込みエンドポイントを使用して実質本番運用ブランチを自動的にプロビジョニングします。 ただし、作成する追加のブランチ (上記の dev ブランチなど) では、バンドル構成でエンドポイントを明示的に定義する必要があります。

project_id 、 branch_id 、およびendpoint_id値は、リソースの命名規則(1 ～ 63 文字、小文字、数字、ハイフンなど) に従う必要があります。

2. バンドルを検証する

バンドル構成が有効かどうかを確認します。

Bash

databricks bundle validate

バンドル構成の概要が返された場合、検証は成功しています。エラーが返された場合は、エラーを修正してこのステップを繰り返します。 「databricks bundle validate」を参照してください。

3. バンドルを展開する

Lakebase プロジェクトを Databricks ワークスペースにデプロイします。

Bash

databricks bundle deploy

これにより、次のものが作成されます。

• 「my-app」という名前のLakebaseプロジェクト
• 読み取り/書き込みエンドポイントを備えた本番本番運用ブランチ (自動的に作成される)
• 「dev」という名前の開発ブランチ
• 0.5 から 2 CU のオートスケールを備えた開発ブランチのプライマリ エンドポイント

「databricks バンドル デプロイ」を参照してください。

4. デプロイメントを確認する

リソースが作成されたことを確認します。

1. Databricks ワークスペースで、 Lakebase → Projects に移動します。
2. [マイアプリケーション] をクリックします。
3. 2 つのブランチが表示されていることを確認します。
   • 本番運用 (もう) - 1 CU のプライマリ コンピュートで自動的に作成されます
   • dev - 0.5-2 CU オートスケール コンピュートのバンドルによって作成されました

5. 設定を更新する

リソースを変更するには、 databricks.ymlファイルを更新して再デプロイします。

Bash

databricks bundle validate
databricks bundle deploy

バンドルは変更されたリソースのみを更新します。

6. リソースをクリーンアップする

Lakebase プロジェクトが完了したら、プロジェクトを削除してリソースを解放できます。

バンドルが作成したリソースを破棄するには、databricks bundle destroyを使用します。

Bash

databricks bundle destroy

これにより、プロジェクトとすべてのブランチ、エンドポイント、データベースが連鎖的に削除され、バンドルのデプロイ状態がクリアされます。デフォルトでは、プロジェクトはソフトデリートされ、7日間保持されます。その後、Lakebase によって完全に削除されます。保持期間中にプロジェクトを回復できます。

バンドル内の他のリソースを削除したり、保持期間を待ったりせずに、プロジェクトのみをすぐに削除するには、Databricks CLI を --purge とともに使用します。

Bash

databricks postgres delete-project projects/my-app --purge

--purge プロジェクトを論理削除するのではなく、即座に完全に削除します。この方法でプロジェクトを削除しても、バンドルのデプロイ状態は更新されません。

注記

7日間の保持期間中、論理削除されたプロジェクトとproject_idが同じ新しいプロジェクトを作成すると、失敗します。同じプロジェクト ID を再利用するには、まず既存のプロジェクトを復元するか、--purge を使用して強制削除するか、保持期間の期限切れを待ってください。

7日間の保持期間が終了する前にソフト削除されたプロジェクトを復元するには、CLIまたはAPIを使用します。

ヒント

本番運用のプロジェクトの誤削除を防ぐには、バンドルの postgres_projects リソースに lifecycle ブロックを追加します:

YAML

resources:
  postgres_projects:
    my_app:
      project_id: 'my-app'
      lifecycle:
        prevent_destroy: true

これにより、リソースの破棄を試みると、バンドル操作はエラーで失敗します。プロジェクトを意図的に削除したい場合は、prevent_destroy: true を削除します。

リソースの代替

バンドル構成では、置換を使用してリソースを参照します。

• ${resources.postgres_projects.my_app.id} - Lakebaseプロジェクトのリソース名を参照します
• ${resources.postgres_branches.dev_branch.id} - ブランチリソース名を参照します

これにより、デプロイメント中に適切な依存関係の順序が保証されます。バンドル置換の詳細については、 「置換」を参照してください。

利用可能なリソース

バンドルでサポートされているLakebaseリソースとそれらの構成オプションの全リストについては、バンドルリソース（postgres_projects, postgres_branches, postgres_endpoints, postgres_catalogs, postgres_synced_tables, postgres_roles, postgres_databases）を参照してください。

プロジェクト権限の管理

Lakebaseプロジェクトは、CAN_CREATE、CAN_USE、およびCAN_MANAGEの権限レベルをサポートしています。すべてのワークスペースユーザーはデフォルトでCAN_CREATEを持っているため、CAN_USEまたはCAN_MANAGEのみをバンドルで割り当てます。各レベルの詳細については、LakebaseプロジェクトACLを参照してください。

postgres_projectsリソース上のpermissionsフィールドを使用して、プロジェクトの権限を宣言します。各エントリは、ユーザー、グループ、またはサービスプリンシパルに権限レベルを付与します：

YAML

postgres_projects:
  my_project:
    project_id: my-project
    permissions:
      - service_principal_name: <sp-application-id>
        level: CAN_MANAGE

Permissions API、CLI、またはSDKを使用して、個別に権限を管理することもできます。

その他のリソース

• 宣言型自動化バンドル
• 宣言型自動化バンドルのリソースリファレンス
• Lakebaseプロジェクトの管理
• ブランチを管理する
• ブランチベース開発チュートリアル
• Lakebase 向け Terraform を使い始める