Konfiguration av Databricks Asset Bundle

I den här artikeln beskrivs syntaxen för Databricks Asset Bundle-konfigurationsfiler, som definierar Databricks-tillgångspaket. Se Vad är Databricks-tillgångspaket?.

Information om hur du skapar och arbetar med paket finns i Utveckla Databricks-tillgångspaket.

databricks.yml

Ett paket måste innehålla en (och endast en) konfigurationsfil med namnet databricks.yml i roten i paketprojektmappen. databricks.yml är huvudkonfigurationsfilen som definierar ett paket, men den kan referera till andra konfigurationsfiler, till exempel resurskonfigurationsfiler, i mappningen include . Paketkonfigurationen uttrycks i YAML. Mer information om YAML finns i den officiella YAML-specifikationen.

Det enklaste databricks.yml definierar paketnamnet, som ligger inom det nödvändiga mappningspaketet på den översta nivån, och en måldistribution.

bundle:
  name: my_bundle

targets:
  dev:
    default: true

Mer information om alla toppnivåmappningar finns i Mappningar.

Tips

Med Python-stöd för Databricks-tillgångspaket kan du definiera resurser i Python. Se Paketkonfiguration i Python.

Specifikation

Följande YAML-specifikation innehåller konfigurationsnycklar på toppnivå för Databricks-tillgångspaket. Konfigurationsreferens finns i Konfigurationsreferens.

# This is the default bundle configuration if not otherwise overridden in
# the "targets" top-level mapping.
bundle: # Required.
  name: string # Required.
  databricks_cli_version: string
  cluster_id: string
  deployment: Map
  git:
    origin_url: string
    branch: string

# This is the identity to use to run the bundle
run_as:
  - user_name: <user-name>
  - service_principal_name: <service-principal-name>

# These are any additional configuration files to include.
include:
  - '<some-file-or-path-glob-to-include>'
  - '<another-file-or-path-glob-to-include>'

# These are any additional files or paths to include or exclude.
sync:
  include:
    - '<some-file-or-path-glob-to-include>'
    - '<another-file-or-path-glob-to-include>'
  exclude:
    - '<some-file-or-path-glob-to-exclude>'
    - '<another-file-or-path-glob-to-exclude>'
  paths:
    - '<some-file-or-path-to-synchronize>'

# These are the default artifact settings if not otherwise overridden in
# the targets top-level mapping.
artifacts:
  <some-unique-artifact-identifier>:
    build: string
    dynamic_version: boolean
    executable: string
    files:
      - source: string
    path: string
    type: string

# These are for any custom variables for use throughout the bundle.
variables:
  <some-unique-variable-name>:
    description: string
    default: string or complex
    lookup: Map
    type: string

# These are the default workspace settings if not otherwise overridden in
# the targets top-level mapping.
workspace:
  artifact_path: string
  auth_type: string
  azure_client_id: string # For Azure Databricks only.
  azure_environment: string # For Azure Databricks only.
  azure_login_app_id: string # For Azure Databricks only. Reserved for future use.
  azure_tenant_id: string # For Azure Databricks only.
  azure_use_msi: true | false # For Azure Databricks only.
  azure_workspace_resource_id: string # For Azure Databricks only.
  client_id: string # For Databricks on AWS only.
  file_path: string
  google_service_account: string # For Databricks on Google Cloud only.
  host: string
  profile: string
  resource_path: string
  root_path: string
  state_path: string

# These are the permissions to apply to resources defined
# in the resources mapping.
permissions:
  - level: <permission-level>
    group_name: <unique-group-name>
  - level: <permission-level>
    user_name: <unique-user-name>
  - level: <permission-level>
    service_principal_name: <unique-principal-name>

# These are the resource settings if not otherwise overridden in
# the targets top-level mapping.
resources:
  apps:
    <unique-app-name>:
      # See the REST API create request payload reference for apps.
  clusters:
    <unique-cluster-name>:
      # See the REST API create request payload reference for clusters.
  dashboards:
    <unique-dashboard-name>:
      # See the REST API create request payload reference for dashboards.
  experiments:
    <unique-experiment-name>:
      # See the REST API create request payload reference for experiments.
  jobs:
    <unique-job-name>:
      # See REST API create request payload reference for jobs.
  model_serving_endpoint:
    <unique-model-serving-endpoint-name>:
    # See the model serving endpoint request payload reference.
  models:
    <unique-model-name>:
      # See the REST API create request payload reference for models (legacy).
  pipelines:
    <unique-pipeline-name>:
      # See the REST API create request payload reference for :re[LDP] (pipelines).
  quality_monitors:
    <unique-quality-monitor-name>:
    # See the quality monitor request payload reference.
  registered_models:
    <unique-registered-model-name>:
    # See the registered model request payload reference.
  schemas:
    <unique-schema-name>:
      # See the Unity Catalog schema request payload reference.
  secret_scopes:
    <unique-secret-scope-name>:
      # See the secret scope request payload reference.
  volumes:
    <unique-volume-name>:
    # See the Unity Catalog volume request payload reference.

# These are the targets to use for deployments and workflow runs. One and only one of these
# targets can be set to "default: true".
targets:
  <some-unique-programmatic-identifier-for-this-target>:
    artifacts:
      # See the preceding "artifacts" syntax.
    bundle:
      # See the preceding "bundle" syntax.
    default: boolean
    git: Map
    mode: string
    permissions:
      # See the preceding "permissions" syntax.
    presets:
      <preset>: <value>
    resources:
      # See the preceding "resources" syntax.
    sync:
      # See the preceding "sync" syntax.
    variables:
      <preceding-unique-variable-name>: <non-default-value>
    workspace:
      # See the preceding "workspace" syntax.
    run_as:
      # See the preceding "run_as" syntax.

Exempel

Det här avsnittet innehåller några grundläggande exempel som hjälper dig att förstå hur paket fungerar och hur du strukturerar konfigurationen.

Anteckning

Konfigurationsexempel som demonstrerar paketfunktioner och vanliga användningsfall för paket finns i Paketkonfigurationsexempel och paketexempellagringsplatsen i GitHub.

Följande exempelpaketkonfiguration anger en lokal fil med namnet hello.py som finns i samma katalog som paketkonfigurationsfilen databricks.yml. Det kör den här anteckningsboken som ett jobb på fjärrklustret med det angivna kluster-ID:t. Fjärrarbetsytans URL och arbetsytans autentiseringsuppgifter läses från anroparens lokala konfigurationsprofil med namnet DEFAULT.

bundle:
  name: hello-bundle

resources:
  jobs:
    hello-job:
      name: hello-job
      tasks:
        - task_key: hello-task
          existing_cluster_id: 1234-567890-abcde123
          notebook_task:
            notebook_path: ./hello.py

targets:
  dev:
    default: true

I följande exempel läggs ett mål med namnet prod till som använder en annan fjärrarbetsytas URL och autentiseringsuppgifter för arbetsytan, som läses från anroparens .databrickscfg-filens matchande host-post med den angivna arbetsytans URL. Det här jobbet kör samma notebook men använder ett annat fjärrkluster med angivet kluster-ID.

Anteckning

Databricks rekommenderar att du använder mappningen host i stället för mappningen default där det är möjligt, eftersom det gör paketkonfigurationsfilerna mer portabla. Om du anger mappningen host instrueras Databricks CLI att hitta en matchande profil i .databrickscfg filen och sedan använda profilens fält för att avgöra vilken Databricks-autentiseringstyp som ska användas. Om det finns flera profiler med ett matchande host fält måste du använda --profile alternativet för paketkommandon för att ange en profil som ska användas.

Observera att du inte behöver deklarera mappningen notebook_task inom mappningen prod, eftersom den återgår till att använda mappningen notebook_task inom den översta mappningen resources om inte mappningen notebook_task uttryckligen åsidosätts inom mappningen prod.

bundle:
  name: hello-bundle

resources:
  jobs:
    hello-job:
      name: hello-job
      tasks:
        - task_key: hello-task
          existing_cluster_id: 1234-567890-abcde123
          notebook_task:
            notebook_path: ./hello.py

targets:
  dev:
    default: true
  prod:
    workspace:
      host: https://<production-workspace-url>
    resources:
      jobs:
        hello-job:
          name: hello-job
          tasks:
            - task_key: hello-task
              existing_cluster_id: 2345-678901-fabcd456

Använd följande paketkommandon för att verifiera, distribuera och köra det här jobbet inom dev målet. Mer information om livscykeln för ett paket finns i Utveckla Databricks-tillgångspaket.

# Because the "dev" target is set to "default: true",
# you do not need to specify "-t dev":
databricks bundle validate
databricks bundle deploy
databricks bundle run hello_job

# But you can still explicitly specify it, if you want or need to:
databricks bundle validate
databricks bundle deploy -t dev
databricks bundle run -t dev hello_job

Verifiera, distribuera och kör det här jobbet inom prod målmiljön, i stället:

# You must specify "-t prod", because the "dev" target
# is already set to "default: true":
databricks bundle validate
databricks bundle deploy -t prod
databricks bundle run -t prod hello_job

Om du vill ha mer modularisering och bättre återanvändning av definitioner och inställningar i paket delar du upp paketkonfigurationen i separata filer:

# databricks.yml

bundle:
  name: hello-bundle

include:
  - '*.yml'

# hello-job.yml

resources:
  jobs:
    hello-job:
      name: hello-job
      tasks:
        - task_key: hello-task
          existing_cluster_id: 1234-567890-abcde123
          notebook_task:
            notebook_path: ./hello.py

# targets.yml

targets:
  dev:
    default: true
  prod:
    workspace:
      host: https://<production-workspace-url>
    resources:
      jobs:
        hello-job:
          name: hello-job
          tasks:
            - task_key: hello-task
              existing_cluster_id: 2345-678901-fabcd456

Mappningar

I följande avsnitt beskrivs paketkonfigurationens toppnivåmappningar. Konfigurationsreferens finns i Konfigurationsreferens.

• paket
• run_as
• inkludera
• synkronisering
• Artefakter
• Variabler
• arbetsyta
• Behörigheter
• Resurser
• Mål

bunt

En paketkonfigurationsfil får bara innehålla en mappning på den översta nivån bundle som associerar paketets innehåll och inställningarna för Azure Databricks-arbetsytan.

Den här bundle mappningen måste innehålla en name mappning som anger ett programmatiskt (eller logiskt) namn för paketet. I följande exempel deklareras ett paket med det programmatiska (eller logiska) namnet hello-bundle.

bundle:
  name: hello-bundle

En bundle mappning kan också vara underordnad ett eller flera av målen i den översta målmappningen . Var och en av dessa underordnade bundle mappningar anger eventuella icke-standard undantag på målobjektsnivå. Det går dock inte att åsidosätta värdet för toppnivåmappningen bundlename på målnivån.

kluster_id

Mappningen bundle kan ha en underordnad mappning cluster_id. Med den här mappningen kan du ange ID för ett kluster som ska användas som åsidosättning för kluster som definierats någon annanstans i paketkonfigurationsfilen. Information om hur du hämtar ID:t för ett kluster finns i Kluster-URL och ID.

Åsidosättningen cluster_id är avsedd för utvecklingsändamål och stöds endast för det målobjekt som har mappningen mode satt till development. Mer information om mappningen finns i targetmål.

compute_id

Anteckning

Den här inställningen är föråldrad. Använd cluster_id i stället.

Mappningen bundle kan ha en underordnad mappning compute_id. Med den här mappningen kan du ange ID för ett kluster som ska användas som åsidosättning för kluster som definierats någon annanstans i paketkonfigurationsfilen.

Git

Du kan hämta och åsidosätta information om Git-versionskontroll som är associerad med ditt paket, vilket är användbart för att sprida distributionsmetadata som kan användas senare för att identifiera resurser. Du kan till exempel spåra lagringsplatsens ursprung för ett jobb som distribueras av CI/CD.

När du kör ett bundle kommando som validate, deploy eller run, bundle fyller kommandots konfigurationsträd med följande standardinställningar:

• bundle.git.origin_url, som representerar lagringsplatsens ursprungs-URL. Det här är samma värde som du skulle få om du körde kommandot git config --get remote.origin.url från din klonade lagringsplats. Du kan använda ersättningar för att referera till det här värdet med dina paketkonfigurationsfiler, som ${bundle.git.origin_url}.
• bundle.git.branch, som representerar den aktuella grenen i repositoryt. Det här är samma värde som du skulle få om du körde kommandot git branch --show-current från din klonade lagringsplats. Du kan använda ersättningar för att referera till det här värdet med dina paketkonfigurationsfiler, som ${bundle.git.branch}.

Om du vill hämta eller åsidosätta Git-inställningar måste ditt paket finnas i en katalog som är associerad med en Git-lagringsplats, till exempel en lokal katalog som initieras genom att köra git clone kommandot. Om katalogen inte är associerad med en Git-lagringsplats är de här Git-inställningarna tomma.

Du kan åsidosätta inställningarna origin_url och branch i mappningen git av din toppnivåmappning bundle om det behövs, på följande sätt:

bundle:
  git:
    origin_url: <some-non-default-origin-url>
    branch: <some-non-current-branch-name>

databricks_cli_version

Mappningen bundle kan innehålla en databricks_cli_version mappning som begränsar den Databricks CLI-version som krävs av paketet. Detta kan förhindra problem som orsakas av mappningar som inte stöds i en viss version av Databricks CLI.

CLI-versionen av Databricks överensstämmer med semantisk versionshantering, och mappningen stöder specificering av versionsbegränsningar. Om det aktuella databricks --version värdet inte ligger inom de gränser som anges i paketets databricks_cli_version mappning uppstår ett fel när databricks bundle validate det körs i paketet. I följande exempel visas några vanliga syntaxer för versionsbegränsningar:

bundle:
  name: hello-bundle
  databricks_cli_version: '0.218.0' # require Databricks CLI 0.218.0

bundle:
  name: hello-bundle
  databricks_cli_version: '0.218.*' # allow all patch versions of Databricks CLI 0.218

bundle:
  name: my-bundle
  databricks_cli_version: '>= 0.218.0' # allow any version of Databricks CLI 0.218.0 or higher

bundle:
  name: my-bundle
  databricks_cli_version: '>= 0.218.0, <= 1.0.0' # allow any Databricks CLI version between 0.218.0 and 1.0.0, inclusive

kör_som

Inställningen run_as specificerar user_name eller service_principal_name som ska användas för att köra paketet. Det ger möjlighet att separera den identitet som används för att distribuera ett paketjobb eller en pipeline från den som används för att köra jobbet eller pipelinen.

Se Ange en körningsidentitet för ett Databricks Asset Bundles-arbetsflöde.

inkludera

Matrisen include anger en lista över sökvägsglober som innehåller konfigurationsfiler som ska ingå i paketet. Dessa sökvägsmönster är relativa till platsen för paketkonfigurationsfilen där dessa mönster anges.

Databricks CLI inkluderar inte några konfigurationsfiler som standard i paketet. Du måste använda matrisen include för att ange alla konfigurationsfiler som ska ingå i paketet, förutom databricks.yml själva filen.

Den här include matrisen kan bara visas som en mappning på den översta nivån.

Följande exempelkonfiguration innehåller tre konfigurationsfiler. Dessa filer finns i samma mapp som paketkonfigurationsfilen:

include:
  - 'bundle.artifacts.yml'
  - 'bundle.resources.yml'
  - 'bundle.targets.yml'

Följande exempelkonfiguration innehåller alla filer med filnamn som börjar med bundle och slutar med .yml. Dessa filer finns i samma mapp som paketkonfigurationsfilen:

include:
  - 'bundle*.yml'

synkronisering

Med sync mappningen kan du konfigurera vilka filer som ingår i dina paketdistributioner.

inkludera och exkludera

Mappningarna include och exclude i sync mappning anger en lista över filer eller mappar som ska inkluderas i eller exkluderas från paketdistributioner, beroende på följande regler:

• Baserat på en lista över fil- och sökvägsglober i en .gitignore fil i paketets rot kan mappningen include innehålla en lista över filglober, sökvägsglober eller båda, i förhållande till paketets rot, som uttryckligen ska inkluderas.
• Baserat på en lista över fil- och sökvägsglober i en .gitignore fil i paketets rot, plus listan över fil- och sökvägsglober i mappningen include , exclude kan mappningen innehålla en lista över filglober, sökvägsglober eller båda, i förhållande till paketets rot, som uttryckligen ska undantas.

Alla sökvägar till angivna filer och mappar är relativa till platsen för paketkonfigurationsfilen där de anges.

Syntaxen för include och exclude fil- och sökvägsmönster följer standardmönstersyntaxen .gitignore . Se gitignore-mönsterformat.

Om filen .gitignore till exempel innehåller följande poster:

.databricks
my_package/dist

Och paketkonfigurationsfilen innehåller följande include mappning:

sync:
  include:
    - my_package/dist/*.whl

Sedan ingår alla filer i my_package/dist mappen med filnamnstillägget *.whl . Andra filer i my_package/dist mappen ingår inte.

Men om paketkonfigurationsfilen också innehåller följande exclude mappning:

sync:
  include:
    - my_package/dist/*.whl
  exclude:
    - my_package/dist/delete-me.whl

Sedan ingår alla filer i my_package/dist mappen med filnamnstillägget *.whl, förutom filen med namnet delete-me.whl. Andra filer i my_package/dist mappen ingår inte heller.

Mappningen sync kan också deklareras i mappningen targets för ett specifikt mål. Alla sync mappningar som deklareras i ett mål sammanfogas med eventuella mappningsdeklarationer på den översta nivån sync . Om du till exempel fortsätter med föregående exempel sammanfogas följande include mappning på targets nivån med mappningen include i mappningen på den översta nivån sync :

targets:
  dev:
    sync:
      include:
        - my_package/dist/delete-me.whl

Stigar

Mappningen sync kan innehålla en paths mappning som anger lokala sökvägar som ska synkroniseras till arbetsytan. Med paths mappningen kan du dela vanliga filer mellan paket och kan användas för att synkronisera filer som finns utanför paketroten. (Paketroten är platsen för filen databricks.yml.) Detta är särskilt användbart när du har en enda lagringsplats som är värd för flera paket och vill dela bibliotek, kodfiler eller konfiguration.

Angivna sökvägar måste vara relativa till filer och kataloger som är förankrade i mappen där mappningen paths anges. Om ett eller flera sökvägsvärden går uppåt i katalogen till en överordnad mapp till paketroten, bestäms rotsökvägen dynamiskt för att säkerställa att katalogstrukturen förblir intakt. Om paketrotmappen till exempel heter my_bundle synkroniserar den här konfigurationen databricks.ymlcommon mappen som finns en nivå ovanför paketroten och själva paketroten:

sync:
  paths:
    - ../common
    - .

En distribution av det här paketet resulterar i följande mappstruktur på arbetsytan:

common/
  common_file.txt
my_bundle/
  databricks.yml
  src/
    ...

Artefakter

Mappningen på den översta nivån artifacts anger en eller flera artefakter som skapas automatiskt under paketdistributioner och kan användas senare i paketkörningar. Varje underordnad artefakt stöder följande mappningar:

• type krävs för Python-hjulbyggen. Om du vill skapa en Python-hjulfil innan du distribuerar ställer du in den på whl. För att skapa andra artefakter behöver den här inställningen inte anges.
• path är en valfri sökväg. Sökvägarna är relativa till platsen för paketkonfigurationsfilen. För Python-hjulversioner är det sökvägen till Python-hjulfilens setup.py fil. Om path inte ingår försöker Databricks CLI hitta Python-hjulfilens setup.py fil i paketets rot.
• files är en valfri mappning som innehåller en underordnad source mappning, som du kan använda för att ange de skapade artefakterna. Sökvägarna är relativa till platsen för paketkonfigurationsfilen.
• build är en valfri uppsättning icke-standardversionskommandon som du vill köra lokalt före distributionen. För Python-hjulversioner förutsätter Databricks CLI att det kan hitta en lokal installation av Python-paketet wheel för att köra versioner och kör kommandot python setup.py bdist_wheel som standard under varje paketdistribution. Ange flera kompileringskommandon genom att separera varje kommando med dubbel-ampersand-tecken (&&).
• dynamic_version gör det möjligt för paket att uppdatera hjulversionen baserat på tidsstämpeln för hjulfilen. Ny kod kan sedan distribueras utan att du behöver uppdatera versionen i setup.py eller pyproject.toml. Den här inställningen är endast giltig när type är inställd på whl.

I följande exempelkonfiguration skapas ett hjul med hjälp av Poetry. Ett komplett exempelpaket som används artifacts för att skapa ett hjul finns i Skapa en Python-hjulfil med databricks-tillgångspaket.

artifacts:
  default:
    type: whl
    build: poetry build
    path: .

En exempelkonfiguration som skapar en JAR och laddar upp den till Unity Catalog finns i Paket som laddar upp en JAR-fil till Unity Catalog.

Tips

Du kan definiera, kombinera och åsidosätta inställningarna för artefakter i paket enligt beskrivningen i Definiera artefaktinställningar i Databricks-tillgångspaket.

Variabler

Filen med paketinställningar kan innehålla en mappning på den översta nivån variables där anpassade variabler definieras. För varje variabel anger du en valfri beskrivning, standardvärde, om den anpassade variabeln är en komplex typ eller uppslag för att hämta ett ID-värde med följande format:

variables:
  <variable-name>:
    description: <variable-description>
    default: <optional-default-value>
    type: <optional-type-value> # "complex" is the only valid value
    lookup:
      <optional-object-type>: <optional-object-name>

Anteckning

Variabler antas vara av typen string, såvida inte type är inställt på complex. Se Definiera en komplex variabel.

Om du vill referera till en anpassad variabel i paketkonfigurationen använder du ersättningen ${var.<variable_name>}.

Mer information om anpassade variabler och ersättningar finns i Substitutioner och variabler i Databricks-tillgångspaket.

arbetsyta

Paketkonfigurationsfilen kan bara innehålla en mappning på den översta nivån workspace för att ange eventuella icke-standardinställningar för Azure Databricks-arbetsytor som ska användas.

Viktigt!

Giltiga sökvägar för Databricks-arbetsytor börjar antingen med /Workspace, eller /Volumes stöds också för artefakter. Anpassade arbetsytesökvägar prefixeras automatiskt med /Workspace, så om du använder någon ersättning för arbetsytesökväg ${workspace.file_path}, till exempel i din anpassade sökväg, behöver du inte lägga till /Workspace till sökvägen.

rotväg

Den här workspace mappningen kan innehålla en root_path mappning för att ange en icke-standardrotsökväg som ska användas på arbetsytan för både distributioner och körningar av arbetsflöden, till exempel:

workspace:
  root_path: /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/my-envs/${bundle.target}

Databricks CLI använder som standardinställning standardsökvägen root_path, som använder /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/${bundle.target}.

artefakt_sökväg

Den här workspace-mappningen kan också innehålla en artifact_path-mappning för att ange en icke-standardiserad artefaktsökväg att använda på arbetsytan för både distributioner och arbetsflödeskörningar, till exempel:

workspace:
  artifact_path: /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/my-envs/${bundle.target}/artifacts

Databricks CLI använder som standardinställning standardsökvägen artifact_path, som använder ${workspace.root}/artifacts.

Anteckning

Mappningen artifact_path stöder inte DBFS-sökvägar (Databricks File System).

filväg

Den här workspace mappningen kan också innehålla en file_path mappning för att ange en icke-standardfilsökväg som ska användas på arbetsytan för både distributioner och arbetsflödeskörningar, till exempel:

workspace:
  file_path: /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/my-envs/${bundle.target}/files

Databricks CLI använder som standardinställning standardsökvägen file_path, som använder ${workspace.root}/files.

tillståndsväg

Mappningen state_path har standardvägen ${workspace.root}/state och representerar sökvägen i din arbetsyta för att lagra information om Terraform-tillstånd för distributioner.

Andra mappningar för arbetsytor

Mappningen workspace kan också innehålla följande valfria mappningar för att ange den Azure Databricks-autentiseringsmekanism som ska användas. Om de inte anges i den här workspace mappningen måste de anges i en workspace mappning som underordnad ett eller flera av målen i den översta målmappningen .

Viktigt!

Du måste hårdkoda värden för följande workspace mappningar för Azure Databricks-autentisering. Du kan till exempel inte ange anpassade variabler för dessa mappningars värden med hjälp av syntaxen ${var.*} .

• När du kör kommandona "validate", "deploy", "run" och "destroy" med Databricks CLI, anger mappningen profile (eller alternativen --profile och -p) namnet på en konfigurationsprofil som ska användas med den här arbetsytan för Azure Databricks-autentisering. Den här konfigurationsprofilen mappar till den som du skapade när du konfigurerade Databricks CLI.

  Anteckning

  Databricks rekommenderar att du använder mappningen host (eller alternativen eller --profile-p när du kör paketet validerar, distribuerar, kör och förstör kommandon med Databricks CLI) i stället för mappningen profile , eftersom det gör paketkonfigurationsfilerna mer portabla. Om du anger mappningen host instrueras Databricks CLI att hitta en matchande profil i .databrickscfg filen och sedan använda profilens fält för att avgöra vilken Databricks-autentiseringstyp som ska användas. Om det finns flera profiler med ett matchande host fält i .databrickscfg filen måste du använda mappningen profile (eller kommandoradsalternativen --profile-p ) för att instruera Databricks CLI om vilken profil som ska användas. Ett exempel finns i måldeklarationen prod i exemplen.

• Mappningen host anger URL:en för din Azure Databricks-arbetsyta. Se URL per arbetsyta.

• För OAuth-autentisering från dator till dator (M2M) används mappningen client_id . Du kan också ange det här värdet i den lokala miljövariabeln DATABRICKS_CLIENT_ID. Eller så kan du skapa en konfigurationsprofil med client_id värdet och sedan ange profilens namn med mappningen profile (eller genom att använda --profile alternativen eller -p när du kör paketet validera, distribuera, köra och förstöra kommandon med Databricks CLI). Se Auktorisera obevakad åtkomst till Azure Databricks-resurser med ett tjänsthuvudnamn och OAuth.

  Anteckning

  Du kan inte ange ett hemligt Azure Databricks OAuth-värde i paketkonfigurationsfilen. Ange i stället den lokala miljövariabeln DATABRICKS_CLIENT_SECRET. Eller så kan du lägga till client_secret-värdet i en konfigurationsprofil och sedan ange profilens namn med profile-mappningen (eller genom att använda alternativen --profile eller -p när du kör kommandona validera, distribuera, köra, och förstöra i Databricks CLI).

• För Azure CLI-autentisering används mappningen azure_workspace_resource_id . Du kan också ange det här värdet i den lokala miljövariabeln DATABRICKS_AZURE_RESOURCE_ID. Eller så kan du skapa en konfigurationsprofil med azure_workspace_resource_id värdet och sedan ange profilens namn med mappningen profile (eller genom att använda --profile alternativen eller -p när du kör paketet validera, distribuera, köra och förstöra kommandon med Databricks CLI). Se Azure CLI-autentisering.

• För Azure-klienthemlig autentisering med tjänstens huvudnamn används mappningarna azure_workspace_resource_id, azure_tenant_idoch azure_client_id . Du kan också ange dessa värden i de lokala miljövariablerna DATABRICKS_AZURE_RESOURCE_ID, ARM_TENANT_IDrespektive , och ARM_CLIENT_ID. Eller så kan du skapa en konfigurationsprofil med azure_workspace_resource_idvärdena , azure_tenant_idoch azure_client_id och sedan ange profilens namn med mappningen profile (eller genom att använda --profile alternativen eller -p när du kör paketet validera, distribuera, köra och förstöra kommandon med Databricks CLI). Se Autentisering för MS Entra service principal.

  Anteckning

  Du kan inte ange ett Azure-klienthemlighetsvärde i paketkonfigurationsfilen. Ange i stället den lokala miljövariabeln ARM_CLIENT_SECRET. Eller så kan du lägga till azure_client_secret-värdet i en konfigurationsprofil och sedan ange profilens namn med profile-mappningen (eller genom att använda alternativen --profile eller -p när du kör kommandona validera, distribuera, köra, och förstöra i Databricks CLI).

• För Azure-autentisering av hanterade identiteter används mappningarna azure_use_msi, azure_client_idoch azure_workspace_resource_id . Du kan också ange dessa värden i de lokala miljövariablerna ARM_USE_MSI, ARM_CLIENT_IDrespektive , och DATABRICKS_AZURE_RESOURCE_ID. Eller så kan du skapa en konfigurationsprofil med azure_use_msivärdena , azure_client_idoch azure_workspace_resource_id och sedan ange profilens namn med mappningen profile (eller genom att använda --profile alternativen eller -p när du kör paketet validera, distribuera, köra och förstöra kommandon med Databricks CLI). Se autentisering av hanterade Azure-identiteter.

• Mappningen azure_environment anger Azure-miljötypen (till exempel Public, UsGov, Kina och Tyskland) för en specifik uppsättning API-slutpunkter. Standardvärdet är PUBLIC. Du kan också ange det här värdet i den lokala miljövariabeln ARM_ENVIRONMENT. Eller så kan du lägga till azure_environment-värdet i en konfigurationsprofil och sedan ange profilens namn med profile-mappningen (eller genom att använda alternativen --profile eller -p när du kör kommandona validera, distribuera, köra, och förstöra i Databricks CLI).

• Mappningen azure_login_app_id är inte i drift och är reserverad för intern användning.

• Mappningen auth_type anger vilken Azure Databricks-autentiseringstyp som ska användas, särskilt i fall där Databricks CLI härleder en oväntad autentiseringstyp. Se Auktorisera åtkomst till Azure Databricks-resurser.

Behörigheter

Mappningen på den översta nivån permissions anger en eller flera behörighetsnivåer som ska tillämpas på alla resurser som definierats i paketet. Om du vill använda behörigheter för en specifik resurs kan du läsa Definiera behörigheter för en specifik resurs.

Tillåtna behörighetsnivåer på den översta nivån är CAN_VIEW, CAN_MANAGEoch CAN_RUN.

I följande exempel i en paketkonfigurationsfil definieras behörighetsnivåer för en användare, grupp och tjänstens huvudnamn, som tillämpas på alla jobb, pipelines, experiment och modeller som definierats i resources paketet:

permissions:
  - level: CAN_VIEW
    group_name: test-group
  - level: CAN_MANAGE
    user_name: someone@example.com
  - level: CAN_RUN
    service_principal_name: 123456-abcdef

Resurser

Mappningen resources anger information om de Azure Databricks-resurser som används av paketet.

Den här resources mappningen kan visas som en mappning på den översta nivån, eller så kan den vara underordnad ett eller flera av målen i den översta målmappningen och innehåller noll eller en av de resurstyper som stöds. Varje resurstypmappning innehåller en eller flera enskilda resursdeklarationer, som var och en måste ha ett unikt namn. Dessa enskilda resursdeklarationer använder motsvarande objekts nyttolast för skapaåtgärdens begäran, som uttrycks i YAML, för att definiera resursen. Egenskaper som stöds för en resurs är motsvarande objekts fält som stöds.

Nyttolaster för begäran om att skapa operationer dokumenteras i Databricks REST API Reference, och kommandot visar alla objektscheman som stöds. Dessutom databricks bundle validate returnerar kommandot varningar om okända resursegenskaper finns i paketkonfigurationsfiler.

Följande exempelkonfiguration definierar en jobbresurs:

resources:
  jobs:
    hello-job:
      name: hello-job
      tasks:
        - task_key: hello-task
          existing_cluster_id: 1234-567890-abcde123
          notebook_task:
            notebook_path: ./hello.py

Mer information om resurser som stöds i paket samt vanliga konfigurationer och exempel finns i Databricks Asset Bundles-resurser och paketkonfigurationsexempel.

Mål

Mappningen targets anger en eller flera kontexter där Azure Databricks-arbetsflöden ska köras. Varje mål är en unik samling artefakter, Azure Databricks-arbetsyteinställningar och Azure Databricks-jobb- eller pipelineinformation.

Mappningen targets består av en eller flera målmappningar, som var och en måste ha ett unikt programmatiskt (eller logiskt) namn.

Den här targets mappningen är valfri men rekommenderas starkt. Om den anges kan den bara visas som en mappning på den översta nivån.

Inställningarna på den översta arbetsytan, artefakter och resursmappningar används om de inte anges i en targets mappning, men eventuella motstridiga inställningar åsidosättas av inställningarna i ett mål.

Ett mål kan också åsidosätta värdena för alla variabler på den översta nivån.

förval

Om du vill ange ett standardmål för paketkommandon anger du mappningen default till true. Det här målet med namnet dev är till exempel standardmålet:

targets:
  dev:
    default: true

Om ett standardmål inte har konfigurerats, eller om du vill verifiera, distribuera och köra jobb eller pipelines inom ett specifikt mål, använder -t du alternativet för paketkommandona.

Följande kommandon validerar, distribuerar och kör my_job inom målen dev och prod:

databricks bundle validate
databricks bundle deploy -t dev
databricks bundle run -t dev my_job

databricks bundle validate
databricks bundle deploy -t prod
databricks bundle run -t prod my_job

I följande exempel deklareras två mål. Det första målet har namnet dev och är standardmålet som används när inget mål har angetts för paketkommandon. Det andra målet har namnet prod och används endast när det här målet anges för paketkommandon.

targets:
  dev:
    default: true
  prod:
    workspace:
      host: https://<production-workspace-url>

läge och förinställningar

För att underlätta enkel utveckling och metodtips för CI/CD tillhandahåller Databricks Asset Bundles distributionslägen för mål som anger standardbeteenden för arbetsflöden för förproduktion och produktion. Vissa beteenden kan också konfigureras. Mer information finns i Distributionslägen för Databricks Asset Bundle.

Tips

Om du vill ange körningsidentiteter för paket kan du ange run_as för varje mål enligt beskrivningen i Ange en körningsidentitet för ett Databricks Asset Bundles-arbetsflöde.

Om du vill ange att ett mål ska behandlas som ett utvecklingsmål lägger du till mappningsuppsättningen mode i development. Om du vill ange att ett mål ska behandlas som ett produktionsmål lägger du till mappningsuppsättningen mode i production. Det här målet med namnet prod behandlas till exempel som ett produktionsmål:

targets:
  prod:
    mode: production

Du kan anpassa några av beteendena med hjälp av mappningen presets . En lista över tillgängliga förinställningar finns i Anpassade förinställningar. I följande exempel visas ett anpassat produktionsmål som prefix och taggar alla produktionsresurser:

targets:
  prod:
    mode: production
    presets:
      name_prefix: 'production_' # prefix all resource names with production_
      tags:
        prod: true

Om både mode och presets anges åsidosätter förinställningar standardlägets beteende. Inställningar för enskilda resurser åsidosätter förinställningarna. Om ett schema till exempel är inställt på UNPAUSED, men förinställningen trigger_pause_status är inställd på PAUSED, kommer schemat att återupptas.