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. Ihre Paketbereitstellungen können diese Verhaltensweisen mit einer einzeiligen Modusdeklaration verwenden, anstatt diese Standardverhaltensweisen manuell in Ihrer Paketkonfigurationsdatei anzugeben – und vielleicht dabei zu vergessen, eine von mehreren beabsichtigten Verhaltensweisen hinzuzufügen oder zu konfigurieren.

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

Die Bereitstellung eines Entwicklungsziels durch Ausführen des Befehls databricks bundle deploy -t <target-name> implementiert die folgenden Verhaltensweisen:

• setzt allen Ressourcen, die nicht als Dateien oder Notebooks bereitgestellt werden, das Präfix [dev ${workspace.current_user.userName}] 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 zugehörige bereitgestellte Aufträge an.
• aktiviert gleichzeitige Ausführungen für alle zugehörigen bereitgestellten Aufträge.

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

Die Bereitstellung eines Produktionsziels durch Ausführen des databricks bundle deploy -t <target-name>-Befehls implementiert die folgenden Verhaltensweisen:

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