Concepts clés dans Databricks Apps

Cet article présente les concepts fondamentaux de Databricks Apps, notamment comment les applications sont structurées, comment elles gèrent les dépendances et l'état, comment les autorisations fonctionnent et comment les applications interagissent avec les ressources de la plateforme. La compréhension de ces concepts est utile lors du développement, du déploiement et de la gestion d'applications dans votre workspace.

Application

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

Chaque application comprend sa propre configuration, identité et environnement d'exécution isolé. Étant donné que les applications appartiennent à un Workspace spécifique, elles peuvent accéder aux ressources au niveau du Workspace, telles que les SQL Warehouses, et aux ressources au niveau du compte, telles que Unity Catalog. Les développeurs peuvent également choisir de partager des applications avec des utilisateurs en dehors du Workspace mais au sein du même compte Databricks.

Bien que le conteneur d'application s'exécute sur l'infrastructure Serverless 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 disponibles du plan de données Databricks. Pour plus d'information, consultez la présentation de l'architecture Databricks.

Pour lancer et gérer les apps, accédez à la section Apps de l'interface utilisateur du workspace.

Architecture et isolement

Les applications Databricks sont basées sur la même architecture que le compute serverless et bénéficient des mêmes couches d'isolation, notamment des ressources de compute dédiées, de la segmentation réseau, du chiffrement au repos et en transit, et du principe du moindre privilège. Pour plus de détails sur la configuration du réseau, consultez Configurer le réseau pour Databricks Apps.

URL de l'application

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

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

Où :

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

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 nouvelle application avec un nom différent.

Template

Une App Template est une structure préconfigurée qui aide les développeurs à start rapidement la création d'applications à l'aide d'un framework pris en charge. Chaque Template comprend une structure de fichier de base, un manifeste app.yaml, un fichier requirements.txt pour les applications Python et un exemple de code source.

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

• Utilisez requirements.txt pour répertorier les packages Python supplémentaires à installer avec pip, ou utilisez pyproject.toml pour la gestion des dépendances basée sur uv.
• Utilisez package.json pour lister les packages Node.js à installer avec npm.

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

Les développeurs peuvent générer une nouvelle application à partir d'un Template en utilisant l'UI Databricks ou le CLI.

Environnement système

Les Databricks Apps s'exécutent dans un environnement système préconfiguré géré par Databricks. Pour en savoir plus, consultez l'environnement Databricks Apps.

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

• Pour **Python**, utilisez requirements.txt pyproject.tomlou.
• Pour **Node.js**, package.jsonutilisez.

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

Lors du déploiement, 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 le default.

Voir Gérer les dépendances d'une application Databricks pour plus de détails.

Ressources de l'application

Les Ressources d'application sont des services natifs de Databricks dont une application dépend, tels que les SQL Warehouse, les endpoints de service de modèles, les Jobs, les secrets ou les volumes. Vous déclarez ces dépendances dans le manifeste databricks.yml à l'aide du champ resources. Databricks prend en charge les types de ressources suivants :

• SQL Warehouse
• Job
• Endpoint de service de modèle
• Genie Agent
• Secret
• Volume

Pour accéder aux services Databricks qui n'ont pas encore de type de ressource pris en charge, utilisez un secret géré par Unity Catalog pour injecter des identifiants en toute sécurité. Consultez Gestion des secrets.

Il y a deux étapes pour configurer les ressources d'application :

• **Déclaration (développement)** - Déclarez chaque ressource requise dans le databricks.yml manifeste. Ceci définit les Ressources dont l’application a besoin et les autorisations qu’elle requiert.
• Configuration (déploiement) - Lors du déploiement, utilisez l'interface utilisateur de Databricks Apps pour configurer les Ressources déclarées avec des instances spécifiques au Workspace (par exemple, en sélectionnant un SQL Warehouse spécifique).

Cette séparation entre la déclaration et la configuration permet aux applications d'être portables d'un environnement à l'autre. Par exemple, vous pouvez déployer le même code d’application dans un workspace de développement et le Link à un SQL Warehouse. En production, vous pouvez réutiliser le code et configurer un warehouse différent sans apporter de modifications au code. Pour prendre cela en charge, évitez de coder en dur les ID de ressources ou les valeurs spécifiques à l’environnement dans votre application.

Databricks applique le principe du moindre privilège. Les applications doivent utiliser des Ressources existantes et ne peuvent pas en créer de nouvelles. Lors du déploiement, les administrateurs du Workspace examinent et approuvent l'accès aux Ressources demandé par l'application. Le Service Principal de l'application reçoit les autorisations nécessaires, et le développeur de l'application doit avoir l'autorisation de les accorder.

Pour en savoir plus, consultez Ajouter des ressources à une application Databricks.

État de l'application

Une application peut avoir l'un des statuts suivants : En cours d'exécution , Arrêtée , En déploiement ou Plantée .

• En cours d'exécution – L'application est active et accessible. Databricks facture les ressources de compute utilisées pendant l’exécution de l’application.
• Arrêtée – L'application n'est pas accessible et n'entraîne aucun coût. Databricks préserve la configuration et l'environnement de l'application, ce qui vous permet de la redémarrer sans la reconfigurer.
• **Déploiement** — L'application démarre. Il n'est pas encore accessible et n'entraîne aucun frais à ce stade.
• Échec – L'application n'a pas pu start ou s'est arrêtée de manière inattendue. Il est inaccessible et n'entraîne pas de frais. Vous pouvez consulter les logs 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 le contexte dont l'application a besoin pour persister à travers les sessions utilisateur ou les interactions. Les applications ne conservent pas l'état en mémoire après les redémarrages. Toute donnée conservée en mémoire est perdue lorsque l'application s'arrête.

Vous pouvez stocker l'état des manières suivantes :

• Stockage en mémoire pour les données temporaires dans une seule 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 Databricks utilisant Databricks SQL pour les données structurées persistantes et les charges de travail analytiques.

• Fichiers Workspace pour données non structurées persistantes.

• Les volumes Unity Catalog pour les données non structurées persistantes avec la gouvernance Unity Catalog.

• Instances de base de données Lakebase pour les données relationnelles persistantes avec compatibilité PostgreSQL.

Les cas d'utilisation courants incluent la mise en cache des résultats de query, la sauvegarde des préférences utilisateur ou l'enregistrement des actions utilisateur entre les sessions.

Autorisation de l'application

Databricks Apps utilise OAuth 2.0 pour l'authentification et le contrôle d'accès. Chaque application possède deux identités complémentaires qui déterminent la manière dont elle s'authentifie et autorise l'accès aux ressources Databricks : autorisation d'application et autorisation d'utilisateur .

• Autorisation de l'application – Databricks crée automatiquement un Service Principal pour chaque application. Ce Service Principal agit comme l'identité de l'application et se voit accorder 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 de l’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 Databricks où l'application est déployée. Après s'être connecté via le Single Sign On (SSO), l'application peut utiliser les identifiants de l'utilisateur pour accéder à des Ressources régies comme un SQL Warehouse. Cela permet à l’application de respecter les autorisations affinées gérées par Unity Catalog sans accorder ces autorisations au Service Principal de l’application.

Les applications demandent des périmètres OAuth spécifiques dans leur manifeste pour contrôler les APIs et les Ressources auxquelles elles peuvent accéder. Ce modèle flexible prend en charge la sécurité de niveau entreprise et permet un contrôle d'accès granulaire.

Pour plus d'information, consultez Configurer l'autorisation dans une application Databricks.

Utilisateurs de l'application

Après le déploiement, les développeurs d'applications peuvent partager une application avec des utilisateurs ou des groupes en 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 workspace, mais ils doivent faire partie du même compte Databricks. Pour partager avec des utilisateurs externes, synchronisez-les d'abord dans le compte à l'aide de votre fournisseur d'identité. Pour plus d’informations, consultez Synchroniser les utilisateurs et les groupes depuis votre fournisseur d’identité à l’aide de SCIM.

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