Aller au contenu principal

Module 1 — Espace de travail Azure ML et organisation des ressources

Un espace de travail Azure ML (workspace) n'est pas un service isolé mais un point d'orchestration qui agrège cinq services satellites dans un groupe de ressources unique. Comprendre cette topologie évite les deux erreurs les plus courantes : chercher un fichier de modèle dans le portail du workspace alors qu'il vit dans le compte de stockage, et pester contre un déploiement qui échoue parce que l'identité gérée du workspace n'a pas le droit de lire l'image.

Les cinq satellites obligatoires​

À la création, Azure provisionne ou raccroche cinq ressources dans le même groupe de ressources :

RessourceRôle
Storage Accountstocke données, journaux, artefacts de tâche, snapshots de code
Key Vaultstocke secrets, chaînes de connexion, identifiants d'accès aux données
Container Registry (ACR)héberge les images conteneurisées des environnements
Application Insightsreçoit les journaux et métriques des tâches et des points de terminaison
Log Analytics (via Insights)index consultable par KQL sur les mêmes journaux

Pour le fil rouge des magasins, ces cinq ressources sont créées d'un coup :

az group create -n rg-prev-demande -l westeurope
az ml workspace create -n mlw-prev-demande -g rg-prev-demande

La commande crée en cascade le compte de stockage mlwprevdemandestore, le coffre mlw-prev-demande-kv, le registre mlwprevdemandeacr, et l'instance Application Insights. Chaque nom Azure a ses règles (unicité globale pour le stockage, longueur maximale pour l'ACR) : laisser la CLI générer les noms au premier essai est le plus sûr.

Le contrat implicite du groupe de ressources​

Toutes les ressources d'un même workspace doivent vivre dans le même groupe de ressources et la même région. Ce n'est pas une bonne pratique, c'est une contrainte du produit. En pratique, un projet par groupe de ressources donne un modèle mental clair : rg-prev-demande-dev, rg-prev-demande-prod. Le contrôle des coûts (module 10) et la suppression complète en une commande deviennent triviaux.

Un anti-patron courant consiste à partager un compte de stockage entre plusieurs workspaces « pour économiser ». Le coût du stockage est marginal, et la contention sur les journaux de tâches devient rapidement infernale à débuguer.

Identités et rôles : qui a le droit de quoi​

L'espace de travail est protégé par le contrôle d'accès basé sur les rôles Azure (Azure RBAC). Trois rôles suffisent à couvrir l'immense majorité des cas :

  • Reader : voit l'espace dans le portail, ne lance rien
  • AzureML Data Scientist : lance des tâches, publie des modèles, ne modifie ni le calcul ni les permissions
  • AzureML Compute Operator : crée et supprime des grappes de calcul, sans toucher aux données

Le rôle Contributor classique d'Azure donne trop de droits pour une équipe de science des données. Il est réservé à l'ingénieur qui provisionne l'infrastructure.

L'identité gérée du workspace​

À la création, Azure attribue au workspace une identité gérée assignée par le système (system-assigned managed identity). C'est elle qui, par défaut, lit et écrit dans le compte de stockage, tire les images de l'ACR, et écrit dans Application Insights. Deux corollaires importants :

  • Un accès données au nom de l'identité du workspace ne demande aucun secret dans le code ; la variable d'environnement DefaultAzureCredential du SDK suffit.
  • Si un jeu de données pointe vers un compte de stockage externe au groupe de ressources, il faut explicitement accorder le rôle Storage Blob Data Reader à l'identité du workspace sur ce compte. C'est la première cause d'échec au déploiement.
from azure.ai.ml import MLClient
from azure.identity import DefaultAzureCredential

ml_client = MLClient(
    credential=DefaultAzureCredential(),
    subscription_id="00000000-0000-0000-0000-000000000000",
    resource_group_name="rg-prev-demande",
    workspace_name="mlw-prev-demande",
)
print(ml_client.workspace_name)

Ce MLClient est l'objet unique qui sert dans tout le reste du cours : c'est lui qui reçoit les définitions de calcul, de données, d'environnement et de tâche.

En résumé​

  • Un workspace Azure ML agrège cinq satellites (Storage, Key Vault, ACR, App Insights, Log Analytics) dans le même groupe de ressources et la même région
  • Séparer les environnements par groupe de ressources et non par partage de stockage, la suppression et l'analyse de coûts en dépendent
  • Utiliser les rôles AzureML Data Scientist et AzureML Compute Operator plutôt que Contributor, plus fin et plus sûr
  • L'identité gérée du workspace doit avoir accès à toute ressource externe (stockage, ACR privé) sinon les tâches échouent au démarrage sans message clair

Le module suivant s'appuie sur cet espace pour choisir les cibles de calcul : instances de développement, grappes à mise à l'échelle automatique et calcul sans serveur.