Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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 jsondetails per veld in rapporten, waarin wordt uitgelegd waardoor een bepaalde actie is geactiveerd. -
Herhaalbare plannen:
bundle deploy --plan plan.jsonvoert 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.enginein uw databricks.yml:bundle: engine: directStel de
DATABRICKS_BUNDLE_ENGINEomgevingsvariabele 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:
- De lokale bundelconfiguratie wordt vergeleken met de momentopnameconfiguratie die wordt gebruikt voor de meest recente implementatie. De afgelegen toestand speelt geen rol.
- De externe status wordt vergeleken met de momentopnameconfiguratie die wordt gebruikt voor de meest recente implementatie.
Het resultaat is dat:
-
databricks.ymlresourcewijzigingen 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.ymlverwijdert. 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.ymlverwijdert. 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:
- Verwijzingen naar velden die aanwezig zijn in de lokale configuratie, worden omgezet in de waarde die is opgegeven in de lokale configuratie.
- 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
GETaanvraag 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:
- Clusterbeleid
- Unity Catalog catalogi
- Externe locaties van Unity Catalog
- Unity Catalog-geheimen
- Genie-ruimten
- Exemplaargroepen
- Taakruns
- AI Search-eindpunten
- MCP-diensten
- Diensten van modelaanbieders
- Modelservices
- Postgres snapshot-planningen
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.