Modes de déploiement du pack de ressources Databricks

Cet article décrit la syntaxe des modes de déploiement databricks Asset Bundle . Les bundles permettent la gestion par programmation des flux de travail Azure Databricks. Découvrez quelles sont les offres groupées de ressources Databricks ?

Dans les flux de travail CI/CD, les développeurs codent, testent, déploient et exécutent des solutions en différentes phases ou modes. Par exemple, l’ensemble de modes le plus simple inclut un mode de développement pour la validation de préproduction, suivi d’un mode de production pour les livrables validés. Les packs de ressources Databricks fournissent une collection facultative de comportements par défaut qui correspondent à chacun de ces modes. Pour utiliser ces comportements pour une cible spécifique, définissez mode ou configurez presets pour une cible dans le mappage de configuration targets. Pour plus d’informations sur targets, consultez le mappage des cibles de configuration des packs.

Mode de développement

Pour déployer votre ensemble en mode développement, commencez par ajouter le mappage mode, défini à development, vers la cible prévue. Par exemple, cette cible nommée dev est traitée comme une cible de développement uniquement :

targets:
  dev:
    mode: development

Le déploiement d’une cible en mode développement en exécutant la databricks bundle deploy -t <target-name> commande implémente les comportements suivants, qui peuvent être personnalisés à l’aide de présélections :

Ajoute le préfixe [dev ${workspace.current_user.short_name}] à toutes les ressources qui ne sont pas déployées en tant que fichiers ou notebooks, et place une étiquette Azure Databricks dev sur chaque travail et chaque pipeline déployé.
Marque tous les pipelines déclaratifs Lakeflow Spark déployés en tant que development: true.
Permet l'utilisation de --cluster-id <cluster-id> dans les appels associés à la commande bundle deploy, qui remplacera toutes et chacune des définitions de cluster existantes déjà spécifiées dans le fichier de configuration du bundle associé. Au lieu d’utiliser --cluster-id <cluster-id> dans les appels associés à la commande bundle deploy, vous pouvez définir le mappage cluster_id ici, ou en tant que mappage enfant du mappage bundle, à l’ID du cluster à utiliser.
Met en suspens toutes les planifications et tous les déclencheurs sur les ressources déployées, comme les travaux ou les moniteurs de qualité. Définissez schedule.pause_status sur UNPAUSED pour annuler la mise en suspens des planifications et des déclencheurs d’un travail individuel.
Active les exécutions simultanées sur tous les travaux déployés afin d'accélérer les itérations. Définissez max_concurrent_runs sur 1 pour désactiver les exécutions simultanées d’un travail individuel.
Désactive le verrou de déploiement pour accélérer l’itération. Ce verrou empêche les conflits de déploiement qui sont peu susceptibles de se produire en mode de développement. Définissez bundle.deployment.lock.enabled sur true pour réactiver le verrou.

Mode de production

Pour déployer votre paquet en mode production, commencez par ajouter le mappage mode et le configurer en tant que production sur la cible prévue. Par exemple, cette cible nommée prod est traitée comme une cible de production :

targets:
  prod:
    mode: production

Le déploiement d’une cible de production en exécutant la commande databricks bundle deploy -t <target-name> implémente les comportements suivants :

Vérifie que tous les pipelines déclaratifs Lakeflow Spark déployés sont marqués development: false.
Valide que la branche GIT actuelle est égale à la branche GIT spécifiée dans la cible. La spécification d'une branche GIT dans la cible est facultative et peut être effectuée avec une propriété supplémentaire git comme suit :
```
git:
  branch: main
```
Cette validation peut être remplacée en spécifiant --force lors du déploiement.
Databricks vous recommande d’utiliser des principaux de service pour les déploiements de production. Vous pouvez l’appliquer en paramétrant run_as sur un principal de service. Consultez Principaux de service et Spécifier une identité d’exécution pour un workflow Packs de ressources Databricks. Si vous n’utilisez pas des principaux de service, prenez note des comportements supplémentaires suivants :
- Valide que les mappages artifact_path, file_path, root_path ou state_path ne sont pas remplacés par un utilisateur spécifique.
- Vérifie que les mappages run_as et permissions sont spécifiés pour clarifier les identités qui ont des autorisations spécifiques pour les déploiements.
Contrairement au comportement précédent visant à définir le mappage mode sur development, la définition du mappage mode sur production ne permet de remplacer aucune des définitions de cluster existantes spécifiées dans le fichier de configuration du pack associé, par exemple en utilisant l’option --compute-id <cluster-id> ou le mappage compute_id.

Préréglages personnalisés

Databricks Asset Bundles prend en charge les présélections configurables pour les cibles, ce qui vous permet de personnaliser les comportements des cibles. Les présélections disponibles sont répertoriées dans le tableau suivant :

Remarque

Sauf si une exception est spécifiée dans le tableau ci-dessous, si les deux mode et presets sont définies, les présélections remplacent le comportement du mode par défaut et les paramètres des ressources individuelles remplacent les présélections. Par exemple, si la max_concurrent_runs valeur pour un travail est 10, mais que le jobs_max_concurrent_runs préréglage est défini sur 20, le nombre maximal d'exécution simultanée du travail est de 10.

Prédéfini	Descriptif
`artifacts_dynamic_version`	Indique s’il faut mettre à jour dynamiquement la version des `whl` artefacts pendant le déploiement. Les valeurs valides sont `true` ou `false`. Si le paramètre de configuration de niveau supérieur artifacts.dynamic_version est spécifié, il remplace cette présélection.
`jobs_max_concurrent_runs`	Nombre maximal d’exécutions simultanées autorisées pour les travaux.
`name_prefix`	Chaîne de préfixe à ajouter aux noms de ressources.
`pipelines_development`	Indique si le pipeline est en mode développement. Les valeurs valides sont `true` ou `false`.
`source_linked_deployment`	Réservé pour une utilisation ultérieure. Indique si les ressources créées pendant le déploiement pointent vers des fichiers sources dans l’espace de travail au lieu de leurs copies d’espace de travail.
`tags`	Un ensemble de balises clé-valeur qui s’appliquent à toutes les ressources prenant en charge les balises, y compris les tâches et les expériences. Les paquets d'actifs Databricks ne prennent pas en charge les balises pour la ressource `schema`.
`trigger_pause_status`	Un statut de pause à appliquer à tous les déclencheurs et à toutes les planifications. Les valeurs valides sont `PAUSED` ou `UNPAUSED`. Si `mode` est défini à `development`, `trigger_pause_status` est toujours `PAUSED`.

L’exemple suivant montre une configuration de préréglages personnalisés pour l’objectif nommé dev :

targets:
  dev:
    presets:
      name_prefix: 'testing_' # prefix all resource names with testing_
      pipelines_development: true # set development to true for pipelines
      trigger_pause_status: PAUSED # set pause_status to PAUSED for all triggers and schedules
      jobs_max_concurrent_runs: 10 # set max_concurrent runs to 10 for all jobs
      tags:
        department: finance

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-12-11