Databricks : CI/CD avec Azure DevOps et 3 méthodes de déploiement de notebooks en masse, la 3eme va vous étonner !
Avant de parler de méthode de déploiement, on va parler un peu de Databricks et de CI/CD.
Il n’y a pas toujours besoin de mettre en place du CI/CD, surtout lorsqu’on a des usages “self-service” et que l’on travaille directement production. Mais par exemple lorsqu’on a besoin d’automatiser des traitements (ça doit tourner tous les jours en automatique ou en continu via du streaming) et que l’on veut pas tout casser en production en cas d’erreur suite à une modification de code. Dans ces cas là, il vaut mieux travailler sur différents environnements identiques et indépendants. Et notamment au moins avec un environnement de dev pour pouvoir coder et tester son code tranquillement avant de modifier la prod. Beaucoup de personnes écrivent des livres entiers sur le sujet, mais nous on va simplifier et résumer le CI/CD à 2 choses :
- bien gérer la vie de son code grâce à un contrôleur de sources (un repo) => je ne perds plus de code, je trace les modifications, je travaille à plusieurs…
- déployer facilement et de façon automatisée le code dans les différents environnements => j’appuie sur un bouton et ça part en prod !
Databricks est compatible avec ces usages de développement et de déploiement en continue pour tous vos projets de data science et de data engineer.
Tout d’abord, il est possible de se connecter nativement à Github, Bitbucket Cloud ou dans Azure DevOps et de synchroniser ses notebooks automatiquement dans un repository GIT. Personnellement, j’utilise surtout Azure DevOps qui est simple à utiliser et sécurisé donc adapté à un usage en entreprise. Pour savoir comment mettre ca en place, la documentation Databricks est plutôt complète: https://docs.azuredatabricks.net/user-guide/notebooks/azure-devops-services-version-control.html#notebook-integration
Attention, il va falloir mettre en place la synchro pour chaque notebook et après modification du notebook dans Databricks, surtout ne pas oublier de cliquer sur “Save now” et mettre un commentaire (un vrai commentaire avec la description de vos modifications, pas de “zezg” ou “ghherhe” !) pour lancer un commit et synchroniser avec le script du repo, sinon bah ça fait rien 
!
Une fois synchronisés, les notebooks se retrouvent alors dans le repo sous forme de fichiers textes Python, Scala, R ou SQL en fonction du type de notebook (même si ce notebook contient des blocks d’un autre langage).
Tout ces principes de synchro seront à mettre en place dans le workspace Databricks de développement seulement, pas besoin pour les autres environnements.
Maintenant lorsque vos développements sont terminés, vous allez vouloir déployer vos notebooks sur d’autre workspaces Databricks pour l’UAT, la Préprod, la Prod … il est possible d’utiliser aussi Azure DevOps et ses pipelines de Build et de Release :
- La partie Build va aller chercher les scripts dans le repo et générer un objet qu’on appelle un Artifact (l’équivalent d’un package de déploiement)
- La partie Release elle va récupérer l’Artifact et le déployer dans le workspace Databricks de l’environnement souhaité.
Sans rentrer trop dans les détails, le Build est simple, il suffit d’aller chercher les scripts dans le repo, la Release est un peu plus compliquée car il faut une méthode pour déployer les composants (code, notebooks…) et avec Azure DevOps il existe déjà des composants proposés par la communauté dans le marketplace :
Moi je vous propose une troisième solution de déploiement en masse de notebooks un peu plus “roots” via un script PowerShell :
Param(
[string]$apiKey,
[string]$rootDirectory,
[string]$uriroot
)
Set-Location -Path $rootDirectory
# Create directory
foreach($directory in Get-ChildItem ".\" -Recurse -Directory)
{
write-host $directory.FullName.Replace($rootDirectory,"")
$body = @{
path = $directory.FullName.Replace($rootDirectory,"").replace("\","/")
}
$bodyjson = (ConvertTo-Json $body)
$headers = @{
'Authorization' = "Bearer $apiKey"
}
$uri = "$uriroot/2.0/workspace/mkdirs"
Invoke-RestMethod -Method 'Post' -Uri $uri -Headers $headers -Body $bodyjson
}
# Deploy Notebooks
foreach($file in Get-ChildItem ".\" -Recurse -File -Filter "*.*")
{
write-host $file.FullName.Replace($rootDirectory,"")
$EncodedText = [System.Convert]::ToBase64String([System.IO.File]::ReadAllBytes($file.FullName))
$lng = ""
if($file.Extension -eq ".py")
{
$lng = "PYTHON"
}
elseif($file.Extension -eq ".scala")
{
$lng = "SCALA"
}
elseif($file.Extension -eq ".sql")
{
$lng = "SQL"
}
elseif($file.Extension -eq ".r")
{
$lng = "R"
}
else {
continue
}
$body = @{
content = $EncodedText
path = $file.FullName.Replace($rootDirectory,"").replace("\","/").replace($file.Extension,"")
language = $lng
overwrite = $TRUE
format = "SOURCE"
}
$bodyjson = (ConvertTo-Json $body)
$headers = @{
'Authorization' = "Bearer $apiKey"
}
$uri = "$uriroot/2.0/workspace/import"
Invoke-RestMethod -Method 'Post' -Uri $uri -Headers $headers -Body $bodyjson
}
L’intérêt de ce script PowerShell par rapport aux autres solutions est surtout qu’il fonctionnera aussi en dehors de Azure DevOps
Les paramètres en entré sont :
En local il s’appelle de cette façon : .\deploynotebooks.ps1 -apiKey « <accesKey> » -rootDirectory « C:\pathTo\notebooks » -uriroot https://westeurope.azuredatabricks.net/api
Et dans Azure DevOps, mettez le script quelque part dans votre repo et vous pourrez passer par une tache d’exécution de script PowerShell de votre pipeline de release :
Views:
2 168
One thought on “Databricks : CI/CD avec Azure DevOps et 3 méthodes de déploiement de notebooks en masse, la 3eme va vous étonner !”