Le contenu de Databricks Voices est rédigé et publié par des employés de Databricks qui souhaitent partager leurs propres apprentissages et leurs connaissances sur Databricks. Ce contenu complète la documentation officielle du produit Databricks disponible dans les autres sections de ce site.
Azure DevOps avec des bundles d'automatisation déclaratifs : guide d'intégration étape par étape
L'établissement d'un processus CI/CD (intégration continue/déploiement continu) fiable est essentiel pour gérer efficacement le cycle de vie de vos charges de travail de données et d'IA dans Azure Databricks. Cependant, avec de nombreuses options de configuration et une plateforme en constante évolution, la grande question est : « Par où start ? » Ce blog complet simplifie la complexité pour présenter une approche CI/CD recommandée pour Azure Databricks.
Nous nous concentrons sur les meilleures pratiques les plus récentes qui prennent en charge une gouvernance forte avec un minimum de surcharge administrative, même lors de la prise en charge de plusieurs équipes dans une infrastructure partagée. Il est adapté aux développeurs qui aiment travailler dans l’interface utilisateur du Databricks Workspace, bien qu’il prenne également entièrement en charge les IDEs comme Visual Studio Code.
L'approche recommandée consiste à utiliser Declarative Automation Bundles (DAB ; anciennement connus sous le nom de Databricks Asset Bundles) pour le déploiement. Les bundles s'intègrent parfaitement avec les dossiers Git Databricks pour le contrôle de version, Azure DevOps pour l'automatisation et les connexions de service Azure DevOps pour la connectivité Databricks. À la fin de ce blog, je compare les connexions de service DevOps et les approches OIDC Databricks pour intégrer DevOps et Databricks à titre de référence.
Enfin, nous allons suivre une stratégie de branchement simple mais efficace basée sur le tronc dans DevOps. La staging sera déployée automatiquement après que les pull requests de la Branch de fonctionnalités auront été approuvées et Merge dans la branche principale. Le déploiement en production à partir de la branche principale sera conditionné par la réussite du déploiement en staging et nécessitera une étape d’approbation supplémentaire que nous implémenterons.
Ce blog couvre un large éventail de sujets, mais en vous guidant vers les choix optimaux, il vous fera gagner un temps et des efforts considérables à long terme. Le contenu est divisé en trois parties :
- Aligner vos exigences en matière d'infrastructure et de gouvernance
- Mise en place d’un processus de développement de bundles avec version
- Configuration d'un pipeline Azure DevOps pour le déploiement sur la staging et la production
Partie 1 : Aligner votre infrastructure et les exigences de gouvernance
Chaque organisation doit décider quel niveau de séparation et d'organisation est requis pour les workspaces Databricks, les environnements de déploiement, Unity Catalog, les projets DevOps et les repositories Git. Il n’y a pas de réponse unique adaptée à toutes les organisations, et nous ne pouvons qu’effleurer ces considérations avant de passer au sujet de cet article.
Rubrique | Considération | Pour cet article |
|---|---|---|
Environnements | Trois est courant, mais certains peuvent en utiliser deux, et d'autres quatre ou plus. | Nous utiliserons : dev , staging et prod . |
Workspace Databricks | En général, les Workspace correspondent aux environnements. Les grandes organisations peuvent également organiser leurs unités commerciales dans des Workspace séparés. L'un des avantages de disposer de trois Workspace est que l'administrateur du Workspace peut librement activer les fonctionnalités en préversion et d'autres paramètres dans le workspace « dev » en ayant la certitude de ne pas affecter les charges de travail de staging et de production. | Nous allons montrer comment plusieurs équipes indépendantes peuvent utiliser deux Workspace ( |
Catalogues | Il existe de nombreuses stratégies pour organiser vos données dans Unity Catalog. | Nous nommerons nos catalogues |
Projets Azure DevOps | Les petites organisations utilisent un seul projet pour simplifier la configuration, tandis que les grandes organisations peuvent avoir besoin de plusieurs projets pour définir des limites strictes entre les repository de code et les approbateurs. | Nous utiliserons un projet appelé |
repository Git | Il existe des avantages et des inconvénients pour un seul « mono repository » par rapport à plusieurs repos par équipe ou par domaine. | Comme nous avons déjà sélectionné un projet DevOps basé sur des équipes, nous utiliserons son unique dépôt default . |
Remarque : je vous encourage à suivre l'exemple et la stratégie organisationnelle décrits dans ce blog pour voir comment l'ensemble du processus fonctionne efficacement. Vous pourrez ensuite réfléchir aux enseignements tirés et aux différences potentielles en matière de gouvernance et d'organisation pour votre entreprise, puis apporter les changements nécessaires. Une fois ces choix effectués, examinons visuellement notre stratégie organisationnelle.
Au sein de notre organisation « d'entreprise » (BU1), l'équipe 2 gère les données RH, et tout le reste est géré par l'équipe 1. Ces deux équipes travailleront indépendamment dans nos Workspace bu1-dev et bu1-prod partagés. Pour que cela fonctionne bien, il est important de noter qu'une ou plusieurs personnes doivent avoir la confiance des deux équipes pour servir d'administrateurs de workspace. Si cela peut être organisé, la gestion de l'infrastructure est simplifiée ; sinon, les équipes 1 et 2 doivent être séparées dans leurs propres Workspace de développement/production.
Plus tard, une autre division (BU2) pourrait être acquise et partager le même répertoire Entra ID tout en choisissant d'avoir des Workspace et une infrastructure DevOps distincts. C'est très bien, et c'est la raison pour laquelle nous préfixerons nos noms de catalogue dans Unity Catalog (par exemple, bu1_dev, bu2_dev).
Nous adopterons l'approche « mono repo » dans chaque projet DevOps et organiserons davantage notre code à l'aide de Declarative Automation Bundles. Dans ce blog, nous utiliserons un seul bundle « Hello World » pour illustrer le fonctionnement des processus de développement et de CI/CD recommandés. En pratique, vous aurez de nombreux bundles pour un domaine de données donné (par exemple, la finance), et ceux-ci peuvent tous être versionnés dans le même référentiel. Nous utiliserons un seul pipeline DevOps pour les déploiements de staging et de production, mais vous pouvez choisir une stratégie de pipeline différente.
Partie 2 : mise en place d’un processus de développement de bundles versionnés
Les Bundles Databricks et les dossiers Git fonctionnent parfaitement avec Azure DevOps, vous préparant au succès dans votre processus CI/CD. C'est parti.
Configuration initiale d’Azure DevOps
C'est assez simple : il suffit de créer le projet Azure DevOps de l'équipe et d'initialiser le dépôt. Vous n'avez pas besoin de créer de Branch : nous utiliserons la main Branch intégrée et créerons nos feature Branch dans Databricks en utilisant l'UI d'intégration Git intégrée.
Créez votre projet, initialisez la branch principale, puis accédez au repo et copiez l’URL du repository dans votre presse-papiers pour l’étape suivante.
Créer un compte lié pour accéder au référentiel
Dans le workspace Databricks, chaque développeur crée son propre identifiant de compte lié Azure DevOps (Microsoft Entra) , ce qui lui permet de s’authentifier auprès du repository Git. Faites-le maintenant dans votre workspace « dev » sur la page Paramètres > Utilisateur > Comptes liés . Vous n’avez pas besoin de le faire dans votre workspace de production, car aucune intégration Git n’est nécessaire (DevOps enverra le code en production).
Créer un dossier Git qui pointe vers le repo
Dans son répertoire Personnel , chaque développeur crée son propre dossier Git qui pointe vers le repo de l’équipe. Cette étape est effectuée par chaque développeur une seule fois. Cliquez sur Créer > Dossier Git .
Collez l'URL du repo de votre projet Azure DevOps (elle doit être dans votre presse-papiers), puis cliquez sur Créer un dossier Git .
Vous remarquerez que les dossiers Git ont des propriétés spéciales dans l'interface utilisateur du Workspace, notamment ces deux boutons.
Cliquez sur Ouvrir dans l’éditeur et notez qu’un nouvel tab de navigateur s’ouvre avec votre dossier Git dans un nouveau mode de création « focalisé ». Nous en discuterons dans un instant.
Nous n’utiliserons pas cette vue pour le moment, alors fermez l’ tab du navigateur qui vient de s’ouvrir.
Cliquez maintenant sur le bouton Git Branch comme indiqué ci-dessous.
Dans l'interface utilisateur d'intégration Git, cliquez sur Créer une Branch , attribuez un nom à votre Branch de fonctionnalités (par exemple, features/initial_work_on_hello_world), puis cliquez sur Créer .
Cliquez sur le bouton « X » dans le coin supérieur droit de la boîte de dialogue d'intégration Git pour la fermer. À l’aide de vos identifiants Microsoft Entra, l’intégration Databricks Git a créé la branch dans votre Repo Azure DevOps et vous a basculé vers celle-ci dans l’interface utilisateur de Workspace, comme illustré ci-dessous.
Navigation dans l’interface utilisateur de workspace
À partir d’avril 2026, deux aperçus de l’interface utilisateur affecteront le comportement des menus présentés dans cet article. Demandez à votre administrateur de workspace d’aller sur Previews et de chercher « tree ». By default, le nouvel aperçu du contexte de « création » (le premier, ci-dessous) est activé, et la nouvelle arborescence du navigateur de fichiers ne l’est pas. Nous vous recommandons d’activer les deux afin de pouvoir suivre l’article et parce qu’ils facilitent tous deux le travail avec les dossiers Git et les bundles d’asset. Voici les Link de documentation pour référence :
- Contexte de création
- Vue arborescente de l’explorateur de fichiers
- Documentation générale de l’interface utilisateur de Workspace
Créer et déployer votre premier bundle sur « Dev »
Dans votre dossier Git, cliquez sur Créer , puis sur Bundle .
Il existe différentes manières d'organiser votre copie de développement des bundles dans votre dossier Git. Une liste plate de bundles, comme indiqué ci-dessous, fonctionne bien. Vous pouvez également créer des dossiers sous le dossier Git et organiser vos bundles à l'intérieur.
Pour les besoins de ce blog, saisissez un nom comme hello_world dans Nom du bundle et choisissez l'option Projet vide . Après avoir cliqué sur Créer , une liste de ressources complémentaires s'affiche pour votre bundle. Choisissez Ajouter une nouvelle définition de job et saisissez un titre de job comme Update Event Table .
Ne cliquez pas sur le bouton Ajouter et déployer ; à la place, cliquez sur la flèche vers le bas et choisissez Ajouter uniquement, déployer ultérieurement . Si vous avez cliqué par erreur sur Ajouter et déployer, ce n’est pas grave, mais vous avez déployé un job vers dev qui n’a encore rien à faire.
Ajoutez du code et configurez votre job
Ajoutons du code à notre projet pour voir le processus CI/CD en action. Pour les besoins de ce blog, vous pouvez download le Notebook Hello_World.ipynb à partir de cet emplacement, puis l'importer dans votre dossier de bundle comme indiqué ci-dessous.
Veillez à l’importer dans le dossier de bundle d'asset hello_world (pas le dossier des Ressources), comme illustré ci-dessous.
Tout en restant sur le fichier job.yml , décommentez les lignes 8 à 19 du fichier YAML du job en utilisant la combinaison de touches Basculer le commentaire de ligne (vous pouvez obtenir une liste des raccourcis clavier à partir du menu contextuel, comme illustré ci-dessous). Après avoir décommenté les lignes, effectuez les deux changements affichés en jaune. Sachez que les chemins sont sensibles à la casse. Vous avez renommé la première tâche de votre job et l'avez pointée vers le notebook que vous venez d'importer.
Ouvrez le notebook Hello_World et notez quelques éléments. La première cellule définit un widget appelé « catalog » sans default. Le notebook que vous avez importé a rendu le widget de catalogue en haut, mais il est vide, vous pouvez donc remplir le catalogue dans lequel vous souhaitez écrire. Pour ce laboratoire, nous allons créer un catalogue appelé bu1_dev.
Saisissez votre valeur pour le champ de widget « catalog » comme indiqué ci-dessous. Remarquez qu’il existe également un widget appelé « job_run_id » qui n’a pas de valeur par default.
Allez-y et exécutez le notebook maintenant en cliquant sur le bouton Tout exécuter en haut. Vous devriez utiliser le compute Serverless pour cet article afin de ne pas avoir à attendre le démarrage d'un cluster.
Notez dans la sortie et l’Explorateur de catalogue qu’une ligne a été insérée, incluant l’heure et l’utilisateur qui a exécuté le code.
Dans le Workspace, cliquez sur le bouton deploy (la fusée) du bundle, attendez que la liste Bundle Ressources ait fini de charger, puis cliquez sur le bouton Deploy .
Cliquez à nouveau sur Déployer pour confirmer que votre définition de Job mise à jour doit être déployée.
Félicitations ! Vous devriez voir un message indiquant que le déploiement sur votre cible de développement a réussi.
Cliquez sur Workspace dans la navigation latérale pour voir ce qui a été déployé et où.
Databricks déploie le bundle d’asset dans votre dossier Home/.bundle. Ceci est représenté par l’ environnement de déploiement de développement en bleu ci-dessous. À ce stade, rien n'est dans le contrôle de version Azure DevOps.
Cliquez sur Jobs et pipelines dans la navigation latérale.
Votre déploiement de bundle a aussi créé un job. Notez que le titre du job est préfixé par [dev your_user_id].
Ouvrez le job et cliquez sur le tab Tasks . Passez en revue les informations ci-dessous.
Les messages (1) et (4) indiquent que ce job a été créé par un déploiement de bundle et que vous ne devez pas modifier ce job dans l'interface utilisateur (vous pouvez le modifier, mais vos modifications seront effacées la prochaine fois que vous déploierez votre bundle). Le nom de votre tâche de notebook (2) correspond à ce que vous avez modifié dans le fichier Update Event Table.job.yml. Le chemin du notebook (3) que vous avez spécifié dans le fichier job.yml est utilisé. Le job est défini pour s'exécuter en tant que vous (5). Actuellement, aucun parameter de Job (6) n'est affiché – nous travaillerons sur ce point par la suite. Il y a un bouton Déconnecter de la source (7) dans l'interface utilisateur.
Le déploiement lié à la source est une fonctionnalité facultative du déploiement de bundle et est activé default pour le déploiement de développement. C’est une fonctionnalité pratique car votre dev Job fait référence au Notebook de votre Home/bu1-team1/hello_world folder Workspace dans l’espace de travail. Une copie n’est pas envoyée dans le dossier de déploiement de bundle pour le développement (Home/.bundle/hello_world). Ce qui est pratique avec le déploiement lié à la source en développement, c’est que vous pouvez apporter des corrections itératives à votre Notebook et réexécuter votre Job à partir de l’interface utilisateur des jobs sans avoir à redéployer votre bundle d’asset .
Revenez à l’tab Exécutions et cliquez sur le bouton Exécuter maintenant . Utilisez le compute de Job Serverless afin de ne pas avoir à attendre le start d’un cluster de jobs.
Le job échouera car le notebook ne peut pas trouver de valeur pour la variable de catalogue. Lorsque vous avez exécuté le Notebook manuellement, vous avez tapé une valeur dans le widget de catalogue, mais lorsque le Notebook a été exécuté à partir d’un job, le widget de catalogue était vide et aucune valeur default n’a été spécifiée dans la première cellule non plus.
Nous ne voulons pas de valeur default pour le catalogue, car nous avons l'intention d'exécuter ce Notebook dans les environnements de développement, de préproduction et de production. Nous voulons envoyer des noms de catalogue spécifiques au job en fonction de l'environnement dans lequel il s'exécute. Configurons cela ensuite.
Paramétrage du nom de catalogue transmis à votre notebook
Dans cette section, vous travaillerez avec deux fichiers que vous download dans un instant. Mais commençons par comprendre comment ils fonctionnent ensemble :
-
Configuration du bundle (databricks.yml) - Vous définirez une variable personnalisée catalog_var et des valeurs spécifiques à l’environnement pour celle-ci ( bu1_dev , bu1_stg et bu1_prd ). Cela impliquera également la définition de nos cibles d’environnement de déploiement (développement, préproduction et production).
-
Configuration du Job (job.yml) : vous définirez un catalogue de parameter de Job pour accepter la valeur de la variable de bundle lors du déploiement, et nous configurerons un base_parameter de tâche de Job afin que le parameter de Job soit disponible pour notre Notebook. Pour plus d'informations sur ces sujets, cliquez sur les liens derrière les termes ci-dessus. Visuellement, la connexion variable/parameter ressemble à ceci :
Comme vous pouvez le voir, le fichier de configuration du bundle (databricks.yml) contient des informations de configuration générales aux lignes 1 à 12 et des cibles d'environnement à partir de la ligne 14. Chaque cible (dev, staging et prod) définit les caractéristiques du bundle pour cet environnement. Cela inclut la manière d’accéder au workspace Databricks, les noms/valeurs de variables à transmettre et le mode de déploiement à utiliser pour l’environnement.
Nous définissons une variable de bundle catalog_var et lui attribuons la valeur bu1_dev lors du déploiement dans l’environnement cible « dev ». Nous lui affecterons la valeur bu1_stg pour l’environnement de préproduction, et ainsi de suite. Vous définissez vous-même ces objectifs environnementaux. Vous pouvez en avoir autant que vous le souhaitez et les nommer comme vous le souhaitez. Cependant, le nom de la cible du bundle doit correspondre à la valeur spécifiée dans votre pipeline Azure DevOps pour les étapes de validation et de déploiement du bundle, comme vous allez le voir.
Le paramètre de mode de déploiement a deux valeurs : développement et production. La cible dev utilise le mode développement, tandis que staging et prod utilisent le mode production. Le mode développement préfixe vos jobs déployés avec [dev <your_user_name>] afin qu’ils soient plus faciles à distinguer si vous et vos collègues travaillez sur des copies distinctes du même bundle/pipeline en dev. Le mode de développement permet également le déploiement lié au code source, comme décrit précédemment, ce qui facilite l’itération sur le câblage de votre bundle et le code de votre notebook. Voici une référence complète décrivant le comportement du paramètre mode: du bundle.
Pour vous faire gagner du temps, voici le code terminé pour l'exemple que nous suivons. Copiez-les dans vos fichiers Event Table Job.yml et databricks.yml.
Home/bu1-team1/hello_world/Ressources/Update Event Table.job.yml
Spécifiez votre e-mail dans la ligne surlignée ci-dessous.
Notez que le code inclut un deuxième parameter pour capturer l' ID d'exécution du Job afin que nous puissions l'écrire dans la table d'événements. La syntaxe {{job.run_id}} capture dynamiquement l'ID d'exécution. Nous l'ajouterons à la chaîne job_run_id_, que vous verrez lorsque ce parameter sera écrit dans la table. Vous pouvez modifier la définition du parameter et supprimer le préfixe si vous le souhaitez. Comme ce parameter est défini dynamiquement par le job, il n'est pas nécessaire de créer une variable de bundle pour lui comme vous l'avez fait avec catalog_var.
resources:
jobs:
Update_Event_Table:
name: Update Event Table
queue:
enabled: true
parameters:
- name: catalog
default: ${var.catalog_var}
- name: job_run_id
default: 'job_run_id_{{job.run_id}}'
tasks:
- task_key: notebook_task_1
notebook_task:
notebook_path: ../Hello_World.ipynb
base_parameters:
catalog: ${var.catalog_var}
job_run_id: 'job_run_id_{{job.run_id}}'
email_notifications:
on_failure:
- your_email@example.com
trigger:
periodic:
interval: 1
unit: DAYS
Accueil/bu1-team1/hello_world/databricks.yml
Modifiez les URLs du workspace pour qu'elles correspondent à votre environnement et changez les noms des catalogues si nécessaire. Notez que nous utilisons le même workspace pour le dev et la staging dans cet article, mais vous pouvez utiliser trois workspaces séparés pour le dev/staging/prod si vous le souhaitez. Effectuez simplement les modifications ci-dessous.
# Declarative Automation Bundle (DAB) configuration; more info here:
# https://docs.databricks.com/en/dev-tools/bundles/settings.html
bundle:
name: 'hello_world'
include:
- resources/*.yml
- resources/*/*.yml
# Define custom variables; more info here:
# https://docs.databricks.com/en/dev-tools/bundles/reference#variables
variables:
catalog_var:
description: Custom variable containing the target catalog
default: ''
targets:
# TODO - adjust the catalog names and workspace URLs to match your deployment
# The "dev" target used by the bundle deploy feature
dev:
mode: development
default: true
variables:
catalog_var: bu1_dev
workspace:
host: https://adb-###########.#.azuredatabricks.net
# The "staging" target used by Azure DevOps
staging:
mode: production
variables:
catalog_var: bu1_stg
workspace:
host: https://adb-###########.#.azuredatabricks.net
root_path: /Workspace/devops/staging/bu1-team1/.bundle/${bundle.name}
# The "prod" target used by Azure DevOps
prod:
mode: production
variables:
catalog_var: bu1_prd
workspace:
host: https://adb-###########.#.azuredatabricks.net
root_path: /Workspace/devops/prod/bu1-team1/.bundle/${bundle.name}
Après avoir mis à jour les URL de Workspace dans votre fichier databricks.yml, cliquez sur le bouton Recharger de votre navigateur web.
Cela est nécessaire car nous avons sourcé le fichier avec un texte d'espace réservé (##########) pour l'URL du Workspace, et l'interface utilisateur du bundle le détecte dès que vous effectuez la modification. Cela prête à confusion à l'étape suivante, car le système pensera qu'il n'y a pas de cibles valides pour le déploiement. Après avoir effectué vos modifications et rechargé l'interface utilisateur de Workspace dans votre navigateur Web, passez à l'étape suivante.
Cliquez sur le bouton Déployer du bundle, puis sur le menu déroulant Cible .
Notez le message indiquant que le déploiement sur d'autres Workspace n'est pas pris en charge. En fait, cela signifie que la fonctionnalité de déploiement de bundles est conçue uniquement pour déployer localement, sur le workspace dans lequel vous vous trouvez.
Nous n’utiliserons le bouton de déploiement de bundle que pour pousser localement le bundle vers notre cible de développement. Nous utiliserons Azure DevOps pour déployer nos bundles vers les environnements de staging et de production.
Appuyez sur la touche Échap (ESC) pour fermer le menu déroulant, puis cliquez sur le bouton Déployer .
Cliquez à nouveau sur Déployer et examinez les messages de sortie ci-dessous.
Une fois votre DAB déployé sur dev, allez sur votre page Jobs et cliquez sur le bouton d’exécution pour start votre Job. Une fois que vous l’avez start, vous pouvez cliquer sur votre Job et le voir s’exécuter.
Une fois l’exécution terminée, cliquez sur votre job et constatez que les parameter catalog et job run ID ont été créés et renseignés comme prévu, et que votre code a ajouté une autre ligne à la table bu1_dev.default.test_events.
Une fois que votre code fonctionne en développement, enregistrons-le dans Git.
Cliquez sur le bouton Workspaces (le « dossier ») et prenez quelques minutes pour vous familiariser avec la nouvelle interface utilisateur de Workspace. Cliquez sur le bouton « Tous les fichiers », puis revenez sur le bouton « Dossier » à côté. Notez que cela permet simplement d’alterner entre le dossier du bundle DAB et le dossier normal. Notez également les tab des fichiers ouverts à droite. Il est pratique de pouvoir ouvrir plusieurs fichiers à la fois, même dans des dossiers/sous-dossiers différents, et de basculer de l’un à l’autre sans avoir à parcourir la structure des dossiers à gauche.
Lorsque vous êtes prêt, cliquez sur le bouton Git à côté de votre dossier de bundle.
Allez-y, ajoutez quelques commentaires et cliquez sur commit et envoyer pour votre premier projet DAB !
Dans le message en haut de l’écran, cliquez sur le lien de création d’une requête d’extraction pour créer votre demande d’extraction ici, pour plus de facilité. Cela vous redirigera vers Azure DevOps, où vous pourrez renseigner les détails de votre demande d’extraction !
Cliquez sur Créer pour créer votre PR, puis arrêtez-vous ici.
Passons à la configuration du pipeline de déploiement Azure DevOps. De cette façon, lorsque nous irons dans DevOps pour approuver et Merge votre PR, nous devrions voir notre nouveau pipeline DevOps déployer automatiquement votre code hello world initial vers la mise en scène.
Partie 3 - Création du pipeline de déploiement Azure DevOps pour CI/CD
En guise de révision, nos exigences CI/CD sont :
-
Les PR de développeur approuvées doivent être Merge dans main et automatiquement déployées en staging. Ici, le code fusionné peut être testé dans le contexte plus large de la plateforme de données, éventuellement aux côtés d'autres modifications approuvées en attente de promotion vers prod.
-
Puis, après une approbation supplémentaire, la Branch principale est déployée en prod.
Nous allons commencer par mettre en place le processus de staging, qui consiste à créer une connexion de service DevOps, à la mapper sur un Service Principal (SP) Databricks géré par Entra ID, à créer un dossier de déploiement de workspace pour le staging et à accorder au SP des autorisations sur le dossier et sur le catalogue bu1_stg dans Unity Catalog. Nous répéterons ce processus pour la production. Nous allons ensuite créer les groupes de variables DevOps, les approbateurs/portes d' environnement de production et le pipeline pour réunir le tout. Après cela, nous pourrons le tester !
Voici une vue d'ensemble des étapes que vous effectuerez deux fois (une fois pour la staging et une fois pour la prod), sauf indication contraire :
Étape | Emplacement | Quoi | Pourquoi |
|---|---|---|---|
1 | Azure DevOps > Paramètres du projet | Créer la connexion de service | Facilite une connexion sécurisée et flexible entre DevOps et Azure Databricks pour le déploiement de bundles vers les environnements de staging et de production. Pour une comparaison avec l’approche plus récente basée sur OIDC de Databricks, consultez la rubrique à la fin de cet article. |
2 | Portail Azure | Créer l’enregistrement de l’application | |
3 | Workspace Databricks > Paramètres | Créer le service principal | Il s'agira du propriétaire des ressources déployées par DevOps ; vous devez donner à ce principal l'accès en écriture au dossier de déploiement et des privilèges dans Unity Catalog. |
4 | Workspace Databricks > Dossiers | Créez votre SP et les permissions de groupe admin sur le dossier | En déployant dans des dossiers par équipe, vous avez la possibilité de définir des autorisations afin que chaque équipe puisse voir son propre code déployé si nécessaire. |
5 | Workspace Databricks > Catalogue | Donnez au SP et à d'autres groupes les autorisations appropriées dans Unity Catalog. | Les tables et les schémas créés par le SP appartiennent au SP. |
6 | Azure DevOps > Bibliothèque | Créer un groupe de variables pour chaque étape | Ils contiennent la variable |
7 | Azure DevOps > Environnements | Vous ne créerez ceci que pour « prod » | Cela servira à configurer le mécanisme d’approbation pour le déploiement en prod. |
8 | Azure DevOps > Dépôt | Créez un dossier racine appelé « /.cicd » ou similaire pour le code du pipeline. | Cela permet de séparer votre pipeline et le code de votre bundle. Pensez à exiger des approbateurs spéciaux pour les modifications de code dans les fichiers de ce dossier racine. |
9 | Azure DevOps > Pipelines | Créer un pipeline de version pour votre projet hello_world | Cela déploiera votre code en préproduction et en production après les approbations nécessaires. |
10 | Testez-le ! | Vérifiez les messages écrits dans votre table d’événements dans les catalogues de staging et de prod | Vous pouvez envisager la façon d'organiser vos bundles et vos pipelines de déploiement. Un pipeline peut déployer plusieurs bundles, ou vous pouvez les garder en rapport 1:1 pour un meilleur contrôle. |
Créer la connexion de service intermédiaire et l’enregistrement d’application
Accédez à Project settings > Pipelines > Service connections dans votre projet DevOps et cliquez sur Create service connection .
Choisissez l'option Azure Resource Manager et cliquez sur Suivant .
Important ! Pour le Type d’identité , vous verrez deux options.
Choisissez l'option Inscription d’application ou identité gérée (manuel) surlignée ci-dessous ( ne choisissez pas celle qui est marquée comme recommandée).
Cela vous permet de nommer clairement l' inscription à l'application Azure qui prend en charge votre connexion au service DevOps. Ceci est important car le nom de votre inscription à l'application Azure est synchronisé avec le nom de votre Service Principal Databricks, et c'est ce que votre équipe de données recherchera lors de l'octroi des autorisations sur vos ressources Unity Catalog et Workspace.
Si vous choisissez l’autre option, le nom de l’enregistrement de l’application sera automatiquement généré par Azure comme <devops_org>-<project>-<GUID>, sans indication permettant de savoir s’il s’agit d’une préparation ou d’une production. Vous ne pouvez pas le renommer, ce qui rendra difficile l’attribution des autorisations ultérieurement. L’approche manuelle que nous recommandons dans cet article comporte quelques étapes supplémentaires, mais c’est votre meilleure option.
Remarque : les deux approches impliquent la création d’une inscription d’application dans votre portail Azure. Par conséquent, si vous ne disposez pas des autorisations nécessaires pour ce faire, vous recevrez une erreur et devrez effectuer ces étapes avec une personne qui dispose de ces autorisations.
Après avoir choisi Inscription d’application ou identité managée (manuel) , remplissez le nom de la connexion de service (par exemple, bu1-team1-staging-svc-conn), la description et l’ID de votre répertoire (tenant) dans la section Partie 1 : Bases , puis cliquez sur Suivant .
Cela vous amène à la partie 2 : détails de l’enregistrement de l’application .
Astuce : pour trouver votre identifiant de tenant, cliquez sur le cercle contenant votre identifiant utilisateur dans la bannière du portail DevOps, puis cliquez sur le Link Changer de répertoire . L’identifiant du tenant est la chaîne qui se trouve sous le répertoire actuel.
À ce stade, vous devrez garder l’écran de la partie 2 ouvert et ouvrir le portail Azure dans un autre tab. Vous pouvez suivre les étapes ci-dessous et les voir illustrées dans l'image ci-dessous.
- Créez l' enregistrement de l'application (par exemple
bu1-team1-cicd-staging-app) dans le portail Azure. - Copiez l’ID Application (anciennement appelé ID client) et ajoutez-le au champ Partie 2 de la connexion de service DevOps intitulé Application (client) ID .
- Une fois sur place, remplissez votre ID d’abonnement . Vous pouvez obtenir l’ID d’abonnement en recherchant Abonnements dans le portail Azure.
- Saisissez votre nom d'abonnement - ne cliquez pas encore sur le bouton Vérifier et enregistrer.
- De retour sur le portail Azure, sur la page d’enregistrement de votre application, cliquez sur Gérer sur la gauche.
- Cliquez ensuite sur Certificats et secrets .
- Cliquez sur le tab Identifiants fédérés .
- Cliquez sur Ajouter un identifiant .
- Choisissez Autre émetteur.
- Copiez l’ URL de l’émetteur de votre connexion de service sous la partie 2 et collez-la dans le champ Émetteur .
- Copiez l’ identifiant de l’objet et collez-le dans le champ Valeur .
- Saisissez un nom pour votre identifiant (par exemple,
bu1-team1-cicd-staging-fed-credential). - Cliquez sur Ajouter .
- De retour sur l’écran de connexion de service, cochez la case Accorder l’autorisation d’accès à tous les pipelines . Ce n'est pas grave, car cela signifie que tous les pipelines DevOps de notre projet DevOps
bu1-team1. Si vous organisez les choses différemment, vous pouvez toujours accorder l’accès à cette connexion plus tard.
Ne cliquez pas encore sur Vérifier et enregistrer ! Vous devez donner à votre enregistrement d'application l'autorisation de lire votre abonnement. Si vous avez cliqué dessus de toute façon, examinez attentivement le message d'erreur. Vous verrez que le travail de la partie 1 a été enregistré en tant que brouillon. Vous pourrez revenir en arrière et terminer la partie 2 après avoir effectué les étapes requises.
Allez sur le portail Azure et recherchez votre abonnement. Accédez à Contrôle d’accès (IAM) et cliquez sur Ajouter une attribution de rôle . Cliquez sur Lecteur sous Nom, puis cliquez sur Suivant . Laissez l'option Attribuer l'accès définie sur Utilisateur, groupe ou Service Principal et cliquez sur le Link Sélectionner des membres. Recherchez votre service principal (remarque : votre inscription d'application a précédemment créé un service principal en arrière-plan avec le même nom, par exemple bu1-team1-cicd-staging-app), sélectionnez-le, puis cliquez sur Sélectionner .
Cliquez sur Examiner + attribuer .
Retournez maintenant à Azure DevOps et sur votre écran Modifier la connexion au service Partie 2 et cliquez sur le bouton Vérifier et enregistrer .
Félicitations ! Cela fait beaucoup d’étapes, mais elles sont nécessaires, car vous devez établir une relation de confiance entre votre projet Azure DevOps et votre inscription d’application/Service Principal du portail Azure ; ces services ne se font pas tous confiance par default.
Nous allons maintenant configurer la relation de confiance entre notre application Azure/Service Principal et le Service Principal Databricks qui exécutera les ressources que Azure DevOps a déployées dans votre workspace.
Créer le Service Principal Databricks pour les tâches CI/CD
Accédez à votre workspace de staging (dans cet article, nous utilisons le workspace bu1-dev). Accédez à Paramètres du Workspace > Identité et accès > Service Principal et cliquez sur Gérer . Cliquez sur Ajouter un service principal , puis sur le bouton Ajouter un nouveau .
Sous Gestion, choisissez Microsoft Entra ID géré , puis copiez l’ ID d’application de votre enregistrement d’application Azure.
L'interface utilisateur illustrée ci-dessous pour l'option gérée par Microsoft Entra ID affiche un champ pour saisir le nom du service principal. Bien que ce champ vous permette de saisir et d'enregistrer une valeur, elle ne sera pas conservée, comme vous le verrez lorsque vous rechercherez ce service principal dans l'interface des autorisations dans Databricks.
Donnez-lui n’importe quel nom comme bu1-team1-cicd-staging-sp (mais vous verrez qu’il sera bientôt changé pour le nom de votre inscription d’application) et cliquez sur Ajouter .
Note : il est possible d'utiliser une connexion de service Azure DevOps, un enregistrement d'application Azure et un Service Principal Databricks uniques pour tous vos processus CI/CD (incluant les déploiements en préproduction et en production). Cependant, vous remarquerez que nous avons inclus le terme « staging » dans les noms de ces ressources CI/CD que nous avons créées, afin que vous puissiez ultérieurement ajouter les versions « prod » et disposer d'une gouvernance plus précise sur votre processus CI/CD.
Cliquez sur votre SP Databricks une fois qu'il est créé. Il aura besoin des droits Accès au workspace et Accès SQL , en fonction de votre code. Je vous recommande d'utiliser les jobs serverless, en particulier pendant le développement, pour accélérer vos tests CI/CD par essai-erreur. Si vous utilisez des jobs serverless, vous n'avez pas besoin d'assigner le droit Autoriser la création de clusters sans restriction .
Explorez l' Autorisations tab. Cela vous permet de décider qui peut gérer et utiliser le SP, et non ce que ce SP peut faire dans votre workspace. Vous pouvez décider si une équipe dans l'environnement de staging doit exécuter manuellement un job pour une raison quelconque. Dans ce cas, donnez à cette équipe l'autorisation USE.
Explorez la tab Intégration Git . Cette fonctionnalité permet à votre SP de se connecter à un repository Git, ce qui est nécessaire lorsque le job est configuré pour extraire le code du notebook à partir de Git au moment de l'exécution. Mais nous n’utilisons pas cette approche dans ce blog. Nous configurons DevOps pour qu'il envoie le code du notebook et les ressources du bundle dans chaque environnement. Laissez l'intégration Git non configurée pour le SP.
Créer le dossier de déploiement de staging
Dans le workspace, créez un emplacement de staging dans lequel le pipeline Azure DevOps déploiera votre code. Ensuite, faites un clic droit sur ce dossier et choisissez le menu Partage (autorisations) . Recherchez votre SP et accordez-lui les autorisations Peut gérer , comme illustré ci-dessous (n’oubliez pas que, comme mentionné précédemment, vous recherchez l’inscription d’application que vous avez créée dans le portail Azure, qui est synchronisée avec le nom du service principal Databricks que vous venez de créer).
Si vous souhaitez que votre équipe de développement voit ce qui est déployé ici, accordez-lui des autorisations de visualisation. En règle générale, les développeurs, les équipes d'assurance qualité et les administrateurs ne doivent pas avoir accès en écriture au dossier de déploiement cible du bundle de staging.
Attribution des autorisations Unity Catalog à votre Service Principal
Il existe plusieurs stratégies pour créer et gérer les autorisations sur les catalogues et les schémas. Dans ce blog, nous créons manuellement les catalogues et attribuons des autorisations d'éditeur de données à notre SP. Nous accordons également l'autorisation de gestion afin que notre SP puisse supprimer des tables et gérer les autorisations si nous devions le faire dans notre code de job. N'hésitez pas à reconsidérer et à faire évoluer vos choix si nécessaire.
Donnez à votre SP la permission de créer des assets de données dans votre catalogue de staging comme indiqué ci-dessous.
Accédez au schéma default de votre catalogue intermédiaire et constatez que la plupart de ces autorisations sont héritées comme prévu. Examinez les autorisations sur votre schéma bu1_stg.default. Notez que votre SP peut lire et écrire dans ce schéma même s’il n’en est pas le propriétaire (vous êtes le propriétaire car il a été créé lorsque vous avez créé le catalogue).
Créer votre Pipeline Azure DevOps (bu1-team1-hello-world-pipeline.yml)
Nous souhaitons que notre pipeline CI/CD comporte deux étapes :
-
DeployStaging - S’exécute automatiquement lorsque le code d’une Branch de fonctionnalité a été approuvé et Merge dans la branche principale.
-
DeployProd - S'exécute après DeployStaging et après une approbation que vous pouvez configurer. Nous utiliserons des groupes de variables DevOps pour stocker les URL des Workspace et un environnement DevOps pour définir le processus d'approbation qui limite notre déploiement de production.
Allez dans votre projet DevOps > Pipelines > Bibliothèque et cliquez sur le bouton + Groupe de variables . Nommez-la stagingVariables (vous la référencerez lors de la première étape de votre pipeline) et ajoutez une variable DATABRICKS_HOST ainsi qu’une URL pointant vers le hostname de votre workspace de staging (bu1-dev dans l’exemple de cet article). Puis cliquez sur Enregistrer .
Répétez le processus pour un autre groupe de variables appelé prodVariables , auquel vous référencerez dans la deuxième étape de votre pipeline.
Accédez à votre projet DevOps > Environnements et cliquez sur le bouton Créer un environnement . Donnez-lui le nom prod (vous y ferez référence dans la deuxième étape de votre pipeline), laissez la ressource sur Aucune et cliquez sur Créer .
Ensuite, cliquez sur le Approbations et vérifications tab et cliquez sur la vérification des Approbations . Pour cet article, nous choisirons simplement deux approbateurs, mais vous pouvez configurer cela selon les besoins de votre organisation.
Vous n'avez pas besoin de créer un environnement de préparation, car nous prévoyons de déployer automatiquement après la fusion avec main, sans conditions ni approbations.
Accédez à la page Projet DevOps > Repos > Fichiers et créez un dossier (par exemple, .cicd ) et votre pipeline Hello World à l’intérieur.
Copiez le code YAML suivant et modifiez la valeur azureSubscription aux lignes 33 et 102 pour qu'elle corresponde au nom de vos connexions de service DevOps (oui, il est déroutant de devoir utiliser le nom de la connexion de service, mais le système demande le nom de l'abonnement). Examinez les commentaires et apportez les autres ajustements nécessaires.
- Vous pouvez aussi download le fichier à partir de ce lien - https://github.com/databricks-solutions/databricks-dab-examples/blob/main/knowledge-base/azure-devops-cicd-example/bu1-team1-hello-world-pipeline.yml
# This triggers the pipeline on a commit to the 'main' branch
trigger:
branches:
include:
- main
# Prevents the pipeline from triggering on Pull Requests; only on merges
pr: none
stages:
# -----------------------------------------------
# Stage 1: Deploy to Staging (automatic on merge)
# -----------------------------------------------
# TODO - In the bundle validate/deploy steps below, change "workingDirectory"
# to the folder containing your databricks.yml and edit the target values if
# your choice differs from "staging" used in the example below.
- stage: DeployStaging
displayName: 'Deploy to Staging'
variables:
- group: stagingVariables
condition: |
eq(variables['Build.SourceBranch'], 'refs/heads/main')
jobs:
- job: deployStagingJob
pool:
vmImage: ubuntu-latest
steps:
- task: UsePythonVersion@0
inputs:
versionSpec: 3.11
- task: AzureCLI@2
displayName: 'Get Databricks Token (Staging)'
inputs:
# TODO - Change azureSubscription value to the name of your DevOps "staging" Service Connection
azureSubscription: bu1-team1-staging-svc-conn
scriptType: 'bash'
scriptLocation: 'inlineScript'
failOnStandardError: true
# Set the token as a pipeline variable for subsequent steps; note that the "echo"
# line does not print the token to the pipeline logs. The resource ID is the well-known
# Azure AD application ID for Databricks (same for all tenants).
inlineScript: |
set -e
DATABRICKS_TOKEN=$(az account get-access-token --resource 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d --query "accessToken" -o tsv)
echo "##vso[task.setvariable variable=DATABRICKS_TOKEN]$DATABRICKS_TOKEN"
# Clone the repository so the bundle files are available to the pipeline agent
- checkout: self
displayName: 'Checkout repository'
# Install Python dependencies here if your bundle requires them
# For example:
# - script: pip install -r requirements.txt
# displayName: 'Install Python dependencies'
- script: |
curl -fsSL https://raw.githubusercontent.com/databricks/setup-cli/main/install.sh | sh
databricks --version
displayName: 'Install Databricks CLI'
- script: databricks bundle validate -t staging
displayName: 'Validate bundle for the "staging" environment'
env:
DATABRICKS_HOST: $(DATABRICKS_HOST)
DATABRICKS_TOKEN: $(DATABRICKS_TOKEN)
workingDirectory: $(Build.SourcesDirectory)/hello_world
- script: databricks bundle deploy -t staging
displayName: 'Deploy bundle to the "staging" environment'
env:
DATABRICKS_HOST: $(DATABRICKS_HOST)
DATABRICKS_TOKEN: $(DATABRICKS_TOKEN)
workingDirectory: $(Build.SourcesDirectory)/hello_world
# -----------------------------------------------
# Stage 2: Deploy to Production (requires approval in Azure DevOps)
# -----------------------------------------------
# TODO - In the bundle validate/deploy steps below, change "workingDirectory"
# to the folder containing your databricks.yml and edit the target values if
# your choice differs from "prod" used in the example below.
- stage: DeployProd
displayName: 'Deploy to Prod'
dependsOn: DeployStaging
condition: succeeded()
variables:
- group: prodVariables
jobs:
# A "deployment:" job (rather than a regular "job:") is required to
# connect to an Azure DevOps Environment and enable the approval gate.
- deployment: deployProdJob
displayName: 'Deploy to Prod'
pool:
vmImage: ubuntu-latest
# Setup the approval gate. The value for "environment" must match
# the Azure DevOps Environment name where approvals are configured.
environment: 'prod'
strategy:
runOnce:
deploy:
steps:
- checkout: self
- task: UsePythonVersion@0
displayName: 'Use Python 3.11'
inputs:
versionSpec: 3.11
- task: AzureCLI@2
displayName: 'Get Databricks Token (Prod)'
inputs:
# TODO - Change azureSubscription value to the name of your DevOps "prod" Service Connection
azureSubscription: bu1-team1-prod-svc-conn
scriptType: 'bash'
scriptLocation: 'inlineScript'
failOnStandardError: true
# Set the token as a pipeline variable for subsequent steps; note that the "echo"
# line does not print the token to the pipeline logs. The resource ID is the well-known
# Azure AD application ID for Databricks (same for all tenants).
inlineScript: |
set -e
DATABRICKS_TOKEN=$(az account get-access-token --resource 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d --query "accessToken" -o tsv)
echo "##vso[task.setvariable variable=DATABRICKS_TOKEN]$DATABRICKS_TOKEN"
# Install Python dependencies here if your bundle requires them
# For example:
# - script: pip install -r requirements.txt
# displayName: 'Install Python dependencies'
- script: |
curl -fsSL https://raw.githubusercontent.com/databricks/setup-cli/main/install.sh | sh
databricks --version
displayName: 'Install Databricks CLI'
- script: databricks bundle validate -t prod
displayName: 'Validate bundle for the "prod" environment'
env:
DATABRICKS_HOST: $(DATABRICKS_HOST)
DATABRICKS_TOKEN: $(DATABRICKS_TOKEN)
workingDirectory: $(Build.SourcesDirectory)/hello_world
- script: databricks bundle deploy -t prod
displayName: 'Deploy bundle to the "prod" environment'
env:
DATABRICKS_HOST: $(DATABRICKS_HOST)
DATABRICKS_TOKEN: $(DATABRICKS_TOKEN)
workingDirectory: $(Build.SourcesDirectory)/hello_world
Cliquez sur Commit pour l'enregistrer dans la branche principale de votre dépôt.
Avant de créer le pipeline DevOps et de le pointer vers ce fichier, approuvons et fusionnons la pull request initiale des DAB « Hello World » afin qu'il y ait du code à déployer.
Dans votre projet Azure DevOps, cliquez sur Repos > Requêtes d’extraction et sélectionnez la requête d’extraction que vous avez créée précédemment à partir de l’interface utilisateur d’intégration Databricks Git.
Cliquez sur Terminer , puis choisissez vos options de fusion avant de cliquer sur le bouton Terminer la Merge .
Vous pouvez vérifier que le code de votre bundle se trouve maintenant dans la branch main.
Créons maintenant le pipeline. Accédez au menu Projet > Pipelines > Pipelines et cliquez sur Créer un pipeline . Choisissez Azure Repos Git .
Choisissez le repository de votre équipe, puis cliquez sur Fichier YAML Azure Pipelines existant .
Saisissez le chemin d'accès à votre fichier de pipeline et cliquez sur Continuer .
Avant de pouvoir exécuter le pipeline, vous devez :
- Répétez les étapes précédentes pour créer votre connexion au service de production (
bu1-team1-prod-svc-conn), votre SP Databricks et votre dossier de déploiement sur le workspace de production, ainsi que les autorisations pour le catalogue de production, ou - Commentez toutes les lignes de l’étape 2 de votre pipeline pour éviter les erreurs de validation.
Déploiement en staging
Une fois que vous avez pris votre décision, cliquez sur Exécuter.
Vous n’avez pas besoin de définir ni de modifier quoi que ce soit sur l’écran suivant qui s’affiche.
Votre job de déploiement vers le staging sera exécuté. La première fois qu’il s’exécutera, vous verrez un message vous demandant l’autorisation d’accéder au groupe de variables de staging. Donnez-lui l’autorisation.
Lorsque le déploiement de staging est terminé, trouvez votre job et exécutez-le.
Voyez que les données ont été ajoutées par le Service Principal. Selon la partie de l’interface utilisateur, vous verrez l’identifiant d’application ou le nom de l’enregistrement de l’application, comme indiqué ci-dessous.
Bien que le déploiement de code, l'exécution du job et l'écriture des données dans la table aient tous été effectués par le SP d'inscription d'application Azure, c'est l'administrateur de workspace qui l'a activé dans les paramètres de workspace, et le propriétaire d'Unity Catalog qui lui a accordé des droits d'éditeur sur le schéma.
Déploiement en production
Lorsque vous êtes prêt, cliquez sur le bouton Réviser et approuvez l'exécution de l'étape de déploiement de production.
Votre bundle doit être déployé dans le workspace de prod. Recherchez le job et exécutez-le, puis vérifiez le catalogue de prod pour voir s'il s'est exécuté.
Félicitations ! Si vous êtes arrivé jusqu'ici, vous êtes maintenant un champion du CI/CD d'Azure Databricks.
Comparaison de deux approches de fédération d’identité de Workload : connexions de service courtées par Azure AD vs intégration OIDC de Databricks
L'approche adoptée pour intégrer Azure DevOps et Databricks dans ce blog utilise des connexions de service Azure DevOps soutenues par l'enregistrement d'applications. Il s’agit d’un modèle bien établi pour fédérer en toute sécurité la charge de travail de votre pipeline entre les deux services cloud. Mais Databricks a récemment introduit une alternative basée sur OIDC. Comment les comparer, et quelle est la meilleure option ?
Les deux approches utilisent des protocoles sécurisés basés sur des jetons (OIDC et OAuth). La différence est l'émetteur. Dans le blog, j’utilise la fonctionnalité de connexion de service DevOps, ce qui signifie que le pipeline DevOps (via la tâche AzureCLI@2) obtient un access token Azure AD et le transmet au CLI Databricks en tant que DATABRICKS_TOKEN. Cela fonctionne bien quand votre pipeline a également besoin d'accéder à d'autres ressources Azure (Storage, Key Vault, etc.) par l'intermédiaire du même service principal.
Databricks prend aussi en charge une alternative plus récente : la fédération de jetons OAuth (également appelée fédération d’identité de charge de travail ou OIDC). Grâce à cette approche, le pipeline Azure DevOps s'authentifie directement auprès de Databricks ; sans intermédiaire Azure AD, sans connexions de service et sans étape de récupération de jeton explicite. Vous créez une politique de fédération sur le Service Principal Databricks qui approuve l'émetteur OIDC de votre organisation Azure DevOps, et la CLI Databricks gère automatiquement l'échange de jetons à l'aide du System.AccessToken intégré au pipeline.
Cela permet effectivement d’obtenir un pipeline plus simple (aucune tâche AzureCLI@2, aucune connexion de service Azure), mais l’authentification ne concerne que Databricks : si vous avez besoin d’accéder à d’autres ressources Azure, vous devrez toujours utiliser l’autre approche de connexion de service présentée dans ce blog. Pour en savoir plus, consultez dev-tools/auth/provider-azure-devops.md dans la documentation Databricks.
Aspect | Approche 1 : Authentification intermédiaire par Azure AD (ce blog) | Approche 2 : fédération OIDC native de Databricks (option alternative) |
|---|---|---|
Link doc | Activer la fédération d'identité de charge de travail pour les pipelines Azure DevOps | |
Maturité | Schéma bien établi | Plus récent (fédération Databricks OAuth) |
Protocoles utilisés | OIDC, OAuth 2.0, jeton porteur | OIDC → Databricks OAuth 2.0 |
Intermédiaire d’authentification | Azure AD (courtier de jetons) | Aucun (OIDC direct) |
Acquisition de jetons | Explicite | Automatique par le SDK Databricks ou la CLI Databricks |
Azure CLI dans le pipeline | Obligatoire | Non requis |
Connexions de service Azure | Obligatoire (une par env) | Non requis |
Politique de fédération | Sur Azure AD (approuve Azure DevOps) | Sur SP Databricks (fait confiance à Azure DevOps) |
Complexité | Deux sauts ; 8 étapes de pipeline par étape | Un saut ; 2 à 3 étapes de pipeline par étape |
Accès aux ressources Azure | Le même SP peut accéder à d'autres ressources Azure (key vault, etc.). | S’authentifie uniquement auprès de Databricks |
Mieux quand |
|
|
Quelle est la différence | Ignore entièrement Azure AD. Une politique de fédération est créée directement sur le service principal de Databricks qui approuve l’émetteur OIDC Azure DevOps ( | |
Nécessite |
|