Important
Lakebaseの宣言的自動化バンドルのサポートは ベータ版です。
このガイドは、コードとしてインフラストラクチャを使用して Lakebase リソースを管理するための宣言型オートメーション バンドルの使用を開始するのに役立ちます。 Lakebase プロジェクトを作成し、開発ブランチとエンドポイントを追加し、これらのリソースを宣言によって管理する方法について説明します。 これは、開発環境およびテスト環境でAzure Databricksリソースをプログラムで管理するための一般的なワークフローです。
バンドル リソースの完全なリファレンスと使用可能なすべての構成オプションについては、 バンドル リソースを参照してください。
注
postgres_projects はLakebaseの宣言的自動化バンドルリソースです。 既存の自動化があって、 database_instancesは動作し続けますが、新しいインスタンスはLakebaseプロジェクトとして作成されます。
既定での自動スケールを参照してください。
[前提条件]
開始する前に、次のものが必要です。
- Databricks CLI バージョン 0.287.0 以降。 インストールされているバージョンを確認するには、
databricks -vを実行します。 Databricks CLI をインストールするには、 Databricks CLI のインストールまたは更新に関する記事を参照してください。postgres_catalogsおよびpostgres_synced_tablesリソースには、Databricks CLI バージョン 1.0.0 以降が必要です。 - Azure Databricks ワークスペース用に構成された認証。 このガイドでは、OAuth ユーザー対マシン (U2M) 認証を使用します。 Databricks CLI チュートリアルの 「ワークスペースへのアクセスの構成」 を参照してください。
- Lakebase プロジェクトに対する CAN MANAGE アクセス許可。 「 プロジェクトのアクセス許可の管理」を参照してください。
リソースの階層
Lakebase リソースは親子階層に従います。子の前に親リソースを作成します。 完全なリソース モデル (プロジェクト、ブランチ、コンピューティング、データベースなど) については、「 プロジェクト」を参照してください。
このガイドの操作の順序: Project → ブランチ → エンドポイント
1. バンドル構成を作成する
既定の最小テンプレートを使用してバンドルを初期化します。 これにより、 databricks.yml を含むバンドル フォルダーが作成され、CLI 構成 (ワークスペース ホストを含む) が取得されます。
databricks bundle init default-minimal
メッセージが表示されたら、バンドル プロジェクトの名前を入力します (例: lakebase-bundle)。 CLI によって、その名前のディレクトリが作成されます。 バンドル ディレクトリに切り替えます。
cd lakebase-bundle
databricks.yml ファイルを変更して、Lakebase プロジェクト、ブランチ、エンドポイントを定義します。
resources セクション (および必要に応じてバンドル名) を追加または更新します。 例えば次が挙げられます。
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に設定します。
パスワード接続の管理を参照してください。
:::caution 既定では、Lakebase プロジェクトを削除すると論理的に削除されます。 プロジェクトは 7 日間保持され、その後、Lakebase によって完全に削除されます。 プロジェクトを直ちに完全に削除するには、--purge CLI コマンドにdelete-projectを渡します (bundle destroyではなく、--purge フラグがありません)。 詳細については、 手順 6 を参照してください。
:::
About エンドポイント: Lakebase プロジェクトを作成すると、Azure Databricksは読み取り/書き込みエンドポイントを使用して既定の運用ブランチを自動的にプロビジョニングします。 ただし、作成する追加のブランチ (上記の開発ブランチなど) では、それらのエンドポイントがバンドル構成で明示的に定義されている必要があります。
project_id、branch_id、およびendpoint_idの値は、リソースの名前付け規則 (1 ~ 63 文字、小文字、数字、ハイフンなど) に従う必要があります。
2. バンドルを検証する
バンドル構成が有効かどうかを確認します。
databricks bundle validate
バンドル構成の概要が返された場合、検証は成功しました。 エラーが返された場合は、エラーを修正し、この手順を繰り返します。 databricks バンドルの検証を参照してください。
3. バンドルをデプロイする
Azure Databricks ワークスペースに Lakebase プロジェクトをデプロイします。
databricks bundle deploy
これにより、次が作成されます。
- "my-app" という名前の Lakebase プロジェクト
- 読み取り/書き込みエンドポイントを持つ既定の運用ブランチ (自動的に作成)
- "dev" という名前の開発ブランチ
- 開発ブランチのプライマリエンドポイントで、自動スケーリングは0.5から2 CUで設定されています。
databricks バンドルのデプロイを参照してください。
4. デプロイを確認する
リソースが作成されたことを確認します。
- Azure Databricks ワークスペースで、Lakebase → Projects に移動します。
- [ マイ アプリケーション] をクリックします。
- 次の 2 つのブランチが表示されることを確認します。
- 運用環境 (既定) - 1 CU プライマリ計算ユニットにより自動的に作成される
- dev - 0.5～2 CU のオートスケーリング コンピューティング リソースを含むバンドルで作成されました
5. 構成を更新する
リソースを変更するには、 databricks.yml ファイルを更新して再デプロイします。
databricks bundle validate
databricks bundle deploy
バンドルは、変更されたリソースのみを更新します。
6.リソースをクリーンアップする
Lakebase プロジェクトが完了したら、それを削除してリソースを解放できます。
databricks bundle destroyを使用して、バンドルによって作成されたリソースを破棄します。
databricks bundle destroy
これにより、プロジェクトとそのすべてのブランチ、エンドポイント、およびデータベースが削除され、バンドルのデプロイ状態がクリアされます。 既定では、プロジェクトは論理的に削除され、7 日間保持され、その後 Lakebase によって完全に削除されます。 プロジェクトはリテンション期間中に復旧できます。
バンドル内の他のリソースを削除したり、リテンション期間を待たずにプロジェクトのみを直ちに削除するには、databricks CLI と共に --purgeを使用します。
databricks postgres delete-project projects/my-app --purge
--purge は、プロジェクトをソフト削除するのではなく、直ちに完全削除します。 この方法でプロジェクトを削除しても、バンドルのデプロイ状態は更新されません。
注
7 日間の保持期間中に、論理削除されたプロジェクトと同じ project_id を持つ新しいプロジェクトを作成しようとすると、失敗します。 同じプロジェクト ID を再利用するには、最初に既存のプロジェクトを復旧するか、 --purgeで強制的にハード削除するか、保持期間の有効期限が切れるのを待ちます。
7 日間のリテンション期間が経過する前に論理的に削除されたプロジェクトを復旧するには、CLI または API を使用します。
Tip
運用プロジェクトが誤って削除されないようにするには、バンドル内のlifecycle リソースにpostgres_projects ブロックを追加します。
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」を参照してください。
permissions リソースの [postgres_projects] フィールドを使用して、プロジェクトのアクセス許可を宣言します。 各エントリは、ユーザー、グループ、またはサービス プリンシパルにアクセス許可レベルを付与します。
postgres_projects:
my_project:
project_id: my-project
permissions:
- service_principal_name: <sp-application-id>
level: CAN_MANAGE
アクセス許可 API、CLI、または SDK を使用して、アクセス許可を個別に管理することもできます。
