Migrer vers le moteur de déploiement direct

Important

Cette fonctionnalité est expérimentale.

Databricks Asset Bundles a été initialement basé sur le fournisseur Databricks Terraform pour gérer les déploiements. Toutefois, dans un effort de déplacement de cette dépendance, Databricks CLI version 0.279.0 et ultérieure prend en charge deux moteurs de déploiement différents : terraform et direct. Le moteur de déploiement direct ne dépend pas de Terraform et deviendra bientôt la valeur par défaut. Le moteur de déploiement Terraform sera ultérieurement abandonné.

Quels sont les avantages du déploiement direct ?

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

• Aucune exigence de télécharger Terraform et terraform-provider-databricks avant le déploiement
• Évite les problèmes liés aux pare-feu, aux proxys et aux registres de fournisseurs personnalisés
• Différences détaillées des modifications disponibles à l’aide de bundle plan -o json
• Déploiement plus rapide
• Temps réduit pour libérer de nouvelles ressources groupées, car il n’est pas nécessaire de s’aligner sur la version du fournisseur Terraform

Comment 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.
• Pour les nouveaux bundles, déployez-les avec la variable d’environnement DATABRICKS_BUNDLE_ENGINE définie sur direct.

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 commande de migration de déploiement groupé 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
   

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

     rm .databricks/bundle/my_target/resources.json
     

   • Si la vérification a réussi, 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. Au lieu de cela, définissez la variable d’environnement DATABRICKS_BUNDLE_ENGINE et déployez :

DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target

Quelles sont les modifications apportées au moteur de déploiement direct ?

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.

recherche de valeurs de substitution de $resources

L’utilisation la plus courante de substitution $resources consiste à résoudre les ID (par exemple, $resources.jobs.my_job.id), qui se comportent de façon identique entre le moteur de déploiement Terraform et le moteur de déploiement direct.

Toutefois, la résolution de la $resources substitution dans le moteur de déploiement direct (par exemple, $resources.pipelines.my_pipeline.name) 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 de résolution utilisé est disponible 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.