Bonnes pratiques pour les Databricks Apps

Cette page répertorie les bonnes pratiques importantes pour le développement et l'exécution de Databricks Apps. Ces lignes directrices se concentrent sur les exigences de sécurité, de performance et de plateforme.

Bonnes pratiques générales

• Utilisez les fonctionnalités natives de Databricks pour le traitement des données . Le compute d'application est optimisé pour le rendu d'interface utilisateur. Utilisez Databricks SQL pour les requêtes et les datasets, Lakeflow Jobs pour le traitement par lots et Model Serving pour les charges de travail d'inférence IA. Déchargez le traitement de données lourd vers ces services afin d'éviter les problèmes de performance. Testez votre application dans des conditions de charge prévues pour vérifier qu'elle satisfait à vos exigences.

• Implémenter la gestion de l'arrêt progressif . Votre application doit s'arrêter dans les 15 secondes suivant la réception d'un signal SIGTERM, ou elle se termine de force avec SIGKILL.

• Évitez les opérations privilégiées . Les applications s'exécutent en tant qu'utilisateurs non privilégiés et ne peuvent pas effectuer d'actions nécessitant des autorisations élevées, telles que l'accès root. Vous ne pouvez pas installer de packages au niveau du système à l’aide de gestionnaires de packages comme apt-get, yum ou apk. Utilisez plutôt les packages Python de PyPI ou les packages Node.js de npm pour gérer les dépendances de votre application.

• Comprenez la mise en réseau gérée par la plateforme. Les requêtes sont transmises par l'intermédiaire d'un proxy inverse, de sorte que votre application ne peut pas dépendre de l'origine des requêtes. Databricks gère la terminaison TLS et exige que les applications prennent en charge HTTP/2 en clair (H2C). N'implémentez pas la gestion TLS personnalisée.

• Liez-vous à l'hôte et au port corrects. Votre application doit écouter sur 0.0.0.0 et utiliser le port spécifié dans la variable d'environnement DATABRICKS_APP_PORT. Consultez Définir les variables d'environnement dans une application Databricks.

• Minimize container Startup time . Maintenez la logique d'initialisation légère pour réduire la latence de start à froid. Évitez les opérations bloquantes comme les installations de grandes dépendances ou les appels API externes pendant le Startup. Chargez les ressources lourdes uniquement lorsque cela est nécessaire.

• Journaliser dans la sortie standard et l'erreur standard . Databricks capture les logs des flux de sortie standard et d'erreur. Utilisez-les pour tous les logs afin qu'ils soient visibles dans l'interface utilisateur de Databricks. Évitez d'écrire des logs dans des fichiers locaux.

• **Gérez élégamment les erreurs inattendues**. Implémentez une gestion globale des exceptions pour éviter les plantages dus aux erreurs non détectées. Retourner des réponses d'erreur HTTP appropriées sans exposer les traces de pile ou les données sensibles.

• Utiliser uv pour la gestion des dépendances Python . Databricks recommande uv pour toutes les applications Python. Il offre des installations plus rapides, un fichier de verrouillage (uv.lock) pour des builds entièrement reproductibles et la possibilité d'utiliser n'importe quelle version de Python. Si vous utilisez requirements.txt, pin les numéros de version exacts pour garantir des environnements cohérents entre les versions.

• Valider et nettoyer les saisies utilisateur . Validez toujours les données entrantes et nettoyez-les pour éviter les attaques par injection ou les entrées mal formées, même dans les applications internes.

• Utilisez la mise en cache en mémoire pour les opérations coûteuses . Mettez en cache les données fréquemment utilisées telles que les résultats de query ou les réponses d'API pour réduire la latence et éviter le traitement redondant. Utilisez functools.lru_cache, cachetools, ou des bibliothèques similaires, et scopez soigneusement les caches dans les applications multi-utilisateurs.

• **Utilisez des modèles de requêtes asynchrones pour les Opérations de longue durée**. Évitez les requêtes synchrones qui attendent la fin des Opérations, et qui peuvent expirer. Au lieu de cela, effectuez une requête initiale pour start l’Opération, puis query périodiquement l’état de la Ressource ou l’Endpoint pour vérifier le statut d’achèvement.

Bonnes pratiques de sécurité

• Suivez le principe du moindre privilège . N'accorder que les autorisations nécessaires pour chaque utilisateur ou groupe. Utilisez CAN USE au lieu de CAN MANAGE, sauf si un contrôle total est requis. Voir les Bonnes pratiques pour les autorisations.

• Choisissez les méthodes d’authentification avec soin . Utilisez les Service Principal lorsque l'accès aux Ressources et aux données est le même pour tous les utilisateurs de l'application. N'implémentez l'authentification de l'utilisateur que dans les workspaces avec des auteurs d'applications de confiance et du code d'application revu par des pairs, lorsque l'application doit respecter les autorisations de l'utilisateur appelant.

• Utilisez des Service Principals dédiés pour chaque application . Ne partagez pas les identifiants Service Principal entre les applications ou les utilisateurs. N'accordez que les autorisations minimales nécessaires, telles que CAN USE ou CAN QUERY. Faites pivoter les identifiants Service Principal lorsque les créateurs d'applications quittent votre organisation. Consultez Gérer l'accès des applications aux ressources.

• Isoler les environnements d'applications . Utilisez différents espaces de travail pour séparer les applications de développement, de préproduction et de production. Cela empêche l'accès accidentel aux données de production pendant le développement et les tests.

• **Accédez aux données via un compute approprié**. Ne configurez pas votre application pour accéder ou traiter les données directement. Utilisez les SQL Warehouses pour les queries, Model Serving pour l'inférence d'IA et Lakeflow Jobs pour le traitement par batch.

• Gérer les secrets . N'exposez jamais de valeurs secrètes brutes dans les variables d'environnement. Utilisez valueFrom dans la configuration de votre application et faites pivoter les secrets régulièrement, surtout lorsque les rôles d'équipe changent. Voir les Bonnes pratiques.

• Minimisez les périmètres et enregistrez les actions de l'utilisateur . Lorsque vous utilisez l'autorisation utilisateur, demandez uniquement les périmètres dont votre application a besoin, et enregistrez toutes les actions utilisateur avec des enregistrements d'audit structurés. Consultez les bonnes pratiques d'autorisation des utilisateurs.

• Restreindre l'accès réseau sortant . Autorisez uniquement les domaines dont votre application a besoin, tels que les repository de package et les APIs externes. Utilisez le mode d'exécution à blanc et les Logs de refus pour valider votre configuration. Consultez les meilleures pratiques pour la configuration des politiques réseau.

• **Suivez les bonnes pratiques de codage sécurisé**. Paramétrez les queries SQL pour prévenir les attaques par injection et appliquez les directives générales de développement sécurisé, telles que la validation des entrées et la gestion des erreurs. Consultez API d'exécution d'instructions : Exécuter SQL sur les warehouse.

• Supervisez les activités suspectes . Examinez régulièrement les logs d'audit pour détecter les modèles d'accès inhabituels ou les actions non autorisées. Configurez des alertes pour les événements de sécurité critiques.