Partager via

Modes de déploiement du pack de ressources Databricks

  • Article

Cet article décrit la syntaxe des modes de déploiement du pack de ressources Databricks. Les bundles permettent la gestion par programmation des flux de travail Azure Databricks. Consultez Que sont les packs de ressources Databricks ?

Dans les flux de travail CI/CD, les développeurs codent, testent, déploient et exécutent généralement des solutions dans différentes phases ou modes. Par exemple, l'ensemble de modes le plus simple inclut un mode développement pour la validation préproduction, suivi d'un mode 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 en savoir plus sur targets, consultez le mappage des cibles de configuration de regroupement.

Mode de développement

Pour déployer votre pack en mode développement, commencez par ajouter le mappage mode et le définir sur 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 commande databricks bundle deploy -t <target-name> implémente les comportements suivants. Ces comportements 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 tâche et pipeline déployé.
  • Marque tous les pipelines Delta Live Tables déployés associés comme development: true. Reportez-vous à Utiliser le mode de développement pour exécuter des mises à jour de pipeline.
  • Permet l'utilisation de --compute-id <cluster-id> d'appels associés à la commande bundle deploy, qui remplacent toutes les définitions de cluster existantes déjà spécifiées dans le fichier de configuration du bundle associé. Au lieu d’utiliser --compute-id <cluster-id> dans les appels associés à la commande bundle deploy, vous pouvez définir le mappage compute_id ici, ou en tant que mappage enfant du mappage bundle, à l’ID du cluster à utiliser.
  • Interrompt toutes les planifications et tous les déclencheurs sur les ressources déployées, telles que les travaux ou les moniteurs de qualité. Définissez schedule.pause_status sur UNPAUSED pour annuler la suspension des planifications et des déclencheurs d’un travail individuel.
  • Active les exécutions simultanées sur tous les travaux déployés pour accélérer l’itération. 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 production

Pour déployer votre pack en mode production, commencez par ajouter le mappage mode et le définir sur production vers à 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 :

  • Valide que tous les pipelines Delta Live Tables déployés associés sont marqués comme 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 Gérer les principaux de service et Spécifier une identité d’exécution pour un Workflowl Offres groupées d’actifs 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.
    • Valide 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 :

Préréglage Description
name_prefix La chaîne de préfixe à ajouter aux noms des ressources.
pipelines_development Indique si le pipeline est en mode Développement ou non. Les valeurs valides sont true ou false.
trigger_pause_status Un statut de pause à appliquer à tous les déclencheurs et à toutes les planifications. Les valeurs valides sont PAUSED ou UNPAUSED.
jobs_max_concurrent_runs Nombre maximum d’exécutions simultanées autorisées pour les projets.
tags Un jeu de clés : des balises de valeur qui s’appliquent à toutes les ressources qui prennent en charge les balises. Ces ressources comprennent les projets et les expériences. Les bundles de ressources Databricks ne prennent pas en charge les balises pour la ressource schema.

Remarque

Si mode et presets sont tous deux définis, les préréglages remplacent le comportement du mode par défaut et les paramètres des ressources individuelles remplacent les préréglages. Par exemple, si une planification est définie sur UNPAUSED, mais que la présélection trigger_pause_status est définie sur PAUSED, alors la planification reprend la réception du courrier.

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