Installer brugerdefinerede Python-biblioteker fra private PyPI på Databricks | af David Suarez

I dette blogindlæg vil jeg forklare, hvordan du integrerer dine private PyPI-depoter på Databricks-klynger trin for trin. Som et resultat vil du være i stand til at installere dine egne brugerdefinerede Python-biblioteker lige så nemt, som du normalt gør med de offentlige.

Denne metode åbner døren for deling af kode og biblioteker på tværs af datateams, mens versionering bevares. Desuden giver det mulighed for at anvende hybride kodningstilgange på Databricks, hvor du kan kombinere biblioteker skrevet på lokal maskine (korrekt testet og frigivet ved hjælp af CI/CD-pipelines) og Notebooks ved hjælp af disse biblioteker.

Bemærk: denne vejledning er fokuseret på Azure. Hvis du tilfældigvis arbejder på en anden cloud-udbyder, men du stadig er interesseret i dette emne, skal du fortsætte med at læse. Du vil højst sandsynligt også nemt kunne oversætte konceptet til andre miljøer.

Databricks giver en meget enkel måde at installere offentlige biblioteker på klynger på, så du kan installere dem med blot et par klik. Desværre, når det kommer til selvfremstillede brugerdefinerede biblioteker, er processen ikke så let.

I dette tilfælde er den mest populære løsning, som jeg hidtil har set, at pakke koden ind i et Python-hjul og uploade den til en Blob Storage, så du kan installere den som et DBFS-bibliotek. Den anden løsning, der blev fundet, er at installere et bibliotek direkte fra et Git Repository, så du skal angive Git URL og godkendelsesmetode. Selvom begge løsninger gør tricket, mangler vi noget meget vigtigt her: versionering.

Hvorfor biblioteksversionering er vigtig?

Når du skriver dine egne biblioteker, vil du nogle gange skrive kode, der er så skræddersyet til en specifik løsning, at genbrugsmulighederne ikke er for høje. I andre tilfælde kan du oprette en kodepakke med klasser og hjælpefunktioner, som du gerne vil dele med dine kolleger, så de ikke behøver at genopfinde hjulet. I begge tilfælde, hvis du fortsætter med at arbejde på dit bibliotek, vil du introducere ændringer, der kan ødelægge løsninger, der endda kører i produktion.

Den eneste måde at forhindre det i at ske og holde alle glade er ved at introducere biblioteksversionering. På denne måde kan hver løsning eller miljø bruge en anden fast version af biblioteket, og intet går i stykker, når der indføres ændringer.

Private PyPI-depoter på Databricks

Når vi vender tilbage til selvfremstillede biblioteker i Databricks, kommer ingen af ​​de tidligere præsenterede tilgange med en robust løsning til dette problem. Du kan enten uploade og vedligeholde Python-hjul med forskellige versionsnavne på Blob Storage eller frigive filialer på Git Repo. Selvom det gør tricket, vil det være svært at spore ændringerne af hver version tilbage, og du bliver nødt til at bygge og vedligeholde mekanismen selv, og endnu sværere, tilpasse dig alle brugerne af dit bibliotek. Med andre ord er disse klodsede løsninger på et allerede løst problem.

PyPI-lagre har eksisteret i årevis, og de mest populære Python-biblioteker derude er udgivet på en offentlig PyPI-repo. På samme måde kan du have dit eget PyPI-lager og også drage fordel af versionsfunktionerne – og du ønsker måske, at dette lager skal være privat, så dine organisationsbiblioteker ikke er offentligt tilgængelige for alle.

På Azure DevOps, det er super nemt at have dit eget private PyPI-lager. Du skal bare oprette en Artefakt feed, som under motorhjelmen har pakkelager til de mest almindelige programmeringssprog. Derefter kan du udgive din Python hjul der og drage fordel af alle funktionerne i det. For eksempel: evnen til at holde styr på, hvilken commit af din Git Repo hver version blev udgivet.

Så nu hvor jeg har forklaret nogle af fordelene ved at bruge et privat PyPI-lager til at beholde vores brugerdefinerede bibliotekers versioner, lad os se, hvordan vi kan integrere det på Databricks-klynger, så du er i stand til at installere dine brugerdefinerede biblioteker.

Forudsætninger

Sammenfattende har du brug for din brugerdefinerede Python-pakke offentliggjort i en Azure Artefakt feedog en KeyVault registreret som en hemmeligt omfang i en Databricks Arbejdsplads.

Hvis du er lidt vild og ikke ved, hvordan du kommer dertil endnu, er her en liste med alle forudsætninger med nogle nyttige links:

• Azure DevOps-projekt.
• Git Repo i Azure Repos (hvordan man opretter en Git-repo her).
• Python-kode i Git Repo med en setup.py for at generere et Python-hjul (hvordan man genererer et Python-hjul her).
• Artefaktfeed (hvordan man opretter et artefaktfeed her).
• Azure Pipeline YAML-fil i Git Repo for at generere og udgive Python-hjulet til artefaktfeedet (kode her).
• Registrer og kør Azure Pipeline fra YAML-fil (hvordan du gør det her).
• Azure Databricks Workspace.
• Azure Key Vault.
• Azure Key Vault registreret i Databricks Workspace som et hemmeligt omfang (hvordan gør du det her).

Min egen demo opsætning

Til denne artikel har jeg lavet en demo-opsætning, og det kan være godt for dig at se den for, hvis du ser en reference.

Python-pakken, som jeg bruger til demoen (kaldet “demopakke”) er meget enkel. Den indeholder kun et par funktioner, der genererer Dataframes med PySpark og Pandas. Som du kan se på billedet, er det også blevet udgivet til mit artefaktfeed kaldet “datalabartifacts”.

På Azure har jeg lige en ressourcegruppe med Databricks og Key Vault. Ydermere er Key Vault blevet registreret i Databricks som et Secret Scope med samme navn.

Målet med denne proces er at tillade de underliggende VM’er fra Spark Clusters i Databricks at integrere dit Private PyPI-lager, der findes i Artifact Feed, og at være i stand til at installere Python Libraries fra det.

1. Generer personlig adgangstoken på Azure DevOps

Fordi vores artefaktfeed er privat (og vi ønsker at holde det privat), skal vi sørge for en måde, hvorpå vores VM’er kan autentificere mod Arifact-feedet.

Desværre, efter at have lavet en masse research, er den sikreste måde at gøre det på, som jeg har fundet, at bruge et Azure DevOps Personal Access Tokens (PAT). Denne PAT er personlig og udstedt pr. DevOps-bruger, så Spark VM’erne vil bruge dette token til at udgive sig for at være brugeren til at udføre godkendelsen. Det betyder, at du i Artifact Feed-registret vil se, at udstederbrugeren er den, der downloader pakker. Desuden udløber PAT efter et år, så vær opmærksom på, at du bliver nødt til at forny den, før den udløber.

Rådet her er at oprette en servicekonto (falsk bruger i DevOps) med begrænset adgang og kun bruges til at generere denne PAT, og forny den inden udløbsdagen.

Under alle omstændigheder kan du generere et personligt adgangstoken fra Azure DevOps ved at klikke på Brugerindstillinger → Personlige adgangstokens → Ny token. Giv det et navn, angiv udløbstiden og tilladelserne til PAT (kun Læs om emballage er påkrævet). Når du er færdig, skal du kopiere det genererede token.

2. Tilføj tokenet som en hemmelighed i KeyVault

Det genererede token kan bruges til at hente pakker fra artefaktfeedet. Hvis dette bliver eksfiltreret uden for din organisation, kan dette være et stort problem. Det betyder, at hackere kan stjæle de softwarepakker, der er tilgængelige i Artifact Feeds.

Ingen ønsker, at det skal ske, så vi skal opbevare tokenet et sikkert sted, så vi kan bruge det uden at udsætte det som almindelig tekst. Til det skal vi oprette en ny hemmelighed i Azure Key Vault for at gemme den.

Gå til din nøgleboks, klik på Hemmeligheder → Generer/importérog opret en hemmelighed ved at give den et navn og bruge PAT-tokenet genereret i det forrige trin som værdi.

Bemærk: den anvendte nøgleboks skal være den, der er registreret i Databricks Workspace som hemmeligt omfang.

3. Tilføj miljøvariabel til Databricks-klyngen

Det er endelig tid til at hoppe ind i Databricks Workspace!

Gå til Beregn → vælg Klynge → Kofiguration, og fortsæt med at redigere den. Under Avancerede indstillingertilføje følgende Miljø Variabel:

PYPI_TOKEN={{secrets/YourSecretScopeName/pypitoken}}

På denne måde sætter vi en værdi fra en hemmelighed på det hemmelige omfang, der er forbundet med vores nøgleboks.

Bemærk: Glem ikke at erstatte Secret Scope og Secret navnene med dine egne.

4. Hent PyPI repository URL

Lad os gå tilbage til Azure DevOps et øjeblik og få URL’en til det private PyPI-lager.

For at gøre dette skal du klikke på Artefakter → vælg din Artifact Feed→ Tilslut til feed → pipog kopier derefter URL’en.

4. Opret Init Script til Databricks Clusters med den magiske sauce

Før jeg introducerer den magiske sauce, lad mig først forklare tricket.

Når du installerer et bibliotek på en Databricks-klynge ved hjælp af brugergrænsefladen, instruerer Databricks alle noder om at installere biblioteket individuelt, så de trækker pakken og fortsætter med installationen.

Dette betyder, at hvis vi ønsker at installere pakker fra private PyPI repositories i Databricks Clusters, skal hver node være i stand til at 1) finde den private PyPI-repo og 2) godkende den med succes.

For at gøre det, skal vi fortælle hver klynge node Pip-installation, hvad der er URL’en på den private PyPI-repo, og hvordan man godkender, i dette tilfælde ved at bruge token-godkendelsen. Stedet at gøre det er /etc/pip.conf fil, hvor vi skal tilføje en ny a extra-index-url.

I praksis kan vi opnå dette i Databricks ved at gøre brug af Init Scripts. Disse er Shell-scripts, der kører på hver node under klyngeinitialisering.