Aller au contenu principal
Dernière mise à jour le

Databricks Container Services pour le compute standard

info

Bêta

Databricks Container Services pour le compute standard est en version Beta. Un administrateur de workspace doit activer cette fonctionnalité à partir de la page **Previews** du Workspace. Il s'agit d'un service distinct de Databricks Container Services pour le compute dédié, qui est généralement disponible.

Databricks Container Services pour le compute standard vous permet de spécifier une image Docker lorsque vous créez un compute standard, vous donnant accès à des conteneurs personnalisés dans des environnements de compute partagés. Votre image Docker est la seule définition de l'environnement de charge de travail, vous pouvez donc reproduire l'environnement distant localement pour des résultats cohérents entre le développement et la production.

Votre image personnalisée est utilisée pour les conteneurs sandbox qui exécutent le code utilisateur, comme les commandes REPL Python et les UDF Python. Le moteur Spark s'exécute dans un environnement géré par Databricks, et les queries Spark sont envoyées entre les conteneurs sandbox et le moteur Spark à l'aide de Spark Connect.

De plus, pour vous aider à créer votre image personnalisée, Databricks fournit une image de base alignée sur les versions d'environnement serverless que vous pouvez étendre pour répondre à vos besoins.

Exigences​

Pour utiliser Databricks Container Services pour le compute standard :

  • La ressource de compute doit exécuter Databricks Runtime 18 LTS ou version ultérieure et utiliser le mode d'accès Standard .
  • Vous devez disposer d'un démon Docker récent avec la commande docker disponible sur votre PATH.
remarque

Assurez-vous de sélectionner 18 LTS . Ne sélectionnez pas **18,0**, **18,1** ou **18,2**.

Étape 1 : Activer Databricks Container Services pour le compute standard​

Pour utiliser Databricks Container Services pour le compute standard, un administrateur de Workspace doit activer la fonctionnalité à partir de la page Préversions :

  1. Connectez-vous à votre workspace Databricks en tant qu'administrateur.
  2. Dans le menu utilisateur en haut à droite, cliquez sur Aperçus .
  3. Recherchez DCS pour compute standard et activez-le.

Étape 2 : Créez votre image personnalisée​

Ces instructions vous montrent comment créer une image personnalisée en étendant une image de base fournie par Databricks (recommandé). L'image de base contient les dépendances requises pour lancer vos workloads, telles que Ubuntu, Python et JDK. Vous pouvez extraire databricksruntime/environment:v5-standard, superposer vos packages, et hériter des mises à jour et correctifs de sécurité gérés par Databricks.

Si vous souhaitez créer une image de base minimale à partir de zéro, consultez Référence : créer une image de base minimale à partir de zéro.

Étape 2a : Extraire l’image de base​

Pour extraire l'image de base, exécutez :

Bash
docker pull databricksruntime/environment:v5-standard

Étape 2b : Écrivez un Dockerfile qui étend l'image de base​

Installez des packages Python personnalisés dans l'environnement virtuel /databricks/python3 de l'image de base. C'est l'environnement virtuel système qui lance vos charges de travail.

Dockerfile
FROM databricksruntime/environment:v5-standard

RUN /databricks/python3/bin/python -m pip install <your python package>

L'exemple suivant montre comment installer un package à partir d'un repository privé.

Dockerfile
FROM databricksruntime/environment:v5-standard

ENV PIP_INDEX_URL=https://pypi.org/simple

RUN /databricks/python3/bin/python -m pip install --no-cache-dir simplejson

Vous pouvez utiliser n'importe quelle instruction Dockerfile standard (par exemple, RUN, ENV, WORKDIR, COPY). Les instructions suivantes sont ignorées en raison de la manière dont Databricks lance votre charge de travail :

  • USER
  • CMD
  • ENTRYPOINT
  • EXPOSE
  • HEALTHCHECK
  • SHELL
  • STOPSIGNAL
remarque

Pour les charges de travail Scala, copiez vos fichiers JAR dans le répertoire /scala-jars/user de l'image et chmod 0644 afin que l'utilisateur du sandbox puisse les lire. Databricks charge les JAR à partir de ce chemin d’accès vers le classpath Scala REPL et les classpaths UDF Scala.

Étape 2c : Créer l'image​

Pour créer l'image, exécutez :

Bash
docker build -f <your-dockerfile> -t <registry-url>/<project>[/<repo>]:<tag> .
attention

Testez minutieusement votre image personnalisée sur un compute Databricks. Une image qui fonctionne sur une machine locale ou de build pourrait ne pas start, désactiver silencieusement des fonctionnalités ou cesser de fonctionner lorsqu'elle est lancée sur Databricks.

Référence : créer une image de base minimale à partir de zéro​

Si vous avez besoin d'un contrôle total sur le contenu de votre image de base (par exemple, pour répondre à des exigences strictes en matière de taille d'image, de chaîne d'approvisionnement ou de conformité), vous pouvez créer un équivalent minimal de databricksruntime/environment:v5-standard à partir de zéro au lieu de l'étendre.

attention

Construire à partir de zéro est une option avancée. Vous assumez la responsabilité de suivre les modifications en amont de l'image v5-standard, y compris les Python pins, les correctifs de sécurité, les outils de plateforme et les fichiers requis par la plateforme sous /databricks/ et /etc/environment. Au lieu de cela, Databricks recommande d'étendre databricksruntime/environment:v5-standard, comme indiqué précédemment à l'étape 2.

Databricks fournit un Dockerfile de référence et requirements.txt qui recréent l'environnement Python essentiel de v5-standard. Download les deux fichiers dans le même répertoire avant de construire :

Pour créer l'image, exécutez :

Bash
docker build -t <your-registry>/<repo>:<tag> .

Si votre hôte de build ne peut pas atteindre https://pypi.org, ignorez l'index pip au moment de la build en exécutant :

Bash
docker build --build-arg PIP_INDEX_URL=https://your-mirror/simple -t <your-registry>/<repo>:<tag> .

Avant de passer à l'étape suivante, vérifiez que les packages Python organisés s'importent correctement en exécutant :

Bash
docker run --rm --cpus 2 <your-registry>/<repo>:<tag> \
  /databricks/python3/bin/python -c \
  "import pandas, numpy, pyarrow, mlflow, databricks.connect; print('OK')"

Étape 3 : Poussez votre image vers un registre​

Ensuite, poussez votre image vers un registre Docker. Databricks Container Services prend en charge les mêmes registres sur le compute standard et dédié :

D'autres registres qui prennent en charge l'absence d'authentification ou l'authentification de base devraient également fonctionner. L'authentification de base utilise votre nom d'utilisateur et votre mot de passe de registre.

Pour une meilleure performance de tirage d'images, utilisez un registre dans le même cloud et la même région que votre Workspace Databricks.

Bash
echo "$REGISTRY_PASSWORD" | docker login -u <registry-username> --password-stdin <registry-url>
docker push <registry-url>/<project>[/<repo>]:<tag>
remarque

Si vous utilisez Docker Hub, vérifiez que vos limites de débit s'adaptent au compute que vous prévoyez de lancer sur une période de six heures. Consultez la documentation Docker pour plus de détails. Si cette limite est dépassée, les requêtes renvoient 429 Too Many Requests.

Étape 4 : Lancez votre compute​

Vous pouvez lancer un compute qui utilise votre image personnalisée à l'aide de l'interface utilisateur ou de l'API. Les exigences suivantes doivent être respectées :

  • Le mode d'accès du compute doit être Standard (dans l'API, définissez data_security_mode sur DATA_SECURITY_MODE_STANDARD). Si le compute est défini sur le mode d'accès Dédié , une version différente de Databricks Container Services est utilisée, qui s'attend à une image de base différente et ne parviendra pas à se lancer avec l'image de base que vous avez créée.
  • La version de Databricks Runtime doit être 18 LTS ou supérieure. Assurez-vous de sélectionner 18 LTS , et non 18,0 , 18,1 ou 18,2 .
remarque

Pour lancer par rapport à un pool d'instances, le pool doit être créé avec preloaded_docker_images défini, et le docker_image du cluster doit correspondre. Consultez Utiliser Databricks Container Services avec un Pool d'instances avant le lancement.

Lancez votre compute en utilisant l'interface utilisateur​

  1. Sur la page Créer un compute, assurez-vous que le mode d'accès est défini sur Standard et que le Databricks runtime est défini sur 18 LTS ou une version ultérieure. Veillez à sélectionner 18 LTS , et non 18,0 , 18,1 , ou 18,2 .

  2. Sous Avancé , sélectionnez l'onglet Docker .

  3. Sélectionnez Utiliser votre propre conteneur Docker .

  4. Dans le champ URL de l'image Docker , saisissez votre image personnalisée.

    Registre

    Format de balise

    Docker Hub

    <organization>/<repository>:<tag> (par exemple : databricksruntime/environment:v5-standard)

    Registre d'artefacts GCP

    <region>-docker.pkg.dev/<project-id>/<repo-name>/<image-name>:<tag>

    Registre

    Format de balise

    Docker Hub

    <organization>/<repository>:<tag> (par exemple : databricksruntime/environment:v5-standard)

    Registre d'artefacts GCP

    <region>-docker.pkg.dev/<project-id>/<repo-name>/<image-name>:<tag>

  5. Sélectionnez le type d’authentification. Consultez Authentification de l'image Docker.

remarque

Si vous ne voyez pas les paramètres **Docker** lorsque vous créez le compute, Databricks Container Services n'est peut-être pas activé dans votre Workspace. Un administrateur de Workspace doit l'activer avant qu'un utilisateur puisse spécifier une image Docker. Consultez l'Étape 1 : Activer Databricks Container Services pour le compute standard.

Lancez votre compute à l'aide de l'API​

Voici un exemple d'appel d'API qui crée un compute standard avec votre image personnalisée. Assurez-vous que data_security_mode est défini sur DATA_SECURITY_MODE_STANDARD et que spark_version est défini sur une valeur Databricks Runtime 18 LTS ou supérieure. Pour Databricks Runtime 18 LTS, utilisez 18.x-scala2.13, pas 18.0.x-scala2.13, 18.1.x-scala2.13 ou 18.2.x-scala2.13.

Bash
databricks clusters create \
--cluster-name <cluster-name> \
--node-type-id n2-highmem-4 \
--json '{
  "num_workers": 1,
  "docker_image": {
    "url": "<docker-registry-image-url>",
    "basic_auth": {
      "username": "<docker-registry-username>",
      "password": "<docker-registry-password>"
    }
  },
  "spark_version": "18.x-scala2.13",
  "data_security_mode": "DATA_SECURITY_MODE_STANDARD"
}'

Authentification de l'image Docker​

Les exigences d'authentification dépendent de votre type d'image Docker. Vous pouvez également utiliser des secrets pour stocker les noms d'utilisateur et les mots de passe d'authentification. Consultez Utiliser des secrets pour l'authentification.

  • Pour les images Docker publiques, vous n'avez pas besoin d'inclure d'information d'authentification. Dans l'interface utilisateur, réglez **Authentification** sur **default**. Pour l'appel d'API, n'incluez pas les champs basic_auth.
  • Pour les images Docker privées, authentifiez-vous à l’aide d’un ID Service Principal et d’un mot de passe (ou des secrets applicables) comme nom d’utilisateur et mot de passe.
  • Pour Azure Container Registry, authentifiez-vous à l’aide d’un identifiant et d’un mot de passe de Service Principal (ou des secrets applicables) comme nom d’utilisateur et mot de passe. Voir la documentation sur l'authentification du Service Principal du registre de conteneurs Azure pour des informations sur la création du Service Principal.

Utiliser les secrets pour l'authentification​

Le service de conteneur Databricks prend en charge l'utilisation de secrets pour l'authentification. Lorsque vous créez votre ressource de compute dans l'interface utilisateur, utilisez le champ **Authentification** pour sélectionner **Nom d'utilisateur et mot de passe**, puis, au lieu de saisir votre nom d'utilisateur ou mot de passe en texte clair, saisissez vos secrets en utilisant le {{secrets/<scope-name>/<dcs-secret>}} format. Si vous utilisez l'API, saisissez les secrets dans les champs basic_auth.

Pour plus d'informations sur la création de secrets, consultez Gestion des secrets.

Utiliser Databricks Container Services avec un pool d'instances​

Pour utiliser Databricks Container Services avec un pool d'instances, vous devez créer le pool à l'aide de l'API Instance Pools, et non de l'interface utilisateur.

Le pool doit être créé avec des images Docker préchargées. Cela réchauffe les instances inactives avec votre image personnalisée afin que les charges de travail start plus rapidement. Définissez le champ preloaded_docker_images de la requête avec les mêmes références d'image et la même authentification que celles que vous utilisez lorsque vous lancez le compute directement. Le champ est une liste, de sorte qu'un seul pool peut précharger plusieurs images.

Le Pool et ses Ressources de compute attachées doivent s'accorder sur l'utilisation de Docker. Si un Pool ne dispose pas de preloaded_docker_images défini, vous ne pouvez pas lancer de compute Databricks Container Services dessus. Créer un nouveau pool avec preloaded_docker_images défini.

Pour les Pools créés avec preloaded_docker_images, toute ressource de compute lancée contre le Pool doit fournir un docker_image correspondant dans sa requête de création. Sinon, la création de compute échoue avec 'docker_image' must be provided for cluster created with instance pool: <pool-id>.

Migrer depuis les Databricks Container Services d'origine​

Databricks Container Services pour le compute standard est un service différent des Databricks Container Services originaux pour le compute dédié. Cette fonctionnalité présente les différences suivantes :

  • Les charges de travail s'exécutent via le protocole Spark Connect.
  • Les scripts d'initialisation ne modifient pas l'environnement Python de votre charge de travail. Vous devez installer toutes les dépendances Python dans l'image Docker. Vous pouvez continuer à utiliser les scripts d'initialisation pour les applications qui consomment des données de Spark, tels que les agents Datadog ou Kafka.

Pour migrer depuis les Databricks Container Services d’origine pour le compute dédié, reconstruisez votre image personnalisée sur les Databricks Container Services pour le compute standard et mettez à jour votre configuration de compute :

  1. Remplacez la ligne FROM de votre Dockerfile par FROM databricksruntime/environment:v5-standard (ou v5-standard-arm pour AWS Graviton).
  2. Portez vos instructions Dockerfile vers la nouvelle image de base. Les instructions Dockerfile standard sont prises en charge, à l'exception de celles listées à l'Étape 2 : Créez votre image personnalisée.
  3. Installez les packages Python dans /databricks/python3 au lieu de tout autre virtualenv. Les charges de travail (notebooks, Python wheel, scripts Python) lisent à partir de ce chemin.
  4. Mettez à jour votre configuration de compute pour utiliser le mode d'accès Standard et Databricks Runtime 18 LTS ou version ultérieure. Assurez-vous de sélectionner 18 LTS , et non 18,0 , 18,1 ou 18,2 .
  5. Déplacez toute configuration d'environnement Python qu'un script d'initialisation effectuait auparavant dans le Dockerfile.

Limitations​

En plus des limitations du compute standard, Databricks Container Services pour le compute standard présente les limitations suivantes :

  • Les bibliothèques à portée de compute ne sont pas prises en charge.
  • Les référentiels de paquets privés ne sont pas pris en charge.
  • Databricks Runtime for Machine Learning n’est pas pris en charge.
  • Pour lancer un compute standard avec Databricks Container Services contre un Pool d'instances, le Pool doit être créé avec preloaded_docker_images défini. Voir Utiliser Databricks Container Services avec un Pool d'instances.

Dépannage​

Si l'onglet Docker n'apparaît pas sous Avancé lorsque vous créez du compute, Databricks Container Services n'est pas activé pour votre workspace. Un administrateur de Workspace doit l'activer dans le Workspace avant qu'un utilisateur puisse spécifier une image Docker. Voir Activer les services de conteneurs.

La tab Docker peut également être masquée par une politique de compute qui masque l'attribut docker_image.url. Si la fonctionnalité est activée mais que la tab est toujours manquante, demandez à un administrateur de Workspace de vérifier si la politique qui vous est assignée masque cet attribut. Consultez les attributs pris en charge.

Sur cette page