Templates de projet Declarative Automation Bundles

Les Bundles d'automatisation déclaratifs (anciennement appelés Bundles d'assets Databricks) décrivent les ressources Databricks telles que les jobs, les pipelines et les Notebooks sous forme de fichiers sources. Ils vous permettent d'inclure des métadonnées avec ces fichiers sources pour provisionner l'infrastructure et d'autres ressources, et de fournir une définition de bout en bout d'un projet, le tout packageé comme un projet déployable unique. Consultez Que sont les Declarative Automation Bundles ?

Les Template de bundle permettent aux utilisateurs de créer des bundles de manière cohérente et reproductible, en établissant des structures de dossiers, des étapes et des tâches de build, des tests et d'autres attributs d'Infrastructure-as-Code (IaC) DevOps communs à un pipeline de déploiement.

Par exemple, si vous exécutez régulièrement des jobs nécessitant des packages personnalisés avec une étape de compilation fastidieuse lors de l'installation, vous pouvez accélérer votre cycle de développement en créant un template de bundle qui spécifie un environnement de conteneur personnalisé.

Databricks fournit un ensemble de default bundle Templates, mais vous pouvez également créer des modèles de bundle personnalisés. Les utilisateurs peuvent ensuite initialiser des bundles en utilisant la commande bundle init, en spécifiant un default Template ou votre Template personnalisé.

Créer un bundle à l'aide d'un template

Pour utiliser un template de bundle Databricks pour créer votre bundle, utilisez la commande bundle init de l'interface CLI Databricks, en spécifiant le nom du template à utiliser, ou sélectionnez un template disponible lors de la création d'un bundle dans le workspace. Consultez Créer un bundle.

Par exemple, la commande suivante crée un bundle en utilisant le Template de bundle Python par default :

sh
databricks bundle init default-python

Pour utiliser un Template de bundle personnalisé, transmettez le chemin local ou l'URL distante du Template à la commande bundle init de la CLI Databricks.

Par exemple, la commande suivante utilise le Template dab-container-template créé dans le Tutoriel sur le Template de Bundle Personnalisé:

sh
databricks bundle init /projects/my-custom-bundle-templates/dab-container-template

Si vous ne spécifiez pas de Template, la commande bundle init vous invite à choisir parmi l’ensemble des default Templates disponibles.

Default bundle Template

Databricks fournit les templates de bundle par défaut suivants :

Modèle	Description
`default-minimal`	Un Template pour la création d'un bundle vide. Ce Template contient uniquement les fichiers requis et aucun exemple de code, et configure également les variables de catalogue essentielles. Cela vous permet de créer rapidement de nouveaux projets de bundle. Voir « default-minimal ».
`default-python`	Un Template pour l'utilisation de Python avec Databricks. Ce Template crée un bundle avec un Job et un pipeline ETL et nécessite uv. Voir default-python.
`default-scala`	Un Template pour l'utilisation de Scala avec Databricks. Ce Template crée un bundle qui construit un JAR Scala configuré pour être déployé sur un compute Serverless. Consultez default-scala.
`default-sql`	Un Template pour l'utilisation de SQL avec Databricks. Ce Template contient un fichier de configuration qui définit un Job qui exécute des queries SQL sur un SQL Warehouse. Consultez default SQL.
`dbt-sql`	Un Template qui s'appuie sur dbt-core pour le développement local et les bundles pour le déploiement. Ce Template contient la configuration qui définit un Job avec une tâche dbt, ainsi qu'un fichier de configuration qui définit des profils dbt pour les Jobs dbt déployés. Consultez dbt-sql.
`mlops-stacks`	Un Template full stack avancé pour démarrer de nouveaux projets MLOps Stacks. Consultez mlops-stacks et Declarative Automation Bundles for MLOps Stacks.
`pydabs`	Une version modifiée du template `default-python` qui utilise Python pour la configuration du bundle au lieu de YAML. Voir pydabs.

Modèle	Description
`default-minimal`	Un Template pour la création d'un bundle vide. Ce Template contient uniquement les fichiers requis et aucun exemple de code, et configure également les variables de catalogue essentielles. Cela vous permet de créer rapidement de nouveaux projets de bundle. Voir « default-minimal ».
`default-python`	Un Template pour l'utilisation de Python avec Databricks. Ce Template crée un bundle avec un Job et un pipeline ETL et nécessite uv. Voir default-python.
`default-scala`	Un Template pour l'utilisation de Scala avec Databricks. Ce Template crée un bundle qui construit un JAR Scala configuré pour être déployé sur un compute Serverless. Consultez default-scala.
`default-sql`	Un Template pour l'utilisation de SQL avec Databricks. Ce Template contient un fichier de configuration qui définit un Job qui exécute des queries SQL sur un SQL Warehouse. Consultez default SQL.
`dbt-sql`	Un Template qui s'appuie sur dbt-core pour le développement local et les bundles pour le déploiement. Ce Template contient la configuration qui définit un Job avec une tâche dbt, ainsi qu'un fichier de configuration qui définit des profils dbt pour les Jobs dbt déployés. Consultez dbt-sql.
`mlops-stacks`	Un Template full stack avancé pour démarrer de nouveaux projets MLOps Stacks. Consultez mlops-stacks et Declarative Automation Bundles for MLOps Stacks.
`pydabs`	Une version modifiée du template `default-python` qui utilise Python pour la configuration du bundle au lieu de YAML. Voir pydabs.

Template de bundle personnalisé

Les templates de bundle utilisent la syntaxe de templating de package Go, ce qui offre une flexibilité pour les templates de bundle personnalisés que vous pouvez créer. Consultez la documentation du template de package Go.

Template project structure

Au minimum, un projet de template de bundle doit avoir :

Un fichier databricks_template_schema.json à la racine du projet qui définit une propriété d'invite utilisateur pour le nom du projet de bundle. Voir le schéma du template.
Un fichier databricks.yml.tmpl situé dans un dossier template qui définit la configuration de tous les bundles créés avec le template. Si votre fichier databricks.yml.tmpl référence des Template de configuration *.yml.tmpl supplémentaires, spécifiez leur emplacement dans le mapping include. Voir les Template de configuration.

En outre, la structure de dossiers et les fichiers inclus du dossier du projet de Template de bundle template sont reproduits par les bundles créés avec le Template. Par exemple, si vous souhaitez que le Template génère un bundle avec un Notebook simple dans le dossier src et une définition de Job qui exécute le Notebook dans le dossier resources, vous organiseriez votre projet de Template comme suit :

basic-bundle-template
  ├── databricks_template_schema.json
  └── template
      └── {{.project_name}}
          ├── databricks.yml.tmpl
          ├── resources
          │   └── {{.project_name}}_job.yml.tmpl
          └── src
              └── simple_notebook.ipynb

astuce

Le nom du dossier du projet et le nom du fichier de définition du Job dans ce Template de bundle utilisent une variable de template. Pour des informations sur les assistants et variables de template, consultez Assistants et variables de template.

Schéma de template

Un projet de Template de bundle personnalisé doit contenir un fichier JSON databricks_template_schema.json à la racine du projet. Ce fichier définit les champs utilisés par l'interface CLI Databricks lorsque la commande bundle init est exécutée, tels que le texte d'invite.

Le fichier databricks_template_schema.json de base suivant définit une variable d'entrée project_name pour le projet de bundle, qui inclut le message d'invite et une valeur default. Il définit ensuite un message de succès pour l'initialisation du projet de bundle qui utilise la valeur de la variable en entrée dans le message.

JSON
{
  "properties": {
    "project_name": {
      "type": "string",
      "default": "basic_bundle",
      "description": "What is the name of the bundle you want to create?",
      "order": 1
    }
  },
  "success_message": "\nYour bundle '{{.project_name}}' has been created."
}

Champs du schéma de Template

Le fichier databricks_template_schema.json prend en charge la définition de variables d'entrée pour collecter des informations lors de l'initialisation du bundle à partir de votre utilisateur dans le champ properties, ainsi que des champs supplémentaires pour personnaliser l'initialisation.

Les variables d'entrée sont définies dans le champ properties du schéma de template. Chaque variable d'entrée définit les métadonnées nécessaires pour présenter une invite à l'utilisateur lors de l'initialisation du bundle. La valeur de la variable est ensuite accessible en utilisant la syntaxe de variable de Template, telle que {{.project_name}}.

Vous pouvez également définir les valeurs de certains champs pour personnaliser le processus d'initialisation du bundle.

Les champs de schéma pris en charge sont listés dans le tableau suivant.

Champ de schéma	Description
`properties`	Les définitions des variables d'entrée du template de bundle. Databricks vous recommande de définir au moins une variable d'entrée qui est le nom du projet de bundle.
`properties.<variable_name>`	Le nom de la variable d'entrée.
`properties.<variable_name>.default`	default à utiliser si une valeur n'est pas fournie par l'utilisateur avec `--config-file` dans le cadre de la commande `bundle init`, ou sur la ligne de commande lorsqu'elle est demandée.
`properties.<variable_name>.description`	Le message de prompt utilisateur associé à la variable d'entrée.
`properties.<variable_name>.enum`	Une liste de valeurs possibles pour la propriété, telles que `"enum": ["azure", "aws", "gcp"]`. Si ce champ est défini, le CLI Databricks présente les valeurs sous forme de liste en ligne de commande pour inviter l'utilisateur à sélectionner une valeur.
`properties.<variable_name>.order`	Un entier qui définit l'ordre relatif des propriétés d'entrée. Cela contrôle l’ordre dans lequel les invites pour ces variables d’entrée sont affichées sur la ligne de commande.
`properties.<variable_name>.pattern`	Le modèle d'expression régulière à utiliser pour valider l'entrée utilisateur, par exemple `"pattern": "^[^ .\\\\/]{3,}$"`. Pour la syntaxe d'expression régulière prise en charge, consultez https://github.com/google/re2/wiki/Syntax.
`properties.<variable_name>.pattern_match_failure_message`	Le message qui est affiché à l'utilisateur si la valeur saisie par l'utilisateur ne correspond pas au modèle spécifié, par exemple, `Project name must be at least 3 characters long and cannot contain the following characters: \"\\\", \"/\", \" \" and \".\"."`.
`properties.<variable_name>.skip_prompt_if`	Ignorez l'invite pour la variable d'entrée si ce schéma est déjà satisfait par la configuration présente. Dans ce cas, la valeur default de la propriété est utilisée à la place. Pour un exemple, consultez le template mlops-stacks. Seules `const` comparaisons sont prises en charge.
`properties.<variable_name>.skip_prompt_if.properties.<previous_variable_name>.const`	Si la valeur de `<previous_variable_name>` correspond à la constante configurée dans `skip_prompt_if`, l'invite pour `<variable_name>` sera ignorée.
`template_dir`	Le chemin d'accès au répertoire de Template, tel que `../default`. Cela permet des modèles génériques en autorisant plusieurs fichiers `databricks_template_schema.json` à référencer le même répertoire.
`welcome_message`	Le premier message à afficher avant de demander à l'utilisateur une entrée.
`success_message`	Le message à imprimer après l'initialisation réussie du Template.
`min_databricks_cli_version`	La version semver minimale de cette CLI Databricks que le template requiert. `databricks bundle init` échoue si la version de CLI est inférieure à cette version.
`version`	Réservé pour une utilisation future. La version du schéma. Ceci est utilisé pour déterminer si le schéma est compatible avec la version CLI actuelle.

Champ de schéma	Description
`properties`	Les définitions des variables d'entrée du template de bundle. Databricks vous recommande de définir au moins une variable d'entrée qui est le nom du projet de bundle.
`properties.<variable_name>`	Le nom de la variable d'entrée.
`properties.<variable_name>.default`	default à utiliser si une valeur n'est pas fournie par l'utilisateur avec `--config-file` dans le cadre de la commande `bundle init`, ou sur la ligne de commande lorsqu'elle est demandée.
`properties.<variable_name>.description`	Le message de prompt utilisateur associé à la variable d'entrée.
`properties.<variable_name>.enum`	Une liste de valeurs possibles pour la propriété, telles que `"enum": ["azure", "aws", "gcp"]`. Si ce champ est défini, le CLI Databricks présente les valeurs sous forme de liste en ligne de commande pour inviter l'utilisateur à sélectionner une valeur.
`properties.<variable_name>.order`	Un entier qui définit l'ordre relatif des propriétés d'entrée. Cela contrôle l’ordre dans lequel les invites pour ces variables d’entrée sont affichées sur la ligne de commande.
`properties.<variable_name>.pattern`	Le modèle d'expression régulière à utiliser pour valider l'entrée utilisateur, par exemple `"pattern": "^[^ .\\\\/]{3,}$"`. Pour la syntaxe d'expression régulière prise en charge, consultez https://github.com/google/re2/wiki/Syntax.
`properties.<variable_name>.pattern_match_failure_message`	Le message qui est affiché à l'utilisateur si la valeur saisie par l'utilisateur ne correspond pas au modèle spécifié, par exemple, `Project name must be at least 3 characters long and cannot contain the following characters: \"\\\", \"/\", \" \" and \".\"."`.
`properties.<variable_name>.skip_prompt_if`	Ignorez l'invite pour la variable d'entrée si ce schéma est déjà satisfait par la configuration présente. Dans ce cas, la valeur default de la propriété est utilisée à la place. Pour un exemple, consultez le template mlops-stacks. Seules `const` comparaisons sont prises en charge.
`properties.<variable_name>.skip_prompt_if.properties.<previous_variable_name>.const`	Si la valeur de `<previous_variable_name>` correspond à la constante configurée dans `skip_prompt_if`, l'invite pour `<variable_name>` sera ignorée.
`template_dir`	Le chemin d'accès au répertoire de Template, tel que `../default`. Cela permet des modèles génériques en autorisant plusieurs fichiers `databricks_template_schema.json` à référencer le même répertoire.
`welcome_message`	Le premier message à afficher avant de demander à l'utilisateur une entrée.
`success_message`	Le message à imprimer après l'initialisation réussie du Template.
`min_databricks_cli_version`	La version semver minimale de cette CLI Databricks que le template requiert. `databricks bundle init` échoue si la version de CLI est inférieure à cette version.
`version`	Réservé pour une utilisation future. La version du schéma. Ceci est utilisé pour déterminer si le schéma est compatible avec la version CLI actuelle.

Modèles de configuration

Un template de bundle personnalisé devrait contenir un fichier databricks.yml.tmpl dans un dossier template du projet de template de bundle qui est utilisé pour créer le fichier de configuration databricks.yml du projet de bundle. Des Template pour les fichiers de configuration de ressources peuvent être créés dans le dossier resources. Renseignez ces fichiers Template avec le Template de configuration YAML.

Les simples Templates de configuration d'exemple suivants pour databricks.yml et le *_job.yml associé établissent le nom du bundle et deux environnements cibles, et définissent un Job qui exécute le notebook dans le bundle, pour les bundles créés à l'aide de ce Template. Ces Template de configuration tirent parti des substitutions de bundle et des assistants de Template de bundle.

template/{{.project_name}}/databricks.yml.tmpl:

YAML
# databricks.yml
# This is the configuration for the bundle {{.project_name}}.

bundle:
  name: {{.project_name}}

include:
  - resources/*.yml

targets:
  # The deployment targets. See https://docs.databricks.com/en/dev-tools/bundles/deployment-modes.html
  dev:
    mode: development
    default: true
    workspace:
      host: {{workspace_host}}

  prod:
    mode: production
    workspace:
      host: {{workspace_host}}
      # Deploy to a folder whose write access is restricted to the deploying
      # identity. Avoid /Shared, which is writable by all workspace users.
      root_path: /Workspace/Production/.bundle/${bundle.name}
    
    {{- if not is_service_principal}}
    run_as:
      # This runs as {{user_name}} in production. Alternatively,
      # a service principal could be used here using service_principal_name
      user_name: {{user_name}}
    
    {{end -}}

template/{{.project_name}}/resources/{{.project_name}}_job.yml.tmpl:

YAML
# {{.project_name}}_job.yml
# The main job for {{.project_name}}

resources:
    jobs:
        
        {{.project_name}}_job:
        name: {{.project_name}}_job
        tasks:
            - task_key: notebook_task
            job_cluster_key: job_cluster
            notebook_task:
                notebook_path: ../src/simple_notebook.ipynb
        job_clusters:
            - job_cluster_key: job_cluster
            new_cluster:
                node_type_id: i3.xlarge
                spark_version: 13.3.x-scala2.12

Assistants de Template et variables

Les helpers de template sont des fonctions fournies par Databricks que vous pouvez utiliser dans vos fichiers de template pour obtenir des informations spécifiques à l'utilisateur à l'exécution ou interagir avec le moteur de template. Vous pouvez également définir vos propres variables de template.

Les aides Template suivantes sont disponibles pour les projets de Template de bundle Databricks. Pour plus d’information sur l’utilisation des Template et des variables Go, consultez Template Go.

Aide	Description
`{{url}}`	Un alias pour https://pkg.go.dev/net/url#Parse. Cela permet l'utilisation de toutes les méthodes de `url.URL`.
`{{regexp}}`	Un alias pour https://pkg.go.dev/regexp#Compile. Cela permet l'utilisation de toutes les méthodes de `regexp.Regexp`.
`{{random_int}}`	Renvoie, en tant qu'entier, un nombre pseudo-aléatoire non-négatif dans l'intervalle semi-ouvert (0,n).
`{{uuid}}`	Renvoie, sous forme de chaîne, un UUID qui est un identifiant universel unique de 128 bits (16 octets) tel que défini dans le RFC 4122. Cet ID est stable pendant la durée de l'exécution du template et peut être utilisé pour renseigner le champ `bundle.uuid` dans databricks.yml par les auteurs de templates.
`{{bundle_uuid}}`	Un identifiant unique pour le bundle. Plusieurs invocations de cette fonction retourneront le même UUID.
`{{pair}}`	Une paire clé-valeur. Ceci est utilisé avec l'assistant `map` pour générer des cartes à utiliser dans un Template.
`{{map}}`	Convertit une liste de paires en objet de mappage. Ceci est utile pour transmettre plusieurs objets aux templates définis dans le répertoire de la bibliothèque. Étant donné que la syntaxe de template de texte Go pour l'invocation d'un Template permet uniquement de spécifier un seul argument, cette fonction peut être utilisée pour contourner cette limitation. Par exemple, dans la ligne suivante, `{{template "my_template" (map (pair "foo" $arg1) (pair "bar" $arg2))}}`, `$arg1` et `$arg2` peuvent être référencés depuis l'intérieur de `my_template` comme `.foo` et `.bar`.
`{{smallest_node_type}}`	Renvoie le plus petit type de nœud.
`{{path_separator}}`	Le caractère de séparation de chemin pour le système d'exploitation. Il s'agit de `/` pour les systèmes basés sur Unix et de `\` pour Windows.
`{{workspace_host}}`	L'URL d'hôte du Workspace auquel l'utilisateur est actuellement authentifié.
`{{user_name}}`	Le nom complet de l'utilisateur qui initialise le template.
`{{short_name}}`	Le nom abrégé de l'utilisateur initialisant le Template.
`{{default_catalog}}`	Renvoie le catalogue Workspace default. S'il n'y a pas de default, ou si Unity Catalog n'est pas activé, cela renvoie une chaîne vide.
`{{is_service_principal}}`	Indique si l'utilisateur actuel est un Service Principal ou non.
`{{ skip <glob-pattern-relative-to-current-directory> }}`	Indique au moteur de Template d'ignorer la génération de tous les fichiers et répertoires qui correspondent au modèle de glob d'entrée. Pour un exemple, consultez le template mlops-stacks.

Aide	Description
`{{url}}`	Un alias pour https://pkg.go.dev/net/url#Parse. Cela permet l'utilisation de toutes les méthodes de `url.URL`.
`{{regexp}}`	Un alias pour https://pkg.go.dev/regexp#Compile. Cela permet l'utilisation de toutes les méthodes de `regexp.Regexp`.
`{{random_int}}`	Renvoie, en tant qu'entier, un nombre pseudo-aléatoire non-négatif dans l'intervalle semi-ouvert (0,n).
`{{uuid}}`	Renvoie, sous forme de chaîne, un UUID qui est un identifiant universel unique de 128 bits (16 octets) tel que défini dans le RFC 4122. Cet ID est stable pendant la durée de l'exécution du template et peut être utilisé pour renseigner le champ `bundle.uuid` dans databricks.yml par les auteurs de templates.
`{{bundle_uuid}}`	Un identifiant unique pour le bundle. Plusieurs invocations de cette fonction retourneront le même UUID.
`{{pair}}`	Une paire clé-valeur. Ceci est utilisé avec l'assistant `map` pour générer des cartes à utiliser dans un Template.
`{{map}}`	Convertit une liste de paires en objet de mappage. Ceci est utile pour transmettre plusieurs objets aux templates définis dans le répertoire de la bibliothèque. Étant donné que la syntaxe de template de texte Go pour l'invocation d'un Template permet uniquement de spécifier un seul argument, cette fonction peut être utilisée pour contourner cette limitation. Par exemple, dans la ligne suivante, `{{template "my_template" (map (pair "foo" $arg1) (pair "bar" $arg2))}}`, `$arg1` et `$arg2` peuvent être référencés depuis l'intérieur de `my_template` comme `.foo` et `.bar`.
`{{smallest_node_type}}`	Renvoie le plus petit type de nœud.
`{{path_separator}}`	Le caractère de séparation de chemin pour le système d'exploitation. Il s'agit de `/` pour les systèmes basés sur Unix et de `\` pour Windows.
`{{workspace_host}}`	L'URL d'hôte du Workspace auquel l'utilisateur est actuellement authentifié.
`{{user_name}}`	Le nom complet de l'utilisateur qui initialise le template.
`{{short_name}}`	Le nom abrégé de l'utilisateur initialisant le Template.
`{{default_catalog}}`	Renvoie le catalogue Workspace default. S'il n'y a pas de default, ou si Unity Catalog n'est pas activé, cela renvoie une chaîne vide.
`{{is_service_principal}}`	Indique si l'utilisateur actuel est un Service Principal ou non.
`{{ skip <glob-pattern-relative-to-current-directory> }}`	Indique au moteur de Template d'ignorer la génération de tous les fichiers et répertoires qui correspondent au modèle de glob d'entrée. Pour un exemple, consultez le template mlops-stacks.

Assistants de Template personnalisés

Pour définir vos propres assistants de Template, créez un fichier de Template dans le dossier library du projet de Template et utilisez la syntaxe de Template Go pour définir les assistants. Par exemple, le contenu suivant d'un fichier library/variables.tmpl définit les variables cli_version et model_name. Lorsque ce Template est utilisé pour initialiser un bundle, la valeur de la variable model_name est construite à l'aide du champ input_project_name défini dans le fichier de schéma du Template. La valeur de ce champ correspond à la saisie de l'utilisateur après une invite.

Go

{{ define `cli_version` -}}
    v0.240.0

{{- end }}

{{ define `model_name` -}}
    
    {{ .input_project_name }}-model

{{- end }}

Pour consulter un exemple complet, reportez-vous au fichier de variables de template MLOps-stacks.

Testez le bundle Template

Enfin, assurez-vous de tester votre Template. Par exemple, utilisez l’interface CLI Databricks pour initialiser un nouveau bundle à l’aide du Template défini dans les sections précédentes :

sh
databricks bundle init basic-bundle-template

Pour l'invite, What is your bundle project name?, saisissez my_test_bundle.

Une fois le bundle de test créé, le message de succès du fichier de schéma est affiché. Si vous examinez le contenu du dossier my_test_bundle, vous devriez voir ce qui suit :

my_test_bundle
   ├── databricks.yml
   ├── resources
   │  └── my_test_bundle_job.yml
   └── src
      └── simple_notebook.ipynb

Et le fichier databricks.yml et le Job sont maintenant personnalisés :

YAML
# databricks.yml
# This is the configuration for the bundle my-test-bundle.

bundle:
  name: my_test_bundle

include:
  - resources/*.yml

targets:
  # The 'dev' target, used for development purposes. See [_](https://docs.databricks.com/en/dev-tools/bundles/deployment-modes.html#development-mode)
  dev:
    mode: development
    default: true
    workspace:
      host: https://my-host.cloud.databricks.com

  # The 'prod' target, used for production deployment. See [_](https://docs.databricks.com/en/dev-tools/bundles/deployment-modes.html#production-mode)
  prod:
    mode: production
    workspace:
      host: https://my-host.cloud.databricks.com
      # Deploy to a folder whose write access is restricted to the deploying
      # identity. Avoid /Shared, which is writable by all workspace users.
      root_path: /Workspace/Production/.bundle/${bundle.name}
    run_as:
      # This runs as someone@example.com in production. Alternatively,
      # a service principal could be used here using service_principal_name
      user_name: someone@example.com

YAML
# my_test_bundle_job.yml
# The main job for my_test_bundle

resources:
    jobs:
        my_test_bundle_job:
        name: my_test_bundle_job
        tasks:
            - task_key: notebook_task
                job_cluster_key: job_cluster
                notebook_task:
                    notebook_path: ../src/simple_notebook.ipynb
        job_clusters:
            - job_cluster_key: job_cluster
                new_cluster:
                    node_type_id: i3.xlarge
                    spark_version: 13.3.x-scala2.12

Partager un Template personnalisé

Si vous souhaitez partager un Template de bundle avec d'autres utilisateurs, vous pouvez le stocker dans un système de contrôle de version avec n'importe quel fournisseur pris en charge par Git et auquel vos utilisateurs ont accès. Pour exécuter la commande bundle init avec une URL Git, assurez-vous que le fichier databricks_template_schema.json se trouve à l'emplacement racine par rapport à cette URL Git.

astuce

Vous pouvez placer le fichier databricks_template_schema.json dans un dossier différent, par rapport à la racine du bundle. Vous pouvez ensuite utiliser l'option --template-dir de la commande bundle init pour faire référence à ce dossier, qui contient le fichier databricks_template_schema.json.

Configurer un dossier de Template personnalisé dans le Workspace

info

Bêta

Cette fonctionnalité est en Bêta.

Des Template de bundles personnalisés peuvent être mis à disposition pour la création de bundles dans le Workspace.

Stockez votre Template de bundle dans un repository GitHub et configurez un dossier Git pour vous y connecter. Pour plus d'informations sur la configuration d'un dossier Git, consultez Cloner un référentiel.
En tant qu’administrateur de compte ou de Workspace, accédez à Paramètres dans le Workspace. Voir Gérer votre workspace.
Cliquez sur Développement .
Sous Declarative Automation Bundles , sélectionnez un dossier pour les templates personnalisés. Tous les Template de bundle personnalisés doivent être disponibles à la racine du dossier.
Lorsque la boîte de dialogue des autorisations apparaît, accordez à tous les utilisateurs l'accès CAN VIEW au dossier pour les Template personnalisés ou sélectionnez Ne pas accorder l'accès pour définir des autorisations plus granulaires.
1. Pour définir des autorisations plus granulaires, sélectionnez les trois points dans n'importe quel dossier et cliquez sur Afficher les détails .
2. Cliquez sur Partager dans le panneau Détails du dossier Git .
3. Choisissez qui peut modifier les Templates (CAN MANAGE) et qui peut créer des bundles à l'aide de Templates (CAN VIEW).
Pour plus d'informations sur les autorisations, consultez les ACLs de dossier et les ACLs de dossier Git.

Les Template dans ce dossier sont maintenant disponibles pour les utilisateurs lorsqu'ils créent des bundles dans le Workspace. Voir Créer un bundle.

Étapes suivantes

Parcourez les templates supplémentaires créés et maintenus par Databricks. Consultez le repository d'exemples de bundle sur GitHub.
Pour utiliser les piles MLOps avec des Template Declarative Automation Bundles, consultez Declarative Automation Bundles pour les piles MLOps.
En savoir plus sur la modélisation de package Go. Consultez la documentation du template de package Go.

Créer un bundle à l'aide d'un template​

Default bundle Template​

Template de bundle personnalisé​

Template project structure​

Schéma de template​

Champs du schéma de Template​

Modèles de configuration​

Assistants de Template et variables​

Assistants de Template personnalisés​

Testez le bundle Template​

Partager un Template personnalisé​

Configurer un dossier de Template personnalisé dans le Workspace​

Étapes suivantes​