Gérer Lakebase avec les Bundles d'automatisation déclaratifs
Ce guide vous aide à démarrer avec les Declarative Automation Bundles pour gérer les ressources Lakebase en utilisant l'infrastructure en tant que code. Vous allez créer un projet Lakebase, ajouter une Branch de développement et un Endpoint, et apprendre à gérer ces ressources de manière déclarative. Il s'agit d'un workflow typique pour la gestion programmatique des ressources Databricks dans les environnements de développement et de test.
Pour la référence complète des ressources de bundle et toutes les options de configuration disponibles, consultez ressources de bundle.
postgres_projects est la Ressource DABs pour l'Autoscaling Lakebase. Si vous avez une automatisation existante utilisant database_instances, elle continue de fonctionner, mais les nouvelles instances sont créées en tant que projets Lakebase Autoscaling au lieu d'instances Lakebase provisionnées. Voir Autoscaling by default.
Prérequis
Avant de commencer, vous avez besoin de :
- Databricks CLI version 0,287.0 ou supérieure. Pour vérifier votre version installée, exécutez
databricks -v. Pour installer la CLI Databricks, consultez Installer ou mettre à jour la CLI Databricks. Les ressourcespostgres_catalogsetpostgres_synced_tablesnécessitent la version 1.0.0 ou supérieure de la CLI Databricks. - Authentification configurée pour votre workspace Databricks. Ce guide utilise l'authentification OAuth utilisateur à machine (U2M). Voir Configurer l'accès à votre workspace dans le didacticiel Databricks CLI.
- Autorisation CAN MANAGE sur les projets Lakebase. Consultez Gérer les autorisations du projet.
Hiérarchie des ressources
Les ressources Lakebase suivent une hiérarchie parent-enfant : vous créez les ressources parentes avant les enfants. Pour le modèle de ressources complet (projets, branches, computes, bases de données, et plus), consultez les Projets.
Ordre des opérations pour ce guide : Projet → Branch → Endpoint
1. Créer une configuration de bundle
Initialiser un bundle à l'aide du Template minimal par default. Cela crée un dossier de bundle avec un databricks.yml et récupère votre configuration CLI (y compris l'hôte du Workspace).
databricks bundle init default-minimal
Lorsque vous y êtes invité, saisissez un nom pour votre projet de bundle (par exemple, lakebase-bundle). La CLI crée un répertoire avec ce nom. Passer au répertoire du bundle :
cd lakebase-bundle
Modifiez votre fichier databricks.yml pour définir un projet, une Branch et un Endpoint Lakebase. Ajoutez ou mettez à jour la section resources (et le nom du bundle si vous le souhaitez). Par exemple :
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 est le default pour les nouveaux projets. Pour autoriser les rôles Postgres natifs à se connecter avec des mots de passe statiques, définissez-le sur true. Consultez Gérer les connexions de mot de passe.
Par default, la suppression d’un projet Lakebase le supprime logiquement. Le projet est conservé pendant 7 jours, après quoi Lakebase le supprime définitivement. Pour supprimer définitivement le projet immédiatement, passez --purge à la commande delete-project CLI (pas bundle destroy, qui n'a pas d'indicateur --purge). Voir l'Étape 6 pour plus de détails.
À propos des endpoints : Quand vous créez un projet Lakebase, Databricks provisionne automatiquement une Branch de production default avec un Endpoint en lecture-écriture. Cependant, toutes les Branches supplémentaires que vous créez (comme la Branch de dev ci-dessus) doivent avoir leurs Endpoints explicitement définis dans la configuration de votre bundle.
Les valeurs project_id, branch_id et endpoint_id doivent suivre les règles de nommage des ressources (par exemple, de 1 à 63 caractères, lettres minuscules, chiffres et tirets).
2. Valider le paquet
Vérifiez si la configuration du bundle est valide :
databricks bundle validate
Si un résumé de la configuration du bundle est renvoyé, la validation a réussi. Si des erreurs sont retournées, corrigez les erreurs et répétez cette étape. Voir databricks bundle validate.
3. Déployez le bundle
Déployer le projet Lakebase dans votre workspace Databricks :
databricks bundle deploy
Ceci crée :
- Un projet Lakebase nommé « my-app »
- Une Branch de production par default avec un endpoint en lecture-écriture (créée automatiquement)
- Une branch de développement nommée « dev »
- Un Endpoint principal pour la Branch de développement avec dimensionnement automatique de 0,5 à 2 CU
Voir déploiement de bundles Databricks.
4. Vérifiez le déploiement
Confirmez que les ressources ont été créées :
- Dans votre Workspace Databricks, naviguez vers Lakebase → Projects .
- Cliquez sur **Mon Application**.
- Vérifiez que vous voyez deux Branch :
- production (default) - Créé automatiquement avec un compute principal de 1 CU
- dev - Créé par votre bundle avec une puissance de compute autoscaling de 0,5-2 CU
5e. Mettre à jour la configuration
Pour modifier vos ressources, mettez à jour le fichier databricks.yml et redéployez :
databricks bundle validate
databricks bundle deploy
Le bundle mettra à jour uniquement les ressources qui ont changé.
6. Nettoyage des ressources
Lorsque vous avez terminé avec le projet Lakebase, vous pouvez le supprimer pour libérer des ressources.
Utilisez databricks bundle destroy pour libérer les ressources créées par le bundle :
databricks bundle destroy
Cela entraîne la suppression du projet et de toutes ses Branch, Endpoint et bases de données, et cela efface l'état de déploiement du bundle. Par default, le projet est supprimé de façon réversible et conservé pendant 7 jours, puis Lakebase le supprime définitivement. Vous pouvez récupérer le projet pendant la période de rétention.
Pour supprimer uniquement le projet immédiatement, sans supprimer les autres ressources du bundle ni attendre la période de rétention, utilisez la CLI Databricks avec --purge:
databricks postgres delete-project projects/my-app --purge
--purge supprime définitivement le projet immédiatement au lieu de le supprimer logiquement. La suppression du projet de cette manière ne met pas à jour l’état de déploiement du bundle.
La création d'un nouveau projet avec le même project_id qu'un projet supprimé logiquement pendant la période de rétention de 7 jours échoue. Pour réutiliser le même ID de projet, récupérez d'abord le projet existant, forcez une suppression définitive avec --purge ou attendez l'expiration de la période de rétention.
Pour récupérer un projet supprimé de manière réversible avant l'expiration de la période de rétention de 7 jours, utilisez la CLI ou l'API.
Pour éviter la suppression accidentelle d’un projet de production, ajoutez un bloc lifecycle à la ressource postgres_projects de votre bundle :
resources:
postgres_projects:
my_app:
project_id: 'my-app'
lifecycle:
prevent_destroy: true
Cela entraîne l'échec des opérations de bundle avec une erreur si elles tentent de détruire la ressource. Supprimez prevent_destroy: true lorsque vous souhaitez délibérément supprimer le projet.
Substitutions de ressources
La configuration du bundle utilise des substitutions pour référencer les ressources :
${resources.postgres_projects.my_app.id}- Fait référence au nom de la ressource du projet Lakebase${resources.postgres_branches.dev_branch.id}- Fait référence au nom de la ressource de la branch
Cela garantit un ordonnancement correct des dépendances lors du déploiement. Pour plus d'informations sur les substitutions de bundle, voir Substitutions.
Ressources disponibles
Pour la liste complète des ressources Lakebase prises en charge dans les bundles et leurs options de configuration, reportez-vous aux ressources du bundle (postgres_projects, postgres_branches, postgres_endpoints, postgres_catalogs, postgres_synced_tables, postgres_roles, postgres_databases).
Gérer les autorisations de projet
Les projets Lakebase prennent en charge les niveaux d'autorisation CAN_CREATE, CAN_USE et CAN_MANAGE. Tous les utilisateurs du Workspace disposent de CAN_CREATE par default, vous n'attribuez donc que CAN_USE ou CAN_MANAGE dans un bundle. Pour plus de détails sur chaque niveau, consultez les ACLs de projet Lakebase.
Déclarez les autorisations de projet à l'aide du champ permissions sur une ressource postgres_projects. Chaque entrée accorde un niveau d'autorisation à un utilisateur, un groupe ou un service principal :
postgres_projects:
my_project:
project_id: my-project
permissions:
- service_principal_name: <sp-application-id>
level: CAN_MANAGE
Vous pouvez également gérer les autorisations séparément à l'aide de l'API, CLI ou SDK des autorisations.