Partager via

Scripts d’initialisation pour les clusters présents dans l’étendue

  • Article

Les scripts init associés aux clusters de l’étendue sont des scripts init définis dans une configuration de cluster. Les scripts init associés aux clusters de l’étendue s’appliquent à la fois aux clusters que vous créez et à ceux qui ont été créés pour exécuter des travaux.

Vous pouvez configurer des scripts init associés aux clusters de l’étendue de trois façons : en utilisant l’interface utilisateur, en utilisant la CLI et en appelant l’API Clusters. Cette section décrit comment effectuer ces tâches à l’aide de l’interface utilisateur. Pour les autres méthodes, consultez l’interface CLI Databricks et l’API Clusters.

Vous pouvez ajouter n’importe quel nombre de scripts. Les scripts sont alors exécutés de manière séquentielle dans l’ordre indiqué.

Si un script init associé aux clusters de l’étendue retourne un code de sortie différent de zéro, le lancement du cluster échoue. Vous pouvez résoudre les problèmes liés aux scripts d’initialisation pour les clusters présents dans l’étendue en configurant la remise des journaux de cluster et en examinant le journal des scripts d’initialisation. Consultez Journalisation du script d'initialisation.

Configurer un script init associé aux clusters de l’étendue à l’aide de l’interface utilisateur

Cette section contient des instructions pour configurer un cluster afin d’exécuter un script d’initialisation à l’aide de l’interface utilisateur Azure Databricks.

Databricks recommande de gérer tous les scripts d’initialisation comme des scripts d’initialisation associés aux clusters de l’étendue. Si vous utilisez le calcul avec un mode d’accès partagé ou utilisateur unique, stockez les scripts d’initialisation dans des volumes Unity Catalog. Si vous utilisez le calcul avec un mode d’accès partagé, sans isolation, utilisez des fichiers de l’espace de travail pour les scripts d’initialisation.

Pour le mode d’accès partagé, vous devez ajouter des scripts d’initialisation à allowlist. Consultez Bibliothèques de listes d’autorisation et scripts d’initialisation sur le calcul partagé.

Pour utiliser l’interface utilisateur afin de configurer un cluster afin d’exécuter un script init, procédez comme suit :

  1. Dans la page de configuration de cluster, cliquez sur le bouton bascule Options avancées.
  2. En bas de la page, cliquez sur l’onglet Scripts init.
  3. Dans la liste déroulante Source, sélectionnez le type de source Espace de travail, Volume ou ABFSS.
  4. Spécifiez un chemin d’accès au script d’initialisation, comme l’un des exemples suivants :
    • Pour un script d’initialisation stocké dans votre répertoire de base avec des fichiers d’espace de travail : /Users/<user-name>/<script-name>.sh.
    • Pour un script d’initialisation stocké avec des volumes Unity Catalog : /Volumes/<catalog>/<schema>/<volume>/<path-to-script>/<script-name>.sh.
    • Pour un script d’initialisation stocké avec le stockage d’objets : abfss://container-name@storage-account-name.dfs.core.windows.net/path/to/init-script.
  5. Cliquez sur Ajouter.

En mode d’accès utilisateur unique, l’identité du principal attribué (un utilisateur ou un principal de service) est utilisée.

En mode d’accès partagé, l’identité du propriétaire du cluster est utilisée.

Remarque

Le mode d’accès partagé sans isolation ne prend pas en charge les volumes, mais utilise la même attribution d’identité que le mode d’accès partagé.

Pour supprimer un script dans la configuration de cluster, cliquez sur l’icône de la corbeille à droite du script. Lorsque vous confirmez la suppression, vous êtes invité à redémarrer le cluster. Si vous le souhaitez, vous pouvez supprimer le fichier de script de l’emplacement où vous l’aviez chargé.

Remarque

Si vous configurez un script d’initialisation à l’aide du type de source ABFSS, vous devez configurer les informations d’identification d’accès.

Databricks recommande d’utiliser les principaux de service Microsoft Entra ID pour gérer l’accès aux scripts d’initialisation stockés dans Azure Data Lake Storage Gen2. Utilisez la documentation liée suivante pour effectuer cette configuration :

  1. Créez un principal de service avec des autorisations de lecture et de liste sur les objets blob souhaités. Consultez Accéder au stockage en utilisant un principal de service et Microsoft Entra ID (Azure Active Directory).

  2. Enregistrez vos informations d’identification à l’aide de secrets. Consultez Gérer les secrets.

  3. Définissez les propriétés dans la configuration Spark et les variables d’environnement lors de la création d’un cluster, comme dans l’exemple suivant :

    Configuration Spark :

    spark.hadoop.fs.azure.account.auth.type.<storage-account>.dfs.core.windows.net OAuth
spark.hadoop.fs.azure.account.oauth.provider.type.<storage-account>.dfs.core.windows.net org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider
spark.hadoop.fs.azure.account.oauth2.client.id.<storage-account>.dfs.core.windows.net <application-id>
spark.hadoop.fs.azure.account.oauth2.client.secret.<storage-account>.dfs.core.windows.net {{secrets/<secret-scope>/<service-credential-key>}}
spark.hadoop.fs.azure.account.oauth2.client.endpoint.<storage-account>.dfs.core.windows.net https://login.microsoftonline.com/<tenant-id>/oauth2/token

    Variables d’environnement :

    SERVICE_CREDENTIAL={{secrets/<secret-scope>/<service-credential-key>}}

  4. (Facultatif) Refactoriser des scripts init en utilisant azcopy ou l’interface Azure CLI.

    Vous pouvez référencer des variables d’environnement définies pendant la configuration du cluster au sein de vos scripts init pour transmettre les informations d’identification stockées en tant que secrets pour la validation.

Avertissement

Les scripts init associés aux clusters de l’étendue sur DBFS sont en fin de vie. L’option DBFS dans l’interface utilisateur existe dans certains espaces de travail pour prendre en charge les charges de travail héritées, et n’est pas recommandée. Tous les scripts init stockés dans DBFS doivent être migrés. Pour obtenir les instructions de migration, consultez Migrer des scripts init depuis DBFS.

Résolution des problèmes liés aux scripts d’initialisation pour les clusters présents dans l’étendue

  • Le script doit exister à l’emplacement configuré. Si le script n’existe pas, les tentatives de démarrage du cluster ou de scale-up des exécuteurs entraînent l’échec.
  • Le script init ne peut pas avoir une taille supérieure à 64 Ko. Si un script dépasse cette taille, le démarrage du cluster échouera et un message d’erreur s’affichera dans le journal du cluster.