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 zijn gemaakt met eerdere versies van de CLI kunnen worden gemigrerd van de Terraform-implementatieengine naar de directe implementatie-engine. Zie Een bestaande bundel migreren.
Vanaf Databricks CLI-versie 1.14.0 worden bundels die nog steeds de Terraform-engine gebruiken, automatisch gemigreerd naar de directe engine na een implementatie waarvan de proefconversie zonder fouten verloopt. Als u zich wilt afmelden, stelt u dit in bundle.engine: terraform of DATABRICKS_BUNDLE_ENGINE=terraform. Zie Direct een nieuwe bundel implementeren.
Belangrijk
Databricks raadt aan om over te stappen naar de directe engine, aangezien de Terraform-deployment engine binnenkort zal worden uitgeschakeld. 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
Om de nieuwe engine voor directe implementatie te gaan gebruiken:
- Migreer bestaande bundels met behulp van
databricks bundle deployment migrate. Zie Een bestaande bundel migreren. - Voor nieuwe of bestaande bundels stelt u
engine: directin uw bundelconfiguratie in, of stelt u de omgevingsvariabeleDATABRICKS_BUNDLE_ENGINEin opdirect. Zie Direct een nieuwe bundel implementeren.
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.
Voer een volledige implementatie uit met Terraform:
databricks bundle deploy -t my_targetDe implementatie migreren:
databricks bundle deployment migrate -t my_targetNote
In Databricks CLI-versies 0.280.0 tot en met 1.4.x voert
bundle deployment migratebundle planuit en stopt de migratie als het plan acties bevat. In dat geval opnieuw deployen en de migratie opnieuw proberen. Als het alsnog niet lukt, kun je de plancontrole overslaan met .--noplancheckControleer of de migratie is geslaagd. Voer
databricks bundle planuit; dit zou moeten slagen en geen acties rapporteren.databricks bundle plan -t my_targetNote
Het plan kan wijzigingen aan resources rapporteren, zelfs wanneer uw lokale configuratie overeenkomt met de geïmplementeerde resource. Dit kan gebeuren omdat het vorige Terraform-statusbestand metagegevensvelden bevat die het platform na de implementatie vult, die niet aanwezig zijn in uw bundelconfiguratie. Deze verschillen zijn geen echte configuratiedrift en veranderen het gedrag van taken niet. De directe engine stemt ze bij de volgende
bundle deployop elkaar af. Voor details over hoe de direct engine diffs berekent, zie Berekening van verschillen in resourcestatus.Als de verificatie mislukt, verwijdert u het nieuwe statusbestand:
rm .databricks/bundle/my_target/resources.jsonAls 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. Voer in plaats daarvan een van de volgende handelingen uit:
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
- AI Search-eindpunten
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.