Migrieren zum direkten Bereitstellungsmodul

Von Bedeutung

Dieses Feature ist experimentell.

Databricks Asset Bundles wurde ursprünglich auf dem Databricks Terraform-Anbieter aufgebaut, um Bereitstellungen zu verwalten. Allerdings unterstützt Databricks CLI ab Version 0.279.0 zwei verschiedene Bereitstellungs-Engines: terraform und direct. Das direkte Bereitstellungsmodul hängt nicht von Terraform ab und wird bald zum Standard. Die Terraform-Bereitstellungsmaschine wird schließlich veraltet sein.

Was sind die Vorteile der direkten Bereitstellung?

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

• Keine Anforderung zum Herunterladen von Terraform und terraform-provider-databricks vor der Bereitstellung
• Vermeiden von Problemen mit Firewalls, Proxys und benutzerdefinierten Anbieterregistrierungen
• Detaillierte Diffs der verfügbaren Änderungsversionen mithilfe von bundle plan -o json
• Schnellere Bereitstellung
• Reduzierte Zeit zum Freigeben neuer Bündelressourcen, da keine Anpassung an die Terraform-Anbieterversion erforderlich ist

Wie beginne ich mit der direkten Bereitstellung?

So verwenden Sie das neue direkte Bereitstellungsmodul:

• Migrieren Sie vorhandene Bündel mithilfe von databricks bundle deployment migrate.
• Stellen Sie neue Bündel bereit, indem Sie die Umgebungsvariable DATABRICKS_BUNDLE_ENGINE auf direct festlegen.

Migrieren eines vorhandenen Bundles

Das direkte Bereitstellungsmodul verwendet eine eigene JSON-Zustandsdatei. Das Schema unterscheidet sich von der Terraform JSON-Zustandsdatei. Der Befehl zum Migrieren des Bundles konvertiert die Terrform-Zustandsdatei (terraform.tfstate) in die Direkte Bereitstellungsstatusdatei (resources.json). Der Befehl liest IDs aus einer bestehenden Bereitstellung.

1. Durchführen einer vollständigen Bereitstellung mit Terraform:

   databricks bundle deploy -t my_target
   

2. Migrieren Sie die Bereitstellung:

   databricks bundle deployment migrate -t my_target
   

3. Überprüfen Sie, ob die Migration erfolgreich war. Der databricks bundle plan Befehl sollte erfolgreich sein, und er sollte keine Änderungen anzeigen.

   databricks bundle plan -t my_target
   

   • Wenn die Überprüfung fehlgeschlagen ist, entfernen Sie die neue Statusdatei:

     rm .databricks/bundle/my_target/resources.json
     

   • Wenn die Überprüfung erfolgreich war, stellen Sie das Bundle bereit, um die Statusdatei mit dem Arbeitsbereich zu synchronisieren:

     databricks bundle deploy -t my_target
     

Direkte Bereitstellung eines neuen Bundles

Der bundle migrate Befehl funktioniert nicht für Bundles, die noch nie bereitgestellt wurden, da keine Zustandsdatei vorhanden ist. Legen Sie stattdessen die Umgebungsvariable DATABRICKS_BUNDLE_ENGINE fest, und stellen Sie Folgendes bereit:

DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target

Was sind die Änderungen im direkten Bereitstellungsmodul?

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

Ressourcenzustands-Differenzberechnung

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 erfolgreich von der Direkt-Engine bereitgestellt. Dies kann allerdings zu einer Abweichung führen. Die bereitgestellten Ressourcen werden während des nächsten Plans oder der Bereitstellung aktualisiert.

$resources Ersetzungssuche

Die häufigste Verwendung von $resources besteht darin, Ersetzungs-IDs (z. B. $resources.jobs.my_job.id) aufzulösen, die sich identisch zwischen den Terraform- und direkten Bereitstellungsengines verhalten.

Die Auflösung der $resources Substitution in der direkten Deployment-Engine (z. B. $resources.pipelines.my_pipeline.name) wird jedoch 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 für die $resource-Auflösung verwendet wird, ist in der Datei out.fields.txt verfügbar. 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.