Compose: Soporte para GPU NVIDIA en Docker Compose

Esto es de mayor importancia ahora que el (ahora) tiempo de ejecución de nvidia heredado aparece roto con Docker 19.03.0 y 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

Esto funciona: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Esto no lo hace: docker run --runtime=nvidia nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

¿Hay algún trabajo en esto?

Obtuve el nuevo Docker CE 19.03.0 en una nueva máquina Ubuntu 18.04 LTS, tengo la versión actual y coincidente de NVIDIA Container Toolkit (née nvidia-docker2), pero no puedo usarlo porque docker-compose.yml 3.7 no es compatible con --gpus bandera.

¿Hay una solución para esto?

Esto funciona: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Esto no lo hace: docker run --runtime=nvidia nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Necesitas tener

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

en su /etc/docker/daemon.json por --runtime=nvidia para continuar trabajando. Más info aquí .

ping @KlaasH @ulyssessouza @Goryudyuma @ chris-crone. ¿Algún avance en esto?

Es una necesidad urgente. ¡Gracias por su esfuerzo!

¿Está previsto que el usuario rellene manualmente /etc/docker/daemon.json después de migrar a Docker> = 19.03 y eliminar nvidia-docker2 para usar nvidia-container-toolkit lugar?

Parece que esto rompe muchas instalaciones. Especialmente, dado que --gpus no está disponible en compose .

No, esto es una solución alternativa hasta que compose admita la bandera gpus.

instalar nvidia-docker-runtime:
https://github.com/NVIDIA/nvidia-container-runtime#docker -engine-setup
agregar a /etc/docker/daemon.json
{
"tiempos de ejecución": {
"nvidia": {
"ruta": "/ usr / bin / nvidia-container-runtime",
"runtimeArgs": []
}
}
}

docker-compose:
tiempo de ejecución: nvidia
medio ambiente:
- NVIDIA_VISIBLE_DEVICES = todos

Ya no existe tal cosa como "/ usr / bin / nvidia-container-runtime". El problema sigue siendo crítico.

ayudará a ejecutar el entorno nvidia con docker-compose, hasta que corrija docker-compose

instalar nvidia-docker-runtime:
https://github.com/NVIDIA/nvidia-container-runtime#docker -engine-setup
agregar a /etc/docker/daemon.json
{
"tiempos de ejecución": {
"nvidia": {
"ruta": "/ usr / bin / nvidia-container-runtime",
"runtimeArgs": []
}
}
}

docker-compose:
tiempo de ejecución: nvidia
medio ambiente:

• NVIDIA_VISIBLE_DEVICES = todos

Esto no funciona para mí, todavía obtengo Unsupported config option for services.myservice: 'runtime' cuando intento ejecutar docker-compose up

¿algunas ideas?

Esto no funciona para mí, todavía obtengo Unsupported config option for services.myservice: 'runtime' cuando intento ejecutar docker-compose up

¿algunas ideas?

después de modificar /etc/docker/daemon.json, reinicie el servicio docker
systemctl reiniciar ventana acoplable
use el formato Compose 2.3 y agregue runtime: nvidia a su servicio de GPU. Docker Compose debe ser la versión 1.19.0 o superior.
archivo docker-compose:
versión: '2.3'

servicios:
nvsmi:
imagen: ubuntu: 16.04
tiempo de ejecución: nvidia
medio ambiente:
- NVIDIA_VISIBLE_DEVICES = todos
comando: nvidia-smi

@cheperuiz , puede configurar nvidia como tiempo de ejecución predeterminado en daemon.json y no dependerá de docker-compose. Pero todos los contenedores de la ventana acoplable usarán el tiempo de ejecución de nvidia; no tengo problemas hasta ahora.
{ "default-runtime": "nvidia", "runtimes": { "nvidia": { "path": "/usr/bin/nvidia-container-runtime", "runtimeArgs": [] } }, }

¡Ah! gracias @Kwull , me perdí esa default-runtime parte ... Todo funciona ahora :)

@uderik , runtime ya no está presente en el esquema actual de formato de archivo de composición 3.7, ni en la versión 3.8 pendiente que eventualmente debería alinearse con Docker 19.03: https://github.com/docker/compose/blob/ 5e587d574a94e011b029c2fb491fb0f4bdeef71c / compose / config / config_schema_v3.8.json

@johncolby runtime nunca ha sido una bandera 3.x. Solo está presente en la pista 2.x, (2.3 y 2.4).

Sí, lo sé, y aunque mi archivo docker-compose.yml incluye version: '2.3' (que han funcionado en el pasado), parece que las últimas versiones lo ignoran ...
Para proyectos futuros, ¿cuál sería la forma correcta de habilitar / deshabilitar el acceso a la GPU? ¿Solo lo hace por defecto + variables env? ¿O habrá soporte para la bandera --gpus ?

@johncolby ¿cuál es el reemplazo de runtime en 3.X?

@ Daniel451 Acabo de generic_resources , algo como:

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

(de https://github.com/docker/cli/blob/9a39a1/cli/compose/loader/full-example.yml#L71-L74)
Diseñe el documento aquí: https://github.com/docker/swarmkit/blob/master/design/generic_resources.md

Aquí está el problema de redacción con respecto al soporte de esquema de redacción 3.8, que ya está combinado en: https://github.com/docker/compose/issues/6530

En el lado del demonio, la capacidad gpu puede registrarse incluyéndola en la CLI daemon.json o dockerd (como la solución temporal anterior codificada en tiempo de ejecución), algo como

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

que luego se registra al conectarse a la utilidad docker de NVIDIA:
https://github.com/moby/moby/blob/09d0f9/daemon/nvidia_linux.go

Parece que la maquinaria está básicamente en su lugar, probablemente solo necesita documentarse ...

¿Cualquier actualización?

También esperando actualizaciones, usando bash con docker run --gpus hasta la solución oficial ...

Esperando actualizaciones asw ell.

También esperando actualizaciones :)

Ok ... no entiendo por qué esto sigue abierto. Estas 3 líneas adicionales hacen que funcione con la versión 3.7 del esquema. Me alegra saber que Docker responde a problemas triviales de la comunidad. Así que clone este repositorio, agregue estas tres líneas y python3 setup.py compile && instálelo, y asegúrese de que su docker-compose.yml sea la versión 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'),

Acabo de agregar un problema interno para rastrear eso.
Recuerde que los RP son bienvenidos: smiley:

Ok ... no entiendo por qué esto sigue abierto. Estas 3 líneas adicionales hacen que funcione con la versión 3.7 del esquema. Me alegra saber que Docker responde a problemas triviales de la comunidad. Así que clone este repositorio, agregue estas tres líneas y python3 setup.py compile && instálelo, y asegúrese de que su docker-compose.yml sea la versión 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'),

Probé tu solución pero recibo muchos errores sobre esa bandera:

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'

¿Necesito un paquete python docker específico?

@DarioTurchi Sí, conocí el problema exacto. Parece que el tipo de HostConfig también debe actualizarse.

No creo que el cambio descrito por @ruckc sea ​​suficiente, porque docker-py también necesitará un cambio. Y parece que todavía se está trabajando en el cambio necesario de docker-py. Mira aquí:
https://github.com/docker/docker-py/pull/2419

Aquí está la rama con los cambios:
https://github.com/sigurdkb/docker-py/tree/gpus_parameter

Entonces, si desea parchear esto ahora, tendrá que compilar docker-compose contra un docker-py modificado de https://github.com/sigurdkb/docker-py/tree/gpus_parameter

No entiendo lo que está pasando aquí:

1) Tengo en /etc/docker/daemon.json

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

pero runtime key ya no se puede usar en v3.x como para https://github.com/docker/compose/issues/6239

También he probado:

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

Así que ya no puedo iniciar mis contenedores con soporte de gpu en 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

Antes de esos cambios funcionaba, entonces, ¿qué puedo hacer ahora?

+1 ¡será muy útil tener dicha función en docker-compose!

¿Alguna eta?

rastreado internamente como https://docker.atlassian.net/browse/COMPOSE-82

+1 sería una función útil para docker-compose

Esta característica sería una excelente adición a docker-compose

En este momento, mi solución para esto es usar la versión 2.3 del archivo docker-compose, que admite el tiempo de ejecución, e instalar manualmente nvidia-container-runtime (ya que ya no está instalado con nvidia-docker).
También estoy configurando las configuraciones de tiempo de ejecución en /etc/docker/daemon.json (no como predeterminado, solo como un tiempo de ejecución disponible).
Con esto puedo usar un archivo de redacción como tal:

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

En este momento, mi solución para esto es usar la versión 2.3 del archivo docker-compose, que admite el tiempo de ejecución, e instalar manualmente nvidia-container-runtime (ya que ya no está instalado con nvidia-docker).
También estoy configurando las configuraciones de tiempo de ejecución en /etc/docker/daemon.json (no como predeterminado, solo como un tiempo de ejecución disponible).
Con esto puedo usar un archivo de redacción como tal:

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

@arruda ¿Te importaría compartir tu daemon.json por favor?

En este momento, mi solución para esto es usar la versión 2.3 del archivo docker-compose, que admite el tiempo de ejecución, e instalar manualmente nvidia-container-runtime (ya que ya no está instalado con nvidia-docker).
También estoy configurando las configuraciones de tiempo de ejecución en /etc/docker/daemon.json (no como predeterminado, solo como un tiempo de ejecución disponible).
Con esto puedo usar un archivo de redacción como tal:

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

@arruda ¿Te importaría compartir tu daemon.json por favor?

Sí, no hay problema, aquí está:

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

Hola

Tengo una aplicación que requiere controladores NVIDIA. He construido una imagen de Docker basada en (DESDE)
nvidia / cudagl: 10.1-tiempo de ejecución-ubuntu18.04

Usando el enfoque recomendado anteriormente, ¿significa que mi imagen no necesita derivarse de nvidia / cudagl: 10.1-runtime-ubuntu18.04 ? Es decir, simplemente podría derivar de (FROM) python: 3.7.3-stretch
y agregar tiempo de ejecución: nvidia al servicio en docker-compose?

Gracias

@rfsch No, eso es algo diferente. runtime: nvidia en docker-compose se refiere al tiempo de ejecución de Docker. Esto hace que la GPU esté disponible para el contenedor. Pero aún necesita alguna forma de usarlos una vez que estén disponibles. runtime in nvidia/cudagl:10.1-runtime-ubuntu18.04 refiere a los componentes de tiempo de ejecución de CUDA. Esto le permite usar las GPU (disponibles en un contenedor por Docker) usando CUDA.

En esta imagen:

runtime: nvidia reemplaza la parte runc / containerd. nvidia/cudagl:10.1-runtime-ubuntu18.04 está completamente fuera de la imagen .

necesitamos esta característica

@ Daniel451 Acabo de generic_resources , algo como:

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

(de https://github.com/docker/cli/blob/9a39a1/cli/compose/loader/full-example.yml#L71-L74)
Diseñe el documento aquí: https://github.com/docker/swarmkit/blob/master/design/generic_resources.md

Aquí está el problema de redacción con respecto al soporte de esquema de redacción 3.8, que ya está combinado en: # 6530

En el lado del demonio, la capacidad gpu puede registrarse incluyéndola en la CLI daemon.json o dockerd (como la solución temporal anterior codificada en tiempo de ejecución), algo como

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

que luego se registra al conectarse a la utilidad docker de NVIDIA:
https://github.com/moby/moby/blob/09d0f9/daemon/nvidia_linux.go

Parece que la maquinaria está básicamente en su lugar, probablemente solo necesita documentarse ...

Hola, @johncolby , intenté esto, pero fallé:

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)

¿alguna sugerencia?

Gracias
David

Instalando nvidia-container-runtime 3.1.4.1 desde https://github.com/NVIDIA/nvidia-container-runtime y poniendo

runtime: nvidia

funciona bien aquí con docker-compose 1.23.1 y 1.24.1 instalados desde https://docs.docker.com/compose/install/ usando este comando de aspecto poco fiable:

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

y, por ejemplo, el contenedor nvidia / cudagl / 10.1-base de dockerhub. He probado el renderizado cuda y OpenGL y todo está cerca del rendimiento nativo.

Seguimiento interno como COMPOSE-82
Tenga en cuenta que dicho cambio también debe implementarse en docker stack (https://github.com/docker/cli/blob/master/cli/compose/types/types.go#L156) para mantener la coherencia

Instalando nvidia-container-runtime 3.1.4.1 desde https://github.com/NVIDIA/nvidia-container-runtime y poniendo

runtime: nvidia

funciona bien aquí con docker-compose 1.23.1 y 1.24.1 instalados desde https://docs.docker.com/compose/install/ usando este comando de aspecto poco fiable:

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

y, por ejemplo, el contenedor nvidia / cudagl / 10.1-base de dockerhub. He probado el renderizado cuda y OpenGL y todo está cerca del rendimiento nativo.

¿puedes compartir tu docker-compose.yml?

oye, @ jdr-face,

aquí está mi prueba siguiendo su sugerencia, instalando nvidia-container-runtime en la máquina host.

version: '3.0'

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

todavía da el error:

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

@ david-gwa como señaló andyneff anteriormente :

runtime nunca ha sido una bandera 3.x. Solo está presente en la pista 2.x, (2.3 y 2.4).

@ david-gwa

¿puedes compartir tu 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

Dependiendo de sus necesidades, algunas de esas opciones pueden ser innecesarias. Como predijo @muru , el truco consiste en especificar una versión antigua. Al menos para mi caso de uso, esto no es un problema, pero solo ofrezco esta configuración como una solución alternativa, realmente debería ser posible con la última versión.

gracias chicos, @ jdr-face, @muru , compose v2 funciona,
Entendí mal que su solución es para v3 compose.

Para el registro, tradicionalmente hablando: compose v2 no es más antiguo que compose v3. Son casos de uso diferentes. v3 está orientado al enjambre, mientras que v2 no. v1 es antiguo.

¿Hay alguna discusión sobre la compatibilidad de Docker-compose para la compatibilidad con GPU nativa de Docker?

Admitir la opción runtime no es la solución para la compatibilidad con GPU en el futuro. NVIDIA describe el futuro de nvidia-docker2 en https://github.com/NVIDIA/nvidia-docker de la siguiente manera.

Tenga en cuenta que con el lanzamiento de Docker 19.03, el uso de paquetes nvidia-docker2 está en desuso ya que las GPU NVIDIA ahora son compatibles de forma nativa como dispositivos en el tiempo de ejecución de Docker.

Actualmente, la compatibilidad con GPU se puede realizar cambiando el tiempo de ejecución, pero es muy posible que esto no funcione en el futuro.

Para ser franco, esta tal vez no sea la mejor práctica, pero de alguna manera lo hacemos funcionar.

La parte complicada es que tenemos que seguir con docker-compose v3.x ya que usamos docker swarm, mientras tanto queremos usar Nvidia Runtime para admitir GPU / CUDA en los contenedores.

Para evitar decirle explícitamente el tiempo de ejecución de Nvidia dentro del archivo docker-compose, configuramos Nvidia como el tiempo de ejecución predeterminado en /etc/docker/daemon.json , y se verá así

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

De modo que todos los contenedores que se ejecutan en las máquinas GPU habilitarán por defecto el tiempo de ejecución de Nvidia.

Espero que esto pueda ayudar a alguien que se enfrenta a un bloqueador similar

Para ser franco, esta tal vez no sea la mejor práctica, pero de alguna manera lo hacemos funcionar.

La parte complicada es que tenemos que seguir con docker-compose v3.x ya que usamos docker swarm, mientras tanto queremos usar Nvidia Runtime para admitir GPU / CUDA en los contenedores.

Para evitar decirle explícitamente el tiempo de ejecución de Nvidia dentro del archivo docker-compose, configuramos Nvidia como el tiempo de ejecución predeterminado en /etc/docker/daemon.json , y se verá así

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

De modo que todos los contenedores que se ejecutan en las máquinas GPU habilitarán por defecto el tiempo de ejecución de Nvidia.

Espero que esto pueda ayudar a alguien que se enfrenta a un bloqueador similar

De hecho, esto es lo que también hacemos. Funciona por ahora, pero me parece un poco raro. Esperamos contar con el soporte completo de compose-v3 pronto. :)

¿Está previsto que el usuario rellene manualmente /etc/docker/daemon.json después de migrar a Docker> = 19.03 y eliminar nvidia-docker2 para usar nvidia-container-toolkit lugar?

Parece que esto rompe muchas instalaciones. Especialmente, dado que --gpus no está disponible en compose .

--gpus no está disponible en redactar
No puedo usar pycharm para vincular docker para ejecutar tensorflow-gpu

¿Alguna actualización sobre este tema? ¿Existe la posibilidad de que --gpus sea compatible con docker-compose pronto?

Para aquellos de ustedes que buscan una solución, esto es lo que terminamos haciendo:

• Instale docker-py desde este PR: https://github.com/docker/docker-py/pull/2471
• Instale docker-compose desde este PR: https://github.com/docker/compose/pull/7124

Y luego ejecute COMPOSE_API_VERSION=auto docker-compose run gpu con el siguiente archivo:

version: '3.7'

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

En Docker 19.03.0 Beta 2, se introdujo el soporte para NVIDIA GPU en forma de la nueva CLI API --gpus. docker / cli # 1714 hablan sobre esta habilitación.

Ahora uno puede simplemente pasar la opción --gpus para la aplicación basada en Docker acelerada por 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                                                 |
+-----------------------------------------------------------------------------+
:~$ 

A partir de hoy, Compose no admite esto. Esta es una solicitud de función para permitir que Compose sea compatible con la GPU NVIDIA.

He resuelto estos problemas, puede intentarlo de la siguiente manera, mi dirección de blog csdn: https://blog.csdn.net/u010420283/article/details/104055046

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

luego, en este archivo daemon.json, agregue este contenido:

{
"tiempo de ejecución predeterminado": "nvidia"
"tiempos de ejecución": {
"nvidia": {
"ruta": "/ usr / bin / nvidia-container-runtime",
"runtimeArgs": []
}
}
}

~ $ sudo systemctl daemon-reload
~ $ sudo systemctl restart docker

Para los usuarios de ansible que desean configurar la solución alternativa descrita anteriormente, existe un rol para instalar nvidia-container-runtime y configurar /etc/docker/deamon.json para usar runtime: nvidia :

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

(por alguna razón, solo se ejecuta en Ubuntu y RHEL, pero es bastante fácil de modificar. Lo ejecuto en Debian)

Luego, en su docker-compose.yml :

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

¿Alguna actualización de la versión oficial 3.x con soporte de gpu? Necesitamos un enjambre :)

¿Hay algún plan para agregar esta función?

Esta característica depende de que docker-py implemente los parámetros device_requests , que es a lo que se traduce --gpus . Ha habido varias solicitudes de extracción para agregar esta función (https://github.com/docker/docker-py/pull/2419, https://github.com/docker/docker-py/pull/2465, https: / /github.com/docker/docker-py/pull/2471) pero no hay reacciones de ningún mantenedor. # 7124 usa https://github.com/docker/docker-py/pull/2471 para proporcionarlo en Redactar, pero aún no hay respuesta de nadie.

Como mencioné en el n. ° 7124, estoy más que feliz de hacer que las relaciones públicas sean más compatibles, pero como ha recibido muy poca atención, no quiero perder el tiempo en algo que no se fusionará ...

Por favor, agregue esta función, ¡será increíble!

¡Por favor, agregue esta función! Estaba más que feliz con el antiguo nevidia-docker2, que me permitió cambiar el tiempo de ejecución en el daemon.json. Sería muy bueno tener esto de vuelta.

Lo necesito, por favor. Realmente lo necesito: /

Me gustaría apilarme también ... ¡necesitamos esta función!

Necesito ejecutar contenedores de CPU y GPU en la misma máquina para que el truco de tiempo de ejecución predeterminado no funcione para mí. ¿Tenemos alguna idea de cuándo funcionará esto en la composición? Dado que no tenemos el indicador de tiempo de ejecución en componer, esto representa una regresión de funcionalidad seria, ¿no es así? Tengo que escribir guiones para que esto funcione, ¡qué asco!

Necesito ejecutar contenedores de CPU y GPU en la misma máquina para que el truco de tiempo de ejecución predeterminado no funcione para mí. ¿Tenemos alguna idea de cuándo funcionará esto en la composición? Dado que no tenemos el indicador de tiempo de ejecución en componer, esto representa una regresión de funcionalidad seria, ¿no es así? Tengo que escribir guiones para que esto funcione, ¡qué asco!

puede hacerlo mediante docker cli (docker run --gpu ....), tengo este tipo de truco (al agregar un proxy, para poder comunicarme con otros contenedores que se ejecutan en otros nodos en swarm). Todos estamos esperando la posibilidad de ejecutarlo en swarm, porque no funciona con el comando de servicio de Docker (como yo sé) ni con componer.

@dottgonzo . Bueno, sí ;-). Soy consciente de esto y de ahí la referencia a los scripts. Pero esta es una forma bastante horrible y no portátil de hacerlo, así que me gustaría hacerlo de una manera más dinámica. Como dije, creo que esto representa una regresión, no una pregunta de características.

COMPOSE_API_VERSION=auto docker-compose run gpu

@ggregoire ¿ Dónde ejecutamos: COMPOSE_API_VERSION = auto docker-compose run gpu?

@joehoeller de su shell lo haría para cualquier otro comando.

En este momento estamos decidiendo para cada proyecto si necesitamos funciones 3.x o si podemos usar docker-compose 2.x donde la opción GPU todavía es compatible. Lamentablemente, funciones como ejecutar objetivos de varias etapas desde un Dockerfile no se pueden usar si se necesita una GPU. ¡Vuelva a agregar esto!

Me gustaría recomendar algo como un campo de "opciones adicionales" para docker-compose donde podemos simplemente agregar indicadores como --gpus=all al comando docker start / run, que aún no son compatibles con docker-compose pero están en la última versión de Docker. De esta manera, los usuarios de redacción no tendrán que esperar a que docker-compose se pongan al día si necesitan una nueva función de la ventana acoplable aún no compatible.

Todavía es necesario ejecutar esto en Docker Swarm para entornos de producción. ¿Será útil para Docker Swarm?

@sebastianfelipe Es muy útil si desea implementar en su enjambre usando componer.
Comparar:
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\"

a algo como esto

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

@sebastianfelipe Es muy útil si desea implementar en su enjambre usando componer.
Comparar:
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\"

a algo como esto

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

Lo siento, ¿ya está funcionando con Docker Swarm usando el archivo yaml docker-compose? Solo para estar seguro: O. ¡Gracias!

solo para docker compose 2.x

El objetivo de este problema es solicitar soporte de gpu de nvidia-docker para docker-compose 3+

¡Ha pasado casi un año desde la solicitud original! ¿Por qué el retraso? ¿Podemos hacer avanzar esto?

ping @KlaasH @ulyssessouza @Goryudyuma @ chris-crone. ¿Algún avance en esto?

Para aquellos de ustedes que buscan una solución, esto es lo que terminamos haciendo:

• Instale docker-py desde este PR: docker / docker-py # 2471
• Instale docker-compose desde este PR: # 7124

Y luego ejecute COMPOSE_API_VERSION=auto docker-compose run gpu con el siguiente archivo:

version: '3.7'

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

Para aquellos de ustedes que están tan impacientes como yo, aquí hay una versión fácil pip install de la solución anterior:

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

¡Enormes felicitaciones a @yoanisgil !
Todavía esperando ansiosamente un parche oficial. Con todos los RP en su lugar, no parece difícil según ningún estándar.

ping @KlaasH @ulyssessouza @Goryudyuma @ chris-crone. ¿Algún avance en esto?

No, no sé por qué me llamaron.
Quiero que me digas que hacer

Espero que haya una actualización sobre esto.

Sí, ha pasado más de un año ... ¿por qué no se fusionan en docker-py ...

No estoy seguro de que las implementaciones propuestas sean las adecuadas para el formato Compose. La buena noticia es que hemos abierto la especificación del formato Compose con la intención de agregar cosas como esta. Puede encontrar la especificación en https://github.com/compose-spec.

Lo que sugiero que hagamos es agregar un problema en la especificación y luego discutirlo en una de las próximas reuniones de la comunidad de Redactar (enlace para invitar en la parte inferior de esta página ).

Esto funciona: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi
Esto no lo hace: docker run --runtime=nvidia nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Necesitas tener

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

en su /etc/docker/daemon.json por --runtime=nvidia para continuar trabajando. Más info aquí .

Dockerd no comienza con este daemon.json

Dios, esto va a llevar años: @

Esto funciona: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi
@deniswal : Sí, lo sabemos, pero estamos preguntando sobre la funcionalidad de

@ chris-crone: Estoy confundido: esto representa una regresión del comportamiento anterior, ¿por qué necesita una nueva especificación de características? ¿No es razonable ejecutar contenedores, algunos de los cuales usan GPU y otros usan CPU en la misma caja física?

Gracias por la consideración.

@ vk1z AFAIK Docker Compose nunca ha tenido compatibilidad con GPU, por lo que esto no es una regresión. La parte que necesita diseño es cómo declarar la necesidad de un servicio de una GPU (u otro dispositivo) en el formato Compose, específicamente cambios como este . Después de eso, debería estar conectado al backend.

Hola chicos, probé algunas soluciones propuestas aquí y nada me funcionó, por ejemplo @miriaford no funcionó en mi caso, ¿también hay alguna forma de usar GPU para ejecutar mis contenedores Docker existentes?
Tengo un i7 con 16 GB de RAM, pero la compilación de algunos proyectos tarda demasiado en completarse, mi objetivo es también utilizar la potencia de la GPU para acelerar el proceso, ¿es posible? ¡Gracias!

@ chris-crone: Nuevamente, estaré dispuesto a que me corrijan, pero ¿no fue eso porque el parámetro runtime: desapareció de compose después de la configuración 2.4? Por eso sentí que era una regresión. Pero no, importa ahora ya que todos deberíamos estar en 3.x de todos modos.

Me encantaría presentar un problema, ¿lo hacemos de acuerdo con las especificaciones en el repositorio de especificaciones, correcto?

pero ¿no fue eso porque el parámetro runtime: desapareció de compose después de la configuración 2.4? Por eso sentí que era una regresión.

Sí exactamente. Tengo un par de proyectos en los que confiamos en el uso de runtime: nvidia en nuestros archivos docker-compose, y este problema nos impide actualizar a 3.x porque no hemos encontrado una manera de usar las GPU allí.

Hola, por favor, arregle esto.
Esto debe marcarse como prioridad de misión crítica -20

Nuevamente, estaré dispuesto a que me corrijan, pero ¿no fue porque el parámetro runtime: desapareció de compose después de la configuración 2.4? Por eso sentí que era una regresión. Pero no, importa ahora ya que todos deberíamos estar en 3.x de todos modos.

No estaba aquí cuando se hizo el cambio, así que no estoy 100% seguro de por qué se abandonó. Sé que ya no necesita el tiempo de ejecución de NVIDIA para usar GPU y que estamos desarrollando la especificación Compose v3 al aire libre aquí con la intención de hacer una versión única de la especificación. Esto puede significar mover algunas funciones v2 a v3.

En términos del campo runtime , no creo que sea así como debería agregarse a la especificación Compose, ya que es muy específico para ejecutarse en un solo nodo. Idealmente, querríamos algo que le permitiera especificar que su carga de trabajo tiene una necesidad de dispositivo (por ejemplo: GPU, TPU, lo que sea que venga a continuación) y luego dejar que el orquestador asigne la carga de trabajo a un nodo que brinde esa capacidad.

Sin embargo, esta discusión debe realizarse sobre la especificación ya que no es específica de Python Docker Compose.

@ chris-crone: Estoy mayormente de acuerdo con su declaración. Agregar hacks a corto plazo es probablemente la forma incorrecta de hacer esto, ya que tenemos una proliferación de dispositivos de borde, cada uno con sus propios tiempos de ejecución. Por ejemplo, como señala, TPU (Google), VPU (Intel) y ARM GPU en la Pi. Entonces necesitamos una historia más completa.

Presentaré un problema contra la especificación hoy y actualizaré este hilo una vez que lo haya hecho. Sin embargo, creo que el orquestador debería ser independiente, por ejemplo, si quiero usar Kube, debería poder hacerlo. Supongo que estará dentro del alcance.

Sin embargo, no estoy de acuerdo con la declaración de uso de GPU, ya que eso no funciona con componer, que es de lo que se trata. Pero creo que todos entendemos qué problema nos gustaría resolver.

@ chris-crone: consulte el problema de especificaciones de docker-compose archivado. Seguiré las actualizaciones sobre ese problema a partir de ahora.

¿Podemos simplemente agregar una opción (algo así como extra_docker_run_args ) para pasar argumentos directamente al docker run subyacente? Esto no solo resolverá el problema actual, sino que también estará preparado para el futuro: ¿qué pasa si Docker agrega soporte para cualquier "XPU", ​​"YPU" o cualquier otra característica nueva que pueda aparecer en el futuro?

Si necesitamos una larga discusión de ida y vuelta cada vez que Docker agrega una nueva característica, será extremadamente ineficiente y causará un retraso inevitable (y confusión innecesaria) entre las actualizaciones docker-compose y docker . La delegación de argumentos de apoyo puede proporcionar un alivio temporal para este problema recurrente para todas las funciones futuras.

@miriaford No estoy seguro de que pasar un blob sin interpretar respalde la noción de

Pero estoy de acuerdo en que la composición y la ventana acoplable deberían estar sincronizadas y la función de zapping de las funciones de trabajo de las que depende la gente (aunque fue una versión importante) no es del todo kosher.

@ vk1z Estoy de acuerdo, debería haber un mecanismo de sincronización mucho mejor entre compose y docker . Sin embargo, no espero que dicho mecanismo se diseñe pronto. Mientras tanto, también necesitamos una forma temporal de hacer nuestra propia sincronización sin hackear profundamente el código fuente.

Si la propuesta de delegación de argumentos no es una opción, ¿qué sugerimos que hagamos? Estoy de acuerdo en que no es una solución bonita, pero es al menos _mucho_ mejor que esta solución alternativa, ¿no es así? https://github.com/docker/compose/issues/6691#issuecomment -616984053

@miriaford docker-compose no llama al ejecutivo de la ventana acoplable con un argumento, en realidad usa docker_py, que usa la API http para el demonio de la ventana acoplable. Por lo tanto, no hay un comando "subyacente docker run ". La CLI de la ventana acoplable no es una API, la conexión de socket es el punto de contacto de la API. Por eso no siempre es tan fácil.

Para simplificar demasiado las cosas, en el proceso de ejecutar una ventana acoplable, hay dos llamadas principales, una que crea el contenedor y otra que lo inicia, cada una ingiere diferentes piezas de información, y saber cuál es mientras se necesita a alguien que tenga conocimientos de API, cuál No sé como yo tendemos a conocer el docker CLI. No creo que poder agregar argumentos adicionales a las llamadas de docker_py sea tan útil como cree, excepto en casos de uso seleccionados.

Para hacer las cosas aún más difíciles, a veces la biblioteca docker_py está detrás de la API y tampoco tiene todo lo que necesita de inmediato, y debe esperar a que se actualice. Dicho todo esto, extra_docker_run_args no es una solución simple.

@andyneff Gracias por tu explicación. De hecho, no estoy muy familiarizado con el funcionamiento interno de Docker. Si lo comprendo correctamente, hay 4 API que deben sincronizarse manualmente para cualquier actualización de nuevas funciones:

1. API de socket de Docker
2. docker_py que proporciona una interfaz de Python a la API de socket
3. Docker CLI (nuestro punto de entrada familiar a la cadena de herramientas de Docker)
4. Interfaz de Docker-compose que llama a la API de Docker Socket

Esto plantea la pregunta: ¿por qué no existe un mecanismo de sincronización automático (o al menos semiautomático)? La propagación manual de nuevas actualizaciones de funciones a través de 4 API parece condenada a ser propensa a errores, propensa a retrasos y confusa ...

PD: No digo que sea una tarea _simple_ tener sincronización automática, pero realmente creo que debería haber una para hacer la vida más fácil en el futuro.

Me estoy metiendo un poco en la pedantería ahora ... Pero como lo describiría como ...

• El conector de la ventana acoplable es la API oficial de la ventana acoplable. A menudo es un socket de archivo, pero también puede ser TCP (o cualquier otro, imagino usando socat )
• La docker CLI usa esa API para brindarnos a los usuarios una herramienta increíble
  
  
  
  • Docker escribe la API y la CLI, por lo que siempre se sincronizan en el momento del lanzamiento. (Creo que es seguro decirlo, CLI es un ciudadano de primera clase del ecosistema de Docker)
  
  
• La biblioteca docker_py toma esa API y la coloca en una biblioteca increíble que pueden usar otras bibliotecas de Python. Sin esto, usted mismo estaría haciendo todas estas llamadas HTTP y tirando de su cabello.
  
  
  
  • Sin embargo, docker_py se inició como una biblioteca de terceros y, por lo tanto, tradicionalmente ha seguido la API de la ventana acoplable y se han agregado cosas más tarde o según sea necesario (recursos limitados).
  
  
• compose usa una versión de docker_py y luego agrega todas estas características increíbles, nuevamente según sea necesario (en función de problemas como este)
  
  
  
  • Sin embargo, componer no puede hacer mucho hasta docker_py (lo que no digo que esté retrasando este problema, no lo sé, solo estoy hablando en general)
  
  

Entonces sí, dice:

• "componer yaml + componer argumentos" -> "docker_py" -> "docker_api"
• Y la CLI no es parte de esto (y créeme, esa es la forma correcta de hacer las cosas)

No puedo hablar por docker_py o compose, pero imagino que tienen horas de trabajo limitadas contribuyendo a ello, por lo que es más difícil mantenerse al día con TODAS las locas características de docker que Docker agrega CONSTANTEMENTE. Pero dado que Docker es una biblioteca go, y tengo entendido que el soporte de Python no es (actualmente) un ciudadano de primera clase. Aunque es bueno que ambos proyectos estén bajo el paraguas de Docker, al menos desde el punto de vista de la organización github.

Dicho todo esto ... yo también estoy esperando un --gpus soporte runtime: nvidia lugar, que al menos me dará "una" ruta para moverme adelante en docker-compose 2.x.

@andyneff FYI, hay compatibilidad con Docker CLI en la última versión de docker-compose. Permite usar buildkit por ejemplo. https://www.docker.com/blog/faster-builds-in-compose-thanks-to-buildkit-support/

@andyneff ¡ esta es una descripción general muy útil! Gracias de nuevo

@lig impresionante! ¡Gracias por la corrección! De hecho, estaba pensando "¿Cómo encajará el kit de construcción en todo esto?" Mientras escribía eso.

Lo que me sorprende un poco es que docker-compose es una parte bastante intrínseca del nuevo marco de la aplicación docker y me imagino que querrían sincronizar docker-compose y docker por al menos esa razón. Me pregunto cuál es realmente el bloqueador: ¿No hay suficiente ancho de banda de Python? Parece un poco increíble.

Entonces, ¿cómo encaja Docker Swarm en la estructura que @andyneff acaba de describir? Swarm utiliza la versión 3 del formato de archivo de redacción (¿definido por el proyecto "componer"?) Pero se desarrolla como parte de docker ?

Disculpas si eso está fuera de tema para este problema en particular. He perdido la noción de qué problema es cuál, pero comencé a seguir esto porque me gustaría poder decirle a un servicio que se ejecuta en un enjambre que necesita usar un tiempo de ejecución particular. Solo podemos hacer eso con v2 de la especificación de archivo de composición, lo que significa que no podemos hacerlo con Swarm, que requiere v3. En otras palabras, no estoy realmente interesado en lo que hace la CLI de docker-compose, sino solo en la especificación definida para los archivos docker-compose.yml que consume el enjambre de docker.

Oh enjambre, el que se escapó ... (de mí). Desafortunadamente, ese es el # 6239 que fue cerrado por un BOT. :( Alguien intentó en el # 6240 pero le dijeron que ...

@miriaford , ¡parece que hay un PR para sincronizarlos! # 6642 ?! (¿Esto es solo para v3 ???)

Entonces, debido a la naturaleza del enjambre, hay ciertas cosas que haces y no haces en los nodos del enjambre. Por lo tanto, la API de Docker no siempre le permite hacer las mismas opciones en una ejecución de enjambre, como una ejecución normal. No sé si el tiempo de ejecución es una de estas cosas, pero a menudo es por eso que no puede hacer cosas en v3 (la versión compatible con swarm) y sí en v2 (la versión no compatible con swarm).

Nadie que lea esto sabe de lo que están hablando.
Todos intentamos implementar jellyfin con aceleración de hardware.
Hasta que arreglen esto de nuevo a la forma en que se supone que es, cuando dice servicio, 3.x no es bueno.
No lo use.

Necesita poner 2.4 para el servicio.
Entonces puedes usar la aceleración de hardware para jellyfin, ez

Así que vamos chicos, ¿cuál es la ETA en esto, 1 año, 2 años?

@KlaasH @ulyssessouza @Goryudyuma @ chris-crone Hola, estoy trabajando en este problema, encontré que faltaba el soporte en "docker-py", he trabajado en esa parte. Ahora, para que funcione, necesito pasar las configuraciones a través del archivo docker-compose.yml. ¿Puedes ayudarme con el esquema? es decir, para agregarlo, debo agregarlo a un nuevo esquema o hay algún lugar donde se puedan pasar las configuraciones

@fakabbir Asumiría que está bien usar COMPOSE_DOCKER_CLI_BUILD para esto. Agregar la capacidad de proporcionar una lista arbitraria de docker run argumentos podría incluso ayudar a evitar problemas similares en el futuro.

@lig ¿cómo se

@lig AFAICS compose usa docker-py lugar de docker run cli. Por lo tanto, agregar argumentos docker run arbitrarios no funcionaría a menos que docker-py admita.

ref: https://github.com/docker/compose/issues/6691#issuecomment -585199425

Esta sola cosa reduce enormemente la utilidad de docker-compose para muchas personas. Que no haya recibido mucha atención y deseo de arreglarlo, especialmente cuando funcionó en una ventana acoplable más antigua, es bastante sorprendente.
¿No sería una forma de hacerlo permitir que se proporcionen argumentos arbitrarios de docker --run en un archivo de docker-compose? Entonces --gpus all, por ejemplo, podría pasarse a la ventana acoplable.

Entiendo que puede haber razones filosóficas o técnicas por las que uno podría querer hacerlo de una manera particular. Pero no poner manos a la obra y hacerlo de NINGUNA manera hace que la mente se tambalee.

@lig ¿cómo se

Bueno, la variable de entorno NVIDIA_VISIBLE_DEVICES te permitirá controlar eso, ¿no?

Esta sola cosa reduce enormemente la utilidad de docker-compose para muchas personas. Que no haya recibido mucha atención y deseo de arreglarlo, especialmente cuando funcionó en una ventana acoplable más antigua, es bastante sorprendente.
¿No sería una forma de hacerlo permitir que se proporcionen argumentos arbitrarios de docker --run en un archivo de docker-compose? Entonces --gpus all, por ejemplo, podría pasarse a la ventana acoplable.

No creo que permitir pasar docker --run args sea el camino a seguir. compose no llama realmente docker por sí mismo, sino que usa docker-py .

Entiendo que puede haber razones filosóficas o técnicas por las que uno podría querer hacerlo de una manera particular. Pero no poner manos a la obra y hacerlo de NINGUNA manera hace que la mente se tambalee.

Un RP está abierto al respecto: https://github.com/docker/compose/pull/7124. Siéntase libre de "ponerle las manos encima".

Creo que según el cambio en la especificación de composición de la ventana acoplable , deberíamos volver pronto a la compatibilidad anterior según la composición 2.4 y el tiempo de ejecución de nvidia funcionará. Obviamente, no funcionará para TPU u otros aceleradores, lo cual es muy desafortunado, pero para aquellos que quieran ejecutar (costoso) nvidia gpus, funcionará.

Así que esperando un PR verde en docker-py para fusionarse https://github.com/docker/docker-py/pull/2471

¡SI! ¡El RP en docker-py ha sido aprobado! https://github.com/docker/docker-py/pull/2471
¿Cuál es el siguiente paso aquí?

Que pasa aquí ? Sería genial poder admitir el tiempo de ejecución de nvidia en docker-compose

https://github.com/docker/docker-py/pull/2471 se ha fusionado.

Ahora que docker / docker-py # 2471 se ha fusionado, podemos instalar docker-py desde master. Pero dado que el docker-compose ha cambiado desde el genial [PR] de @yoanisgil (https://github.com/docker/compose/pull/7124) (¡Felicitaciones!), Es poco probable que se fusione. Entonces, en este punto, el docker-compose se puede instalar desde ese PR para salvar el día.

Para los que terminaron aquí sin ver los comentarios anteriores:

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

Luego use la siguiente plantilla en su archivo de redacción. (fuente: comentario ):

Y luego ejecute COMPOSE_API_VERSION=auto docker-compose run gpu con el siguiente archivo:

version: '3.7'

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

Confirmo que esto funcionó en mi máquina local. No sé si funciona con Swarm.

No se puede tener un compromiso particular de docker-compose en producción. ¿Es necesario modificar la base del # 7124 o hay otro RP que incorporará el nuevo docker-py ?

Hola @bkakilli ,

¡Gracias por la ayuda! Acabo de probar tu sugerencia, pero aparece un error al ejecutar mi ventana acoplable-compose

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

_análisis es el nombre de mi contenedor_

Cambié mi docker-compose.yml de:

version: '2.3'

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

a:

version: '3.7'

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

¿Hay algo más aparte de pip install git+ para configurar esto correctamente? ¿O quizás edité mal el archivo de configuración?

@frgfm asegúrese de que está instalando compose y docker-py desde los enlaces correctos. Es posible que haya utilizado el propio repositorio de docker-compose en lugar de la bifurcación (y la rama) de yoanisgil. Vea si está utilizando el siguiente enlace:

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

Puede intentar poner --upgrade param en pip install. De lo contrario, sospecharía de la configuración del entorno virtual. ¿Quizás tiene otra instalación de docker-compose, que se está utilizando de forma predeterminada? Por ejemplo, puede haberlo instalado para el sistema con las instrucciones de "Linux" aquí: https://docs.docker.com/compose/install/. Le sugiero que eche un vistazo a las "Opciones de instalación alternativas" e instale a través de pip en el entorno virtual (pero use el comando de instalación de pip anterior. No instale el docker-compose predeterminado de PyPI).

¡Hola!
Gracias por toda la información. Estaba tratando de ejecutar su enfoque @bkakilli y docker-compose build funcionó, pero al ejecutar docker-compose up me salió el error:
docker.errors.InvalidVersion: device_requests param is not supported in API versions < 1.40

Mi docker_compose.yml se ve así:

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

¡Gracias por adelantado!

@ugmSorcero Establece la variable de entorno COMPOSE_API_VERSION=1.40 luego vuelve a ejecutar tus comandos

@ugmSorcero, ¿ @EpicWink @bkakilli Estoy ejecutando la versión indicada en la instalación de pip pero todavía obtengo el error de device_requests param is not supported in API versions < 1.40 incluso si exporto dicha variable a 1.40

Para el archivo de redacción dado

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

Usando la versión de docker-compose instalada como arriba, en Bash en Linux, el siguiente comando funciona correctamente:

COMPOSE_API_VERSION=1.40 docker-compose up

El siguiente comando falla:

docker-compose up

Esto tiene salida de error:

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 muchas gracias. No me di cuenta de que docker-compose up tenía que ejecutarse de esa manera. Lo tomé como un paso de 2 donde primero exporté COMPOSE_API_VERSION separado. Ejecutarlo juntos parece funcionar :)

Sin embargo, tengo otro problema. Si ejecuto COMPOSE_API_VERSION=1.40 docker-compose run nvidiatest entonces nvidia-smi no se encuentra en la ruta, mientras que si ejecuto directamente desde la imagen no hay problema.

Así es como lo estoy reproduciendo.

El archivo local de docker-compose contiene:

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

Si ejecuto mi configuración actual (tanto la versión api automática como la 1.40), aparece el siguiente error:

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

¿Es posible que tenga que ver con el uso de archivos de anulación? Si ejecuto la imagen base de cuda con Docker, no hay problema con obtener resultados 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      |
|=============================================================================|
+-----------------------------------------------------------------------------+

Instalé docker-compose siguiendo las instrucciones anteriores de git después de desinstalar la versión instalada de los documentos oficiales. Aquí está la información de la versión instalada:

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

¿Me estoy perdiendo algo? ¡Gracias por la ayuda!

@jjrugui, esto se está volviendo fuera de tema y no puedo replicar su problema. Perdón por no poder ayudar

@EpicWink no es un problema, y ​​perdón por desviarme del tema :). Si descubro mi problema particular, lo publicaré aquí si es relevante.

¿Alguien está trabajando en otro PR o estamos depurando la rama device-requests para prepararnos para un PR?

Mientras el PR está atascado, porté los cambios de # 7124 a la última versión de la rama master para que coincida con las dependencias, etc. - https://github.com/beehiveai/compose Puede instalar con pip install git+https://github.com/beehiveai/compose.git y cambie la versión en docker-compose.yml a 3.8 :

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

En este entorno, todo funciona como se esperaba.

Como se discutió ayer en la reunión de gobernanza de composición de especificaciones , comenzaremos a trabajar en una propuesta para adoptar algo comparable a # 7124, que podría estar cerca de generic_resouces ya disponible en la sección deploy .

@ndeloof ¡ Eso es genial! Si es posible, publique el enlace a la propuesta aquí. Creo que mucha gente estaría feliz de contribuir a esto, ya que el soporte de GPU es fundamental para las implementaciones de aprendizaje profundo.

@ndeloof históricamente, ¿cuánto tiempo le toma al comité directivo tomar una decisión, 6 meses, un año?

+1

+1

@visheratin ¿ Alguna posibilidad de que pueda mejorar su corrección para que funcione cuando se utilizan varios archivos yml de composición? Tengo un docker-compose.yml base que usa un contenedor que no es nvidia, que quiero anular con el contenedor nvidia cuando hay una GPU, sin embargo, parece que con su solución, si especifico varios archivos compose yml con el "- f ", los campos" device_requests "desaparecen de la configuración.

@proximous ¿Qué quieres decir con "abandona la configuración"? ¿Todos los archivos de redacción tienen la versión 3.8? ¿Puedes compartir el ejemplo para que sea más fácil de reproducir?

Tener un problema con el código en compose / service.py al intentar usar la opción --scale con docker-compose up. ¿Esto no es compatible?

Rastreo (llamadas recientes más última):
Archivo "/ usr / local / bin / docker-compose", línea 11, en
load_entry_point ('docker-compose == 1.27.0.dev0', 'console_scripts', 'docker-compose') ()
Archivo "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", línea 67, en main
mando()
Archivo "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", línea 123, en perform_command
manejador (comando, opciones_comando)
Archivo "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", línea 1067, en
to_attach = up (Falso)
Archivo "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", línea 1063, en up
cli = native_builder,
Archivo "/usr/local/lib/python3.6/site-packages/compose/project.py", línea 648, en up
get_deps,
Archivo "/usr/local/lib/python3.6/site-packages/compose/parallel.py", línea 108, en paralelo_execute
subir error_to_reraise
Archivo "/usr/local/lib/python3.6/site-packages/compose/parallel.py", línea 206, en el productor
resultado = func (obj)
Archivo "/usr/local/lib/python3.6/site-packages/compose/project.py", línea 634, en do
override_options = override_options,
Archivo "/usr/local/lib/python3.6/site-packages/compose/service.py", línea 579, en execute_convergence_plan
renovar_volúmenes_anónimos,
Archivo "/usr/local/lib/python3.6/site-packages/compose/service.py", línea 509, en _execute_convergence_recreate
scale - len (contenedores), detached, start
Archivo "/usr/local/lib/python3.6/site-packages/compose/service.py", línea 479, en _execute_convergence_create
"Creando"
Archivo "/usr/local/lib/python3.6/site-packages/compose/parallel.py", línea 108, en paralelo_execute
subir error_to_reraise
Archivo "/usr/local/lib/python3.6/site-packages/compose/parallel.py", línea 206, en el productor
resultado = func (obj)
Archivo "/usr/local/lib/python3.6/site-packages/compose/service.py", línea 477, en
lambda nombre_servicio: create_and_start (self, service_name.number),
Archivo "/usr/local/lib/python3.6/site-packages/compose/service.py", línea 456, en create_and_start
contenedor = service.create_container (número = n, silencioso = verdadero)
Archivo "/usr/local/lib/python3.6/site-packages/compose/service.py", línea 333, en create_container
contenedor_anterior = contenedor_anterior,
Archivo "/usr/local/lib/python3.6/site-packages/compose/service.py", línea 936, en _get_container_create_options
one_off = one_off)
Archivo "/usr/local/lib/python3.6/site-packages/compose/service.py", línea 1014, en _get_container_host_config
element.split (',') para elemento en device_request ['capacidades']]
Archivo "/usr/local/lib/python3.6/site-packages/compose/service.py", línea 1014, en
element.split (',') para elemento en device_request ['capacidades']]
AttributeError: el objeto 'list' no tiene atributo 'split'

Después de una mayor depuración, descubrí que al usar --scale, por alguna razón, una instancia tiene device_requests ['capacidades'] como ['gpu']. Pero para que se inicien todos los demás contenedores, device_request ['capacidades'] se parece a [['gpu']].

Hice una solución temporal localmente para solucionar este problema solo para que mis contenedores estén en funcionamiento a partir de la línea 1010 en compose / service.py:

''
para device_request en device_requests:
si las 'capacidades' no están en device_request:
Seguir
if type (device_request ['capacidades'] [0]) == lista:
device_request ['capacidades'] = [
element.split ('.') para elemento en device_request ['capacidades'] [0]]
más:
device_request ['capacidades'] = [
element.split ('.') para elemento en device_request ['capacidades']]

`` ``

@proximous ¿Qué quieres decir con "abandona la configuración"? ¿Todos los archivos de redacción tienen la versión 3.8? ¿Puedes compartir el ejemplo para que sea más fácil de reproducir?

@visheratin vea este ejemplo, ¿me equivoco al esperar un resultado diferente?

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

use solo el nogpu.yml:

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

use solo el 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'

Chain config ymls comenzando con un yml que no es de gpu (nota ... falta el tiempo de ejecución):

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

Rendimiento esperado:

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

(Obviamente, estoy intentando algo más elaborado y este es solo un caso simplificado para resaltar el comportamiento inesperado).

@jlaule @proximous Para mantener este hilo en el tema, cree problemas en el repositorio bifurcado, los investigaré cuando tenga tiempo.

Para aquellos que necesitan algo mientras esperan, simplemente configuro K3S (versión de borde de Kubernetes) con soporte de GPU en 30 minutos usando Docker como tiempo de ejecución del contenedor (es decir, use la opción --docker para el script de instalación). Siga https://github.com/NVIDIA/k8s-device-plugin para que funcione el complemento del dispositivo Nvidia.
¡Espero que ayude!

@EpicWink no es un problema, y ​​perdón por desviarme del tema :). Si descubro mi problema particular, lo publicaré aquí si es relevante.

Alguna vez resolviste esto?

Ya no existe tal cosa como "/ usr / bin / nvidia-container-runtime". El problema sigue siendo crítico.

Instale nvidia-docker2 como se indica aquí

He estado abordando esto últimamente y pensé que compartiría mi enfoque.
mi problema era que necesitaba desplegar la pila de Docker y no quería escuchar. docker compose estaba trabajando con el truco de la versión de docker api, pero no se sentía bien y la implementación de la pila no funcionaría independientemente.

así que sin configurar ninguna solicitud de dispositivo de tiempo de ejecución en mi ventana acoplable, agregué esto a mi demonio:

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

También puedes usar GPU- {primera parte de gpu guid}
pero esto fue más fácil. no tuve que instalar ningún pip + ni nada por el estilo, excepto el kit de herramientas del contenedor NV. se despliega y funciona como un encanto.

Tks mucho
Para otros: no olvide reiniciar su demonio de la ventana acoplable.

@pommedeterresautee ah ¡

Tengo que decir que después de 3 semanas de atraque sin parar, estoy bastante desconcertado de que nada parece funcionar.

@haviduck : ¡Gracias! Finalmente una solución simple que simplemente funciona. He pasado tanto tiempo tratando de agregar dispositivos, etc. que me di por vencido. Luego aparece esto, lo intenta y después de un par de minutos tengo la transcodificación de hardware en Plex funcionando.

Agregaré mis 2 centavos a este asunto ... Leí muchas publicaciones y finalmente la solución fue bastante simple.

funcionó para mí con: (tal vez un poco más bajo también hubiera funcionado, ni idea ...)
docker-compose versión 1.27.4, compilación 40524192

1. en la máquina host de Docker, instale los paquetes nvidia-container-toolkit y nvidia-container-runtime
2. en la máquina host de la ventana acoplable: escriba
   nvidia-smi y examine la versión CUDA que aparece a la derecha
   
3. en la máquina host de la ventana acoplable: escriba: (reemplace la versión cuda por la que ha instalado)
   docker ejecutar --rm --gpus todos nvidia / cuda: 10.1-base nvidia-smi
   debería obtener el mismo resultado que obtuvo cuando ejecutó nvidia-smi en la máquina host
4. en el archivo /etc/docker/daemon.json debe ver:
   "runtimes": {"nvidia": {"ruta": "/ usr / bin / nvidia-container-runtime", "runtimeArgs": []}}
5. en su YML de docker-compose debe agregar:
   tiempo de ejecución: nvidia

Eso es !
implemente usando el YML y tendrá soporte de GPU en su docker-compose

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

Vaya, todo este hilo es sobre la versión 3 que no tiene tiempo de ejecución.

Las versiones 1.27.0+ han fusionado los formatos de archivo v2 / v3, por lo que ahora se puede usar runtime cualquier lugar. Además, la especificación para aceleradores también se aterrizó (https://github.com/compose-spec/compose-spec/pull/100) aunque aún no se implementó en docker-compose .

Agregaré mis 2 centavos a este asunto ... Leí muchas publicaciones y finalmente la solución fue bastante simple.

funcionó para mí con: (tal vez un poco más bajo también hubiera funcionado, ni idea ...)
docker-compose versión 1.27.4, compilación 4052419

1. en la máquina host de Docker, instale los paquetes nvidia-container-toolkit y nvidia-container-runtime
2. en la máquina host de la ventana acoplable: escriba
   nvidia-smi y examine la versión CUDA que aparece a la derecha
   
3. en la máquina host de la ventana acoplable: escriba: (reemplace la versión cuda por la que ha instalado)
   docker ejecutar --rm --gpus todos nvidia / cuda: 10.1-base nvidia-smi
   debería obtener el mismo resultado que obtuvo cuando ejecutó nvidia-smi en la máquina host
4. en el archivo /etc/docker/daemon.json debe ver:
   "runtimes": {"nvidia": {"ruta": "/ usr / bin / nvidia-container-runtime", "runtimeArgs": []}}
5. en su YML de docker-compose debe agregar:
   tiempo de ejecución: nvidia

Eso es !
implemente usando el YML y tendrá soporte de GPU en su docker-compose

Para su información, la versión cuda que puede ver en la salida de nvidia-smi refiere a la versión del controlador nvidia cuda, también conocida como su controlador nvidia (también lo llaman cuda, lo cual es confuso). El número de versión en la imagen de la ventana acoplable, por ejemplo, nvidia/cuda:10.1-base nvidia-smi refiere a la versión del kit de herramientas de nvidia (nuevamente, confusamente, el mismo sistema de numeración de versiones, diferentes bestias).

El controlador es compatible con versiones anteriores del kit de herramientas, por lo que puede ejecutar cualquier nvidia/cuda:<version>-base nvidia-smi que desee, siempre que <version> sea ​​menor o igual que la versión del controlador.

Más información aquí: https://stackoverflow.com/questions/53422407/different-cuda-versions-shown-by-nvcc-and-nvidia-smi

No veo los binarios de Docker Compose 1.27.4 disponibles para el sistema basado en 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)

¡Hola @collabnix!

¿Cuál es la salida de pip --version ?

Compose 1.27 dejó de ser compatible con Python 2, por lo que es posible que no vea las versiones 1.27.x si su sistema tiene Python 2.

@collabnix, eso es porque ya ha instalado compose, intente pip install --upgrade docker-compose

Ahora puedo actualizar a 1.27.4. La actualización de pip funcionó. Gracias @kshcherban y @ chris-crone
Es una locura ver que la mayoría de los proyectos en los que trabajé en el pasado y que usan Python 2.7 realmente necesitan una actualización.

La actualización de docker-compose a 1.27.4 resolvió el problema.
(se puede actualizar a 1.19.3 más tarde para resolver el problema)

$ 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
funciona bien con docker-compose.
en la computadora host, verifique la gpu utilizada por nvidia-smi.

@ bttung-2020
@PyCod
Si uso dokcer-nvidia-devel (no en tiempo de ejecución): nvidia / cuda: 10.1-cudnn7-devel-ubuntu18.04 en docker-hub
¿Funciona? ¿Cómo debo editar el archivo docker-compose.yaml?