Freigeben über

Bereitstellungsmodi für Databricks-Ressourcenpakete

In diesem Artikel wird die Syntax für die Bereitstellungsmodi der Databricks-Ressourcenpakete beschrieben. Pakete ermöglichen die programmgesteuerte Verwaltung von Azure Databricks-Workflows. Weitere Informationen finden Sie unter Was sind Databricks-Ressourcenpakete?

In CI/CD-Workflows programmieren, testen und stellen Entwickler Lösungen in verschiedenen Phasen oder Modi bereit und führen sie aus. Der einfachste Satz von Modi umfasst zum Beispiel einen Entwicklungsmodus für die Vorproduktionsvalidierung, gefolgt von einem Produktionsmodus für geprüfte Ergebnisse. Databricks-Ressourcenpakete bieten eine optionale Sammlung von Standardverhaltensweisen, die jedem dieser Modi entsprechen. Um diese Verhaltensweisen für ein bestimmtes Ziel zu verwenden, legen Sie ein mode fest oder konfigurieren Sie presets für ein Ziel in der targets-Konfigurationszuordnung. Weitere Informationen zu targets finden Sie in der Zielzuordnung der Bundlekonfiguration.

Entwicklungsmodus

Um Ihr Paket im Entwicklungsmodus bereitzustellen, müssen Sie zuerst das mode-Mapping, als development festlegt, zum vorgesehenen Ziel hinzufügen. Beispielsweise wird dieses Ziel mit dem Namen dev als Produktionsziel behandelt:

targets:
  dev:
    mode: development

Beim Bereitstellen eines Ziels im Entwicklermodus durch Ausführen des Befehls databricks bundle deploy -t <target-name> werden die folgenden Verhaltensweisen implementiert, die anhand von Voreinstellungen angepasst werden können:

  • Fügt allen Ressourcen, die nicht als Dateien oder Notebooks bereitgestellt werden, das Präfix [dev ${workspace.current_user.short_name}] hinzu und versieht jeden bereitgestellten Auftrag und jede bereitgestellte Pipeline mit einem dev Azure Databricks-Tag.
  • Kennzeichnet alle verwandten bereitgestellten Lakeflow Spark Declarative Pipelines als development: true.
  • Ermöglicht die Verwendung von --cluster-id <cluster-id> in verwandten Aufrufen des bundle deploy-Befehls, wodurch alle vorhandenen Clusterdefinitionen außer Kraft gesetzt werden, die bereits in der zugehörigen Paketkonfigurationsdateien angegeben sind. Anstatt --cluster-id <cluster-id> in verwandten Aufrufen des bundle deploy-Befehls zu verwenden, können Sie die cluster_id-Zuordnung hier oder als untergeordnete Zuordnung der bundle-Zuordnung festlegen, auf die ID des zu verwendenden Clusters.
  • Hält alle Zeitpläne und Trigger für bereitgestellte Ressourcen wie Aufträge oder Qualitätsmonitore an. Heben Sie das Pausieren der Zeitpläne und Trigger für einen einzelnen Auftrag auf, indem Sie schedule.pause_status auf UNPAUSED festlegen.
  • Ermöglicht gleichzeitige Ausführungen für alle bereitgestellten Aufträge für eine schnellere Iteration. Deaktivieren Sie die gleichzeitigen Ausführungen für einen einzelnen Auftrag, indem Sie max_concurrent_runs auf 1 festlegen.
  • Deaktiviert die Bereitstellungssperre für eine schnellere Iteration. Diese Sperre verhindert Bereitstellungskonflikte, die im Entwicklungsmodus unwahrscheinlich sind. Aktivieren Sie die Sperre erneut, indem Sie bundle.deployment.lock.enabled auf true festlegen.

Produktionsmodus

Um Ihr Paket im Produktionsmodus bereitzustellen, müssen Sie zuerst das mode-Mapping, als production festlegt, zum vorgesehenen Ziel hinzufügen. Beispielsweise wird dieses Ziel mit dem Namen prod als Produktionsziel behandelt:

targets:
  prod:
    mode: production

Beim Bereitstellen eines Ziels im Produktionsmodus durch Ausführen des Befehls databricks bundle deploy -t <target-name> werden die folgenden Verhaltensweisen implementiert:

  • Überprüft, ob alle verwandten bereitgestellten Lakeflow Spark Declarative Pipelines als development: false gekennzeichnet sind.

  • überprüft, ob der aktuelle Git-Branch gleich dem Git-Branch ist, der im Ziel angegeben ist. Das Angeben eines Git-Branchs im Ziel ist optional und kann mit einer zusätzlichen git-Eigenschaft wie folgt erfolgen:

    git:
  branch: main

    Diese Validierung kann durch Angabe von --force bei der Bereitstellung außer Kraft gesetzt werden.

  • Databricks empfiehlt die Verwendung von Dienstprinzipalen für Produktionsbereitstellungen. Sie können dies durch Festlegen von run_as auf einen Dienstprinzipal erzwingen. Siehe Dienstprinzipale und Angeben einer Ausführungsidentität für einen Databricks-Ressourcenpaketworkflow. Wenn Sie keine Dienstprinzipale verwenden, beachten Sie die folgenden zusätzlichen Verhaltensweisen:

    • Überprüft, ob artifact_path-, file_path-, root_path- oder state_path-Zuordnungen nicht auf einen bestimmten Benutzer überschrieben werden.
    • überprüft, ob die Zuordnung von run_as und permissions angegeben sind, um zu verdeutlichen, welche Identitäten bestimmte Berechtigungen für die Bereitstellung haben.

  • Im Gegensatz zum folgenden Verhalten beim Festlegen des mode-Mapping auf development erlaubt das Festlegen des mode-Mapping auf production nicht das Überschreiben aller vorhandenen Clusterdefinitionen, die bereits in der zugehörigen Paketkonfigurationsdatei angegeben sind, zum Beispiel mithilfe der Option --compute-id <cluster-id> oder des compute_id-Mapping.

Benutzerdefinierte Voreinstellungen

Databricks Asset Bundles unterstützt konfigurierbare Voreinstellungen für Ziele, mit denen Sie die Verhaltensweisen für Ziele anpassen können. In der folgenden Tabelle sind die verfügbaren Voreinstellungen aufgeführt:

Hinweis

Sofern in der unten stehenden Tabelle keine Ausnahme angegeben ist, überschreiben Voreinstellungen das Verhalten des Standardmodus, wenn sowohl mode als auch presets festgelegt sind, und die Einstellungen einzelner Ressourcen überschreiben wiederum die Voreinstellungen. Wenn der max_concurrent_runs Auftrag beispielsweise 10 ist, die jobs_max_concurrent_runs Voreinstellung jedoch auf 20 festgelegt ist, beträgt die maximale Anzahl gleichzeitiger Ausführungen des Auftrags 10.

Voreinstellung Beschreibung
artifacts_dynamic_version Gibt an, ob die Version von whl Artefakten während der Bereitstellung dynamisch aktualisiert werden soll. Gültige Werte sind true und false. Wenn die artifacts.dynamic_version Konfigurationseinstellung der obersten Ebene angegeben ist, überschreibt sie diese Voreinstellung.
jobs_max_concurrent_runs Die Anzahl der maximal zulässigen gleichzeitigen Ausführungen von Aufträgen.
name_prefix Die Präfixzeichenfolge, die Ressourcennamen vorangestellt werden soll.
pipelines_development Gibt an, ob sich die Pipeline im Entwicklungsmodus befindet. Gültige Werte sind true und false.
source_linked_deployment Reserviert für zukünftige Verwendung. Gibt an, ob Ressourcen, die während der Bereitstellung erstellt wurden, auf Quelldateien im Arbeitsbereich statt auf deren Kopien im Arbeitsbereich verweisen.
tags Eine Reihe von Schlüssel-Wert-Tags, die für alle Ressourcen gelten, die Tags unterstützen, wozu Aufträge und Experimente gehören. Databricks Asset Bundles unterstützen keine Tags für die schema Ressource.
trigger_pause_status Ein Pausenstatus, der auf alle Trigger und Zeitpläne anzuwenden ist. Gültige Werte sind PAUSED und UNPAUSED.
Wenn mode auf development festgelegt ist, ist trigger_pause_status immer PAUSED.

Das folgende Beispiel zeigt eine benutzerdefinierte Konfiguration von Voreinstellungen für das Ziel mit dem Namen dev:

targets:
  dev:
    presets:
      name_prefix: 'testing_' # prefix all resource names with testing_
      pipelines_development: true # set development to true for pipelines
      trigger_pause_status: PAUSED # set pause_status to PAUSED for all triggers and schedules
      jobs_max_concurrent_runs: 10 # set max_concurrent runs to 10 for all jobs
      tags:
        department: finance
  • Last updated on