Migreren naar de engine voor directe implementatie

Belangrijk

Deze functie is experimenteel.

Databricks Asset Bundles is oorspronkelijk gebouwd op de Databricks Terraform-provider om implementaties te beheren. In een poging om van deze afhankelijkheid af te stappen, ondersteunt Databricks CLI versie 0.279.0 en hoger echter twee verschillende implementatie-engines: terraform en direct. De engine voor directe implementatie is niet afhankelijk van Terraform en wordt binnenkort de standaardwaarde. De Terraform-implementatie-engine zal uiteindelijk verouderd verklaard worden.

Wat zijn de voordelen van directe implementatie?

De nieuwe engine voor directe implementatie maakt gebruik van de Databricks Go SDK en biedt de volgende voordelen:

• Geen vereiste om Terraform en terraform-provider-databricks vóór de implementatie te downloaden
• Vermijdt problemen met firewalls, proxy's en aangepaste providerregisters
• Gedetailleerde verschillen in beschikbare wijzigingen met gebruikmaking van bundle plan -o json
• Snellere implementatie
• Beperkte tijd om nieuwe bundelresources vrij te geven, omdat het niet nodig is om te worden afgestemd op de Terraform-providerrelease

Hoe begin ik met het gebruik van directe implementatie?

Om de nieuwe engine voor directe implementatie te gaan gebruiken:

• Migreer bestaande bundels met behulp van databricks bundle deployment migrate.
• Implementeer deze voor nieuwe bundels met de DATABRICKS_BUNDLE_ENGINE omgevingsvariabele ingesteld op direct.

Een bestaande bundel migreren

De engine voor directe implementatie maakt gebruik van een eigen JSON-statusbestand. Het schema verschilt van het Terraform JSON-statusbestand. Met de bundle deployment migrate opdracht wordt het Terrform-statusbestand (terraform.tfstate) geconverteerd naar het bestand met de directe implementatiestatus (resources.json). Met de opdracht worden id's van de bestaande implementatie gelezen.

1. Voer een volledige implementatie uit met Terraform:

   databricks bundle deploy -t my_target
   

2. De implementatie migreren:

   databricks bundle deployment migrate -t my_target
   

3. Controleer of de migratie is geslaagd. De databricks bundle plan opdracht moet slagen en er mogen geen wijzigingen worden weergegeven.

   databricks bundle plan -t my_target
   

   • Als de verificatie mislukt, verwijdert u het nieuwe statusbestand:

     rm .databricks/bundle/my_target/resources.json
     

   • Als de verificatie is geslaagd, implementeert u de bundel om het statusbestand te synchroniseren met de werkruimte:

     databricks bundle deploy -t my_target
     

Direct een nieuwe bundel implementeren

De bundle migrate opdracht werkt niet voor bundels die nog nooit zijn geïmplementeerd omdat er geen statusbestand is. Stel in plaats daarvan de DATABRICKS_BUNDLE_ENGINE omgevingsvariabele in en implementeer:

DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target

Wat zijn de wijzigingen in de engine voor directe implementatie?

De nieuwe engine voor directe implementatie gedraagt zich meestal hetzelfde als de Terrform-implementatie-engine, maar er zijn enkele verschillen. Met name de directe engine houdt de lokale en externe status van resources afzonderlijk bij en lost resourcevervangingen in twee stappen op.

Berekening van resourcestatusverschillen

In tegenstelling tot Terraform die één resourcestatus onderhoudt (een combinatie van lokale configuratie en externe status), houdt de nieuwe engine deze gescheiden en registreert deze alleen lokale configuratie in het statusbestand.

De status-diff-berekening van de bronnen wordt in twee stappen uitgevoerd:

1. De lokale bundelconfiguratie wordt vergeleken met de momentopnameconfiguratie die wordt gebruikt voor de meest recente implementatie. De afgelegen toestand speelt geen rol.
2. De externe status wordt vergeleken met de momentopnameconfiguratie die wordt gebruikt voor de meest recente implementatie.

Het resultaat is dat:

• databricks.yml resourcewijzigingen worden nooit genegeerd en activeren altijd een update.
• Resourcevelden die niet door de implementatie worden verwerkt, activeren geen inconsistente resultaatfout. Deze resources worden met succes uitgerold door het directe systeem, maar dit kan leiden tot een drift. De geïmplementeerde middelen worden bijgewerkt tijdens de eerstvolgende planning of implementatie.

opzoekactie voor bronvervanging

Resourcevervangingen zijn beschikbaar voor het oplossen van resource-id's, bijvoorbeeld ${resources.jobs.my_job.id}. Zie Vervangingen. De oplossing van resourcevervangingen in de engine voor directe implementatie wordt in twee stappen uitgevoerd:

1. Verwijzingen naar velden die aanwezig zijn in de lokale configuratie, worden omgezet in de waarde die is opgegeven in de lokale configuratie.
2. Verwijzingen die niet aanwezig zijn in de lokale configuratie, worden opgelost vanuit de externe staat. Dit is de status die wordt opgehaald met behulp van de juiste GET aanvraag voor een bepaalde resource.

Het schema dat wordt gebruikt om een ${resource.*} vervanging op te lossen, bevindt zich in het bestand out.fields.txt. De velden die zijn gemarkeerd als ALL en STATE kunnen worden gebruikt voor lokale resolutie. De velden die zijn gemarkeerd als ALL of REMOTE kunnen worden gebruikt voor externe resolutie.