Migreren naar de engine voor directe implementatie

Declaratieve automatiseringsbundels zijn oorspronkelijk gebouwd op de Databricks Terraform-provider om implementaties te beheren. Databricks CLI-versies 0.279.0 en hoger ondersteunen echter twee verschillende implementatie-engines: terraform en direct. De engine voor directe implementatie biedt aanzienlijke voordelen en is niet afhankelijk van Terraform.

Nieuwe bundels die zijn gemaakt met Databricks CLI versie 1.3.0 en hoger, gebruiken standaard de engine voor directe implementatie. Bundels die nog steeds de Terraform-deployment-engine gebruiken, worden automatisch gemigrerd naar de directe engine, dus er is geen configuratie nodig. Zie Start met directe implementatie.

Om automatische migratie te voorkomen, zet bundle.engine: terraform of DATABRICKS_BUNDLE_ENGINE=terraform. Dit voorkomt automatische migratie voor alle Databricks CLI-versies. Op Databricks CLI-versies tot 1.19 wordt de Terraform-engine nog steeds gebruikt. Op Databricks CLI versie 1.20.0 en hoger resulteert dit in een foutmelding. Zie Direct een nieuwe bundel implementeren.

Belangrijk

In Databricks CLI versie 1.20.0 werd de Terraform-deployment-engine verwijderd. De Databricks CLI kan nog steeds bundels met Terraform-status automatisch migreren naar de directe engine, maar als de automatische migratie faalt, wordt de deployment afgebroken. Om de Terraform-implementatie-engine te blijven gebruiken, zet vast op Databricks CLI-versie 1.19. Zie Declarative Automation-bundels gebruiken binnenkort standaard de directe implementatie-engine.

Voordelen van directe implementatie

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

  • Snellere implementaties: bundelimplementaties zijn maximaal 40% sneller.
  • Krachtigere en gedetailleerdere validatie en planning: gedetailleerde verschillen in wijzigingen met bundle plan -o json details per veld in rapporten, waarin wordt uitgelegd waardoor een bepaalde actie is geactiveerd.
  • Herhaalbare plannen: bundle deploy --plan plan.json voert een eerder gemaakt plan uit, zodat alleen goedgekeurde acties in productie terechtkomen en implementaties sneller verlopen, omdat de berekening van het plan wordt overgeslagen.
  • Eenvoudige installatie: problemen met firewalls, proxy's en aangepaste providerregisters worden vermeden.
  • Meer bronnen: Aanvullende bronnen, zoals catalogi, externe locaties, AI Search-endpoints en Genie-ruimten, worden ondersteund.
  • Onveranderbare mappen: Assets kunnen desgewenst worden geïmplementeerd in een onveranderbare map met het kenmerk Alleen-lezen voor manipulatiebeveiliging en implementatieconsistentie. Zie immutable_folder.

Begin met directe implementatie

De directe deployment-engine is de standaard voor nieuwe bundels die zijn gemaakt met Databricks CLI versie 1.3.0 en hoger. In Databricks CLI versie 1.14 en hoger worden bundels die de Terraform-engine gebruiken automatisch gemigrerd naar de directe engine bij de deployment.

In Databricks CLI versies 1.8 en hoger kun je een bundel migreren naar de directe engine door engine: direct in te stellen. Zie Direct een nieuwe bundel implementeren.

Direct een nieuwe bundel implementeren

Om de direct deployment engine expliciet in te stellen, doe je een van de volgende:

  • Configureer bundle.engine in uw databricks.yml:

    bundle:
      engine: direct
    
  • Stel de DATABRICKS_BUNDLE_ENGINE omgevingsvariabele in en implementeer:

    DATABRICKS_BUNDLE_ENGINE=direct databricks bundle deploy -t my_target
    

Als zowel de configuratie als de omgevingsvariabele zijn ingesteld, heeft de configuratie voorrang.

Vergelijking van implementatie-engine

De nieuwe engine voor directe implementatie gedraagt zich meestal hetzelfde als de Terrform-implementatie-engine, maar er zijn enkele verschillen.

Berekening van verschillen in de status van resources

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.

Configuratie-instellingen verwijderd

De twee engines verwerken instellingen die u uit uw bundelconfiguratie verwijdert, anders:

  • Met de Terraform-engine blijft de overeenkomstige waarde ongewijzigd in het platform wanneer u een veld van het type set uit uw databricks.yml verwijdert. Terraform beheert alleen velden die expliciet aanwezig zijn in de configuratie, dus een verwijderd veld behoudt de waarde die het had op het moment van de laatste implementatie.
  • Met de directe engine wordt de waarde teruggezet naar de standaardwaarde van de resource wanneer u een ingesteld veld uit uw databricks.yml verwijdert. Omdat de directe engine uw lokale configuratie vergelijkt met de vorige momentopname, wordt een veld dat niet meer aanwezig is behandeld als een wijziging en wordt de resource bijgewerkt naar de standaardwaarde voor de volgende implementatie.

Als u een waarde wilt behouden, stelt u deze expliciet in uw configuratie in in plaats van te vertrouwen op de eerder geïmplementeerde waarde.

Opzoeken van vervanging van resources

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.

Resourcecompatibiliteit

De volgende resources vereisen de directe implementatie-engine en worden niet ondersteund met de Terraform-implementatie-engine:

Daarnaast is het lifecycle.started veld alleen beschikbaar in de engine voor directe implementatie, en alleen voor apps, clustersen sql_warehouses. Wanneer dit is ingesteld op true, wordt de resource uitgerold in de gestarte modus. Bekijk de levenscyclus.