Freigeben über

Bereitstellungsmodi für Databricks-Ressourcenpakete

  • Artikel

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:

  • setzt allen Ressourcen, die nicht als Dateien oder Notebooks bereitgestellt werden, das Präfix [dev ${workspace.current_user.short_name}] voran und versieht jeden bereitgestellten Auftrag und jede bereitgestellte Pipeline dev mit einem Azure Databricks-Tag.
  • markiert alle zugehörigen bereitgestellten Delta Live Tables-Pipelines als development: true. Siehe Verwenden des Entwicklungsmodus zum Ausführen von Pipelineupdates.
  • Ermöglicht die Verwendung von --compute-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 --compute-id <cluster-id> in verwandten Aufrufen des bundle deploy-Befehls zu verwenden, können Sie die compute_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 auf, 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 zugehörigen bereitgestellten Delta Live Tables-Pipelines als development: false markiert 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 Verwalten von Dienstprinzipalen und Angeben einer Ausführungsidentität für einen Databricks Asset Bundles-Workflow.. Wenn Sie keine Dienstprinzipale verwenden, beachten Sie Folgendes:

    • ü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:

Voreinstellung Beschreibung
name_prefix Die Präfixzeichenfolge, die Ressourcennamen voranzustellen ist.
pipelines_development Gibt an, ob sich die Pipeline im Entwicklermodus befindet oder nicht. Gültige Werte sind true und false.
trigger_pause_status Ein Pausenstatus, der auf alle Trigger und Zeitpläne anzuwenden ist. Gültige Werte sind PAUSED und UNPAUSED.
jobs_max_concurrent_runs Die Anzahl maximal zulässiger gleichzeitiger Ausführungen für Aufträge.
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 Ressource schema.

Hinweis

Wenn sowohl mode als auch presets festgelegt ist, setzen Voreinstellungen das Standardverhalten außer Kraft, und Einstellungen einzelner Ressourcen setzen die Voreinstellungen außer Kraft. Wenn z. B. ein Zeitplan auf UNPAUSED, die trigger_pause_status-Voreinstellung aber auf PAUSED festgelegt ist, wird die Pause im Zeitplan beendet.

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