Modes de déploiement des Declarative Automation Bundles

Cette page décrit la syntaxe des modes de déploiement des Declarative Automation Bundles. Les Bundles permettent la gestion programmatique des workflows Databricks. Consultez Que sont les Declarative Automation Bundles ?

Dans les workflows CI/CD, les développeurs codent, testent, déploient et exécutent généralement des solutions à différentes phases, ou modes . Par exemple, l'ensemble de modes le plus simple inclut un mode développement pour la validation en pré-production, suivi d'un mode production pour les livrables validés. Declarative Automation Bundles fournit un ensemble facultatif de comportements par default qui correspondent à chacun de ces modes.

Les modes de déploiement sont facultatifs. Vous pouvez déployer des bundles sans définir de mode ou configurer presets. Les modes de déploiement sont un moyen pratique d'appliquer un ensemble de paramètres couramment utilisés à la fois.

Mode de développement

Pour déployer votre bundle en mode développement, ajoutez le mappage mode, défini sur development, à la cible prévue. Voir le mappage des cibles de configuration du bundle. Par exemple, cette cible nommée dev est traitée comme une cible de développement :

YAML

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, qui peuvent être personnalisés à l'aide de prédéfinitions:

• Préfixe toutes les Ressources qui ne sont pas déployées sous forme de fichiers ou de Notebooks avec le préfixe [dev ${workspace.current_user.short_name}] et étiquette chaque Job et pipeline déployé avec un tag Databricks dev.
• Marque toutes les Lakeflow pipelines déployées comme development: true.
• Permet l'utilisation de --cluster-id <cluster-id> dans les appels associés à la commande bundle deploy, ce qui remplace toutes les définitions de cluster existantes qui sont déjà spécifiées dans le fichier de configuration de 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, sur l'ID du cluster à utiliser.
• Met en pause toutes les planifications et tous les Trigger sur les Ressources déployées, telles que les Job ou les moniteurs de qualité. Reprenez les planifications et les Trigger d'un Job individuel en définissant schedule.pause_status sur UNPAUSED.
• Permet les exécutions simultanées sur tous les Jobs déployés pour une itération plus rapide. Désactivez les exécutions simultanées pour un job individuel en définissant max_concurrent_runs sur 1.
• Désactive le verrouillage de déploiement pour une itération plus rapide. Ce verrou empêche les conflits de déploiement qui sont peu probables en mode de développement. Réactivez le verrou en définissant bundle.deployment.lock.enabled sur true.

Mode de production

Pour déployer votre bundle en mode production, ajoutez le mappage mode, défini sur production, à la cible prévue. Voir le mappage des cibles de configuration du bundle. Par exemple, cette cible nommée prod est traitée comme une cible de production :

YAML

targets:
  prod:
    mode: production

Le déploiement d’une cible en mode production en exécutant la commande databricks bundle deploy -t <target-name> met en œuvre les comportements suivants :

• Valide que tous les LakeFlow Pipelines déployés associés sont marqués comme development: false.

• Valide que la Branch Git actuelle est égale à la Branch Git spécifiée dans la cible. La spécification d'une branch Git dans la cible est facultative et peut être effectuée avec une propriété git supplémentaire comme suit :

  YAML

  git:
    branch: main

  Cette validation peut être remplacée en spécifiant --force lors du déploiement.

• Databricks vous recommande d'utiliser des Service Principal pour les déploiements de production. Vous pouvez appliquer cela en définissant run_as sur un Service Principal. Consultez Services principaux et Spécifier une identité d'exécution pour un workflow Declarative Automation Bundles. Si vous n'utilisez pas de service principals, veuillez noter les comportements supplémentaires suivants :

  • Vérifie 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 quelles identités disposent d'autorisations spécifiques pour les déploiements.

• Contrairement au comportement précédent pour définir le mappage mode sur development, la définition du mappage mode sur production ne permet pas de remplacer les définitions de cluster existantes spécifiées dans le fichier de configuration de bundle associé, par exemple en utilisant l'option --compute-id <cluster-id> ou le mappage compute_id.

Préréglages personnalisés

Les Bundles d'Automatisation Déclarative prennent en charge des préréglages configurables pour les cibles, ce qui vous permet de personnaliser les comportements des cibles. Pour les préréglages disponibles, consultez la référence de configuration.

remarque

À moins qu'une exception ne soit spécifiée pour un préréglage, si mode et presets sont définis, les préréglages remplacent le comportement du mode default, et les paramètres des Ressources individuelles remplacent les préréglages. Par exemple :

• Si le max_concurrent_runs pour un job est de 10, mais que le préréglage jobs_max_concurrent_runs est défini sur 20, le nombre maximal d’exécutions simultanées du job est de 10.
• Si un planning est défini sur UNPAUSED, mais que le préréglage trigger_pause_status est défini sur PAUSED, le planning sera relancé.

L'exemple suivant montre une configuration de préréglages personnalisés pour la cible nommée dev:

YAML

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