Partager via

Concepts clés dans Databricks Apps

Cet article présente les concepts fondamentaux de Databricks Apps, notamment la structure des applications, la gestion des dépendances et de l’état, le fonctionnement des autorisations et la façon dont les applications interagissent avec les ressources de la plateforme. La compréhension de ces concepts permet de développer, de déployer et de gérer des applications dans votre espace de travail.

App

Une application Databricks est une application web qui s’exécute en tant que service conteneurisé sur la plateforme serverless Azure Databricks. Les développeurs utilisent des frameworks pris en charge tels que Streamlit, Dash ou Gradio pour créer des applications qui fournissent des données interactives ou des expériences IA au sein d’un espace de travail Azure Databricks.

Chaque application inclut sa propre configuration, son identité et son environnement d’exécution isolé. Étant donné que les applications appartiennent à un espace de travail spécifique, elles peuvent accéder aux ressources au niveau de l’espace de travail telles que les entrepôts SQL et les ressources au niveau du compte, telles que le catalogue Unity. Les développeurs peuvent également choisir de partager des applications avec des utilisateurs en dehors de l’espace de travail, mais dans le même compte Azure Databricks.

Bien que le conteneur d’applications s’exécute sur l’infrastructure serverless Azure Databricks, l’application elle-même peut se connecter à des ressources serverless et non serverless. Conceptuellement, une application agit comme un service de plan de contrôle qui héberge une interface utilisateur web et accède aux services de plan de données Azure Databricks disponibles. Pour plus d’informations, consultez la vue d’ensemble de l’architecture Databricks.

Pour lancer et gérer des applications, accédez à la section Applications de l’interface utilisateur de l’espace de travail.

URL d’application

Databricks affecte automatiquement à chaque application une URL unique lorsque vous la créez. L’URL suit ce format :

https://<app-name>-<workspace-id>.<region>.databricksapps.com

Where:

  • <app-name> est le nom que vous fournissez lors de la création de l’application
  • <workspace-id> est l’identificateur unique de votre espace de travail
  • <region> est la région cloud où se trouve votre espace de travail

Vous ne pouvez pas modifier l’URL après avoir créé l’application. Si vous avez besoin d’une URL différente, créez une application avec un autre nom.

Template

Un modèle d’application est une structure prédéfinie qui permet aux développeurs de commencer à créer rapidement des applications à l’aide d’une infrastructure prise en charge. Chaque modèle inclut une structure de fichiers de base, un app.yaml manifeste, un fichier pour les applications Python et un requirements.txt exemple de code source.

Le app.yaml fichier définit la commande pour exécuter l’application (par exemple, streamlit run <app-name> pour une application Streamlit), configure des variables d’environnement locales et déclare toutes les ressources requises.

  • Permet requirements.txt de répertorier des packages Python supplémentaires à installer avec pip.
  • Utilisez package.json pour lister les packages Node.js à installer avec npm.

Ces fichiers complètent l’environnement système par défaut et les packages préinstallés. Pour plus d’informations, consultez l’environnement système Databricks Apps.

Les développeurs peuvent générer une nouvelle application à partir d’un modèle à l’aide de l’interface utilisateur Azure Databricks ou de l’interface CLI.

Environnement système et packages

Databricks Apps s’exécute dans un environnement système préconfiguré géré par Azure Databricks. Pour plus d’informations, consultez l’environnement système Databricks Apps.

Chaque application a son propre environnement isolé pour éviter les conflits de dépendances. Pour garantir la cohérence, définissez les packages requis et leurs versions dans le fichier approprié pour votre application :

  • Pour Python, utilisez requirements.txt.
  • Pour Node.js, utilisez package.json.

Pour les déploiements hybrides, vous aurez probablement les deux fichiers.

Pendant le déploiement, Azure Databricks installe ces dépendances dans l’environnement d’exécution isolé de l’application. Si vous incluez un package déjà préinstallé, la version spécifiée remplace la valeur par défaut.

Pour plus d’informations, consultez Gérer les dépendances pour une application Databricks .

Ressources d’application

Les ressources d’application sont des services natifs Azure Databricks dont dépend une application, comme les entrepôts SQL, le modèle servant des points de terminaison, des travaux, des secrets ou des volumes. Vous déclarez ces dépendances dans le manifeste databricks.yml dans le champ resources. Azure Databricks prend en charge les types de ressources suivants :

  • Entrepôt SQL
  • Job
  • Point de terminaison de mise en service
  • Espace Génie
  • Secret
  • Volume

Pour accéder aux services Azure Databricks qui n’ont pas encore de type de ressource pris en charge, utilisez un secret managé par le catalogue Unity pour injecter en toute sécurité des informations d’identification. Consultez la gestion des secrets.

Il existe deux étapes pour configurer les ressources d’application :

  • Déclaration (développement) : déclarez chaque ressource requise dans le databricks.yml manifeste. Cela définit les ressources dont l’application a besoin et les autorisations dont elle a besoin.
  • Configuration (déploiement) : pendant le déploiement, utilisez l’interface utilisateur Databricks Apps pour configurer les ressources déclarées avec des instances spécifiques à l’espace de travail réelles (par exemple, en sélectionnant un entrepôt SQL spécifique).

Cette séparation entre la déclaration et la configuration permet aux applications d’être portables entre les environnements. Par exemple, vous pouvez déployer le même code d’application dans un espace de travail de développement et le lier à un entrepôt SQL. En production, vous pouvez réutiliser le code et configurer un autre entrepôt sans apporter de modifications de code. Pour ce faire, évitez le codage en dur des ID de ressources ou les valeurs spécifiques à l'environnement dans vos applications.

Azure Databricks applique l’accès avec privilèges minimum. Les applications doivent utiliser des ressources existantes et ne peuvent pas en créer de nouvelles. Pendant le déploiement, les administrateurs de l’espace de travail examinent et approuvent l’accès demandé à l’application aux ressources. Le principal de service de l’application reçoit les autorisations nécessaires, et le développeur de l’application doit avoir l’autorisation de les accorder.

Pour plus d’informations, consultez Ajouter des ressources à une application Databricks.

État de l’application

Une application peut avoir l’un des états suivants : En cours d’exécution, Arrêté, Déploiement ou Blocage.

  • Exécution : l’application est active et accessible. Azure Databricks facture les ressources de calcul utilisées pendant l’exécution de l’application.
  • Arrêté : l’application n’est pas accessible et n’entraîne aucun coût. Azure Databricks conserve la configuration et l’environnement de l’application, afin de pouvoir le redémarrer sans reconfigurer.
  • Déploiement : l’application démarre. Il n’est pas encore accessible et n’entraîne pas de frais pendant cette phase.
  • Échec : l’application n’a pas pu démarrer ou s'est arrêtée de façon inattendue. Il est inaccessible et n’entraîne pas de frais. Vous pouvez afficher les journaux d’activité pour résoudre les problèmes et redémarrer l’application une fois le problème résolu.

État de l’application

L’état de l’application inclut toutes les données ou contextes que l’application doit conserver entre les sessions utilisateur ou les interactions. Les applications ne conservent pas l’état en mémoire après les redémarrages. Toutes les données conservées en mémoire sont perdues lorsque l’application s’arrête.

Vous pouvez stocker l’état de la manière suivante :

  • Stockage en mémoire pour les données temporaires au sein d’une même session. Ces données sont perdues lorsque l’application redémarre.
  • Système de fichiers local pour les fichiers temporaires pendant l’exécution de l’application. Ces données sont perdues lorsque l’application redémarre.
  • Tables Azure Databricks utilisant Databricks SQL pour des charges de travail structurées et persistantes en données et en analytique.
  • Fichiers d’espace de travail pour les données non structurées persistantes.
  • Volumes de catalogue Unity pour les données non structurées persistantes avec la gouvernance du catalogue Unity.

Les cas d’usage courants incluent la mise en cache des résultats des requêtes, l’enregistrement des préférences utilisateur ou la journalisation des actions utilisateur entre les sessions.

Authentification et autorisation des applications

Databricks Apps utilise OAuth 2.0 pour l’authentification et le contrôle d’accès. Chaque application a deux identités complémentaires qui déterminent comment elle authentifie et autorise l’accès aux ressources Azure Databricks : l’autorisation d’application et l’autorisation utilisateur.

  • Autorisation d’application : Azure Databricks crée automatiquement un principal de service pour chaque application. Ce principal de service agit comme l’identité de l’application et reçoit des autorisations par le développeur de l’application. Tous les utilisateurs de l’application partagent cette identité et ont accès au même ensemble d’autorisations. Ce modèle est utile pour les opérations qui ne dépendent pas du contexte de l’utilisateur individuel, telles que la journalisation ou les actions au niveau du système.

  • Autorisation utilisateur : ce modèle utilise l’identité de l’utilisateur de l’application pour authentifier et autoriser l’accès. Les utilisateurs doivent appartenir au compte Azure Databricks où l’application est déployée. Après la connexion via l’authentification unique (SSO), l’application peut utiliser les informations d’identification de l’utilisateur pour accéder aux ressources régies comme un entrepôt SQL. Cela permet à l’application de respecter les autorisations affinées gérées par le catalogue Unity sans accorder ces autorisations au principal de service de l’application.

Les applications demandent des étendues OAuth spécifiques dans leur manifeste pour contrôler les API et ressources auxquelles ils peuvent accéder. Ce modèle flexible prend en charge la sécurité de niveau entreprise et permet un contrôle d’accès affiné.

Pour plus d’informations, consultez Configurer l’autorisation dans une application Databricks.

Utilisateurs d’applications

Après le déploiement, les développeurs d’applications peuvent partager une application avec des utilisateurs ou des groupes en leur accordant l’autorisation CAN_USE ou CAN_MANAGE sur l’instance de l’application. Les utilisateurs n’ont pas besoin d’appartenir au même espace de travail, mais ils doivent faire partie du même compte Azure Databricks. Pour partager avec des utilisateurs externes, commencez par les synchroniser dans le compte à l’aide de votre fournisseur d’identité. Pour plus d’informations, consultez Synchroniser des utilisateurs et des groupes à partir de Microsoft Entra ID à l’aide de SCIM.

Vous pouvez également distribuer la même application entre les environnements de développement, de préproduction et de production à l’aide de pipelines CI/CD et d’une infrastructure en tant que code. L’interface utilisateur des applications centralisées permet aux utilisateurs de découvrir et de lancer des applications qu’ils sont autorisés à utiliser.

  • Last updated on