Partager via


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. Pour connaître les présélections disponibles, consultez la référence de configuration.

Remarque

Sauf si une exception est spécifiée pour une présélection, 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 de 10, mais que la jobs_max_concurrent_runs présélection est définie sur 20, le nombre maximal d’exécutions simultanées est de 10.
  • Si une planification est définie sur UNPAUSED, mais que la présélection trigger_pause_status est définie sur PAUSED, la planification sera réactivée.

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