Migrieren zur direkten Bereitstellungs-Engine

Declarative Automation Bundles wurde ursprünglich auf dem Databricks-Terraform-Anbieter zur Verwaltung von Bereitstellungen aufgebaut. Databricks CLI-Versionen 0.279.0 und höher unterstützen jedoch zwei verschiedene Bereitstellungsmodule: terraform und direct. Die direkte Bereitstellungs-Engine bietet erhebliche Vorteile und ist nicht von Terraform abhängig.

Neue Bündel, die mit Databricks CLI, Version 1.3.0 und höher erstellt wurden, verwenden standardmäßig das direkte Bereitstellungsmodul. Bundles, die noch die Terraform-Deployment-Engine verwenden, werden automatisch auf die Direct-Engine migriert, sodass keine Konfiguration erforderlich ist. Siehe Mit der direkten Bereitstellung beginnen.

Um eine automatische Migration zu verhindern, setzen Sie bundle.engine: terraform oder DATABRICKS_BUNDLE_ENGINE=terraform. Dies verhindert die automatische Migration in allen Databricks-CLI-Versionen. Auf den CLI-Versionen von Databricks bis 1.19 wird die Terraform-Engine weiterhin verwendet. Auf Databricks CLI Version 1.20.0 und höher führt dies zu einem Fehler. Siehe Direkte Bereitstellung eines neuen Bundles.

Vorteile der direkten Bereitstellung

Das neue direkte Bereitstellungsmodul verwendet das Databricks Go SDK und bietet die folgenden Vorteile:

• Schnellere Bereitstellungen: Bündelbereitstellungen sind bis zu 40% schneller.
• Leistungsfähigere und detailliertere Validierung und Planung: Detaillierte Diffs der Änderungen mit bundle plan -o json-Berichten, die feldbezogene Details bereitstellen und erklären, was eine bestimmte Aktion ausgelöst hat.
• Wiederverwendbare Pläne: bundle deploy --plan plan.json führt einen zuvor erstellten Plan aus, wodurch sichergestellt wird, dass nur genehmigte Aktionen in die Produktion gelangen und Bereitstellungen schneller erfolgen, da die Planberechnung übersprungen wird.
• Einfache Einrichtung: Probleme mit Firewalls, Proxys und benutzerdefinierten Anbieterregistrierungen werden vermieden.
• Weitere Ressourcen: Zusätzliche Ressourcen wie Kataloge, externe Standorte, AI Search-Endpunkte und Genie-Räume werden unterstützt.
• Unveränderliche Ordner: Objekte können optional in einem unveränderlichen, schreibgeschützten Ordner für Manipulationsschutz und Bereitstellungskonsistenz bereitgestellt werden. Siehe immutable_folder.

Mit der direkten Bereitstellung beginnen

Die Direct-Deployment-Engine ist der Standard für neue Bundles, die mit Databricks CLI Version 1.3.0 und höher erstellt wurden. In Databricks CLI Version 1.14 und höher werden Bundles, die die Terraform-Engine verwenden, beim Deployment automatisch zur Direct-Engine migriert.

In Databricks CLI Versionen 1.8 und höher kann man ein Bundle durch Setzen von engine: direct auf die direkte Engine migrieren. Siehe Direkte Bereitstellung eines neuen Bundles.

Direkte Bereitstellung eines neuen Bundles

Um die Direct Deployment Engine explizit einzustellen, machen Sie eines von Folgenden:

• Legen Sie bundle.engine in Ihrer databricks.yml fest.

  bundle:
    engine: direct
  

• Legen Sie die DATABRICKS_BUNDLE_ENGINE Umgebungsvariable fest, und stellen Sie Folgendes bereit:

  DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target
  

Wenn sowohl die Konfiguration als auch die Umgebungsvariable festgelegt sind, hat die Konfiguration Vorrang.

Vergleich der Deployment-Engines

Das neue direkte Bereitstellungsmodul verhält sich meist genauso wie das Terrform-Bereitstellungsmodul, aber es gibt einige Unterschiede.

Berechnung der Zustandsunterschiede von Ressourcen

Im Gegensatz zu Terraform, die einen einzelnen Ressourcenzustand (eine Mischung aus lokaler Konfiguration und Remotezustand) verwaltet, behält das neue Modul diese getrennt und zeichnet nur die lokale Konfiguration in der Zustandsdatei auf.

Die Ressourcenstatus-Diff-Berechnung erfolgt in zwei Schritten:

1. Die Konfiguration des lokalen Bundles wird mit der Schnappschusskonfiguration verglichen, die für die jüngste Bereitstellung verwendet wurde. Der Remotestatus spielt keine Rolle.
2. Der Status des entfernten Systems wird mit der Konfiguration des Snapshots verglichen, die für die jüngste Bereitstellung verwendet wurde.

Das Ergebnis ist:

• databricks.yml Ressourcenänderungen werden nie ignoriert und lösen immer eine Aktualisierung aus.
• Ressourcenfelder, die von der Implementierung nicht behandelt werden, lösen keinen inkonsistenten Ergebnisfehler aus. Diese Ressourcen werden von der direkten Engine erfolgreich bereitgestellt, dies kann jedoch zu einem Drift führen. Die bereitgestellten Ressourcen werden während des nächsten Plans oder der Bereitstellung aktualisiert.

Konfigurationseinstellungen entfernt

Die beiden Engines gehen unterschiedlich mit Einstellungen um, die Sie aus Ihrer Bundle-Konfiguration entfernen:

• Mit dem Terraform-Modul bleibt der entsprechende Wert auf der Plattform unverändert, wenn Sie ein Set-Feld aus Ihrem databricks.yml entfernen. Terraform verwaltet nur Felder, die explizit in der Konfiguration vorhanden sind, daher behält ein entferntes Feld den Wert bei, den es zum Zeitpunkt der letzten Bereitstellung hatte.
• Wenn Sie die direkte Engine verwenden, wird durch das Entfernen eines gesetzten Felds aus Ihrem databricks.yml der Wert auf den Standardwert der Ressource zurückgesetzt. Da das direkte Modul Ihre lokale Konfiguration mit der vorherigen Momentaufnahme vergleicht, wird ein feld, das nicht mehr vorhanden ist, als Änderung behandelt, und die Ressource wird in der nächsten Bereitstellung auf den Standardwert aktualisiert.

Um einen Wert beizubehalten, legen Sie ihn explizit in Ihrer Konfiguration fest, anstatt sich auf den zuvor bereitgestellten Wert zu verlassen.

Suche nach Ressourcensubstitutionen

Ressourcensubstitutionen sind zum Auflösen von Ressourcen-IDs verfügbar, z. B. ${resources.jobs.my_job.id}. Siehe Ersetzungen. Die Auflösung von Ressourcensubstitutionen in der direkten Bereitstellungs-Engine wird in zwei Schritten durchgeführt:

1. Verweise, die auf Felder verweisen, die in der lokalen Konfiguration vorhanden sind, werden in den in der lokalen Konfiguration angegebenen Wert aufgelöst.
2. Verweise, die in der lokalen Konfiguration nicht vorhanden sind, werden aus dem Remotezustand aufgelöst. Dies ist der Zustand, der mithilfe der entsprechenden GET Anforderung für eine bestimmte Ressource abgerufen wird.

Das Schema, das zum Auflösen einer ${resource.*} Ersetzung verwendet wird, befindet sich in der Datei out.fields.txt. Die Als gekennzeichneten ALL Felder und STATE können für die lokale Auflösung verwendet werden. Die Felder, die als ALL oder REMOTE markiert sind, können für die Remoteauflösung verwendet werden.

Ressourcenkompatibilität

Die folgenden Ressourcen erfordern das direkte Bereitstellungsmodul und werden vom Terraform-Bereitstellungsmodul nicht unterstützt:

• Cluster-Richtlinien
• Unity-Katalogkataloge
• Externe Speicherorte des Unity-Katalogs
• Unity-Katalog-Geheimnisse
• Genie-Räume
• Instanzenpools
• Auftragsausführungen
• Endpunkte für die KI-Suche
• MCP-Dienste
• Modellanbieter-Dienstleistungen
• Modelldienste
• Postgres Snapshot-Zeitpläne

Darüber hinaus ist das Feld lifecycle.started nur in der direkten Bereitstellungs-Engine und nur für apps, clusters und sql_warehouses verfügbar. Wenn true festgelegt ist, wird die Ressource im gestarteten Modus bereitgestellt. Siehe Lebenszyklus.