Veelgestelde vragen over declaratieve automation-bundels

Dit artikel bevat veelgestelde vragen over declaratieve automation-bundels (voorheen bekend als Databricks Asset Bundles).

Waarom is de naam van Databricks Asset Bundles gewijzigd in Declarative Automation Bundles?

De nieuwe naam Declaratieve Automatiseringsbundels weerspiegelt nauwkeuriger het gebruik en de mogelijkheden van bundels. Bovendien veroorzaakt de term assets enige verwarring omdat het meer dan één betekenis heeft in Databricks. Deze naamwijziging veroorzaakt geen onderbrekingen. De bundle CLI-opdracht en al uw bestaande configuratie hoeven niet te worden gewijzigd.

Hoe gebruik ik declaratieve automation-bundles als onderdeel van mijn CI/CD-pijplijn in Azure Databricks?

U kunt declaratieve Automation-bundels gebruiken om assets te definiëren en programmatisch te beheren in uw Azure Databricks CI/CD-implementatie, waaronder meestal:

• Notebooks: Azure Databricks-notebooks vormen vaak een belangrijk onderdeel van data engineering- en data science-werkstromen. U kunt versiebeheer gebruiken voor notebooks en deze ook valideren en testen als onderdeel van een CI/CD-pijplijn. U kunt geautomatiseerde tests uitvoeren op notebooks om te controleren of ze werken zoals verwacht.
• Bibliotheken: beheer de bibliotheekafhankelijkheden die nodig zijn om de geïmplementeerde code uit te voeren. Gebruik versiebeheer voor bibliotheken en neem deze op in geautomatiseerde tests en validatie.
• Werkstromen: Lakeflow-taken bestaan uit taken waarmee u geautomatiseerde taken kunt plannen en uitvoeren met behulp van notebooks of Spark-taken.
• Gegevenspijplijnen: U kunt ook gegevenspijplijnen opnemen in CI/CD-automatisering, met behulp van Lakeflow-pijplijnen om gegevenspijplijnen te declareren.
• Infrastructuurconfiguratie omvat definities en inrichtingsgegevens voor clusters, werkruimten en opslag voor doelomgevingen. Infrastructuurwijzigingen kunnen worden gevalideerd en getest als onderdeel van een CI/CD-pijplijn, zodat ze consistent en foutloos zijn.

Waarom moet ik afzonderlijke ontwikkel- en productiedoelomgevingen hebben?

Met afzonderlijke ontwikkel- en productonomgevingen kunt u het volgende doen:

• Isoleer ontwikkelwijzigingen veilig, zodat ze niet per ongeluk invloed hebben op de productie.
• Voorkom duplicatie van code door resources aan te passen die moeten worden toegepast op een specifieke doelomgeving.
• Stroomlijn en vereenvoudig CI/CD met omgevingsspecifieke configuratie, zoals databasepaden, waarschuwingen en toegangsbeheer.
• Werkstromen hergebruiken in teams en omgevingen.

Gebruik doelen om bundelimplementatieomgevingen te definiëren. Zie doelen.

Hoe maak ik mijn bundels consistent in mijn organisatie?

Gebruik bundelsjablonen voor consistente structuur, om installatiefouten te verminderen en best practices te promoten. U kunt standaardbundelsjablonen gebruiken of u kunt uw eigen aangepaste bundelsjablonen maken. Zie de Declaratieve Automation Bundles-projectsjablonen.

Er is veel herhaling in mijn bundels, zoals dezelfde clusterdefinities. Wat is de beste manier om dit te doen?

Aangepaste variabelen zijn de beste manier om herhalingen te verwerken, evenals instellingen die contextspecifiek zijn. Zie Aangepaste variabelen.

Wat zijn enkele aanbevolen procedures bij het gebruik van bundels in mijn implementatiestroom?

Databricks raadt u het volgende aan:

• Overstappen van handmatige implementaties naar betrouwbare automatisering met behulp van met Git geïntegreerde werkstromen.
• Valideer uw CI/CD-pijplijn voordat u een bundel implementeert met behulp van databricks bundle validate.
• Afzonderlijke implementatiestappen om ervoor te zorgen dat wijzigingen worden gecontroleerd en bedoeld zijn.
• Parameteriseer omgevingen (dev, test, prod) met overschrijvingen om wijzigingen te isoleren.
• Voer integratietests na de implementatie uit om problemen vroegtijdig te ondervangen.
• Gebruik GitHub Actions, Azure DevOps of GitLab CI om deployments te activeren bij commits of het samenvoegen van pull-aanvragen.
• Houd bij wat er is geïmplementeerd, waar en wanneer, zodat elke implementatie wordt toegewezen aan een doorvoer- en bundelversie.

Hoe verplaats ik een bundelimplementatie van /Workspace/Shared?

Zet bundels uit op een locatie die jij of je team bezit in plaats van /Workspace/Shared, die toegankelijk is voor alle gebruikers van de werkruimte, zodat je least-privilege rechten kunt toepassen. Om een bestaande implementatie te verplaatsen:

1. Wijzig het doel root_path van /Workspace/Shared/... naar een specifieke locatie, zoals /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/${bundle.target} of een map van het team. Dit veld wordt bijvoorbeeld onder workspace op het doel gezet.workspace.root_path
2. Bevestig dat de bundel een permissions sectie definieert zodat de juiste identiteiten toegang behouden op de nieuwe locatie. Als dat niet zo is, voeg er dan een toe die het eigenaarsteam CAN_MANAGE verleent, en CAN_VIEW aan de groep users als de resources zichtbaar moeten blijven voor iedereen.
3. Implementeer opnieuw met databricks bundle deploy -t <target>, of laat je CI/CD-pijplijn de wijziging uitrollen. Om eerst de wijziging te bekijken, voer databricks bundle plan -t <target> uit.

Voor productie-implementaties implementeer je als service principal naar een pad dat eigendom is van het team. Zie Specificeer een run identity voor een Declarative Automation Bundles-workflow en Declarative Automation Bundles-implementatiemodi.

Kan ik bestaande taken, pijplijnen, dashboards en andere Databricks-objecten overzetten naar mijn bundel?

Ja. Gebruik de databricks bundle generate opdracht om een configuratiebestand te genereren voor een bestaande taak, pijplijn of dashboard in uw lokale bundel en gebruik databricks bundle deployment bind deze vervolgens om de bundelresource te binden aan de bijbehorende resource in de werkruimte. Dit is ideaal voor het integreren van bestaande werkstromen in gestructureerde, versiebeheer ontwikkelingsprocessen. Binding lost ook relatieve paden op naar absolute werkruimteverwijzingen, waardoor padfouten worden voorkomen.

Zie Migreer bestaande resources naar een bundel.

Hoe test ik mijn bundel iteratief?

U kunt sneller ontwikkelen met iteratieve implementaties en uitvoeringen:

• Valideren voordat u implementeert
• Incrementeel implementeren
• Alleen uitvoeren wat nodig is
• Bewerken en herhalen

Dit versnelt het testen en opsporen van fouten, vermindert het schakelen tussen contexten, maakt veiligere en snellere iteratie mogelijk zonder volledige herimplementaties en dwingt discipline af wanneer u naar productie gaat.