Compose: Prise en charge des GPU NVIDIA sous Docker Compose

Ceci est d'une importance accrue maintenant que l'ancien 'nvidia runtime' semble interrompu avec Docker 19.03.0 et nvidia-container-toolkit-1.0.0-2 : https://github.com/NVIDIA/nvidia-docker/issues/1017

$ cat docker-compose.yml 
version: '2.3'

services:
 nvidia-smi-test:
  runtime: nvidia
  image: nvidia/cuda:9.2-runtime-centos7

$ docker-compose run nvidia-smi-test
Cannot create container for service nvidia-smi-test: Unknown runtime specified nvidia

Cela fonctionne: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Cela ne fonctionne pas: docker run --runtime=nvidia nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Y a-t-il du travail en cours à ce sujet?

J'ai le nouveau Docker CE 19.03.0 sur une nouvelle machine Ubuntu 18.04 LTS, j'ai la version actuelle et correspondante de NVIDIA Container Toolkit (née nvidia-docker2), mais je ne peux pas l'utiliser car docker-compose.yml 3.7 ne prend pas en charge le --gpus drapeau.

Existe-t-il une solution de contournement pour cela?

Cela fonctionne: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Cela ne fonctionne pas: docker run --runtime=nvidia nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Vous devez avoir

{
    "runtimes": {
        "nvidia": {
            "path": "/usr/bin/nvidia-container-runtime",
            "runtimeArgs": []
        }
    }
}

dans votre /etc/docker/daemon.json pour --runtime=nvidia pour continuer à travailler. Plus d'infos ici .

ping @KlaasH @ulyssessouza @Goryudyuma @ chris-crone. Une mise à jour pour ceci?

C'est un besoin urgent. Je vous remercie pour vos efforts!

Est-il prévu que l'utilisateur remplisse manuellement /etc/docker/daemon.json après la migration vers docker> = 19.03 et en supprimant nvidia-docker2 pour utiliser nvidia-container-toolkit place?

Il semble que cela casse beaucoup d'installations. Surtout, puisque --gpus n'est pas disponible dans compose .

Non, c'est une solution de contournement jusqu'à ce que compose prenne en charge l'indicateur gpus.

installez nvidia-docker-runtime:
https://github.com/NVIDIA/nvidia-container-runtime#docker -engine-setup
ajouter à /etc/docker/daemon.json
{
"runtimes": {
"nvidia": {
"chemin": "/ usr / bin / nvidia-container-runtime",
"runtimeArgs": []
}
}
}

docker-compose:
runtime: nvidia
environnement:
- NVIDIA_VISIBLE_DEVICES = tout

Il n'existe plus de "/ usr / bin / nvidia-container-runtime". Le problème est toujours critique.

cela aidera à exécuter l'environnement nvidia avec docker-compose, jusqu'à corriger docker-compose

installez nvidia-docker-runtime:
https://github.com/NVIDIA/nvidia-container-runtime#docker -engine-setup
ajouter à /etc/docker/daemon.json
{
"runtimes": {
"nvidia": {
"chemin": "/ usr / bin / nvidia-container-runtime",
"runtimeArgs": []
}
}
}

docker-compose:
runtime: nvidia
environnement:

• NVIDIA_VISIBLE_DEVICES = tout

Cela ne fonctionne pas pour moi, je reçois toujours le Unsupported config option for services.myservice: 'runtime' en essayant d'exécuter docker-compose up

des idées?

Cela ne fonctionne pas pour moi, je reçois toujours le Unsupported config option for services.myservice: 'runtime' en essayant d'exécuter docker-compose up

des idées?

après avoir modifié /etc/docker/daemon.json, redémarrez le service docker
systemctl redémarrage docker
utilisez le format Compose 2.3 et ajoutez runtime: nvidia à votre service GPU. Docker Compose doit être la version 1.19.0 ou supérieure.
fichier docker-compose:
version: "2.3"

prestations de service:
nvsmi:
image: ubuntu: 16.04
runtime: nvidia
environnement:
- NVIDIA_VISIBLE_DEVICES = tout
commande: nvidia-smi

@cheperuiz , vous pouvez définir nvidia comme runtime par défaut dans daemon.json et ne dépendra pas de docker-compose. Mais tous vos conteneurs docker utiliseront le runtime nvidia - je n'ai pas de problèmes pour l'instant.
{ "default-runtime": "nvidia", "runtimes": { "nvidia": { "path": "/usr/bin/nvidia-container-runtime", "runtimeArgs": [] } }, }

Ah! merci @Kwull , j'ai manqué cette partie default-runtime ... Tout fonctionne maintenant :)

@uderik , runtime n'est plus présent dans le schéma de format de fichier de composition 3.7 actuel, ni dans la version 3.8 en attente qui devrait éventuellement s'aligner sur Docker 19.03: https://github.com/docker/compose/blob/ 5e587d574a94e011b029c2fb491fb0f4bdeef71c / compose / config / config_schema_v3.8.json

@johncolby runtime n'a jamais été un indicateur 3.x. Il n'est présent que dans la piste 2.x, (2.3 et 2.4).

Oui, je sais, et même si mon fichier docker-compose.yml inclut le version: '2.3' (qui a fonctionné dans le passé), il semble être ignoré par les dernières versions ...
Pour les projets futurs, quelle serait la bonne façon d'activer / désactiver l'accès au GPU? juste en faire des variables par défaut + env? ou y aura-t-il un support pour l'indicateur --gpus ?

@johncolby quel est le remplacement de runtime dans 3.X?

@ Daniel451 Je viens de suivre le long de la périphérie, mais il semble que ce sera sous la clé generic_resources , quelque chose comme:

services:
  my_app:
    deploy:
      resources:
        reservations:
          generic_resources:
            - discrete_resource_spec:
                kind: 'gpu'
                value: 2

(depuis https://github.com/docker/cli/blob/9a39a1/cli/compose/loader/full-example.yml#L71-L74)
Document de conception ici: https://github.com/docker/swarmkit/blob/master/design/generic_resources.md

Voici le problème de composition concernant la prise en charge du schéma de compose 3.8, qui est déjà fusionné dans: https://github.com/docker/compose/issues/6530

Du côté du démon, la capacité gpu peut être enregistrée en l'incluant dans la CLI daemon.json ou dockerd (comme la précédente solution de contournement d'exécution codée en dur), quelque chose comme

/usr/bin/dockerd --node-generic-resource gpu=2

qui est ensuite enregistré en se connectant à l'utilitaire docker NVIDIA:
https://github.com/moby/moby/blob/09d0f9/daemon/nvidia_linux.go

Il semble que la machinerie soit fondamentalement en place, il faut probablement juste être documentée ...

Toute mise à jour?

En attente des mises à jour, en utilisant bash avec docker run --gpus jusqu'à ce que le correctif officiel ...

En attente de mises à jour également.

En attente de mises à jour :)

Ok ... je ne comprends pas pourquoi c'est toujours ouvert. Ces 3 lignes supplémentaires le font fonctionner avec la version de schéma 3.7. Heureux de savoir que docker est sensible aux problèmes de communauté triviaux. Alors clonez ce dépôt, ajoutez ces trois lignes, et python3 setup.py compilez et installez-le, et assurez-vous que votre docker-compose.yml est la version 3.7.

[ruckc<strong i="6">@omnilap</strong> compose]$ git diff
diff --git a/compose/config/config_schema_v3.7.json b/compose/config/config_schema_v3.7.json
index cd7882f5..d25d404c 100644
--- a/compose/config/config_schema_v3.7.json
+++ b/compose/config/config_schema_v3.7.json
@@ -151,6 +151,7 @@

         "external_links": {"type": "array", "items": {"type": "string"}, "uniqueItems": true},
         "extra_hosts": {"$ref": "#/definitions/list_or_dict"},
+        "gpus": {"type": ["number", "string"]},
         "healthcheck": {"$ref": "#/definitions/healthcheck"},
         "hostname": {"type": "string"},
         "image": {"type": "string"},
diff --git a/compose/service.py b/compose/service.py
index 55d2e9cd..71188b67 100644
--- a/compose/service.py
+++ b/compose/service.py
@@ -89,6 +89,7 @@ HOST_CONFIG_KEYS = [
     'dns_opt',
     'env_file',
     'extra_hosts',
+    'gpus',
     'group_add',
     'init',
     'ipc',
@@ -996,6 +997,7 @@ class Service(object):
             dns_opt=options.get('dns_opt'),
             dns_search=options.get('dns_search'),
             restart_policy=options.get('restart'),
+            gpus=options.get('gpus'),
             runtime=options.get('runtime'),
             cap_add=options.get('cap_add'),
             cap_drop=options.get('cap_drop'),

Je viens d'ajouter un problème interne pour le suivre.
N'oubliez pas que les RP sont les bienvenus: smiley:

Ok ... je ne comprends pas pourquoi c'est toujours ouvert. Ces 3 lignes supplémentaires le font fonctionner avec la version de schéma 3.7. Heureux de savoir que docker est sensible aux problèmes de communauté triviaux. Alors clonez ce dépôt, ajoutez ces trois lignes, et python3 setup.py compilez et installez-le, et assurez-vous que votre docker-compose.yml est la version 3.7.

[ruckc<strong i="7">@omnilap</strong> compose]$ git diff
diff --git a/compose/config/config_schema_v3.7.json b/compose/config/config_schema_v3.7.json
index cd7882f5..d25d404c 100644
--- a/compose/config/config_schema_v3.7.json
+++ b/compose/config/config_schema_v3.7.json
@@ -151,6 +151,7 @@

         "external_links": {"type": "array", "items": {"type": "string"}, "uniqueItems": true},
         "extra_hosts": {"$ref": "#/definitions/list_or_dict"},
+        "gpus": {"type": ["number", "string"]},
         "healthcheck": {"$ref": "#/definitions/healthcheck"},
         "hostname": {"type": "string"},
         "image": {"type": "string"},
diff --git a/compose/service.py b/compose/service.py
index 55d2e9cd..71188b67 100644
--- a/compose/service.py
+++ b/compose/service.py
@@ -89,6 +89,7 @@ HOST_CONFIG_KEYS = [
     'dns_opt',
     'env_file',
     'extra_hosts',
+    'gpus',
     'group_add',
     'init',
     'ipc',
@@ -996,6 +997,7 @@ class Service(object):
             dns_opt=options.get('dns_opt'),
             dns_search=options.get('dns_search'),
             restart_policy=options.get('restart'),
+            gpus=options.get('gpus'),
             runtime=options.get('runtime'),
             cap_add=options.get('cap_add'),
             cap_drop=options.get('cap_drop'),

J'ai essayé votre solution mais j'obtiens beaucoup d'erreurs à propos de ce drapeau:

ERROR: for <SERVICE_NAME>  __init__() got an unexpected keyword argument 'gpus'
Traceback (most recent call last):
  File "/usr/local/bin/docker-compose", line 11, in <module>
    load_entry_point('docker-compose==1.25.0.dev0', 'console_scripts', 'docker-compose')()
  File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/cli/main.py", line 71, in main
    command()
  File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/cli/main.py", line 127, in perform_command
    handler(command, command_options)
  File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/cli/main.py", line 1106, in up
    to_attach = up(False)
  File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/cli/main.py", line 1102, in up
    cli=native_builder,
  File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/project.py", line 569, in up
    get_deps,
  File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/parallel.py", line 112, in parallel_execute
    raise error_to_reraise
  File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/parallel.py", line 210, in producer
    result = func(obj)
  File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/project.py", line 555, in do
    renew_anonymous_volumes=renew_anonymous_volumes,
  File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/service.py", line 546, in execute_convergence_plan
    scale, detached, start
  File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/service.py", line 468, in _execute_convergence_create
    "Creating"
  File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/parallel.py", line 112, in parallel_execute
    raise error_to_reraise
  File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/parallel.py", line 210, in producer
    result = func(obj)
  File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/service.py", line 466, in <lambda>
    lambda service_name: create_and_start(self, service_name.number),
  File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/service.py", line 454, in create_and_start
    container = service.create_container(number=n, quiet=True)
  File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/service.py", line 337, in create_container
    previous_container=previous_container,
  File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/service.py", line 913, in _get_container_create_options
    one_off=one_off)
  File "/usr/local/lib/python3.6/dist-packages/docker_compose-1.25.0.dev0-py3.6.egg/compose/service.py", line 1045, in _get_container_host_config
    cpu_rt_runtime=options.get('cpu_rt_runtime'),
  File "/usr/local/lib/python3.6/dist-packages/docker-4.0.2-py3.6.egg/docker/api/container.py", line 590, in create_host_config
    return HostConfig(*args, **kwargs)
TypeError: __init__() got an unexpected keyword argument 'gpus'

Ai-je besoin d'un package python spécifique docker ?

@DarioTurchi Ouais, j'ai rencontré le problème exact. Il semble que le type de HostConfig doit également être mis à jour.

Je ne pense pas que le changement décrit par @ruckc soit suffisant, car docker-py aura également besoin d'un changement. Et il semble que le changement nécessaire de docker-py soit toujours en cours d'élaboration. Vois ici:
https://github.com/docker/docker-py/pull/2419

Voici la branche avec les changements:
https://github.com/sigurdkb/docker-py/tree/gpus_parameter

Donc, si vous souhaitez corriger cela maintenant, vous devrez construire docker-compose contre un docker-py modifié à partir de https://github.com/sigurdkb/docker-py/tree/gpus_parameter

Je ne comprends pas ce qui se passe ici:

1) J'ai en /etc/docker/daemon.json

{
    "runtimes": {
        "nvidia": {
            "path": "nvidia-container-runtime",
            "runtimeArgs": []
        }
    }
}

mais la clé runtime ne peut plus être utilisée dans la v3.x comme pour https://github.com/docker/compose/issues/6239

J'ai essayé aussi:

{
    "default-runtime": "nvidia",
    "runtimes": {
        "nvidia": {
            "path": "/usr/bin/nvidia-container-runtime",
            "runtimeArgs": []
        }
    }
}

Je ne peux donc plus démarrer mes conteneurs avec le support gpu sur docker-compose :

bertserving_1    | I:VENTILATOR:[__i:_ge:222]:get devices
bertserving_1    | W:VENTILATOR:[__i:_ge:246]:no GPU available, fall back to CPU

Avant ces changements, cela fonctionnait, alors que puis-je faire maintenant?

+1 il sera très utile d'avoir une telle fonctionnalité dans docker-compose!

Un eta?

suivi en interne comme https://docker.atlassian.net/browse/COMPOSE-82

+1 serait une fonctionnalité utile pour docker-compose

Cette fonctionnalité serait un ajout génial à docker-compose

Pour le moment, ma solution consiste à utiliser la version 2.3 du fichier docker-compose, qui prend en charge le runtime, et à installer manuellement le nvidia-container-runtime (car il n'est plus installé avec le nvidia-docker).
Je suis également en train de paramétrer les configurations d'exécution dans /etc/docker/daemon.json (pas par défaut, juste comme un runtime disponible).
Avec cela, je peux utiliser un fichier de composition en tant que tel:

version: '2.3'
services:
  test:
    image: nvidia/cuda:9.0-base
    runtime: nvidia

Pour le moment, ma solution consiste à utiliser la version 2.3 du fichier docker-compose, qui prend en charge le runtime, et à installer manuellement le nvidia-container-runtime (car il n'est plus installé avec le nvidia-docker).
Je suis également en train de paramétrer les configurations d'exécution dans /etc/docker/daemon.json (pas par défaut, juste comme un runtime disponible).
Avec cela, je peux utiliser un fichier de composition en tant que tel:

version: '2.3'
services:
  test:
    image: nvidia/cuda:9.0-base
    runtime: nvidia

@arruda Pourriez-vous partager votre daemon.json s'il vous plaît?

Pour le moment, ma solution consiste à utiliser la version 2.3 du fichier docker-compose, qui prend en charge le runtime, et à installer manuellement le nvidia-container-runtime (car il n'est plus installé avec le nvidia-docker).
Je suis également en train de paramétrer les configurations d'exécution dans /etc/docker/daemon.json (pas par défaut, juste comme un runtime disponible).
Avec cela, je peux utiliser un fichier de composition en tant que tel:

version: '2.3'
services:
  test:
    image: nvidia/cuda:9.0-base
    runtime: nvidia

@arruda Pourriez-vous partager votre daemon.json s'il vous plaît?

Ouais, pas de problème, c'est ici:

{
    "runtimes": {
        "nvidia": {
            "path": "nvidia-container-runtime",
            "runtimeArgs": []
        }
    }
}

salut

J'ai une application qui nécessite des pilotes NVIDIA. J'ai construit une image docker basée sur (FROM)
nvidia / cudagl: 10.1-runtime-ubuntu18.04

En utilisant l'approche recommandée ci-dessus - cela signifie que mon image n'a pas besoin d'être dérivée de nvidia / cudagl: 10.1-runtime-ubuntu18.04 ? Ie je pourrais simplement dériver de (FROM) python: 3.7.3-stretch
et ajoutez runtime: nvidia au service dans docker-compose?

Merci

@rfsch Non, c'est une chose différente. runtime: nvidia dans docker-compose fait référence au runtime Docker. Cela rend le GPU disponible pour le conteneur. Mais vous avez toujours besoin d'un moyen de les utiliser une fois qu'ils sont disponibles. runtime in nvidia/cudagl:10.1-runtime-ubuntu18.04 fait référence aux composants d'exécution CUDA. Cela vous permet d'utiliser les GPU (mis à disposition dans un conteneur par Docker) à l'aide de CUDA.

Dans cette image:

runtime: nvidia remplace la partie runc / containerd. nvidia/cudagl:10.1-runtime-ubuntu18.04 est complètement en dehors de l'image .

nous avons besoin de cette fonctionnalité

@ Daniel451 Je viens de suivre le long de la périphérie, mais il semble que ce sera sous la clé generic_resources , quelque chose comme:

services:
  my_app:
    deploy:
      resources:
        reservations:
          generic_resources:
            - discrete_resource_spec:
                kind: 'gpu'
                value: 2

(depuis https://github.com/docker/cli/blob/9a39a1/cli/compose/loader/full-example.yml#L71-L74)
Document de conception ici: https://github.com/docker/swarmkit/blob/master/design/generic_resources.md

Voici le problème de composition concernant la prise en charge du schéma de compose 3.8, qui est déjà fusionné dans: # 6530

Du côté du démon, la capacité gpu peut être enregistrée en l'incluant dans la CLI daemon.json ou dockerd (comme la précédente solution de contournement d'exécution codée en dur), quelque chose comme

/usr/bin/dockerd --node-generic-resource gpu=2

qui est ensuite enregistré en se connectant à l'utilitaire docker NVIDIA:
https://github.com/moby/moby/blob/09d0f9/daemon/nvidia_linux.go

Il semble que la machinerie soit fondamentalement en place, il faut probablement juste être documentée ...

Hé, @johncolby , j'ai essayé ceci, mais j'ai échoué:

ERROR: The Compose file './docker-compose.yml' is invalid because:
services.nvidia-smi-test.deploy.resources.reservations value Additional properties are not allowed ('generic_resources' was unexpected)

Aucune suggestion?

Merci
David

Installation de nvidia-container-runtime 3.1.4.1 depuis https://github.com/NVIDIA/nvidia-container-runtime et mise

runtime: nvidia

fonctionne bien ici avec docker-compose 1.23.1 et 1.24.1 installés à partir de https://docs.docker.com/compose/install/ en utilisant cette commande douteuse:

sudo curl -L "https://github.com/docker/compose/releases/download/1.24.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

et par exemple le conteneur nvidia / cudagl / 10.1-base de dockerhub. J'ai essayé le rendu cuda et OpenGL et tout est proche des performances natives.

Suivi interne comme COMPOSE-82
Veuillez noter qu'un tel changement doit également être implémenté dans docker stack (https://github.com/docker/cli/blob/master/cli/compose/types/types.go#L156) pour la cohérence

Installation de nvidia-container-runtime 3.1.4.1 depuis https://github.com/NVIDIA/nvidia-container-runtime et mise

runtime: nvidia

fonctionne bien ici avec docker-compose 1.23.1 et 1.24.1 installés à partir de https://docs.docker.com/compose/install/ en utilisant cette commande douteuse:

sudo curl -L "https://github.com/docker/compose/releases/download/1.24.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

et par exemple le conteneur nvidia / cudagl / 10.1-base de dockerhub. J'ai essayé le rendu cuda et OpenGL et tout est proche des performances natives.

pouvez-vous partager votre docker-compose.yml?

hé, @ jdr-face,

voici mon test suivant votre suggestion, en installant nvidia-container-runtime sur la machine hôte.

version: '3.0'

services:
  nvidia-smi-test:
    runtime: nvidia
    volumes:
      - /tmp/.X11-unix:/tmp/.X11-unix 
    environment:
     - NVIDIA_VISIBLE_DEVICES=0 
     - DISPLAY
    image: vkcube

cela donne toujours l'erreur:

       Unsupported config option for services.nvidia-smi-test: 'runtime'

@ david-gwa comme noté par andyneff plus tôt :

runtime n'a jamais été un indicateur 3.x. Il n'est présent que dans la piste 2.x, (2.3 et 2.4).

@ david-gwa

pouvez-vous partager votre docker-compose.yml?

version: '2.3'

services:
    container:
        image: "nvidia/cudagl/10.1-base"

        runtime: "nvidia" 

        security_opt:
            - seccomp:unconfined
        privileged: true

        volumes:
            - $HOME/.Xauthority:/root/.Xauthority:rw
            - /tmp/.X11-unix:/tmp/.X11-unix:rw

        environment:
          - NVIDIA_VISIBLE_DEVICES=all

Selon vos besoins, certaines de ces options peuvent être inutiles. Comme @muru l'a prédit, l'astuce consiste à spécifier une ancienne version. Au moins pour mon cas d'utilisation, ce n'est pas un problème, mais je ne propose cette configuration que comme solution de contournement, elle devrait vraiment être rendue possible en utilisant la dernière version.

merci les gars, @ jdr-face, @muru , composer v2 fonctionne,
J'ai mal compris que votre solution est pour la v3 compose.

Pour mémoire, traditionnellement: compose v2 n'est pas plus ancien que compose v3. Ce sont des cas d'utilisation différents. La v3 est orientée vers l'essaim tandis que la v2 ne l'est pas. La v1 est ancienne.

Y a-t-il une discussion sur la prise en charge de Docker-compose pour la prise en charge native du GPU de Docker?

La prise en charge de l'option runtime n'est pas la solution pour le support GPU à l'avenir. NVIDIA décrit l'avenir de nvidia-docker2 dans https://github.com/NVIDIA/nvidia-docker comme suit.

Notez qu'avec la sortie de Docker 19.03, l'utilisation des packages nvidia-docker2 est obsolète car les GPU NVIDIA sont désormais pris en charge de manière native en tant que périphériques dans l'environnement d'exécution Docker.

Actuellement, la prise en charge du GPU peut être réalisée en modifiant le runtime, mais il est fort possible que cela ne fonctionne pas à l'avenir.

Pour être franc, ce n'est peut-être pas la meilleure pratique, mais d'une manière ou d'une autre, nous la faisons fonctionner.

La partie délicate est que nous devons nous en tenir à docker-compose v3.x puisque nous utilisons docker swarm, en attendant, nous voulons utiliser le Nvidia Runtime pour prendre en charge GPU / CUDA dans les conteneurs.

Pour éviter de dire explicitement le Nvidia Runtime dans le fichier docker-compose, nous définissons Nvidia comme runtime par défaut dans /etc/docker/daemon.json , et cela ressemblera à

{
    "default-runtime":"nvidia",
    "runtimes": {
        "nvidia": {
            "path": "nvidia-container-runtime",
            "runtimeArgs": []
        }
    }
}

De sorte que tous les conteneurs exécutés sur les machines GPU activeront par défaut le runtime Nvidia.

J'espère que cela peut aider quelqu'un face au bloqueur similaire

Pour être franc, ce n'est peut-être pas la meilleure pratique, mais d'une manière ou d'une autre, nous la faisons fonctionner.

La partie délicate est que nous devons nous en tenir à docker-compose v3.x puisque nous utilisons docker swarm, en attendant, nous voulons utiliser le Nvidia Runtime pour prendre en charge GPU / CUDA dans les conteneurs.

Pour éviter de dire explicitement le Nvidia Runtime dans le fichier docker-compose, nous définissons Nvidia comme runtime par défaut dans /etc/docker/daemon.json , et cela ressemblera à

{
    "default-runtime":"nvidia",
    "runtimes": {
        "nvidia": {
            "path": "nvidia-container-runtime",
            "runtimeArgs": []
        }
    }
}

De sorte que tous les conteneurs exécutés sur les machines GPU activeront par défaut le runtime Nvidia.

J'espère que cela peut aider quelqu'un face au bloqueur similaire

C'est en effet ce que nous faisons aussi. Cela fonctionne pour le moment, mais cela me semble un peu piraté. En espérant un support complet de compose-v3 bientôt. :)

Est-il prévu que l'utilisateur remplisse manuellement /etc/docker/daemon.json après la migration vers docker> = 19.03 et en supprimant nvidia-docker2 pour utiliser nvidia-container-toolkit place?

Il semble que cela casse beaucoup d'installations. Surtout, puisque --gpus n'est pas disponible dans compose .

--gpus n'est pas disponible dans compose
Je ne peux pas utiliser pycharm pour lier docker pour exécuter tensorflow-gpu

Des mises à jour sur ce problème? Y a-t-il une chance que --gpus soit bientôt pris en charge dans docker-compose?

Pour ceux d'entre vous qui recherchent une solution de contournement, voici ce que nous avons fini par faire:

• Installez docker-py depuis ce PR: https://github.com/docker/docker-py/pull/2471
• Installez docker-compose à partir de ce PR: https://github.com/docker/compose/pull/7124

Et puis exécutez COMPOSE_API_VERSION=auto docker-compose run gpu avec le fichier suivant:

version: '3.7'

services:
    gpu:
        image: 'nvidia/cuda:9.0-base'
        command: 'nvidia-smi'
        device_requests:
            - capabilities:
               - "gpu"

Sous Docker 19.03.0 Beta 2, la prise en charge du GPU NVIDIA a été introduite sous la forme d'une nouvelle API CLI --gpus. docker / cli # 1714 parlent de cette activation.

Maintenant, on peut simplement passer l'option --gpus pour l'application basée sur Docker accélérée par GPU.

$ docker run -it --rm --gpus all ubuntu nvidia-smi
Unable to find image 'ubuntu:latest' locally
latest: Pulling from library/ubuntu
f476d66f5408: Pull complete 
8882c27f669e: Pull complete 
d9af21273955: Pull complete 
f5029279ec12: Pull complete 
Digest: sha256:d26d529daa4d8567167181d9d569f2a85da3c5ecaf539cace2c6223355d69981
Status: Downloaded newer image for ubuntu:latest
Tue May  7 15:52:15 2019       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.116                Driver Version: 390.116                   |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla P4            Off  | 00000000:00:04.0 Off |                    0 |
| N/A   39C    P0    22W /  75W |      0MiB /  7611MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+
:~$ 

À partir d'aujourd'hui, Compose ne le prend pas en charge. Il s'agit d'une demande de fonctionnalité permettant à Compose de prendre en charge le GPU NVIDIA.

J'ai résolu ces problèmes ， vous pouvez essayer comme suit, mon adresse de blog csdn: https://blog.csdn.net/u010420283/article/details/104055046

~ $ sudo apt-get install nvidia-container-runtime
~ $ sudo vim /etc/docker/daemon.json

puis, dans ce fichier daemon.json, ajoutez ce contenu:

{
"default-runtime": "nvidia"
"runtimes": {
"nvidia": {
"chemin": "/ usr / bin / nvidia-container-runtime",
"runtimeArgs": []
}
}
}

~ $ sudo systemctl daemon-reload
~ $ sudo systemctl redémarrer le docker

Pour les utilisateurs ansible qui souhaitent configurer la solution de contournement décrite précédemment, il existe un rôle pour installer nvidia-container-runtime et configurer le /etc/docker/deamon.json pour utiliser runtime: nvidia :

https://github.com/NVIDIA/ansible-role-nvidia-docker

(pour une raison quelconque, il ne fonctionne que sur Ubuntu et RHEL, mais il est assez facile à modifier. Je l'exécute sur Debian)

Puis dans votre docker-compose.yml :

version: "2.4"
services:
  test:
    image: "nvidia/cuda:10.2-runtime-ubuntu18.04"
    command: "nvidia-smi"

une mise à jour sur la version officielle 3.x avec le support gpu? Nous avons besoin d'un essaim :)

Est-il prévu d'ajouter cette fonctionnalité?

Cette fonctionnalité dépend de l'implémentation par docker-py des paramètres device_requests , ce que signifie --gpus . Il y a eu plusieurs pull requests pour ajouter cette fonctionnalité (https://github.com/docker/docker-py/pull/2419, https://github.com/docker/docker-py/pull/2465, https: / /github.com/docker/docker-py/pull/2471) mais il n'y a aucune réaction d'aucun responsable. # 7124 utilise https://github.com/docker/docker-py/pull/2471 pour le fournir dans Compose, mais toujours aucune réponse de personne.

Comme je l'ai mentionné dans # 7124, je suis plus qu'heureux de rendre le PR plus conforme, mais comme il a attiré très peu d'attention, je ne veux pas perdre mon temps dans quelque chose qui ne sera pas fusionné ...

Veuillez ajouter cette fonctionnalité, ce sera génial!

S'il vous plaît, ajoutez cette fonctionnalité! J'étais plus que satisfait de l'ancien nevidia-docker2, qui m'a permis de changer le runtime dans le daemon.json. Ce serait extrêmement agréable de le récupérer.

Besoin, s'il vous plaît. J'en ai vraiment besoin: /

J'aimerais aussi m'empiler ... nous avons besoin de cette fonctionnalité!

Je dois exécuter à la fois des conteneurs CPU et GPU sur la même machine pour que le hack d'exécution par défaut ne fonctionne pas pour moi. Avons-nous une idée de quand cela fonctionnera sur la composition? Étant donné que nous n'avons pas l'indicateur d'exécution dans la composition, cela représente une régression de fonctionnalité sérieuse, n'est-ce pas? Je dois écrire des scripts pour que cela fonctionne - beurk!

Je dois exécuter à la fois des conteneurs CPU et GPU sur la même machine pour que le hack d'exécution par défaut ne fonctionne pas pour moi. Avons-nous une idée de quand cela fonctionnera sur la composition? Étant donné que nous n'avons pas l'indicateur d'exécution dans la composition, cela représente une régression de fonctionnalité sérieuse, n'est-ce pas? Je dois écrire des scripts pour que cela fonctionne - beurk!

vous pouvez le faire par docker cli (docker run --gpu ....), j'ai ce genre d'astuce (en ajoutant un proxy, pour pouvoir communiquer avec d'autres conteneurs fonctionnant sur d'autres nœuds sur swarm). Nous attendons tous la possibilité de l'exécuter sur swarm, car il ne fonctionne pas par la commande de service docker (comme je le sais) ni par compose.

@dottgonzo . Hé bien oui ;-). J'en suis conscient et donc la référence aux scripts. Mais c'est une façon assez horrible et non portable de le faire, alors j'aimerais le faire d'une manière plus dynamique. Comme je l'ai dit, je pense que cela représente une régression, pas une demande de fonctionnalité.

COMPOSE_API_VERSION=auto docker-compose run gpu

@ggregoire où

@joehoeller à partir de votre shell était juste que vous feriez pour n'importe quelle autre commande.

Pour le moment, nous décidons pour chaque projet si nous avons besoin de fonctionnalités 3.x ou si nous pouvons utiliser docker-compose 2.x où l'option GPU est toujours prise en charge. Des fonctionnalités telles que l'exécution de cibles à plusieurs étages à partir d'un Dockerfile ne peuvent malheureusement pas être utilisées si le GPU est nécessaire. Veuillez rajouter ceci!

Je voudrais recommander quelque chose comme un champ "options supplémentaires" pour docker-compose où nous pouvons simplement ajouter des indicateurs comme --gpus=all à la commande docker start / run, qui ne sont pas encore / plus pris en charge dans docker-compose mais sont dans la dernière version de docker. De cette façon, les utilisateurs de composition n'auront pas à attendre que docker-compose se rattrape s'ils ont besoin d'une nouvelle fonctionnalité de docker non encore prise en charge.

Est toujours nécessaire de l'exécuter sur Docker Swarm pour les environnements de production. Cela sera-t-il utile pour Docker Swarm?

@sebastianfelipe C'est très utile si vous souhaitez déployer sur votre essaim en utilisant compose.
Comparer:
docker service create --generic-resource "gpu=1" --replicas 10 \ --name sparkWorker <image_name> \"service ssh start && \ /opt/spark/bin/spark-class org.apache.spark.deploy.worker.Worker spark://<spark_master_ip>:7077\"

à quelque chose comme ça

docker stack deploy --compose-file docker-compose.yml stackdemo

@sebastianfelipe C'est très utile si vous souhaitez déployer sur votre essaim en utilisant compose.
Comparer:
docker service create --generic-resource "gpu=1" --replicas 10 \ --name sparkWorker <image_name> \"service ssh start && \ /opt/spark/bin/spark-class org.apache.spark.deploy.worker.Worker spark://<spark_master_ip>:7077\"

à quelque chose comme ça

docker stack deploy --compose-file docker-compose.yml stackdemo

Désolé, fonctionne-t-il déjà avec Docker Swarm en utilisant le fichier yaml docker-compose? Juste pour être sûr: O. Merci!

uniquement pour docker compose 2.x

Le but de ce problème est de demander le support gpu nvidia-docker pour docker-compose 3+

Cela fait presque un an depuis la demande initiale !! Pourquoi ce retard ?? Pouvons-nous faire avancer cela?

ping @KlaasH @ulyssessouza @Goryudyuma @ chris-crone. Une mise à jour pour ceci?

Pour ceux d'entre vous qui recherchent une solution de contournement, voici ce que nous avons fini par faire:

• Installez docker-py à partir de ce PR: docker / docker-py # 2471
• Installez docker-compose à partir de ce PR: # 7124

Et puis exécutez COMPOSE_API_VERSION=auto docker-compose run gpu avec le fichier suivant:

version: '3.7'

services:
    gpu:
        image: 'nvidia/cuda:9.0-base'
        command: 'nvidia-smi'
        device_requests:
            - capabilities:
               - "gpu"

Pour ceux d'entre vous qui sont aussi impatients que moi, voici une version simple pip install de la solution de contournement ci-dessus:

pip install git+https://github.com/docker/docker-py.git@refs/pull/2471/merge
pip install git+https://github.com/docker/compose.git@refs/pull/7124/merge
pip install python-dotenv

Félicitations énormes à
J'attends toujours avec impatience un patch officiel. Avec tous les PR en place, cela ne semble pas difficile à tous égards.

ping @KlaasH @ulyssessouza @Goryudyuma @ chris-crone. Une mise à jour pour ceci?

Non, je ne sais pas pourquoi j'ai été appelé.
Je veux que tu me dises quoi faire?

J'espère qu'il y a une mise à jour à ce sujet.

Ouais, ça fait plus d'un an maintenant ... pourquoi ne fusionnent-ils pas dans docker-py ...

Je ne suis pas sûr que les implémentations proposées soient les bonnes pour le format Compose. La bonne nouvelle est que nous avons ouvert la spécification du format Compose avec l'intention d'ajouter des choses comme celle-ci. Vous pouvez trouver les spécifications sur https://github.com/compose-spec.

Ce que je suggérerais de faire, c'est d'ajouter un problème sur la spécification, puis d'en discuter lors de l'une des prochaines réunions de la communauté Compose (lien pour inviter au bas de cette page ).

Cela fonctionne: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi
Cela ne fonctionne pas: docker run --runtime=nvidia nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Vous devez avoir

{
    "runtimes": {
        "nvidia": {
            "path": "/usr/bin/nvidia-container-runtime",
            "runtimeArgs": []
        }
    }
}

dans votre /etc/docker/daemon.json pour --runtime=nvidia pour continuer à travailler. Plus d'infos ici .

Dockerd ne démarre pas avec ce daemon.json

Seigneur, cela va prendre des années: @

Cela fonctionne: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi
@deniswal : Oui, nous le savons, mais nous nous interrogeons sur la fonctionnalité de composition.

@ chris-crone: Je suis confus: cela représente une régression par rapport à l'ancien comportement, pourquoi a-t-il besoin d'une nouvelle spécification de fonctionnalité? N'est-il pas raisonnable d'exécuter des conteneurs, dont certains utilisent le GPU et d'autres utilisent le CPU sur la même boîte physique?

Merci pour la considération.

@ vk1z AFAIK Docker Compose n'a jamais eu de support GPU donc ce n'est pas une régression. La partie qui doit être conçue est de savoir comment déclarer le besoin d'un service pour un GPU (ou un autre périphérique) au format Compose - spécifiquement des changements comme celui-ci . Après cela, il devrait simplement être raccordé au backend.

Salut les gars, j'ai essayé certaines solutions proposées ici et rien n'a fonctionné pour moi, par exemple @miriaford ne fonctionne pas dans mon cas, y a-t-il également un moyen d'utiliser le GPU pour exécuter mes conteneurs docker existants?
J'ai un i7 avec 16 Go de RAM mais la construction de certains projets prend trop de temps, mon objectif est également d'utiliser la puissance du GPU pour accélérer le processus, est-ce possible? Merci!

@ chris-crone: Encore une fois, je serai prêt à être corrigé, mais n'est-ce pas parce que le paramètre runtime: a disparu de compose après la configuration 2.4? C'est pourquoi j'ai senti que c'était une régression. Mais non, peu importe maintenant puisque nous devrions tous être sur 3.x de toute façon.

Je serais heureux de déposer un problème, faisons-nous cela par rapport aux spécifications du référentiel de spécifications, n'est-ce pas?

mais n'était-ce pas parce que le paramètre runtime: a disparu de compose après la configuration 2.4? C'est pourquoi j'ai senti que c'était une régression.

Oui, exactement. J'ai quelques projets sur lesquels nous comptons sur l'utilisation de runtime: nvidia dans nos fichiers docker-compose, et ce problème nous empêche de passer à la version 3.x car nous n'avons pas trouvé de moyen d'utiliser les GPU là-bas.

Salut, s'il vous plaît, s'il vous plaît, veuillez résoudre ce problème.
Cela devrait être marqué comme priorité critique pour la mission -20

Encore une fois, je serai prêt à être corrigé, mais n'était-ce pas parce que le paramètre runtime: a disparu de compose après la configuration 2.4? C'est pourquoi j'ai senti que c'était une régression. Mais non, peu importe maintenant puisque nous devrions tous être sur 3.x de toute façon.

Je n'étais pas là lorsque le changement a été apporté, donc je ne sais pas à 100% pourquoi il a été abandonné. Je sais que vous n'avez plus besoin du runtime NVIDIA pour utiliser les GPU et que nous faisons évoluer la spécification Compose v3 à l'air libre ici avec l'intention de créer une version unique de la spécification. Cela peut signifier déplacer certaines fonctionnalités de la v2 vers la v3.

En ce qui concerne le champ runtime , je ne pense pas que ce soit ainsi qu'il devrait être ajouté à la spécification Compose car il est très spécifique à l'exécution sur un seul nœud. Idéalement, nous voudrions quelque chose qui vous permette de spécifier que votre charge de travail a un besoin de périphérique (par exemple: GPU, TPU, tout ce qui vient ensuite), puis laissez l'orchestrateur attribuer la charge de travail à un nœud qui fournit cette capacité.

Cette discussion devrait porter sur la spécification, car ce n'est pas spécifique à Python Docker Compose.

@ chris-crone: Je suis principalement d'accord avec votre déclaration. L'ajout de hacks à court terme est probablement la mauvaise façon de le faire car nous avons une prolifération de périphériques de périphérie, chacun avec ses propres temps d'exécution. Par exemple, comme vous le faites remarquer, TPU (Google), VPU (Intel) et ARM GPU sur le Pi. Nous avons donc besoin d'une histoire plus complète.

Je vais déposer un problème contre la spécification aujourd'hui et mettre à jour ce fil une fois que je l'ai fait. Cependant, je pense que l'orchestrateur devrait être indépendant - par exemple si je veux utiliser Kube, je devrais pouvoir le faire. Je suppose que ce sera dans la portée.

Cependant, je ne suis pas d'accord avec la déclaration d'utilisation des GPU, car cela ne fonctionne pas avec compose - c'est de cela qu'il s'agit. Mais je pense que nous comprenons tous quel problème nous aimerions résoudre.

@ chris-crone: Veuillez consulter le problème de spécification de docker-compose déposé. Je suivrai les mises à jour concernant ce problème à partir de maintenant.

Pouvons-nous simplement ajouter une option (quelque chose comme extra_docker_run_args ) pour passer des arguments directement au docker run sous-jacent? Cela résoudra non seulement le problème actuel, mais sera également à l'épreuve du temps: que se passerait-il si docker ajoutait la prise en charge de tout "XPU", ​​"YPU" ou de toute autre nouvelle fonctionnalité qui pourrait apparaître dans le futur?

Si nous avons besoin d'une longue discussion aller-retour chaque fois que docker ajoute une nouvelle fonctionnalité, elle sera extrêmement inefficace et entraînera un retard inévitable (et une confusion inutile) entre les mises docker jour docker-compose et docker . La prise en charge de la délégation d'argument peut apporter un soulagement temporaire à ce problème récurrent pour toutes les fonctionnalités futures.

@miriaford Je ne suis pas sûr que le passage d'un objet blob non interprété prenne en charge la notion de composition d'être déclarative. L'ancienne balise d'exécution indiquait au moins que c'était quelque chose à voir avec l'environnement d'exécution. Compte tenu de la direction dans laquelle le docker évolue (docker-apps), il me semble que cela rendrait le déploiement déclaratif plus difficile car un orchestrateur devrait analyser des blobs arbitraires.

Mais je suis d'accord que la composition et le docker doivent être synchronisés et que le zapping des fonctionnalités de travail dont les gens dépendent (même s'il s'agissait d'une version majeure) n'est pas tout à fait casher.

@ vk1z Je suis d'accord - il devrait y avoir un mécanisme de synchronisation bien meilleur entre compose et docker . Cependant, je ne m'attends pas à ce qu'un tel mécanisme soit conçu de si tôt. En attendant, nous avons également besoin d'un moyen temporaire de faire notre propre synchronisation sans pirater profondément le code source.

Si la proposition de délégation d'argument n'est pas une option, que suggérons-nous de faire? Je suis d'accord que ce n'est pas une jolie solution, mais c'est au moins beaucoup mieux que cette solution de contournement, n'est-ce pas? https://github.com/docker/compose/issues/6691#issuecomment -616984053

@miriaford docker-compose n'appelle pas l'exécutif de docker avec l'argument, il utilise en fait le docker_py qui utilise l'API http pour le démon docker. Il n'y a donc pas de commande "sous-jacente docker run ". La CLI docker n'est pas une API, la connexion socket est le point de contact API. C'est pourquoi ce n'est pas toujours aussi simple.

Pour simplifier les choses, dans le processus d'exécution d'un docker, il y a deux appels principaux, l'un qui crée le conteneur et l'autre qui le démarre, chacun ingère des informations différentes, et savoir ce qui est tout demande à quelqu'un ayant des connaissances en API, ce qui Je ne sais pas comme moi, nous avons tendance à connaître la CLI docker . Je ne pense pas que la possibilité d'ajouter des arguments supplémentaires aux appels docker_py sera aussi utile que vous le pensez, sauf dans certains cas d'utilisation.

Pour rendre les choses encore plus difficiles, la bibliothèque docker_py se trouve parfois derrière l'API, et n'a pas non plus tout ce dont vous avez besoin tout de suite, et vous devez attendre qu'elle soit mise à jour. Cela étant dit, extra_docker_run_args n'est pas une solution simple.

@andyneff Merci pour votre explication. En effet, je ne suis pas trop familier avec le fonctionnement interne de Docker. Si je comprends bien, il y a 4 API qui doivent être synchronisées manuellement pour toute nouvelle mise à jour de fonctionnalités:

1. API de socket Docker
2. docker_py qui fournit une interface python à l'API socket
3. Docker CLI (notre point d'entrée familier vers la chaîne d'outils docker)
4. Interface Docker-compose qui appelle l'API de socket docker

Cela soulève la question: pourquoi n'y a-t-il pas de mécanisme de synchronisation automatique (ou du moins semi-automatique)? La propagation manuelle de nouvelles mises à jour de fonctionnalités sur 4 API semble vouée à être sujette aux erreurs, aux retards et à la confusion ...

PS Je ne dis pas que c'est une tâche _simple_ d'avoir une synchronisation automatique, mais je pense vraiment qu'il devrait y en avoir une pour rendre la vie plus facile à l'avenir.

Je me lance un peu dans la pédantique maintenant ... Mais comme je le décrirais comme ...

• La socket docker est l'API officielle de docker. C'est souvent une socket de fichier, mais peut aussi être TCP (ou tout autre, j'imagine en utilisant socat )
• La CLI docker utilise cette API pour nous offrir aux utilisateurs un outil génial
  
  
  
  • Docker écrit l'API et la CLI, de sorte qu'ils sont toujours synchronisés au moment de la publication. (Je pense que c'est sûr à dire, la CLI est un citoyen de première classe de l'écosystème docker)
  
  
• La bibliothèque docker_py prend cette API et la place dans une bibliothèque géniale que d'autres bibliothèques Python peuvent utiliser. Sans cela, vous passeriez vous-même tous ces appels HTTP et vous tireriez les cheveux.
  
  
  
  • Cependant, docker_py a été démarré en tant que bibliothèque tierce, et il a donc traditionnellement suivi l'API docker, et a ajouté des éléments plus tard ou au besoin (ressources limitées).
  
  
• compose utilise une version de docker_py, puis ajoute toutes ces fonctionnalités impressionnantes, toujours au besoin (en fonction de problèmes comme celui-ci)
  
  
  
  • Cependant, composer ne peut pas faire grand-chose avant docker_py (ce qui, je ne dis pas, retarde ce problème, je ne sais pas, je parle juste en général)
  
  

Alors oui, ça va:

• "composer yaml + composer les arguments" -> "docker_py" -> "docker_api"
• Et la CLI n'en fait pas partie (et croyez-moi, c'est la bonne façon de faire les choses)

Je ne peux pas parler pour docker_py ni composer, mais j'imagine qu'ils ont des heures de travail limitées pour y contribuer, il est donc plus difficile de suivre TOUTES les fonctionnalités de docker folles que docker ajoute CONSTANT. Mais puisque docker est une bibliothèque go, et je crois comprendre que le support de python n'est pas (actuellement) un citoyen de première classe. Bien qu'il soit bien que les deux projets soient sous l'égide des dockers, du moins du point de vue d'une organisation github.

Donc, tout cela étant dit ... moi aussi j'attends un support équivalent --gpus , et je dois utiliser à la place l'ancienne méthode runtime: nvidia , qui me donnera au moins "un" chemin pour me déplacer avancer dans docker-compose 2.x.

@andyneff Pour info, il existe une prise en charge de la CLI Docker dans le dernier docker-compose. Cela permet d'utiliser le buildkit par exemple. https://www.docker.com/blog/faster-builds-in-compose-thanks-to-buildkit-support/

@andyneff c'est un aperçu très utile! Merci encore

@lig génial! Merci pour la correction! Je pensais en fait "Comment le buildkit s'intégrera-t-il dans tout cela" pendant que j'écrivais cela

Ce qui me surprend un peu, c'est que docker-compose est une partie assez intrinsèque du nouveau framework docker-app et j'imagine qu'ils voudraient synchroniser docker-compose et docker pour au moins cette raison. Je me demande ce qu'est vraiment le bloqueur: pas assez de bande passante python? Cela semble un peu incroyable.

Alors, comment Docker Swarm s'intègre-t-il dans la structure que @andyneff vient de décrire? Swarm utilise le format de fichier compose version 3 (défini par le projet "compose"?) Mais est développé dans le cadre de docker ?

Toutes mes excuses si ce n'est pas le sujet de ce problème particulier. J'ai plutôt perdu la trace du problème, mais j'ai commencé à le suivre car j'aimerais pouvoir dire à un service fonctionnant sur un essaim qu'il doit utiliser un runtime particulier. Nous ne pouvons le faire qu'avec la v2 de la spécification compose-file, ce qui signifie que nous ne pouvons pas le faire avec Swarm qui nécessite la v3. En d'autres termes, je ne suis pas vraiment intéressé par ce que fait la CLI docker-compose mais seulement par la spécification définie pour les fichiers docker-compose.yml qui sont consommés par docker swarm.

Oh essaim, celui qui s'est échappé ... (de moi). Malheureusement, c'est # 6239 qui a été fermé par un BOT. :( Quelqu'un a essayé dans # 6240 mais on lui a dit que ...

@miriaford , on dirait qu'il y a un PR pour les synchroniser! # 6642?! (Est-ce juste pour la v3 ???)

Donc, en raison de la nature de l'essaim, il y a certaines choses que vous faites et ne faites pas sur les nœuds d'essaim. Ainsi, l'API Docker ne vous permet pas toujours de faire les mêmes options sur une exécution en essaim, comme une exécution normale. Je ne sais pas si le runtime fait partie de ces choses, mais c'est souvent pourquoi vous ne pouvez pas faire les choses en v3 (la version compatible swarm) et pouvez en v2 (la version non compatible swarm).

Personne ne sait de quoi vous parlez.
Nous essayons tous de déployer jellyfin avec une accélération matérielle.
Jusqu'à ce que vous corrigiez cela comme il est supposé être, quand il dit service, 3.x n'est pas bon.
Ne l'utilisez pas.

Vous devez mettre 2.4 pour le service.
Ensuite, vous pouvez utiliser l'accélération matérielle pour jellyfin, ez

Alors allez les gars, quelle est l'ETA sur ce, 1 an, 2 ans?

@KlaasH @ulyssessouza @Goryudyuma @ chris-crone Salut, je travaille sur ce problème, j'ai trouvé que le support manquait dans "docker-py", j'ai travaillé sur cette partie. Maintenant, pour que cela fonctionne, je dois passer les configurations via le fichier docker-compose.yml. Pouvez-vous m'aider avec le schéma? c'est-à-dire que pour l'ajouter, je dois l'ajouter à un nouveau schéma ou y a-t-il un endroit où les configurations pourraient être passées

@fakabbir Je suppose qu'il est correct d'utiliser simplement COMPOSE_DOCKER_CLI_BUILD pour cela. L'ajout d'une capacité à fournir une liste arbitraire d'arguments docker run pourrait même aider à éviter des problèmes similaires à l'avenir.

@lig comment

@lig AFAICS compose utilise docker-py au lieu de docker run cli. Donc, l'ajout d'arguments arbitraires docker run ne fonctionnerait pas à moins que docker-py prenne également en charge.

réf: https://github.com/docker/compose/issues/6691#issuecomment -585199425

Cette seule chose réduit énormément l'utilité de docker-compose pour de nombreuses personnes. Le fait qu'il n'ait pas suscité beaucoup d'attention et de désir de le réparer, en particulier lorsqu'il fonctionnait dans un ancien docker-compose, est assez étonnant.
Une façon de procéder ne serait-elle pas d'autoriser des arguments docker --run arbitraires à donner dans un fichier docker-compose? Ensuite, --gpus all par exemple pourrait être passé à docker.

Je comprends qu'il peut y avoir des raisons philosophiques ou techniques pour lesquelles on pourrait vouloir le faire d'une manière particulière. Mais ne pas mettre la main dessus et le faire de quelque manière que ce soit stupéfie l'esprit.

@lig comment

Eh bien, la variable d'environnement NVIDIA_VISIBLE_DEVICES vous permettra de contrôler que non?

Cette seule chose réduit énormément l'utilité de docker-compose pour de nombreuses personnes. Le fait qu'il n'ait pas suscité beaucoup d'attention et de désir de le réparer, en particulier lorsqu'il fonctionnait dans un ancien docker-compose, est assez étonnant.
Une façon de procéder ne serait-elle pas d'autoriser des arguments docker --run arbitraires à donner dans un fichier docker-compose? Ensuite, --gpus all par exemple pourrait être passé à docker.

Je ne pense pas qu'autoriser le passage de docker --run args soit la voie à suivre. compose n'appelle pas vraiment docker par lui-même mais utilise à la place docker-py .

Je comprends qu'il peut y avoir des raisons philosophiques ou techniques pour lesquelles on pourrait vouloir le faire d'une manière particulière. Mais ne pas mettre la main dessus et le faire de quelque manière que ce soit stupéfie l'esprit.

Un PR est ouvert à ce sujet: https://github.com/docker/compose/pull/7124. N'hésitez pas à «mettre la main dessus».

Je crois que , selon le changement de la spécification de docker compose , nous devrions bientôt revenir à la compatibilité antérieure selon compose 2.4 et le runtime nvidia fonctionnera. Cela ne fonctionnera évidemment pas pour les TPU ou d'autres accélérateurs - ce qui est très regrettable, mais pour ceux qui veulent utiliser des gpus nvidia (coûteux), cela fonctionnera.

J'attends donc juste qu'un PR vert dans docker-py soit fusionné https://github.com/docker/docker-py/pull/2471

OUAIS! Le PR de docker-py a été approuvé! https://github.com/docker/docker-py/pull/2471
Quelle est la prochaine étape ici?

Quoi de neuf ici? Ce serait cool de pouvoir prendre en charge le runtime nvidia dans docker-compose

https://github.com/docker/docker-py/pull/2471 a été fusionné.

Maintenant que docker / docker-py # 2471 a été fusionné, nous pouvons installer le docker-py de master. Mais puisque le docker-compose a changé depuis le [PR] cool de @yoanisgil (https://github.com/docker/compose/pull/7124) (Félicitations!), Il est peu probable qu'il soit fusionné. Donc, à ce stade, le docker-compose peut être installé à partir de ce PR pour sauver la situation.

Pour ceux qui se sont retrouvés ici sans voir les commentaires précédents:

pip install git+https://github.com/docker/docker-py.git
pip install git+https://github.com/yoanisgil/compose.git@device-requests

Utilisez ensuite le modèle suivant dans votre fichier de composition. (source: commentaire ):

Et puis exécutez COMPOSE_API_VERSION=auto docker-compose run gpu avec le fichier suivant:

version: '3.7'

services:
    gpu:
        image: 'nvidia/cuda:9.0-base'
        command: 'nvidia-smi'
        device_requests:
            - capabilities:
               - "gpu"

Je confirme que cela a fonctionné sur ma machine locale. Je ne sais pas que cela fonctionne avec Swarm.

Impossible d'avoir un commit particulier de docker-compose en production. Le # 7124 doit-il être rebasé ou y a-t-il un autre PR qui va incorporer le nouveau docker-py ?

Salut @bkakilli ,

Merci pour l'aide! Je viens d'essayer votre suggestion, mais j'obtiens une erreur lors de l'exécution de mon docker-compose

ERROR: The Compose file './docker-compose.yml' is invalid because:
Unsupported config option for services.analysis: 'device_requests'

_analyse étant le nom de mon conteneur_

J'ai changé mon docker-compose.yml de:

version: '2.3'

services:
    analysis:
        container_name: analysis
        image: analysis:${TAG}
        runtime: nvidia
        restart: always
        ports:
            - "8000:80"

à:

version: '3.7'

services:
    analysis:
        container_name: analysis
        image: analysis:${TAG}
        device_requests:
          - capabilities:
            - "gpu"
        restart: always
        ports:
            - "8000:80"

Y a-t-il autre chose que pip install git+ pour configurer correctement cela? Ou peut-être ai-je mal édité le fichier de configuration?

@frgfm assurez-vous que vous installez compose et docker-py à partir des liens corrects. Vous avez peut-être utilisé le propre repo de docker-compose au lieu du fork (et de la branche) de yoanisgil. Vérifiez si vous utilisez le lien suivant:

pip install git+https://github.com/yoanisgil/compose.git@device-requests

Vous pouvez essayer de mettre --upgrade param dans pip install. Sinon, je soupçonnerais les paramètres de l'environnement virtuel. Peut-être avez-vous une autre installation de docker-compose, qui est utilisée par défaut? Par exemple, vous l'avez peut-être installé pour le système avec les instructions "Linux" ici: https://docs.docker.com/compose/install/. Je vous suggère de jeter un oeil à "Alternative Install Options" et d'installer via pip dans l'environnement virtuel (mais utilisez la commande pip install ci-dessus. N'installez pas le docker-compose par défaut de PyPI).

Salut!
Merci pour toutes ces informations. J'essayais d'exécuter votre approche @bkakilli et docker-compose build fonctionnait, mais lors de l'exécution de docker-compose up j'ai eu l'erreur:
docker.errors.InvalidVersion: device_requests param is not supported in API versions < 1.40

Mon docker_compose.yml ressemble à ceci:

version: '3.7'

networks:
  isolation-network:
    driver: bridge

services:
 li_t5_service:
    build: .
    ports:
      - "${GRAPH_QL_API_PORT}:5001"
    device_requests:
      - capabilities:
        - "gpu"
    environment:
      - SSH_PRIVATE_KEY=${SSH_PRIVATE_KEY}
      - PYTHONUNBUFFERED=${PYTHONUNBUFFERED}
    networks: 
      - isolation-network

Merci d'avance!

@ugmSorcero Définissez la variable d'environnement COMPOSE_API_VERSION=1.40 puis réexécutez vos commandes

@ugmSorcero avez-vous réussi à corriger cette erreur? @EpicWink @bkakilli J'exécute la version indiquée à partir de l'installation de pip mais j'obtiens toujours l'erreur pour device_requests param is not supported in API versions < 1.40 même si j'exporte une telle variable vers 1,40

Pour le fichier de composition donné

version: "3.7"
services:
  spam:
    image: nvidia/cuda:10.1-cudnn7-runtime
    command: nvidia-smi
    device_requests:
      - capabilities:
          - gpu

En utilisant la version de docker-compose installée comme ci-dessus, dans Bash sous Linux, la commande suivante réussit:

COMPOSE_API_VERSION=1.40 docker-compose up

La commande suivante échoue:

docker-compose up

Cela a une sortie d'erreur:

ERROR: for tmp_spam_1  device_requests param is not supported in API versions < 1.40
...
docker.errors.InvalidVersion: device_requests param is not supported in API versions < 1.40

@EpicWink merci beaucoup. Je n'avais pas réalisé que docker-compose up devait être exécuté de cette façon. Je l'ai pris comme une étape 2 où j'ai d'abord exporté COMPOSE_API_VERSION séparément. L'exécuter ensemble semble fonctionner :)

J'ai un autre problème, cependant. Si j'exécute COMPOSE_API_VERSION=1.40 docker-compose run nvidiatest alors nvidia-smi n'est pas trouvé dans le chemin, tandis que si je cours directement à partir de l'image, il n'y a pas de problème.

Voici comment je le reproduis.

Le fichier local docker-compose contient:

nvidiatest:
    image: nvidia/cuda:10.0-base
    device_requests:
      - capabilities:
        - gpu
    command: nvidia-smi

Si j'exécute ma configuration actuelle (à la fois la version api automatique et la version 1.40), j'obtiens l'erreur suivante:

COMPOSE_API_VERSION=auto docker-compose -f docker-compose.yml -f docker-compose.local.yml run nvidiatest
Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "exec: \"nvidia-smi\": executable file not found in $PATH": unknown

Est-il possible que cela ait à voir avec l'utilisation de fichiers de remplacement? Si je lance simplement l'image de base cuda avec Docker, il n'y a aucun problème pour obtenir la sortie de nvidia-smi :

docker run --gpus all nvidia/cuda:10.0-base nvidia-smi
Mon Aug 24 11:40:04 2020
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 440.100      Driver Version: 440.100      CUDA Version: 10.2     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce RTX 2070    Off  | 00000000:29:00.0  On |                  N/A |
|  0%   46C    P8    19W / 175W |    427MiB /  7974MiB |      2%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
+-----------------------------------------------------------------------------+

J'ai installé docker-compose suivant les instructions ci-dessus de git après avoir désinstallé la version installée à partir de la documentation officielle. Voici les informations de la version installée:

pip3 show --verbose docker-compose
Name: docker-compose
Version: 1.26.0.dev0
Summary: Multi-container orchestration for Docker
Home-page: https://www.docker.com/
Author: Docker, Inc.
Author-email: None
License: Apache License 2.0
Location: /home/jurugu/.local/lib/python3.8/site-packages
Requires: docopt, docker, requests, PyYAML, texttable, websocket-client, six, dockerpty, jsonschema, cached-property
Required-by:
Metadata-Version: 2.1
Installer: pip
Classifiers:
  Development Status :: 5 - Production/Stable
  Environment :: Console
  Intended Audience :: Developers
  License :: OSI Approved :: Apache Software License
  Programming Language :: Python :: 2
  Programming Language :: Python :: 2.7
  Programming Language :: Python :: 3
  Programming Language :: Python :: 3.4
  Programming Language :: Python :: 3.6
  Programming Language :: Python :: 3.7
Entry-points:
  [console_scripts]
  docker-compose = compose.cli.main:main

Est-ce que je manque quelque chose? Merci pour l'aide!

@jjrugui cela devient hors sujet et je ne suis pas en mesure de reproduire votre problème. Désolé de ne pas pouvoir vous aider

@EpicWink pas de problème, et désolé de s'écarter du sujet :). Si je découvre mon problème particulier, je le posterai ici s'il est pertinent.

Est-ce que quelqu'un travaille sur un autre PR ou sommes-nous en train de déboguer la branche device-requests afin de se préparer pour un PR?

Pendant que le PR est bloqué, j'ai porté les modifications de # 7124 vers la dernière version de la branche master pour faire correspondre les dépendances, etc. - https://github.com/beehiveai/compose Vous pouvez installer avec pip install git+https://github.com/beehiveai/compose.git et changez la version en docker-compose.yml en 3.8 :

version: "3.8"
services:
  gpu-test:
    image: nvidia/cuda:10.2-runtime
    command: nvidia-smi
    device_requests:
      - capabilities:
          - gpu

Dans ce cadre, tout fonctionne comme prévu.

Comme discuté hier lors de la réunion de gouvernance de composition-spec , nous commencerons à travailler sur une proposition pour adopter quelque chose de comparable à # 7124, qui pourrait être proche de generic_resouces déjà disponible dans la section deploy .

@ndeloof C'est super! Si cela est possible, veuillez publier le lien vers la proposition ici. Je pense que de nombreuses personnes seraient ravies d'y contribuer, car la prise en charge du GPU est essentielle pour les déploiements d'apprentissage en profondeur.

@ndeloof Historiquement, combien de temps faut-il au comité de pilotage pour prendre une décision, 6 mois, un an?

+1

+1

@visheratin Avez -vous une chance d'améliorer votre correctif afin qu'il fonctionne lorsque vous utilisez plusieurs fichiers yml de composition? J'ai un docker-compose.yml de base qui utilise un conteneur non-nvidia, que je souhaite remplacer par un conteneur nvidia quand il y a un GPU, mais il semble qu'avec votre correctif, si je spécifie plusieurs fichiers yml de composition avec le "- f ", les champs" device_requests "disparaissent de la configuration.

@proximous Qu'entendez-vous par "abandonne la configuration"? Tous les fichiers de composition ont-ils la version 3.8? Pouvez-vous partager l'exemple pour qu'il soit plus facile à reproduire?

Avoir un problème avec le code dans compose / service.py lorsque vous essayez d'utiliser l'option --scale avec docker-compose up. N'est-ce pas pris en charge?

Traceback (dernier appel le plus récent):
Fichier "/ usr / local / bin / docker-compose", ligne 11, dans
load_entry_point ('docker-compose == 1.27.0.dev0', 'console_scripts', 'docker-compose') ()
Fichier "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", ligne 67, dans main
commander()
Fichier "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", ligne 123, dans perform_command
gestionnaire (commande, options_commande)
Fichier "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", ligne 1067, en haut
to_attach = up (Faux)
Fichier "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", ligne 1063, en haut
cli = constructeur_natif,
Fichier "/usr/local/lib/python3.6/site-packages/compose/project.py", ligne 648, en haut
get_deps,
Fichier "/usr/local/lib/python3.6/site-packages/compose/parallel.py", ligne 108, dans parallel_execute
lever error_to_reraise
Fichier "/usr/local/lib/python3.6/site-packages/compose/parallel.py", ligne 206, dans le producteur
résultat = func (obj)
Fichier "/usr/local/lib/python3.6/site-packages/compose/project.py", ligne 634, dans do
override_options = override_options,
Fichier "/usr/local/lib/python3.6/site-packages/compose/service.py", ligne 579, dans execute_convergence_plan
renouveler_anonymes_volumes,
Fichier "/usr/local/lib/python3.6/site-packages/compose/service.py", ligne 509, dans _execute_convergence_recreate
balance - len (conteneurs), détaché, départ
Fichier "/usr/local/lib/python3.6/site-packages/compose/service.py", ligne 479, dans _execute_convergence_create
"Créer"
Fichier "/usr/local/lib/python3.6/site-packages/compose/parallel.py", ligne 108, dans parallel_execute
lever error_to_reraise
Fichier "/usr/local/lib/python3.6/site-packages/compose/parallel.py", ligne 206, dans le producteur
résultat = func (obj)
Fichier "/usr/local/lib/python3.6/site-packages/compose/service.py", ligne 477, dans
nom_service lambda: create_and_start (self, service_name.number),
Fichier "/usr/local/lib/python3.6/site-packages/compose/service.py", ligne 456, dans create_and_start
container = service.create_container (nombre = n, quiet = True)
Fichier "/usr/local/lib/python3.6/site-packages/compose/service.py", ligne 333, dans create_container
previous_container = previous_container,
Fichier "/usr/local/lib/python3.6/site-packages/compose/service.py", ligne 936, dans _get_container_create_options
one_off = one_off)
Fichier "/usr/local/lib/python3.6/site-packages/compose/service.py", ligne 1014, dans _get_container_host_config
element.split (',') pour l'élément dans device_request ['capabilities']]
Fichier "/usr/local/lib/python3.6/site-packages/compose/service.py", ligne 1014, dans
element.split (',') pour l'élément dans device_request ['capabilities']]
AttributeError: l'objet 'list' n'a pas d'attribut 'split'

Après un débogage plus poussé, j'ai trouvé que lors de l'utilisation de --scale, pour une raison quelconque, une instance a le device_requests ['capabilities'] comme ['gpu']. Mais pour que tous les autres conteneurs soient démarrés, le device_request ['capabilities'] ressemble plutôt à [['gpu']].

J'ai fait un correctif temporaire localement pour contourner ce problème juste pour que mes conteneurs soient opérationnels à partir de la ligne 1010 dans compose / service.py:

''
pour device_request dans device_requests:
si 'capabilities' ne figure pas dans device_request:
continuer
if type (device_request ['capabilities'] [0]) == liste:
device_request ['capabilities'] = [
element.split ('.') pour l'élément dans device_request ['capabilities'] [0]]
autre:
device_request ['capabilities'] = [
element.split ('.') pour l'élément dans device_request ['capabilities']]

`` ``

@proximous Qu'entendez-vous par "abandonne la configuration"? Tous les fichiers de composition ont-ils la version 3.8? Pouvez-vous partager l'exemple pour qu'il soit plus facile à reproduire?

@visheratin voir cet exemple, ai-je tort d'attendre un résultat différent?

docker-compose.nogpu.yml:

version: '3.8'

services:
  df:
    build: miniconda-image.Dockerfile

docker-compose.gpu.yml:

version: '3.8'

services:
  df:
    build: nvidia-image.Dockerfile
    device_requests:
      - capabilities:
          - gpu

utilisez uniquement le nogpu.yml:

$ docker-compose -f docker-compose.nogpu.yml config
services:
  df:
    build:
      context: /home/jerry/gpu-test/miniconda-image.Dockerfile
version: '3'

utilisez uniquement le gpu.yml:

$ docker-compose -f docker-compose.gpu.yml config
services:
  df:
    build:
      context: /home/jerry/gpu-test/nvidia-image.Dockerfile
    device_requests:
    - capabilities:
      - gpu
version: '3'

chaîne de configuration ymls commençant par un yml non gpu (note ... manque le runtime):

$ docker-compose -f docker-compose.nogpu.yml -f docker-compose.gpu.yml config
services:
  df:
    build:
      context: /home/jerry/gpu-test/nvidia-image.Dockerfile
version: '3'

production attendue:

$ docker-compose -f docker-compose.nogpu.yml -f docker-compose.gpu.yml config
services:
  df:
    build:
      context: /home/jerry/gpu-test/nvidia-image.Dockerfile
    device_requests:
      - capabilities:
          - gpu
version: '3'

(Évidemment, j'essaie de faire quelque chose de plus élaboré et ce n'est qu'un cas simplifié pour mettre en évidence le comportement inattendu.)

@jlaule @proximous Afin de garder ce fil sur le sujet, veuillez créer des problèmes dans le repo forké, je les examinerai quand j'aurai le temps.

Pour ceux qui ont besoin de quelque chose en attendant, je viens de configurer K3S (version Edge de Kubernetes) avec le support GPU en 30 minutes en utilisant docker comme temps d'exécution du conteneur (c'est-à-dire utiliser l'option --docker du script d'installation). Suivez https://github.com/NVIDIA/k8s-device-plugin pour faire fonctionner le plugin de périphérique Nvidia.
J'espère que ça t'as aidé!

@EpicWink pas de problème, et désolé de s'écarter du sujet :). Si je découvre mon problème particulier, je le posterai ici s'il est pertinent.

Avez-vous déjà résolu cela?

Il n'existe plus de "/ usr / bin / nvidia-container-runtime". Le problème est toujours critique.

Installez nvidia-docker2 comme indiqué ici

Je me suis attaqué à cela ces derniers temps et j'ai pensé partager mon approche.
mon problème était que j'avais besoin de déployer la pile de docker et qu'il ne voulait pas écouter. docker compose j'avais travaillé avec le hack de la version de l'api de docker mais cela ne me semblait pas correct et le déploiement de la pile ne fonctionnerait pas malgré tout.

donc sans définir de demandes de périphérique pr au moment de l'exécution dans mon docker compose, j'ai ajouté ceci à mon démon:

{ "runtimes": { "nvidia": { "path": "/usr/bin/nvidia-container-runtime", "runtimeArgs": [] } }, "default-runtime": "nvidia", "node-generic-resources": [ "NVIDIA-GPU=0" ] }

vous pouvez également utiliser GPU- {première partie de gpu guid}
mais c'était plus facile. n'a pas eu à installer de pip + ou quelque chose comme ça, sauf la boîte à outils du conteneur NV. il se déploie et fonctionne comme un charme.

Tks beaucoup @haviduck ,
Pour les autres: n'oubliez pas de redémarrer votre démon docker.

@pommedeterresautee ah je suis si heureux que cela ait fonctionné pour les autres! aurait dû mentionner le rechargement.

je dois dire qu'après 3 semaines de docking non stop, je suis assez perplexe à quel point rien ne semble fonctionner ..

@haviduck : Merci! Enfin une solution simple qui fonctionne. J'ai passé tellement de temps à essayer d'ajouter des appareils, etc. que j'ai abandonné. Ensuite, cela arrive, essaie et après quelques minutes, le transcodage matériel dans Plex fonctionne.

J'ajouterai mes 2 cents à cette question ... J'ai lu beaucoup de messages et finalement la solution était assez simple.

cela a fonctionné pour moi avec: (peut-être qu'un peu plus bas aurait également fonctionné - aucune idée ...)
docker-compose version 1.27.4, build 40524192

1. sur la machine hôte docker, installez les packages nvidia-container-toolkit et nvidia-container-runtime
2. sur la machine hôte docker: type
   nvidia-smi et examinez la version CUDA qui apparaît à droite
   
3. sur la machine hôte docker: tapez: (remplacez la version cuda par celle que vous avez installée)
   docker run --rm --gpus all nvidia / cuda: nvidia-smi de
   vous devriez obtenir le même résultat que lorsque vous avez exécuté le nvidia-smi sur la machine hôte
4. dans le fichier /etc/docker/daemon.json, vous devriez voir:
   "runtimes": {"nvidia": {"path": "/ usr / bin / nvidia-container-runtime", "runtimeArgs": []}}
5. dans votre YML docker-compose, vous devez ajouter:
   runtime: nvidia

c'est ça !
déployez à l'aide du YML et vous aurez un support GPU dans votre docker-compose

5. in your docker-compose YML you should add:
   **runtime: nvidia**

Oh boy, tout ce fil concerne la version 3 qui n'a pas d'exécution.

Les versions 1.27.0+ ont fusionné les formats de fichiers v2 / v3, donc on peut utiliser runtime n'importe où maintenant. De plus, la spécification pour les accélérateurs a également été définie (https://github.com/compose-spec/compose-spec/pull/100) bien qu'elle ne soit pas encore implémentée dans docker-compose .

J'ajouterai mes 2 cents à cette question ... J'ai lu beaucoup de messages et finalement la solution était assez simple.

cela a fonctionné pour moi avec: (peut-être qu'un peu plus bas aurait également fonctionné - aucune idée ...)
docker-compose version 1.27.4, build 4052419

1. sur la machine hôte docker, installez les packages nvidia-container-toolkit et nvidia-container-runtime
2. sur la machine hôte docker: type
   nvidia-smi et examinez la version CUDA qui apparaît à droite
   
3. sur la machine hôte docker: tapez: (remplacez la version cuda par celle que vous avez installée)
   docker run --rm --gpus all nvidia / cuda: nvidia-smi de
   vous devriez obtenir le même résultat que lorsque vous avez exécuté le nvidia-smi sur la machine hôte
4. dans le fichier /etc/docker/daemon.json, vous devriez voir:
   "runtimes": {"nvidia": {"path": "/ usr / bin / nvidia-container-runtime", "runtimeArgs": []}}
5. dans votre YML docker-compose, vous devez ajouter:
   runtime: nvidia

c'est ça !
déployez à l'aide du YML et vous aurez un support GPU dans votre docker-compose

Pour info, la version cuda que vous pouvez voir dans la sortie de nvidia-smi fait référence à la version du pilote nvidia cuda, alias votre pilote nvidia (ils l'appellent aussi cuda, ce qui est déroutant). Le numéro de version dans l'image du docker, par exemple nvidia/cuda:10.1-base nvidia-smi fait référence à la version de la boîte à outils nvidia (encore une fois, le même système de numérotation de version est confus, différentes bêtes).

Le pilote est rétrocompatible avec la boîte à outils, vous pouvez donc exécuter n'importe quel nvidia/cuda:<version>-base nvidia-smi vous souhaitez, tant que <version> est inférieur ou égal à la version du pilote.

Plus d'informations ici: https://stackoverflow.com/questions/53422407/different-cuda-versions-shown-by-nvcc-and-nvidia-smi

Je ne vois pas les binaires Docker Compose 1.27.4 disponibles pour le système ARM.

pip install docker-compose
Defaulting to user installation because normal site-packages is not writeable
Requirement already satisfied: docker-compose in /usr/local/lib/python3.6/dist-packages (1.26.2)

Salut @collabnix!

Quelle est la sortie de pip --version ?

Compose 1.27 a abandonné la prise en charge de Python 2, il est donc possible que vous ne voyiez pas les versions 1.27.x si votre système a Python 2.

@collabnix c'est parce que vous avez déjà installé compose, essayez pip install --upgrade docker-compose

Je peux maintenant passer à la version 1.27.4. La mise à niveau du pip a fait l'affaire. Merci @kshcherban et @ chris-crone
C'est fou de voir la plupart des projets sur lesquels j'ai travaillé dans le passé et qui utilisent Python 2.7 ont vraiment besoin d'une mise à jour.

La mise à niveau de docker-compose vers la version 1.27.4 a résolu le problème.
(peut être mise à niveau vers 1.19.3 plus tard pour résoudre le problème)

$ cat /etc/docker/daemon.json 
{
    "default-runtime": "nvidia",
    "runtimes": {
        "nvidia": {
            "path": "/usr/bin/nvidia-container-runtime",
            "runtimeArgs": []
        }
    }
}

version: '3.5'

    runtime: nvidia
    environment:
      - NVIDIA_VISIBLE_DEVICES=all
      - NVIDIA_DRIVER_CAPABILITIES=all       
    image: 'detectme'
    ipc: 'host'
    tty: true
    stdin_open: true

$ sudo docker-compose up -d --build
ERROR: The Compose file './docker-compose.yml' is invalid because:
Unsupported config option for services.engine: 'runtime'

$ docker-compose --version
docker-compose version 1.17.1, build unknown

$ sudo curl -L "https://github.com/docker/compose/releases/download/1.27.4/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
$ sudo chmod +x /usr/local/bin/docker-compose
$ sudo rm /usr/bin/docker-compose
$ sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose

$ sudo docker-compose up -d --build
fonctionne bien avec docker-compose.
sur l'ordinateur hôte, vérifiez le GPU utilisé par nvidia-smi.

@ bttung-2020
@PyCod
Si j'utilise le dokcer-nvidia-devel (pas le runtime): nvidia / cuda: 10.1-cudnn7-devel-ubuntu18.04 dans docker-hub
Est-ce que ça marche? Comment dois-je modifier le fichier docker-compose.yaml?