Aller au contenu principal

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 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

Pour Databricks Runtime 18, sélectionnez 18 . Ne sélectionnez pas 18.0 . L'option d'exécution 18 sera renommée 18 LTS dans une prochaine mise à jour.

É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

Pour les types d'instance AWS Graviton (ARM), utilisez la variante ARM :

  • databricksruntime/environment:v5-standard-arm

É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.

Si vous ciblez les types d'instance AWS Graviton, remplacez :v5-standard par :v5-standard-arm dans la ligne FROM.

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 ou supérieure. Pour Databricks Runtime 18, choisissez 18 , pas 18.0 .
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 ou supérieur. Si 18 et 18,0 apparaissent tous les deux, sélectionnez 18 .

  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)

    Amazon ECR

    <aws-account-id>.dkr.ecr.<region>.amazonaws.com/<repository>:<tag>

    Azure Container Registry

    <your-registry-name>.azurecr.io/<repository-name>:<tag>

    Registre

    Format de balise

    Docker Hub

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

    Amazon ECR

    <aws-account-id>.dkr.ecr.<region>.amazonaws.com/<repository>:<tag>

    Azure Container Registry

    <your-registry-name>.azurecr.io/<repository-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 de Databricks Runtime 18 ou une version ultérieure. Pour Databricks Runtime 18, utilisez 18.x-scala2.13, pas 18.0.x-scala2.13.

Avec une image publique (pas d'authentification) :

Bash
databricks clusters create \
--cluster-name <cluster-name> \
--node-type-id <node-type> \
--json '{
"num_workers": 1,
"docker_image": {
"url": "<docker-registry-image-url>"
},
"spark_version": "18.x-scala2.13",
"aws_attributes": {
"availability": "ON_DEMAND"
},
"data_security_mode": "DATA_SECURITY_MODE_STANDARD"
}'

Avec l'authentification de base :

Bash
databricks clusters create \
--cluster-name <cluster-name> \
--node-type-id <node-type> \
--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",
"aws_attributes": {
"availability": "ON_DEMAND"
},
"data_security_mode": "DATA_SECURITY_MODE_STANDARD"
}'

Avec un profil d'instance (pour Amazon ECR) :

Bash
databricks clusters create \
--cluster-name <cluster-name> \
--node-type-id <node-type> \
--json '{
"num_workers": 1,
"docker_image": {
"url": "<image-url>"
},
"spark_version": "18.x-scala2.13",
"aws_attributes": {
"availability": "ON_DEMAND",
"instance_profile_arn": "arn:aws:iam::<aws-account-number>:instance-profile/<iam-role-name>"
},
"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.

  • Pour les images Amazon ECR, n'incluez aucune information d'authentification. Lancez plutôt votre compute avec un profil d'instance qui inclut les autorisations nécessaires pour extraire les images Docker du repository Docker où réside l'image. Pour ce faire, suivez les étapes 3 et 4 du processus de configuration d'un accès sécurisé aux compartiments S3 à l'aide de profils d'instance.

    Voici un exemple de rôle IAM avec l'autorisation d'extraire n'importe quelle image. Le repository est spécifié par <arn-of-repository>.

    JSON
    {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Effect": "Allow",
    "Action": ["ecr:GetAuthorizationToken"],
    "Resource": "*"
    },
    {
    "Effect": "Allow",
    "Action": [
    "ecr:BatchCheckLayerAvailability",
    "ecr:GetDownloadUrlForLayer",
    "ecr:GetRepositoryPolicy",
    "ecr:DescribeRepositories",
    "ecr:ListImages",
    "ecr:DescribeImages",
    "ecr:BatchGetImage"
    ],
    "Resource": ["<arn-of-repository>"]
    }
    ]
    }

    Si l'image Amazon ECR réside dans un compte AWS différent de celui du compute Databricks, utilisez une politique de repository ECR en plus du profil d'instance de compute pour accorder l'accès au compute. Voici un exemple de stratégie de repository ECR. Le rôle IAM endossé par le profil d'instance du compute est spécifié par <arn-of-IAM-role>.

    JSON
    {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Sid": "AllowCrossAccountPush",
    "Effect": "Allow",
    "Principal": {
    "AWS": "<arn-of-IAM-role>"
    },
    "Action": [
    "ecr:BatchCheckLayerAvailability",
    "ecr:BatchGetImage",
    "ecr:DescribeImages",
    "ecr:DescribeRepositories",
    "ecr:GetDownloadUrlForLayer",
    "ecr:GetRepositoryPolicy",
    "ecr:ListImages"
    ]
    }
    ]
    }

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.

  • Prise en charge des types d'instances AWS Graviton.

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 ou une version ultérieure. Pour Databricks Runtime 18, choisissez 18 , pas 18.0 .
  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.

L'extraction d'image échoue avec une erreur 403 d'Amazon ECR

Si le compute ne parvient pas à start et que les logs du Driver montrent une erreur 403 lors de l'extraction d'une image d'Amazon ECR, la cause pourrait être la politique de l'Endpoint VPC S3 pour le Virtual Private Cloud (VPC) du Workspace, plutôt que le rôle IAM ou le profil d'instance.

Amazon ECR utilise Amazon S3 pour stocker les couches d'images. Lorsqu'un client Docker extrait une image d'Amazon ECR, il se connecte à Amazon ECR pour obtenir le manifeste d'image, puis se connecte à Amazon S3 pour download les couches d'image. Si votre Workspace Virtual Private Cloud (VPC) utilise une connectivité privée, des règles de pare-feu ou des politiques d'Endpoint VPC restrictives, assurez-vous qu'Amazon ECR et le compartiment Amazon S3 qu'Amazon ECR utilise pour les couches d'images sont accessibles à partir de la ressource de compute.

Pour confirmer si l'échec est spécifique au chemin d'extraction d'image, connectez-vous en SSH au nœud Driver et exécutez directement la connexion Amazon ECR et l'extraction Docker :

Bash
aws ecr get-login-password --region <region> | \
docker login --username AWS --password-stdin <account>.dkr.ecr.<region>.amazonaws.com
docker pull <account>.dkr.ecr.<region>.amazonaws.com/<repo>:<tag>

Si l'extraction directe échoue après l'authentification à Amazon ECR et que l'erreur mentionne que l'accès à Amazon S3 est refusé, mettez à jour votre configuration réseau ou votre politique d'Endpoint Virtual Private Cloud (VPC) S3 pour autoriser l'accès minimal aux buckets Amazon S3 qu'Amazon ECR requiert pour les couches d'image. Consultez les endpoints Virtual Private Cloud (VPC) d'interface Amazon ECR dans la documentation AWS.

Après avoir mis à jour la règle, réessayez la commande docker pull à partir du nœud driver, puis lancez à nouveau la ressource compute.