Cet article est le 1er d’une série de 3 articles sur l’automatisation des déploiements Databricks :

1. Déploiement d’un Workspace Databricks dans Azure avec Terraform
2. Paramétrage d’un workspace Databricks par Terraform
3. Pipelines de déploiement d’un environnement Databricks (Infra, paramétrage, notebooks,…)

Nous allons voir dans cet article un exemple de déploiement d’un workspace Databricks en utilisant des scripts Terraform.
Nous déploierons un workspace sur lequel nous contrôlons les flux réseaux afin de restreindre les accès à un Data Lake et à un coffre de clé.
Vous trouverez le code source ici

Création basique d’un workspace Databricks

Commençons par la création d’un workspace simple :

resource "azurerm_databricks_workspace" "this" {
  name                          = "dbw-blog-dev-01"
  location                      = "francentrale"
  resource_group_name           = "rg-blog-dev-01"
  sku                           = "standard"
}

Ces quelques lignes de Terraform créent un workspace Databricks, mais pas seulement. Si vous allez voir dans la liste de vos groupes de ressources, vous pouvez voir qu’un nouveau groupe de ressources a été créé.

Cette capture d’écran est un exemple où mon groupe de ressources contenant le workspace Databricks s’appelle « rg-blog-dev-01 ». On voit que Databricks a créé le groupe de ressources « databricks-rg-rg-blog-dev-01 ». Si on parcourt ce groupe de ressources, on peut y voir un Virtual Network, un Network Security Group, un Storage Account et une User Managed Identity :

Dans ce groupe de ressources vous verrez apparaitre d’autres ressources (principalement des VM) quand vous créerez des clusters.
Vous ne pouvez pas supprimer ce groupe de ressources ni les ressources qui y sont associées. Seule la suppression du workspace Databricks le fera disparaitre.

Prise de contrôle sur la création des ressources

On peut très bien laisser Databricks gérer ce groupe de ressources mais ne serait-ce que pour la convention de nommage des ressources, il peut être intéressant de garder un minimum de contrôle sur celles-ci. De plus, si vous devez contrôlez les flux réseaux qui entrent ou sortent de Databricks, vous aurez besoin d’avoir la main sur le Virtual Network créé.

Pour cela, nous allons utiliser la propriété « custom_parameters » dans notre script terraform :

resource "azurerm_databricks_workspace" "this" {
  name                          = "dbw-blog-dev-01"
  location                      = "francentrale"
  resource_group_name           = "rg-blog-dev-01"
  sku                           = "premium"
  managed_resource_group_name   = "rg-blog-dev-02"
  public_network_access_enabled = true

  custom_parameters {
    storage_account_name                                 = "stblogdev01"
    storage_account_sku_name                             = "Standard_LRS"
    virtual_network_id                                   = azurerm_virtual_network.this.id
    public_subnet_name                                   = azurerm_subnet.public.name
    private_subnet_name                                  = azurerm_subnet.private.name
    public_subnet_network_security_group_association_id  = azurerm_network_security_group.public.id
    private_subnet_network_security_group_association_id = azurerm_network_security_group.private.id
  }

  depends_on = [
    azurerm_subnet_network_security_group_association.public,
    azurerm_subnet_network_security_group_association.private,
  ]
}

Dans ce script, nous prenons la main sur la création des ressources grâce aux paramètres suivants :

• managed_resource_group_name : nous définissons le nom du groupe de ressources créé par Databricks. Mais c’est la seule chose sur laquelle nous prenons la main car nous n’avons aucun droit. Ce groupe de ressources ne doit pas préalablement exister, sinon la création du workspace tombe en erreur
• storage_account_name : nous définissons le nom du compte de stockage créé par Databricks. Ce compte de stockage ne doit pas préalablement exister, il sera créé dans le groupe de ressources « managed_resource_group_name »
• storage_account_sku_name : SKU du compte de stockage (LRS, GRS, …)
• virtual_network_id : identifiant du Virtual Network de Databricks. Il est à créer préalablement. Vous pouvez ainsi contrôler les flux entrants et sortants de Databricks
• public_subnet_name et private_subnet_name : les subnets Databricks. Il faut un subnet pour la partie privée et un autre pour la partie publique.
• public_subnet_network_security_group_association_id et private_subnet_network_security_group_association_id : les NSG à rattacher aux subnets

Il ne faut pas oublier de déclarer les dépendances sur les NSG pour que tout soit prêt avant la création du workspace, au risque d’avoir des erreurs.
Ainsi, en exécutant ce script, on voit dans le groupe de ressources Databricks que les ressources ont été créées selon la nomenclature que l’on a défini :

Et on voit que les ressources réseaux ont été déplacées dans notre goupe de ressources car elles ont été créées par nos soins et non plus par Databricks.

En cas d’échec sur la création du workspace

À savoir que si la création du workspace Databricks échoue, rien ne décrit directement l’erreur rencontrée. Et surtout, le script Terraform se terminera en succès ! Le seul moyen d’avoir du détail sur l’erreur est d’aller dans l’activity log du groupe de ressources :

Sur cette capture d’écran, on est sur l’activity log du groupe de ressources dans lequel se trouve le workspace Databricks. On voit une erreur de création de la ressource sur laquelle se trouve le détail : « le compte de stockage existe déjà ».

Réseau

Pour que le script ci-dessus de création du workspace Databricks fonctionne, il faut préalablement déclarer le réseau virtuel et les sous-réseaux. Databricks a besoin de 2 sous-réseaux : un privé et un public. Vous trouverez plus de détails dans la documentation Microsoft
Le plus important se trouve sur la déclaration des subnets :

resource "azurerm_virtual_network" "this" {
  name = "vnet-blog-dev-01"

  location            = "francentrale"
  resource_group_name = "rg-blog-dev-01"

  address_space = ["10.139.0.0/16"]
}

resource "azurerm_subnet" "private" {
  name = "snet-blog-dev-02"

  resource_group_name  = "rg-blog-dev-01"
  virtual_network_name = azurerm_virtual_network.this.name
  address_prefixes     = ["10.139.64.0/18"]

  service_endpoints = ["Microsoft.Storage", "Microsoft.KeyVault"]

  delegation {
    name = "databricks-delegation"

    service_delegation {
      name = "Microsoft.Databricks/workspaces"
      actions = [
        "Microsoft.Network/virtualNetworks/subnets/join/action",
        "Microsoft.Network/virtualNetworks/subnets/prepareNetworkPolicies/action",
        "Microsoft.Network/virtualNetworks/subnets/unprepareNetworkPolicies/action",
      ]
    }
  }
}

resource "azurerm_subnet" "public" {
  name = "snet-blog-dev-01"

  resource_group_name  = "rg-blog-dev-01"
  virtual_network_name = azurerm_virtual_network.this.name
  address_prefixes     = ["10.139.0.0/18"]


  service_endpoints = ["Microsoft.Storage", "Microsoft.KeyVault"]

  delegation {
    name = "databricks-delegation"

    service_delegation {
      name = "Microsoft.Databricks/workspaces"
      actions = [
        "Microsoft.Network/virtualNetworks/subnets/join/action",
        "Microsoft.Network/virtualNetworks/subnets/prepareNetworkPolicies/action",
        "Microsoft.Network/virtualNetworks/subnets/unprepareNetworkPolicies/action",
      ]
    }
  }
}

Les points importants de ce script sont :

• les service endpoints : ici on déclare le type de ressource auquel notre workspace accédera. Si on restreint l’accès de notre Data Lake, il faut alors ajouter « Microsoft.Storage ». Et si on restreint l’accès d’un Key Vault pour l’utilisation d’un secret scope, alors il faut ajouter « Microsoft.KeyVault »
• la délégation : il faut obligatoirement déclarer cette délégation pour que Databricks utilise ce subnet

Restriction sur le Data Lake

Si on veut restreindre les flux réseaux de notre data lake, il faut permettre à databricks d’y accéder. Dans le tout premier script de cet article, nous n’avions pas déclaré le virtual network, laissant Databricks créer le sien. Dans ce cas, il est impossible d’avoir la main sur les flux réseaux. Mais avec ce que nous venons de faire, nous pouvons ajouter des règles de firewall sur la compte de stockage qui nous sert de data lake :

resource "azurerm_storage_account_network_rules" "datalake_network_rules" {
  storage_account_id = azurerm_storage_account.datalake.id

  default_action             = "Deny"
  bypass                     = ["Logging", "Metrics", "AzureServices"]
  virtual_network_subnet_ids = [azurerm_subnet.public.id, azurerm_subnet.private.id]
}

Dans la propriété « virtual_network_subnet_ids », nous passons en paramètre les subnets Databricks. On peut vérifier dans le portail Azure que c’est bien déployé :

Restriction sur un Key Vault

Il est intéressant de prévoir un Key Vault pour l’utilisation de secret scope dans Databricks. De la même manière que le compte de stockage nous pouvons retreindre son accès d’un point de vue réseau :

resource "azurerm_key_vault" "key_vault_core" {
  name                        = "kv-blog-dcube-dev-01"
  resource_group_name         = "rg-blog-dev-01"
  location                    = "francentrale"
  tenant_id                   = data.azurerm_client_config.current.tenant_id
  enabled_for_disk_encryption = true
  soft_delete_retention_days  = 7
  purge_protection_enabled    = false

  sku_name = "standard"

  network_acls {
    bypass                     = "AzureServices"
    default_action             = "Deny"
    virtual_network_subnet_ids = [azurerm_subnet.public.id, azurerm_subnet.private.id]
  }
}

Nous avons désormais toutes les ressources Azure nécessaires au fonctionnement d’un workspace Databricks. Nous allons voir dans les articles suivants comment aller plus loin dans l’Infrastructure As Code. Le prochain article montrera comment utiliser le provider Databricks de Terraform : Paramétrage d’un workspace Databricks par Terraform

Liens

Code source complet : https://github.com/dcube/databricks_template/tree/main/infra/azure
Documentation Microsoft : https://learn.microsoft.com/en-us/azure/databricks/administration-guide/cloud-configurations/azure/vnet-inject
Documentation Terraform : https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/databricks_workspace