Migrer vers le moteur de déploiement direct

Les offres groupées d'automatisation déclaratives ont été initialement construites sur le fournisseur Databricks Terraform pour gérer les déploiements. Toutefois, Databricks CLI versions 0.279.0 et ultérieures prennent en charge deux moteurs de déploiement différents : terraform et direct. Le moteur de déploiement direct offre des avantages significatifs et ne dépend pas de Terraform.

Les nouveaux bundles créés à l’aide de l’interface CLI Databricks version 1.3.0 et ultérieure utilisent par défaut le moteur de déploiement direct. Les bundles créés à l’aide de versions antérieures de l’interface CLI peuvent être migrés du moteur de déploiement Terraform vers le moteur de déploiement direct à l’aide des étapes de migration décrites dans cette page.

Important

Databricks recommande de migrer vers le moteur direct, car le moteur de déploiement Terraform sera bientôt déprécié et le moteur de déploiement direct deviendra la valeur par défaut. Consultez Les bundles d’automatisation déclarative utiliseront bientôt par défaut le moteur de déploiement direct.

Avantages du déploiement direct

Le nouveau moteur de déploiement direct utilise le Kit de développement logiciel (SDK) Databricks Go et présente les avantages suivants :

  • Déploiements plus rapides : les déploiements groupés sont jusqu’à 40% plus rapides.
  • Validation et planification plus performantes et détaillées : comparaison détaillée des modifications à l’aide de rapports bundle plan -o json fournissant, pour chaque champ, des détails expliquant ce qui a déclenché chaque action.
  • Plans réutilisables : bundle deploy --plan plan.json exécute un plan créé précédemment, garantissant que seules les actions approuvées atteignent la production et permettant des déploiements plus rapides, car le calcul du plan est sauté.
  • Configuration simple : Les problèmes liés aux pare-feu, aux proxys et aux registres de fournisseurs personnalisés sont évités.
  • Autres ressources : des ressources supplémentaires telles que des catalogues, des emplacements externes, des points de terminaison de recherche IA et des espaces Genie sont prises en charge.
  • Dossiers immuables : les ressources peuvent éventuellement être déployées dans un dossier immuable, en lecture seule, pour la protection contre les falsifications et la cohérence du déploiement. Voir immutable_folder.

Commencer à utiliser le déploiement direct

Pour commencer à utiliser le nouveau moteur de déploiement direct :

  • Pour les offres groupées existantes, migrez-les à l’aide de databricks bundle deployment migrate. Consultez Migrer un bundle existant.
  • Pour les bundles nouveaux ou existants, définissez engine: direct dans la configuration de votre bundle, ou définissez la variable d’environnement DATABRICKS_BUNDLE_ENGINE sur direct. Consultez Déployer directement un nouveau bundle.

Migrer un bundle existant

Le moteur de déploiement direct utilise son propre fichier d’état JSON. Le schéma est différent du fichier d’état JSON Terraform. La bundle deployment migrate commande convertit le fichier d’état Terrform (terraform.tfstate) en fichier d’état de déploiement direct (resources.json). La commande lit les identifiants du déploiement existant.

  1. Effectuez un déploiement complet avec Terraform :

    databricks bundle deploy -t my_target

  2. Migrez le déploiement :

    databricks bundle deployment migrate -t my_target

  3. Vérifiez que la migration a réussi. La databricks bundle plan commande doit réussir et elle ne doit pas afficher de modifications.

    databricks bundle plan -t my_target

    Note

    Le plan peut signaler des modifications sur les ressources même lorsque votre configuration locale correspond à la ressource déployée. Cela peut se produire, car le fichier d’état Terraform précédent contient des champs de métadonnées que la plateforme remplit après le déploiement, qui ne sont pas présents dans votre configuration de bundle. Ces différences ne sont pas des dérives de configuration réelles et ne modifient pas le comportement du travail. Le moteur direct les réconcilie lors du prochain bundle deploy. Pour plus d’informations sur la façon dont le moteur direct calcule les différences, consultez le calcul des différences d’état des ressources.

    • Si la vérification échoue, supprimez le nouveau fichier d’état :

      rm .databricks/bundle/my_target/resources.json

    • Si la vérification réussit, déployez le bundle pour synchroniser le fichier d’état sur l’espace de travail :

      databricks bundle deploy -t my_target

Déployer directement un nouveau bundle

La bundle migrate commande ne fonctionne pas sur les bundles qui n’ont jamais été déployés, car il n’existe aucun fichier d’état. À la place, effectuez l’une des opérations suivantes :

  • Définissez bundle.engine dans votre databricks.yml :

    bundle:
  engine: direct

  • Définissez la variable d’environnement DATABRICKS_BUNDLE_ENGINE et déployez :

    DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target

Si la configuration et la variable d’environnement sont définies, la configuration est prioritaire.

Comparaison du moteur de déploiement

Le nouveau moteur de déploiement direct se comporte principalement comme le moteur de déploiement Terrform, mais il existe des différences.

Calcul des différences d’état des ressources

Contrairement à Terraform qui conserve un état de ressource unique (une combinaison de configuration locale et d’état distant), le nouveau moteur conserve ces paramètres distincts et enregistre uniquement la configuration locale dans son fichier d’état.

Le calcul des différences d’état des ressources est effectué en deux étapes :

  1. La configuration du bundle local est comparée à la configuration d’instantané utilisée pour le déploiement le plus récent. L’état distant ne joue aucun rôle.
  2. L’état distant est comparé à la configuration d'état instantané utilisée pour le déploiement le plus récent.

Le résultat est que :

  • databricks.yml les modifications de ressources ne sont jamais ignorées et déclenchent toujours une mise à jour.
  • Les champs de ressource non gérés par l’implémentation ne déclenchent pas d’erreur de résultat incohérent. Ces ressources sont déployées avec succès par le moteur direct, mais cela peut entraîner une dérive. Les ressources déployées sont mises à jour pendant le plan ou le déploiement suivant.

Paramètres de configuration supprimés

Les deux moteurs gèrent les paramètres que vous supprimez de votre configuration de bundle différemment :

  • Avec le moteur Terraform, si vous supprimez un champ renseigné de votre databricks.yml, la valeur correspondante reste inchangée dans la plateforme. Terraform gère uniquement les champs explicitement présents dans la configuration. Par conséquent, un champ supprimé conserve la valeur qu’il avait au moment du dernier déploiement.
  • Avec le moteur direct, la suppression d’un champ configuré de votre databricks.yml réinitialise la valeur sur celle par défaut de la ressource. Étant donné que le moteur direct compare votre configuration locale à l’instantané précédent, un champ qui n’est plus présent est traité comme une modification et la ressource est mise à jour avec sa valeur par défaut lors du déploiement suivant.

Pour conserver une valeur, définissez-la explicitement dans votre configuration plutôt que de vous appuyer sur la valeur précédemment déployée.

Recherche de substitution de ressources

Les substitutions de ressources sont disponibles pour la résolution des ID de ressource, par exemple ${resources.jobs.my_job.id}. Voir Substitutions. La résolution des substitutions de ressources dans le moteur de déploiement direct est effectuée en deux étapes :

  1. Les références pointant vers des champs présents dans la configuration locale sont résolues à la valeur fournie dans la configuration locale.
  2. Les références qui ne sont pas présentes dans la configuration locale sont résolues à partir de l’état distant. Il s’agit de l’état récupéré à l’aide de la requête appropriée GET pour une ressource donnée.

Le schéma utilisé pour résoudre une ${resource.*} substitution se trouve dans le fichier out.fields.txt. Les champs marqués comme ALL et STATE peuvent être utilisés pour la résolution locale. Les champs marqués comme ALL ou REMOTE peuvent être utilisés pour la résolution à distance.

Compatibilité des ressources

Les ressources suivantes nécessitent le moteur de déploiement direct et ne sont pas prises en charge avec le moteur de déploiement Terraform :

En outre, le lifecycle.started champ est disponible uniquement dans le moteur de déploiement direct, et uniquement pour apps, clusterset .sql_warehouses Lorsqu’elle est définie à true, elle déploie la ressource en mode démarré. Consultez le cycle de vie.

  • Last updated on