Databricks Container Services pour compute dédié
Une version bêta de Databricks Container Services pour le compute en mode d’accès **standard** est également disponible. Consultez les Databricks Container Services pour le compute standard.
Databricks Container Services vous permet de spécifier une image Docker lorsque vous créez du compute. Voici quelques exemples de cas d'utilisation :
- Personnalisation de la bibliothèque : vous avez un contrôle total sur les bibliothèques système que vous souhaitez installer.
- Environnement de conteneur Golden : votre image Docker est un environnement verrouillé qui ne changera jamais.
- Intégration Docker CI/CD : vous pouvez intégrer Databricks à vos pipelines Docker CI/CD.
Vous pouvez également utiliser des images Docker pour créer des environnements d'apprentissage profond personnalisés sur le compute avec des périphériques GPU. Pour des informations supplémentaires sur l'utilisation du compute GPU avec Databricks Container Services, consultez Databricks Container Services sur le compute GPU.
Pour les tâches à exécuter à chaque start du conteneur, utilisez un script d'initialisation.
Exigences
- Votre workspace Databricks doit avoir Databricks Container Services activé.
- Votre machine doit exécuter un démon Docker récent (testé et compatible avec la version Client/Serveur 18.03.0-ce). et la commande
dockerdoit être disponible sur votrePATH.
Limitations
-
Databricks Container Services n'est pas pris en charge sur un compute utilisant le mode d'accès standard (anciennement mode d'accès partagé).
-
Databricks Runtime for Machine Learning ne prend pas en charge Databricks Container Services.
-
Pour accéder aux Volumes sur Databricks Container Services, ajoutez la configuration suivante dans le champ Configuration Spark du compute :
spark.databricks.unityCatalog.volumes.enabled true. -
Pour accéder aux métastores Hive fédérés sur Databricks Container Services, ajoutez la configuration suivante au champ configuration Spark du compute :
spark.databricks.unityCatalog.hms.federation.enabled true. -
172.17.0.0/16est la plage d'adresses IP par default utilisée par Docker. Pour éviter les problèmes de connectivité dus à un conflit d'adresses IP, évitez de configurer des ressources dans ce sous-réseau. -
Databricks Container Services ne prend pas en charge l'authentification des Notebooks.
-
Databricks Container Services n'est pas pris en charge sur les types d'instances AWS Graviton.
Étape 1 : Construire votre base
Databricks vous recommande de créer votre base Docker à partir d'une base que Databricks a créée et testée. Il est également possible de créer votre base Docker à partir de zéro. Cette section décrit les deux options.
Option 1. Utilisez une base construite par Databricks
Cet exemple utilise la balise 16.4-LTS pour une image qui ciblera un compute avec Databricks Runtime 16.4 LTS :
FROM databricksruntime/standard:16.4-LTS
...
Pour spécifier des bibliothèques Python supplémentaires, telles que la dernière version de pandas et urllib, utilisez la version spécifique au conteneur de pip. Pour le conteneur databricksruntime/standard:16.4-LTS, incluez les éléments suivants :
RUN /databricks/python3/bin/pip install pandas
RUN /databricks/python3/bin/pip install urllib3
Les images de base sont hébergées sur Docker Hub à l'adresse https://hub.docker.com/u/databricksruntime. Les Dockerfiles utilisés pour générer ces bases se trouvent à l'adresse https://github.com/databricks/containers.
Les images hébergées sur Docker Hub avec des tags portant le suffixe « -LTS » seront patchées. Toutes les autres images sont des exemples et ne sont pas mises à jour régulièrement.
Les images de base databricksruntime/standard et databricksruntime/minimal ne doivent pas être confondues avec les environnements databricks-standard et databricks-minimal non liés, inclus dans le Databricks Runtime avec Conda (Bêta) qui n'est plus disponible.
Option 2. Créez votre propre base Docker
Vous pouvez également créer votre image Docker de base à partir de zéro. L'image Docker doit satisfaire à ces exigences :
- Un JDK comme Java sur le système
PATH. La version requise dépend de votre version cible de Databricks Runtime. - Bash
- iproute2 (iproute Ubuntu)
- coreutils (ubuntu coreutils)
- procps (ubuntu procps)
- sudo (sudo Ubuntu)
- Ubuntu Linux
Faites correspondre le JDK à la version Java default de votre version Databricks Runtime cible. Pour connaître la version exacte du JDK incluse avec un runtime spécifique, consultez les notes de publication de cette version du runtime.
Pour construire votre propre image à partir de zéro, vous devez créer l'environnement virtuel. Vous devez également inclure les packages intégrés à Databricks compute, tels que Python et R. Pour get start, vous pouvez utiliser l'image de base appropriée :
- Pour R :
databricksruntime/rbase - Pour Python :
databricksruntime/python - Pour l'image minimale créée par Databricks :
databricksruntime/minimal
Vous pouvez également vous référer aux Dockerfiles d'exemple sur GitHub.
Databricks recommande d'utiliser Ubuntu Linux ; il est toutefois possible d'utiliser Alpine Linux. Pour utiliser Alpine Linux, vous devez inclure ces fichiers :
En outre, vous devez configurer Python, comme illustré dans cet exemple de Dockerfile.
Testez minutieusement votre image de conteneur personnalisée sur un compute Databricks. Votre conteneur peut fonctionner sur une machine locale ou de compilation, mais lorsque votre conteneur est lancé sur Databricks, le lancement du compute peut échouer, certaines fonctionnalités peuvent être désactivées, ou votre conteneur peut cesser de fonctionner, même silencieusement. Dans les pires scénarios, cela pourrait corrompre vos données ou les exposer accidentellement à des tiers externes.
Étape 2 : Déployer votre image de base
Transférez votre image de base personnalisée vers un registre Docker. Ce processus est pris en charge par l'utilisation des registres suivants :
-
Docker Hub sans authentification ou avec authentification de base.
-
Registre de conteneurs Azure avec authentification de base.
-
Amazon Elastic Container Registry (Amazon ECR) avec IAM (à l'exception des Services Cloud Commerciaux (C2S)).
D'autres registres Docker qui prennent en charge l'authentification sans information d'identification ou l'authentification de base sont également censés fonctionner.
Si vous utilisez Docker Hub pour votre registre Docker, assurez-vous de vérifier que les limites de débit tiennent compte de la quantité de compute que vous prévoyez de lancer sur une période de six heures. Ces limites de débit sont différentes pour les utilisateurs anonymes, les utilisateurs authentifiés sans abonnement payant et les abonnements payants. Consultez la documentation Docker pour plus de détails. Si cette limite est dépassée, vous recevrez une réponse « 429 Too Many Requests ».
Étape 3 : Lancez votre compute
Vous pouvez lancer votre compute en utilisant l'interface utilisateur ou l'API.
Lancez votre compute en utilisant l'interface utilisateur
-
Sur la page de création de compute, spécifiez une version de Databricks Runtime qui prend en charge Databricks Container Services.
-
Sous Avancé , sélectionnez l'onglet Docker .
-
Sélectionnez Utiliser votre propre conteneur Docker .
-
Dans le champ **URL de l'image Docker**, saisissez votre image Docker personnalisée.
Exemples d'URL d’image Docker :
Registre
Format de balise
Docker Hub
<organization>/<repository>:<tag>(par exemple :databricksruntime/standard:latest)Amazon ECR
<aws-account-id>.dkr.ecr.<region>.amazonaws.com/<repository>:<tag>Azure Container Registry
<your-registry-name>.azurecr.io/<repository-name>:<tag> -
Sélectionnez le type d’authentification. Vous pouvez utiliser des secrets pour stocker des valeurs d'authentification de nom d'utilisateur et de mot de passe. Consultez l'authentification d'image Docker.
Lancez votre compute à l'aide de l'API
-
Utilisez la CLI Databricks pour lancer un compute avec votre base Docker personnalisée.
Bashdatabricks clusters create \
--cluster-name <cluster-name> \
--node-type-id i3.xlarge \
--json '{
"num_workers": 0,
"docker_image": {
"url": "databricksruntime/standard:latest",
"basic_auth": {
"username": "<docker-registry-username>",
"password": "<docker-registry-password>"
}
},
"spark_version": "16.4.x-scala2.12",
"aws_attributes": {
"availability": "ON_DEMAND",
"instance_profile_arn": "arn:aws:iam::<aws-account-number>:instance-profile/<iam-role-name>"
}
}'
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 un script d'initialisation
Databricks Container Services permet aux clients d'inclure des scripts d'initialisation dans le conteneur Docker. Dans la plupart des cas, vous devez éviter les scripts d'initialisation et plutôt effectuer des personnalisations via Docker directement (en utilisant le Dockerfile). Cependant, certaines tâches doivent être exécutées lorsque le conteneur start, plutôt que lorsque le conteneur est construit. Utilisez un script d'initialisation pour ces tâches.
Par exemple, supposons que vous vouliez exécuter un démon de sécurité à l'intérieur d'un conteneur personnalisé. Installez et créez le daemon dans l'image Docker via votre pipeline de création d'images. Ensuite, ajoutez un script d'initialisation qui start le démon. Dans cet exemple, le script d'initialisation inclurait une ligne comme systemctl start my-daemon.
Dans l'API, vous pouvez spécifier des scripts d'initialisation dans le cadre de la spécification de compute, comme suit. Pour plus d'information, consultez l'API Clusters.
"init_scripts": [
{
"file": {
"destination": "file:/my/local/file.sh"
}
}
]
Pour les images de Databricks Container Services, vous pouvez également stocker les scripts d'initialisation dans le stockage cloud.
Les étapes suivantes ont lieu lorsque vous lancez un compute qui utilise Databricks Container Services :
- Les machines virtuelles sont acquises auprès du fournisseur de cloud.
- L'image Docker personnalisée est download depuis votre dépôt.
- Databricks crée un conteneur Docker à partir de l'image.
- Le code Databricks Runtime est copié dans le conteneur Docker.
- Les scripts d'initialisation sont exécutés. Voir Que sont les scripts d'initialisation ?.
Databricks ignore les primitives Docker CMD et ENTRYPOINT.
Activer les Container Services
Un administrateur du workspace peut contrôler si Databricks Container Services est activé pour le workspace.
Les administrateurs de Workspace peuvent activer ou désactiver le service de conteneurs Databricks à l'aide de la CLI Databricks. Dans un corps de requête JSON, spécifiez enableDcs à true, comme dans l'exemple suivant :
databricks workspace-conf set-status \
--json '{"enableDcs": "true"}'