Migrera till direktimplementeringsmotorn

Viktigt!

Den här funktionen är Experimentell.

Databricks Asset Bundles byggdes ursprungligen ovanpå Databricks Terraform-providern för att hantera distributioner. Databricks CLI version 0.279.0 och senare stöder dock i ett försök att bryta detta beroende två olika distribueringsmotorer: terraform och direct. Den direkta distributionsmotorn är inte beroende av Terraform och blir snart standard. Terraform-distributionsmotorn kommer så småningom att fasas ut.

Vilka är fördelarna med direkt distribution?

Den nya direktdistributionsmotorn använder Databricks Go SDK och ger följande fördelar:

• Inget krav på att ladda ned Terraform och terraform-provider-databricks före distributionen
• Undviker problem med brandväggar, proxyservrar och anpassade providerregister
• Detaljerade diff för tillgängliga ändringar med hjälp av bundle plan -o json
• Snabbare distribution
• Kortare tid för att släppa nya paketresurser eftersom det inte finns något behov av att anpassa sig till Terraform-providerversionen

Hur börjar jag använda direktdistribution?

Så här börjar du använda den nya direktdistributionsmotorn:

• För befintliga paket migrerar du dem med hjälp av databricks bundle deployment migrate.
• För nya paket distribuerar du dem med miljövariabeln inställd på DATABRICKS_BUNDLE_ENGINEdirect.

Migrera ett befintligt paket

Direktdistributionsmotorn använder sin egen JSON-tillståndsfil. Schemat skiljer sig från Terraform JSON-tillståndsfilen. Kommandot för migrering av paketdistribution konverterar Terrform-tillståndsfilen (terraform.tfstate) till direktdistributionstillståndsfilen (resources.json). Kommandot läser ID:n från den befintliga distributionen.

1. Utför en fullständig distribution med Terraform:

   databricks bundle deploy -t my_target
   

2. Migrera utplaceringen:

   databricks bundle deployment migrate -t my_target
   

3. Kontrollera att migreringen lyckades. Kommandot databricks bundle plan bör lyckas och det bör inte visa några ändringar.

   databricks bundle plan -t my_target
   

   • Om verifieringen misslyckades tar du bort den nya tillståndsfilen:

     rm .databricks/bundle/my_target/resources.json
     

   • Om verifieringen lyckades distribuerar du paketet för att synkronisera tillståndsfilen till arbetsytan:

     databricks bundle deploy -t my_target
     

Distribuera ett nytt paket direkt

Kommandot bundle migrate fungerar inte på paket som aldrig har distribuerats eftersom det inte finns någon tillståndsfil. Ange DATABRICKS_BUNDLE_ENGINE i stället miljövariabeln och distribuera:

DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target

Vilka är förändringarna i motorn för direktdistribution?

Den nya direktdistributionsmotorn fungerar mestadels på samma sätt som Terrform-distributionsmotorn, men det finns vissa skillnader.

Beräkning av resurstillståndsdeiff

Till skillnad från Terraform som upprätthåller ett enda resurstillstånd (en blandning av lokal konfiguration och fjärrtillstånd) behåller den nya motorn dessa separata och registrerar endast lokal konfiguration i sin tillståndsfil.

Beräkningen av resurstillståndsdiff görs i två steg:

1. Den lokala paketkonfigurationen jämförs med snapshotkonfigurationen som används för den senaste distributionen. Fjärrtillståndet spelar ingen roll.
2. Fjärrstatus jämförs med den snapshot-konfiguration som används för den senaste distributionen.

Resultatet är att:

• databricks.yml resursändringar ignoreras aldrig och utlöser alltid en uppdatering.
• Resursfält som inte hanteras av implementeringen utlöser inte ett inkonsekvent resultatfel. Dessa resurser distribueras framgångsrikt av direktverktyget, men detta kan resultera i en avvikelse. De distribuerade resurserna uppdateras under nästa plan eller distribution.

$resources ersättningssökning

Den vanligaste användningen av $resources är att lösa ersättnings-ID:er (till exempel $resources.jobs.my_job.id) som fungerar identiskt mellan Terraform- och direktdistributionsmotorerna.

Upplösningen av $resources-substitutionen i den direktutplaceringsmotorn (till exempel $resources.pipelines.my_pipeline.name) sker dock i två steg:

1. Referenser som pekar på fält som finns i den lokala konfigurationen matchas med det värde som anges i den lokala konfigurationen.
2. Referenser som inte finns i den lokala konfigurationen löses från fjärrtillståndet. Det här är tillståndet som hämtas med lämplig GET begäran för en viss resurs.

Schemat som används för $resource upplösning är tillgängligt i filen out.fields.txt. Fälten som har markerats som ALL och STATE kan användas för lokal lösning. Fälten som har markerats som ALL eller REMOTE kan användas för fjärrmatchning.