Compose: Suporte para GPUs NVIDIA no Docker Compose

Isso é cada vez mais importante agora que o (agora) legado 'nvidia runtime' parece quebrado com o Docker 19.03.0 e 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

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

Isso não: docker run --runtime=nvidia nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Qualquer trabalho acontecendo nisso?

Eu tenho o novo Docker CE 19.03.0 em uma nova máquina Ubuntu 18.04 LTS, tenho a versão atual e correspondente do NVIDIA Container Toolkit (née nvidia-docker2), mas não posso usá-lo porque docker-compose.yml 3.7 não suporta o --gpus Bandeira

Existe uma solução alternativa para isso?

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

Isso não: docker run --runtime=nvidia nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Você precisa ter

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

em seu /etc/docker/daemon.json para --runtime=nvidia para continuar trabalhando. Mais informações aqui .

ping @KlaasH @ulyssessouza @Goryudyuma @ chris-crone. alguma atualização disso?

É uma necessidade urgente. Obrigado pelo seu esforço!

Pretende-se que o usuário preencha manualmente /etc/docker/daemon.json após migrar para docker> = 19.03 e remover nvidia-docker2 para usar nvidia-container-toolkit lugar?

Parece que isso quebra muitas instalações. Especialmente porque --gpus não está disponível em compose .

Não, esta é uma solução alternativa para até que o compose suporte o sinalizador gpus.

instale nvidia-docker-runtime:
https://github.com/NVIDIA/nvidia-container-runtime#docker -engine-setup
adicione a /etc/docker/daemon.json
{
"tempos de execução": {
"nvidia": {
"path": "/ usr / bin / nvidia-container-runtime",
"runtimeArgs": []
}
}
}

docker-compose:
runtime: nvidia
meio Ambiente:
- NVIDIA_VISIBLE_DEVICES = all

Não existe mais algo como "/ usr / bin / nvidia-container-runtime". O problema ainda é crítico.

ajudará a executar o ambiente nvidia com docker-compose, até consertar docker-compose

instale nvidia-docker-runtime:
https://github.com/NVIDIA/nvidia-container-runtime#docker -engine-setup
adicione a /etc/docker/daemon.json
{
"tempos de execução": {
"nvidia": {
"path": "/ usr / bin / nvidia-container-runtime",
"runtimeArgs": []
}
}
}

docker-compose:
runtime: nvidia
meio Ambiente:

• NVIDIA_VISIBLE_DEVICES = all

Isso não está funcionando para mim, ainda estou recebendo Unsupported config option for services.myservice: 'runtime' ao tentar executar docker-compose up

alguma ideia?

Isso não está funcionando para mim, ainda estou recebendo Unsupported config option for services.myservice: 'runtime' ao tentar executar docker-compose up

alguma ideia?

depois de modificar /etc/docker/daemon.json, reinicie o serviço docker
systemctl restart docker
use o formato Compose 2.3 e adicione runtime: nvidia ao seu serviço de GPU. O Docker Compose deve ser a versão 1.19.0 ou superior.
arquivo docker-compose:
versão: '2.3'

Serviços:
nvsmi:
imagem: ubuntu: 16.04
runtime: nvidia
meio Ambiente:
- NVIDIA_VISIBLE_DEVICES = all
comando: nvidia-smi

@cheperuiz , você pode definir nvidia como tempo de execução padrão em daemon.json e não será dependente de docker-compose. Mas todos os contêineres do docker usarão o tempo de execução nvidia - não tenho problemas até agora.
{ "default-runtime": "nvidia", "runtimes": { "nvidia": { "path": "/usr/bin/nvidia-container-runtime", "runtimeArgs": [] } }, }

Ah! obrigado @Kwull , perdi aquela default-runtime parte ... Tudo funcionando agora :)

@uderik , runtime não está mais presente no esquema de formato de arquivo de composição 3.7 atual, nem na versão 3.8 pendente que deve eventualmente se alinhar com Docker 19.03: https://github.com/docker/compose/blob/ 5e587d574a94e011b029c2fb491fb0f4bdeef71c / compose / config / config_schema_v3.8.json

@johncolby runtime nunca foi um sinalizador 3.x. Só está presente na faixa 2.x, (2.3 e 2.4).

Sim, eu sei, e embora meu arquivo docker-compose.yml inclua o version: '2.3' (que funcionou no passado), ele parece ser ignorado pelas versões mais recentes ...
Para projetos futuros, qual seria a maneira correta de ativar / desativar o acesso à GPU? apenas tornando-as variáveis ​​+ env padrão? ou haverá suporte para a bandeira --gpus ?

@johncolby qual é a substituição de runtime no 3.X?

@ Daniel451 Estou apenas acompanhando perifericamente, mas parece que estará sob a chave 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)
Documento de design aqui: https://github.com/docker/swarmkit/blob/master/design/generic_resources.md

Aqui está o problema de composição em relação ao suporte de esquema de composição 3.8, que já está mesclado em: https://github.com/docker/compose/issues/6530

No lado do daemon, o recurso gpu pode ser registrado incluindo-o na daemon.json ou dockerd CLI (como a solução alternativa de tempo de execução codificada anteriormente), algo como

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

que então é registrado conectando-se ao utilitário docker da NVIDIA:
https://github.com/moby/moby/blob/09d0f9/daemon/nvidia_linux.go

Parece que o maquinário está basicamente instalado, provavelmente só precisa ser documentado ...

Qualquer atualização?

Também aguardando atualizações, usando bash com docker run --gpus até a correção oficial ...

Aguardando atualizações também.

Também esperando por atualizações :)

Ok ... Não entendo porque ainda está aberto. Essas 3 linhas adicionais fazem com que funcione com o esquema versão 3.7. Fico feliz em saber que o docker responde a problemas triviais da comunidade. Portanto, clone este repositório, adicione essas três linhas e python3 setup.py build && instale-o e certifique-se de que docker-compose.yml seja a versão 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'),

Acabei de adicionar um problema interno para rastrear isso.
Lembre-se de que os RP são bem-vindos: smiley:

Ok ... Não entendo porque ainda está aberto. Essas 3 linhas adicionais fazem com que funcione com o esquema versão 3.7. Fico feliz em saber que o docker responde a problemas triviais da comunidade. Portanto, clone este repositório, adicione essas três linhas e python3 setup.py build && instale-o e certifique-se de que docker-compose.yml seja a versão 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'),

Tentei sua solução, mas recebo muitos erros sobre esse sinalizador:

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'

Eu preciso de um pacote específico de python docker ?

@DarioTurchi Sim, encontrei o problema exato. Parece que o tipo de HostConfig também precisa ser atualizado.

Não acredito que a mudança descrita por @ruckc seja suficiente, porque docker-py também precisará de uma mudança. E parece que a mudança necessária do docker-py ainda está sendo trabalhada. Veja aqui:
https://github.com/docker/docker-py/pull/2419

Aqui está o ramo com as mudanças:
https://github.com/sigurdkb/docker-py/tree/gpus_parameter

Então, se você deseja corrigir isso agora, você terá que construir docker-compose contra um docker-py modificado de https://github.com/sigurdkb/docker-py/tree/gpus_parameter

Eu não entendo o que está acontecendo aqui:

1) Tenho em /etc/docker/daemon.json

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

mas a chave runtime não pode mais ser usada na v3.x como para https://github.com/docker/compose/issues/6239

Eu tentei também:

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

Portanto, não posso mais iniciar meus contêineres com suporte GPU em 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 dessas mudanças funcionava, o que posso fazer agora?

+1, será muito útil ter esse recurso no docker-compose!

Qualquer eta?

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

+1 seria um recurso útil para docker-compose

Este recurso seria um ótimo complemento para docker-compose

No momento, minha solução para isso é usar a versão 2.3 do arquivo docker-compose, que oferece suporte ao runtime, e instalar manualmente o nvidia-container-runtime (já que ele não é mais instalado com o nvidia-docker).
Além disso, estou definindo as configurações de tempo de execução em /etc/docker/daemon.json (não como padrão, apenas como um tempo de execução disponível).
Com isso, posso usar um arquivo de composição como:

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

No momento, minha solução para isso é usar a versão 2.3 do arquivo docker-compose, que oferece suporte ao runtime, e instalar manualmente o nvidia-container-runtime (já que ele não é mais instalado com o nvidia-docker).
Além disso, estou definindo as configurações de tempo de execução em /etc/docker/daemon.json (não como padrão, apenas como um tempo de execução disponível).
Com isso, posso usar um arquivo de composição como:

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

@arruda Você se importaria de compartilhar seu daemon.json por favor?

No momento, minha solução para isso é usar a versão 2.3 do arquivo docker-compose, que oferece suporte ao runtime, e instalar manualmente o nvidia-container-runtime (já que ele não é mais instalado com o nvidia-docker).
Além disso, estou definindo as configurações de tempo de execução em /etc/docker/daemon.json (não como padrão, apenas como um tempo de execução disponível).
Com isso, posso usar um arquivo de composição como:

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

@arruda Você se importaria de compartilhar seu daemon.json por favor?

Sim, sem problemas, aqui está:

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

Oi

Tenho um aplicativo que requer drivers NVIDIA. Eu construí uma imagem docker baseada em (DE)
nvidia / cudagl: 10.1-runtime-ubuntu18.04

Usando a abordagem recomendada acima - isso significa que minha imagem não precisa ser derivada de nvidia / cudagl: 10.1-runtime-ubuntu18.04 ? Ou seja, eu poderia simplesmente derivar de (FROM) python: 3.7.3-stretch
e adicionar runtime: nvidia ao serviço em docker-compose?

obrigado

@rfsch Não, isso é uma coisa diferente. runtime: nvidia em docker-compose refere-se ao tempo de execução do Docker. Isso torna a GPU disponível para o contêiner. Mas você ainda precisa de alguma forma de usá-los assim que estiverem disponíveis. runtime em nvidia/cudagl:10.1-runtime-ubuntu18.04 refere-se aos componentes de tempo de execução CUDA. Isso permite usar as GPUs (disponibilizadas em um contêiner pelo Docker) usando CUDA.

Nesta imagem:

runtime: nvidia substitui a parte runc / containerd. nvidia/cudagl:10.1-runtime-ubuntu18.04 está completamente fora de questão .

precisamos deste recurso

@ Daniel451 Estou apenas acompanhando perifericamente, mas parece que estará sob a chave 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)
Documento de design aqui: https://github.com/docker/swarmkit/blob/master/design/generic_resources.md

Aqui está o problema de composição em relação ao suporte de esquema de composição 3.8, que já está mesclado em: # 6530

No lado do daemon, o recurso gpu pode ser registrado incluindo-o na daemon.json ou dockerd CLI (como a solução alternativa de tempo de execução codificada anteriormente), algo como

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

que então é registrado conectando-se ao utilitário docker da NVIDIA:
https://github.com/moby/moby/blob/09d0f9/daemon/nvidia_linux.go

Parece que o maquinário está basicamente instalado, provavelmente só precisa ser documentado ...

Ei, @johncolby , tentei fazer isso, mas falhou:

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)

alguma sugestão?

obrigado
David

Instalando nvidia-container-runtime 3.1.4.1 de https://github.com/NVIDIA/nvidia-container-runtime e colocando

runtime: nvidia

funciona bem aqui com docker-compose 1.23.1 e 1.24.1 instalados em https://docs.docker.com/compose/install/ usando este comando de aparência duvidosa:

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

e, por exemplo, o contêiner nvidia / cudagl / 10.1-base do dockerhub. Eu tentei renderização cuda e OpenGL e está tudo perto do desempenho nativo.

Rastreado internamente como COMPOSE-82
Observe que essa mudança também precisa ser implementada em docker stack (https://github.com/docker/cli/blob/master/cli/compose/types/types.go#L156) para consistência

Instalando nvidia-container-runtime 3.1.4.1 de https://github.com/NVIDIA/nvidia-container-runtime e colocando

runtime: nvidia

funciona bem aqui com docker-compose 1.23.1 e 1.24.1 instalados em https://docs.docker.com/compose/install/ usando este comando de aparência duvidosa:

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

e, por exemplo, o contêiner nvidia / cudagl / 10.1-base do dockerhub. Eu tentei renderização cuda e OpenGL e está tudo perto do desempenho nativo.

você pode compartilhar seu docker-compose.yml?

ei, @ jdr-face,

aqui está meu teste seguindo sua sugestão, instalando nvidia-container-runtime na 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

ainda dá o erro:

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

@ david-gwa conforme observado por andyneff anteriormente :

runtime nunca foi uma bandeira 3.x. Só está presente na faixa 2.x, (2.3 e 2.4).

@ david-gwa

você pode compartilhar seu 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

Dependendo de suas necessidades, algumas dessas opções podem ser desnecessárias. Como @muru previu, o truque é especificar uma versão antiga. Pelo menos para o meu caso de uso, isso não é um problema, mas eu só ofereço essa configuração como uma solução alternativa, realmente deve ser possível usando a versão mais recente.

obrigado pessoal, @ jdr-face, @muru , compose v2 funciona,
Não entendi que sua solução é para composição v3.

Para que conste, tradicionalmente falando: compose v2 não é mais antigo que compose v3. Eles são casos de uso diferentes. A v3 é voltada para o enxame, enquanto a v2 não é. v1 é antigo.

Há alguma discussão sobre o suporte do Docker-compose para suporte a GPU nativa do Docker?

O suporte da opção runtime não é a solução para suporte de GPU no futuro. NVIDIA descreve sobre o futuro da nvidia-docker2 em https://github.com/NVIDIA/nvidia-docker da seguinte maneira.

Observe que, com o lançamento do Docker 19.03, o uso de pacotes nvidia-docker2 foi descontinuado, uma vez que as GPUs NVIDIA agora têm suporte nativo como dispositivos no tempo de execução do Docker.

Atualmente, o suporte à GPU pode ser realizado alterando o tempo de execução, mas é altamente possível que isso não funcione no futuro.

Para ser franco, essa talvez não seja a melhor prática, mas de alguma forma a fazemos funcionar.

A parte complicada é que temos que ficar com docker-compose v3.x já que estamos usando docker swarm, enquanto isso, queremos usar o Nvidia Runtime para suportar GPU / CUDA nos contêineres.

Para evitar informar explicitamente o Nvidia Runtime dentro do arquivo docker-compose, definimos o Nvidia como o tempo de execução padrão em /etc/docker/daemon.json , e será semelhante a

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

De forma que todos os contêineres em execução nas máquinas GPU habilitarão o tempo de execução da Nvidia por padrão.

Espero que isso possa ajudar alguém a enfrentar o bloqueador semelhante

Para ser franco, essa talvez não seja a melhor prática, mas de alguma forma a fazemos funcionar.

A parte complicada é que temos que ficar com docker-compose v3.x já que estamos usando docker swarm, enquanto isso, queremos usar o Nvidia Runtime para suportar GPU / CUDA nos contêineres.

Para evitar informar explicitamente o Nvidia Runtime dentro do arquivo docker-compose, definimos o Nvidia como o tempo de execução padrão em /etc/docker/daemon.json , e será semelhante a

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

De forma que todos os contêineres em execução nas máquinas GPU habilitarão o tempo de execução da Nvidia por padrão.

Espero que isso possa ajudar alguém a enfrentar o bloqueador semelhante

Isso é realmente o que fazemos também. Funciona por enquanto, mas parece um pouco estranho para mim. Esperamos por suporte completo ao compose-v3 em breve. :)

Pretende-se que o usuário preencha manualmente /etc/docker/daemon.json após migrar para docker> = 19.03 e remover nvidia-docker2 para usar nvidia-container-toolkit lugar?

Parece que isso quebra muitas instalações. Especialmente porque --gpus não está disponível em compose .

--gpus não está disponível para composição
Não posso usar o pycharm para vincular o docker para executar o tensorflow-gpu

Alguma atualização para esse problema? Existe uma chance de que --gpus seja compatível com docker-compose em breve?

Para aqueles que estão procurando uma solução alternativa, o que acabamos fazendo:

• Instale docker-py a partir deste PR: https://github.com/docker/docker-py/pull/2471
• Instale docker-compose a partir deste PR: https://github.com/docker/compose/pull/7124

E então execute COMPOSE_API_VERSION=auto docker-compose run gpu com o seguinte arquivo:

version: '3.7'

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

No Docker 19.03.0 Beta 2, o suporte para GPU NVIDIA foi introduzido na forma de nova API CLI --gpus. docker / cli # 1714 fala sobre essa ativação.

Agora é possível simplesmente passar a opção --gpus para um aplicativo baseado em Docker acelerado 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 hoje, o Compose não oferece suporte para isso. Esta é uma solicitação de recurso para habilitar o Compose para suporte para GPU NVIDIA.

Eu resolvi este problema, você pode tentar da seguinte maneira, meu endereço de blog csdn: https://blog.csdn.net/u010420283/article/details/104055046

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

então, neste arquivo daemon.json, adicione este conteúdo:

{
"tempo de execução padrão": "nvidia"
"tempos de execução": {
"nvidia": {
"path": "/ usr / bin / nvidia-container-runtime",
"runtimeArgs": []
}
}
}

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

Para os usuários ansible que desejam configurar a solução alternativa descrita anteriormente, há uma função para instalar nvidia-container-runtime e configurar o /etc/docker/deamon.json para usar runtime: nvidia :

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

(por algum motivo, ele roda apenas no Ubuntu e RHEL, mas é muito fácil de modificar. Eu executo no Debian)

Em seguida, em docker-compose.yml :

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

alguma atualização na versão 3.x oficial com suporte gpu? Precisamos de enxame :)

Existe algum plano para adicionar esse recurso?

Este recurso depende da implementação de docker-py dos parâmetros device_requests , que é o significado de --gpus . Houve várias solicitações pull para adicionar este recurso (https://github.com/docker/docker-py/pull/2419, https://github.com/docker/docker-py/pull/2465, https: / /github.com/docker/docker-py/pull/2471) mas não há reações de nenhum mantenedor. # 7124 usa https://github.com/docker/docker-py/pull/2471 para fornecê-lo no Compose, mas ainda sem resposta de ninguém.

Como mencionei no # 7124, estou mais do que feliz em tornar o PR mais compatível, mas como ele recebeu muito pouca atenção, não quero perder meu tempo com algo que não será mesclado ...

Por favor, adicione este recurso, será incrível!

Por favor, adicione este recurso! Fiquei mais do que feliz com o antigo nevidia-docker2, que me permitiu alterar o tempo de execução no daemon.json. Seria extremamente bom ter isso de volta.

Precisa, por favor. Realmente preciso: /

Eu também gostaria de continuar ... precisamos desse recurso!

Preciso executar os contêineres de CPU e GPU na mesma máquina para que o hack de tempo de execução padrão não funcione para mim. Temos alguma ideia de quando isso vai funcionar na composição? Dado que não temos o sinalizador de tempo de execução na composição, isso representa uma regressão de funcionalidade séria, não é? Estou tendo que escrever scripts para fazer isso funcionar - eca!

Preciso executar os contêineres de CPU e GPU na mesma máquina para que o hack de tempo de execução padrão não funcione para mim. Temos alguma ideia de quando isso vai funcionar na composição? Dado que não temos o sinalizador de tempo de execução na composição, isso representa uma regressão de funcionalidade séria, não é? Estou tendo que escrever scripts para fazer isso funcionar - eca!

você pode fazer isso por docker cli (docker run --gpu ....), eu tenho esse tipo de truque (adicionando um proxy, para poder se comunicar com outros contêineres em execução em outros nós no swarm). Estamos todos esperando pela capacidade de executá-lo no swarm, porque ele não funciona pelo comando docker service (como eu sei) nem por composição.

@dottgonzo . Bem, sim ;-). Estou ciente disso e, portanto, da referência aos scripts. Mas esta é uma maneira horrível e não portátil de fazer isso, então eu gostaria de fazer de uma forma mais dinâmica. Como eu disse, acho que isso representa uma regressão, não uma pergunta de recurso.

COMPOSE_API_VERSION=auto docker-compose run gpu

@ggregoire onde executamos: COMPOSE_API_VERSION = auto docker-compose run gpu?

@joehoeller do seu shell era apenas o que você faria para qualquer outro comando.

No momento, estamos decidindo para cada projeto se precisamos de recursos 3.x ou se podemos usar docker-compose 2.x onde a opção de GPU ainda é suportada. Recursos como a execução de alvos de vários estágios a partir de um Dockerfile infelizmente não podem ser usados ​​se a GPU for necessária. Por favor, adicione isso de volta!

Gostaria de recomendar algo como um campo de "opções adicionais" para docker-compose, onde podemos apenas adicionar sinalizadores como --gpus=all ao comando docker start / run, que ainda não são / mais compatíveis com docker-compose mas estão na versão mais recente do docker. Dessa forma, os usuários do compose não terão que esperar que docker-compose se atualize se precisarem de um novo recurso docker ainda não compatível.

Ainda é necessário executar isso no Docker Swarm para ambientes de produção. Isso será útil para Docker Swarm?

@sebastianfelipe É muito útil se você deseja implantar em seu swarm usando compose.
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\"

para algo assim

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

@sebastianfelipe É muito útil se você deseja implantar em seu swarm usando compose.
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\"

para algo assim

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

Desculpe, então ele já está funcionando com o Docker Swarm usando o arquivo docker-compose yaml? Só para ter certeza: O. Obrigado!

apenas para docker compose 2.x

O ponto principal deste problema é solicitar o suporte nvidia-docker gpu para docker-compose 3+

Já se passou quase um ano desde o pedido original !! Por que o atraso ?? Podemos avançar ??

ping @KlaasH @ulyssessouza @Goryudyuma @ chris-crone. alguma atualização disso?

Para aqueles que estão procurando uma solução alternativa, o que acabamos fazendo:

• Instale docker-py a partir deste PR: docker / docker-py # 2471
• Instale docker-compose a partir deste PR: # 7124

E então execute COMPOSE_API_VERSION=auto docker-compose run gpu com o seguinte arquivo:

version: '3.7'

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

Para aqueles de vocês que são tão impacientes quanto eu, aqui está uma versão pip install fácil da solução alternativa acima:

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

Muitos parabéns para
Ainda esperando ansiosamente por um patch oficial. Com todos os PRs implementados, não parece difícil por nenhum padrão.

ping @KlaasH @ulyssessouza @Goryudyuma @ chris-crone. alguma atualização disso?

Não, não sei porque fui chamado.
Eu quero que você me diga o que fazer?

Espero que haja uma atualização sobre isso.

Sim, já faz mais de um ano ... por que eles não estão se fundindo em docker-py ...

Não tenho certeza se as implementações propostas são as corretas para o formato Compose. A boa notícia é que abrimos a especificação do formato Compose com a intenção de adicionar coisas como esta. Você pode encontrar a especificação em https://github.com/compose-spec.

O que eu sugiro que façamos é adicionar um problema na especificação e, em seguida, discuti-lo em uma das próximas reuniões da comunidade do Compose (link para convidar na parte inferior desta página ).

Isso funciona: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi
Isso não: docker run --runtime=nvidia nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Você precisa ter

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

em seu /etc/docker/daemon.json para --runtime=nvidia para continuar trabalhando. Mais informações aqui .

Dockerd não começa com este daemon.json

Cristo, isso vai levar anos: @

Isso funciona: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi
@deniswal : Sim, sabemos disso, mas estamos perguntando sobre a funcionalidade de composição.

@ chris-crone: Estou confuso: isso representa uma regressão do comportamento anterior, por que precisa de uma nova especificação de recurso? Não é razoável executar contêineres, alguns dos quais usam GPU e outros usam CPU na mesma caixa física?

Obrigado pela consideração.

@ vk1z AFAIK Docker Compose nunca teve suporte para GPU, então isso não é uma regressão. A parte que precisa de design é como declarar a necessidade de um serviço por uma GPU (ou outro dispositivo) no formato Compose - especificamente mudanças como esta . Depois disso, deve ser apenas canalizado para o back-end.

Oi pessoal, tentei algumas soluções propostas aqui e nada funcionou para mim, por exemplo @miriaford não funcionou no meu caso, também existe alguma maneira de usar GPU para rodar meus contêineres docker existentes?
Eu tenho um i7 com 16 GB de RAM, mas a compilação de alguns projetos demora muito para ser concluída. Meu objetivo é também usar a potência da GPU para acelerar o processo, isso é possível? Obrigado!

@ chris-crone: Mais uma vez, estarei disposto a ser corrigido, mas não foi porque o parâmetro runtime: desapareceu da composição após a configuração 2.4? Por isso senti que era uma regressão. Mas não, importa agora, já que todos devemos estar no 3.x de qualquer maneira.

Ficaria feliz em registrar um problema, fazemos isso contra a especificação no repositório de especificações, correto?

mas não foi porque o runtime: parameter desapareceu da composição após a configuração 2.4? Por isso senti que era uma regressão.

Sim, exatamente. Tenho alguns projetos em que contamos com o uso de runtime: nvidia em nossos arquivos docker-compose, e esse problema nos impede de atualizar para 3.x porque não encontramos uma maneira de usar GPUs lá.

Oi, por favor, por favor, corrija isso.
Isso deve ser marcado como prioridade de missão crítica -20

Novamente, estarei disposto a ser corrigido, mas não foi porque o runtime: parameter desapareceu da composição após a configuração 2.4? Por isso senti que era uma regressão. Mas não, importa agora, já que todos devemos estar no 3.x de qualquer maneira.

Eu não estava aqui quando a alteração foi feita, então não tenho 100% de certeza por que ela foi descartada. Eu sei que você não precisa mais do tempo de execução da NVIDIA para usar GPUs e que estamos desenvolvendo a especificação Compose v3 aqui com a intenção de fazer uma única versão da especificação. Isso pode significar mover algumas funcionalidades da v2 para a v3.

Em termos do campo runtime , não acho que seja assim que ele deve ser adicionado à especificação do Compose, pois é muito específico para a execução em um único nó. O ideal seria algo que permitisse que você especifique que sua carga de trabalho tem uma necessidade de dispositivo (por exemplo: GPU, TPU, o que vier a seguir) e, em seguida, deixe o orquestrador atribuir a carga de trabalho a um nó que fornece esse recurso.

Essa discussão deve ser feita na especificação, pois não é específica do Python Docker Compose.

@ chris-crone: Eu concordo principalmente com sua declaração. Adicionar hacks de curto prazo é provavelmente a maneira incorreta de fazer isso, já que temos uma proliferação de dispositivos de ponta, cada um com seus próprios tempos de execução. Por exemplo, como você aponta, TPU (Google), VPU (Intel) e ARM GPU no Pi. Portanto, precisamos de uma história mais completa.

Vou registrar um problema contra a especificação hoje e atualizar este tópico assim que tiver feito isso. No entanto, acho que o orquestrador deve ser independente - por exemplo, se eu quiser usar o Kube, devo ser capaz de fazê-lo. Estou assumindo que estará no escopo.

No entanto, discordo da declaração de uso de GPUs, uma vez que isso não funciona com compose - que é o que está em causa. Mas acho que todos nós entendemos qual problema gostaríamos que fosse resolvido.

@ chris-crone: Consulte o problema de especificação docker-compose arquivado. Seguirei as atualizações contra esse problema a partir de agora.

Podemos simplesmente adicionar uma opção (algo como extra_docker_run_args ) para passar argumentos diretamente para o docker run subjacente? Isso não apenas resolverá o problema atual, mas também será à prova de futuro: e se o docker adicionar suporte para qualquer "XPU", ​​"YPU" ou qualquer outro recurso novo que possa vir no futuro?

Se precisarmos de uma longa discussão de ida e volta toda vez que o docker adicionar um novo recurso, ele será extremamente ineficiente e causará um atraso inevitável (e confusão desnecessária) entre as atualizações de docker-compose e docker . Apoiar a delegação de argumentos pode fornecer um alívio temporário para esse problema recorrente para todos os recursos futuros.

@miriaford Não tenho certeza se passar um blob não interpretado suporta a noção de composição de ser declarativo. A tag de tempo de execução antiga pelo menos indicava que tinha algo a ver com o tempo de execução. Dada a direção da tendência do docker (docker-apps), parece-me que fazer isso tornaria a implantação declarativa mais difícil, pois um orquestrador teria que analisar blobs arbitrários.

Mas eu concordo que compose e docker devem ser sincronizados e zapping recursos de trabalho dos quais as pessoas dependem (mesmo que seja uma versão principal) não é muito kosher.

@ vk1z Eu concordo - deve haver um mecanismo de sincronização muito melhor entre compose e docker . No entanto, não espero que esse mecanismo seja projetado tão cedo. Enquanto isso, também precisamos de uma maneira temporária de fazer nossa própria sincronização sem invadir profundamente o código-fonte.

Se a proposta de delegação de argumentos não for uma opção, o que sugerimos que façamos? Eu concordo que não é uma solução bonita, mas é pelo menos _muito_ melhor do que esta solução alternativa, não é? https://github.com/docker/compose/issues/6691#issuecomment -616984053

@miriaford docker-compose não chama o docker executive com argumento; na verdade, usa docker_py que usa a API http para o docker daemon. Portanto, não há um comando " docker run " subjacente. A docker CLI não é uma API, a conexão de soquete é o ponto de contato da API. É por isso que nem sempre é fácil.

Para simplificar as coisas, no processo de execução de um docker, há duas chamadas principais, uma que cria o contêiner e outra que o inicia, cada uma ingere diferentes partes de informações, e saber qual é o tempo que leva alguém com conhecimento de API, que Não sei como tendemos a conhecer a docker CLI. Não acho que poder adicionar args extras às chamadas docker_py será tão útil quanto você pensa, exceto em casos de uso selecionados.

Para tornar as coisas ainda mais difíceis, às vezes a biblioteca docker_py está por trás da API e também não tem tudo de que você precisa imediatamente, e você tem que esperar a atualização. Dito isso, extra_docker_run_args não é uma solução simples.

@andyneff Obrigado pela sua explicação. Na verdade, não estou muito familiarizado com o funcionamento interno do Docker. Se bem entendi, existem 4 APIs que precisam ser sincronizadas manualmente para quaisquer novas atualizações de recursos:

1. API Docker socket
2. docker_py que fornece interface python para a API de soquete
3. Docker CLI (nosso ponto de entrada familiar para o conjunto de ferramentas do docker)
4. Interface Docker-compose que chama docker socket API

Isso levanta a questão: por que não existe um mecanismo de sincronização automático (ou pelo menos semiautomático)? Propagar manualmente as novas atualizações de recursos em 4 APIs parece fadado a ser sujeito a erros, sujeito a atrasos e confuso ...

PS Não estou dizendo que seja uma tarefa _simples_ ter sincronização automática, mas realmente acho que deveria haver uma para tornar a vida mais fácil no futuro.

Estou meio que entrando em pedantismo agora ... Mas como eu descreveria como ...

• O soquete docker é A API oficial para docker. Muitas vezes é um soquete de arquivo, mas também pode ser TCP (ou qualquer outro, imagino que use socat )
• A docker CLI usa essa API para fornecer aos usuários uma ferramenta incrível
  
  
  
  • O Docker grava a API e a CLI, para que sejam sempre sincronizadas no momento do lançamento. (Acho que é seguro dizer, o CLI é um cidadão de primeira classe do ecossistema docker)
  
  
• A biblioteca docker_py pega essa API e a coloca em uma biblioteca incrível que outras bibliotecas Python podem usar. Sem isso, você mesmo estaria fazendo todas essas chamadas HTTP e arrancando os cabelos.
  
  
  
  • No entanto, docker_py foi iniciado como uma biblioteca de terceiros e, portanto, tradicionalmente segue a API docker e tem coisas adicionadas posteriormente ou conforme necessário (recursos limitados).
  
  
• compose usa uma versão do docker_py e adiciona todos esses recursos incríveis, novamente conforme necessário (com base em problemas como este)
  
  
  
  • No entanto, a composição não pode fazer muito até docker_py (o que não estou dizendo que está impedindo este problema, não sei, estou apenas falando em geral)
  
  

Então sim, vai:

• "compose yaml + compose args" -> "docker_py" -> "docker_api"
• E a CLI não faz parte disso (e acredite, essa é a maneira certa de fazer as coisas)

Não posso falar por docker_py ou compose, mas imagino que eles tenham limitado o número de horas de trabalho contribuindo para isso, então é mais difícil acompanhar TODOS os recursos loucos e insanos do docker que o docker está CONSTANTEMENTE adicionando. Mas, uma vez que docker é uma biblioteca go, e meu entendimento é que o suporte a python não é (atualmente) um cidadão de primeira classe. Embora seja bom que ambos os projetos estejam sob o guarda-chuva do docker, pelo menos do ponto de vista da organização do github.

Então, tudo que foi dito ... Eu também estou esperando por um suporte --gpus equivalente, e tenho que usar o antigo método runtime: nvidia , que pelo menos me dará "um" caminho para mover encaminhar no docker-compose 2.x.

@andyneff Para https://www.docker.com/blog/faster-builds-in-compose-thanks-to-buildkit-support/

@andyneff, esta é uma visão geral muito útil! obrigado novamente

@lig incrível! Obrigado pela correção! Na verdade, eu estava pensando "Como o buildkit se encaixará em tudo isso" enquanto escrevia

O que estou um pouco surpreso é que docker-compose é uma parte bastante intrínseca da nova estrutura docker-app e eu imagino que eles gostariam de sincronizar docker-compose e docker pelo menos por esse motivo. Eu me pergunto o que o bloqueador realmente é: largura de banda do Python insuficiente? Parece um pouco inacreditável.

Então, como o Docker Swarm se encaixa na estrutura que @andyneff acabou de descrever? Swarm usa o formato de arquivo de composição versão 3 (definido pelo projeto "composição"?), Mas é desenvolvido como parte de docker ?

Pedimos desculpas se isso estiver fora do assunto para este problema específico. Eu já perdi a noção de qual problema é qual, mas comecei a seguir porque gostaria de ser capaz de dizer a um serviço em execução em um enxame que ele precisa usar um determinado tempo de execução. Só podemos fazer isso com a v2 da especificação do arquivo de composição, o que significa que não podemos fazer isso com o Swarm, que requer a v3. Em outras palavras, não estou realmente interessado no que a CLI docker-compose faz, mas apenas na especificação definida para arquivos docker-compose.yml que são consumidos pelo docker swarm.

Oh enxame, aquele que fugiu ... (de mim). Infelizmente, é o # 6239 que foi fechado por um BOT. :( Alguém tentou em # 6240, mas foi informado de que ...

@miriaford , parece que há um PR para sincronizá-los! # 6642 ?! (Isso é apenas para v3 ???)

Portanto, por causa da natureza do enxame, há certas coisas que você faz e não faz em nós do enxame. Portanto, a API Docker nem sempre permite que você faça as mesmas opções em uma execução de enxame, como uma execução normal. Não sei se o tempo de execução é uma dessas coisas improvisadas, mas é frequentemente por isso que você não pode fazer coisas na v3 (a versão compatível com o swarm) e pode na v2 (a versão não compatível com o swarm).

Ninguém lendo isso sabe do que vocês estão falando.
Todos nós estamos tentando implantar jellyfin com aceleração de hardware.
Até que vocês consertem isso de volta ao que deveria ser, quando diz serviço, 3.x não é bom.
Não use.

Você precisa colocar 2.4 para o serviço.
Então você pode usar aceleração de hardware para jellyfin, ez

Então vamos lá pessoal, qual é o ETA disso, 1 ano, 2 anos?

@KlaasH @ulyssessouza @Goryudyuma @ chris-crone Olá, estou trabalhando neste problema, descobri que faltava suporte em "docker-py", trabalhei nessa parte. Agora, para fazê-lo funcionar, preciso passar as configurações por meio do arquivo docker-compose.yml. Você pode me ajudar com o esquema? ou seja, para adicioná-lo, devo adicioná-lo a um novo esquema ou há algum lugar onde as configurações possam ser passadas

@fakabbir Eu presumo que está ok apenas usar COMPOSE_DOCKER_CLI_BUILD para isso. Adicionar a capacidade de fornecer uma lista arbitrária de docker run argumentos pode até ajudar a evitar problemas semelhantes no futuro.

@lig como você lida quando apenas um serviço requer acesso a uma GPU?

@lig AFAICS composição usa docker-py vez de docker run cli. Portanto, adicionar argumentos docker run arbitrários não funcionaria, a menos que docker-py suporte.

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

Essa única coisa diminui a utilidade do docker-compose enormemente para muitas pessoas. O fato de ele não ter visto muita atenção e desejo de consertá-lo, especialmente quando funcionou em um docker-compose mais antigo, é bastante surpreendente.
Uma maneira de fazer isso não seria permitir que argumentos docker --run arbitrários fossem fornecidos em um arquivo docker-compose? Então --gpus all, por exemplo, pode ser passado para o docker.

Eu entendo que pode haver razões filosóficas ou técnicas pelas quais alguém pode querer fazer isso de uma maneira particular. Mas não colocar as mãos na massa e fazer de QUALQUER maneira confunde a mente.

@lig como você lida quando apenas um serviço requer acesso a uma GPU?

Bem, a variável de ambiente NVIDIA_VISIBLE_DEVICES permitirá que você controle isso não?

Essa única coisa diminui a utilidade do docker-compose enormemente para muitas pessoas. O fato de ele não ter visto muita atenção e desejo de consertá-lo, especialmente quando funcionou em um docker-compose mais antigo, é bastante surpreendente.
Uma maneira de fazer isso não seria permitir que argumentos docker --run arbitrários fossem fornecidos em um arquivo docker-compose? Então --gpus all, por exemplo, pode ser passado para o docker.

Não acho que permitir a passagem de docker --run args é o caminho a seguir. compose realmente não chama docker por si só, mas em vez disso usa docker-py .

Eu entendo que pode haver razões filosóficas ou técnicas pelas quais alguém pode querer fazer isso de uma maneira particular. Mas não colocar as mãos na massa e fazer de QUALQUER maneira confunde a mente.

Um PR está aberto sobre isso: https://github.com/docker/compose/pull/7124. Sinta-se à vontade para "colocar as mãos nisso".

Acredito que de acordo com a mudança nas especificações do docker compose , devemos voltar em breve à compatibilidade anterior conforme o Compose 2.4 e o runtime da nvidia funcionará. Obviamente não funcionará para TPUs ou outros aceleradores - o que é muito lamentável, mas para aqueles que desejam executar o NVIDIA GPUS (caro), ele funcionará.

Então, apenas esperando por um PR verde em docker-py para ser mesclado https://github.com/docker/docker-py/pull/2471

SIM! O PR em docker-py foi aprovado! https://github.com/docker/docker-py/pull/2471
Qual é o próximo passo aqui?

O que há aqui? Seria legal poder dar suporte ao tempo de execução da nvidia no docker-compose

https://github.com/docker/docker-py/pull/2471 foi mesclado.

Agora que docker / docker-py # 2471 foi mesclado, podemos instalar o docker-py do master. Mas como o docker-compose mudou desde o legal [PR] de @yoanisgil (https://github.com/docker/compose/pull/7124) (Kudos!), É improvável que seja mesclado. Portanto, neste ponto, o docker-compose pode ser instalado a partir desse PR para salvar o dia.

Para quem acabou aqui sem ver os comentários anteriores:

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

Em seguida, use o seguinte modelo em seu arquivo de composição. (fonte: comentário ):

E então execute COMPOSE_API_VERSION=auto docker-compose run gpu com o seguinte arquivo:

version: '3.7'

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

Confirmo que funcionou na minha máquina local. Não sei se funciona com o Swarm.

Não é possível ter um commit específico de docker-compose em produção. O # 7124 precisa ser realocado ou há outro PR que vai incorporar o novo docker-py ?

Olá @bkakilli ,

Obrigado pela ajuda! Acabei de tentar sua sugestão, mas recebo um erro ao executar meu docker-compose

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

_análise sendo o nome do meu container_

Mudei meu docker-compose.yml de:

version: '2.3'

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

para:

version: '3.7'

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

Existe alguma coisa além de pip install git+ para configurar isso corretamente? Ou talvez eu editei mal o arquivo de configuração?

@frgfm certifique-se de instalar o compose e docker-py a partir dos links corretos. Você pode ter usado o repositório do docker-compose em vez do fork (e branch) de yoanisgil. Veja se você está usando o seguinte link:

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

Você pode tentar colocar --upgrade param para instalar o pip. Caso contrário, eu suspeitaria das configurações do ambiente virtual. Talvez você tenha outra instalação docker-compose, que está sendo usada por padrão? Por exemplo, você pode ter instalado para o sistema com as instruções "Linux" aqui: https://docs.docker.com/compose/install/. Eu sugiro que você dê uma olhada em "Opções de instalação alternativas" e instale via pip no ambiente virtual (mas use o comando pip install acima. Não instale o docker-compose padrão do PyPI).

Oi!
Obrigado por todas as informações. Eu estava tentando executar sua abordagem @bkakilli e docker-compose build funcionou, mas ao executar docker-compose up recebi o erro:
docker.errors.InvalidVersion: device_requests param is not supported in API versions < 1.40

Meu docker_compose.yml se parece com isto:

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

Desde já, obrigado!

@ugmSorcero Defina a variável de ambiente COMPOSE_API_VERSION=1.40 e execute novamente seus comandos

@ugmSorcero você conseguiu consertar esse erro? @EpicWink @bkakilli Estou executando a versão indicada na instalação do pip, mas ainda recebo o erro de device_requests param is not supported in API versions < 1.40 mesmo se eu exportar essa variável para 1,40

Para o arquivo de composição fornecido

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

Usando a versão de docker-compose instalada como acima, no Bash no Linux, o seguinte comando é bem-sucedido:

COMPOSE_API_VERSION=1.40 docker-compose up

O seguinte comando falha:

docker-compose up

Isso tem saída de erro:

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 muito obrigado. Não percebi que docker-compose up tinha que ser executado dessa forma. Eu fiz isso como uma etapa em que primeiro exportei COMPOSE_API_VERSION separadamente. Executá-lo em conjunto parece funcionar :)

Eu tenho outro problema, no entanto. Se eu executar COMPOSE_API_VERSION=1.40 docker-compose run nvidiatest então nvidia-smi não será encontrado no caminho, enquanto se eu executar diretamente a partir da imagem, não haverá problema.

É assim que estou reproduzindo.

O arquivo local docker-compose contém:

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

Se eu executar minha configuração atual (versão automática da API e 1.40), recebo o seguinte erro:

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

É possível que tenha a ver com o uso de arquivos de substituição? Se eu apenas executar a imagem base cuda com o Docker, não haverá problema em obter a saída 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      |
|=============================================================================|
+-----------------------------------------------------------------------------+

Instalei docker-compose seguindo as instruções acima do git depois de desinstalar a versão instalada dos documentos oficiais. Aqui estão as informações da versão 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

Estou perdendo alguma coisa? Obrigado pela ajuda!

@jjrugui, isso está ficando fora do assunto e não consigo reproduzir o seu problema. Desculpe por não poder ajudar

@EpicWink não é um problema e desculpe por desviar do assunto :). Se eu descobrir meu problema específico, vou postá-lo aqui se for relevante.

Alguém está trabalhando em outro PR ou estamos depurando a filial device-requests para nos prepararmos para um PR?

Enquanto o PR estava travado, eu portei as alterações de # 7124 para a versão mais recente do branch master para corresponder às dependências, etc. - https://github.com/beehiveai/compose Você pode instalar com pip install git+https://github.com/beehiveai/compose.git e mude a versão em docker-compose.yml para 3.8 :

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

Nessa configuração, tudo funciona conforme o esperado.

Conforme discutido ontem na reunião de governança de especificação de composição , começaremos a trabalhar em uma proposta para adotar algo comparável a # 7124, que poderia estar perto de generic_resouces já disponível na seção deploy .

@ndeloof Isso é ótimo! Se for possível, poste o link para a proposta aqui. Acho que muitas pessoas ficariam felizes em contribuir com isso, já que o suporte da GPU é fundamental para implantações de aprendizado profundo.

@ndeloof historicamente, quanto tempo leva para o comitê de direção tomar uma decisão, 6 meses, um ano?

+1

+1

@visheratin Alguma chance de você melhorar sua correção para que funcione ao usar vários arquivos yml de composição? Eu tenho um docker-compose.yml base que usa um contêiner não-nvidia, que desejo substituir pelo contêiner nvidia quando houver uma GPU, no entanto, parece que com sua correção, se eu especificar vários arquivos yml de composição com o "- f ", os campos" device_requests "saem da configuração.

@proximous O que você quer dizer com "sai da configuração"? Todos os arquivos de composição têm a versão 3.8? Você pode compartilhar o exemplo para que seja mais fácil de reproduzir?

Tendo um problema com o código em compose / service.py ao tentar usar a opção --scale com docker-compose up. Isso não é compatível?

Traceback (última chamada mais recente):
Arquivo "/ usr / local / bin / docker-compose", linha 11, em
load_entry_point ('docker-compose == 1.27.0.dev0', 'console_scripts', 'docker-compose') ()
Arquivo "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", linha 67, no principal
comando()
Arquivo "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", linha 123, em perform_command
manipulador (comando, opções_de_comando)
Arquivo "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", linha 1067, em até
to_attach = up (False)
Arquivo "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", linha 1063, em até
cli = native_builder,
Arquivo "/usr/local/lib/python3.6/site-packages/compose/project.py", linha 648, em até
get_deps,
Arquivo "/usr/local/lib/python3.6/site-packages/compose/parallel.py", linha 108, em parallel_execute
aumentar error_to_reraise
Arquivo "/usr/local/lib/python3.6/site-packages/compose/parallel.py", linha 206, no produtor
resultado = função (obj)
Arquivo "/usr/local/lib/python3.6/site-packages/compose/project.py", linha 634, em do
override_options = override_options,
Arquivo "/usr/local/lib/python3.6/site-packages/compose/service.py", linha 579, em execute_convergence_plan
renovar_anônimo_volumes,
Arquivo "/usr/local/lib/python3.6/site-packages/compose/service.py", linha 509, em _execute_convergence_recreate
escala - len (contêineres), destacado, iniciar
Arquivo "/usr/local/lib/python3.6/site-packages/compose/service.py", linha 479, em _execute_convergence_create
"Criando"
Arquivo "/usr/local/lib/python3.6/site-packages/compose/parallel.py", linha 108, em parallel_execute
aumentar error_to_reraise
Arquivo "/usr/local/lib/python3.6/site-packages/compose/parallel.py", linha 206, no produtor
resultado = função (obj)
Arquivo "/usr/local/lib/python3.6/site-packages/compose/service.py", linha 477, em
lambda service_name: create_and_start (self, service_name.number),
Arquivo "/usr/local/lib/python3.6/site-packages/compose/service.py", linha 456, em create_and_start
container = service.create_container (número = n, quiet = True)
Arquivo "/usr/local/lib/python3.6/site-packages/compose/service.py", linha 333, em create_container
previous_container = previous_container,
Arquivo "/usr/local/lib/python3.6/site-packages/compose/service.py", linha 936, em _get_container_create_options
one_off = one_off)
Arquivo "/usr/local/lib/python3.6/site-packages/compose/service.py", linha 1014, em _get_container_host_config
element.split (',') para o elemento em device_request ['capacidades']]
Arquivo "/usr/local/lib/python3.6/site-packages/compose/service.py", linha 1014, em
element.split (',') para o elemento em device_request ['capacidades']]
AttributeError: o objeto 'list' não tem nenhum atributo 'split'

Após mais depuração, descobri que, ao usar --scale, por algum motivo uma instância tem device_requests ['capacity'] como ['gpu']. Mas para todos os outros contêineres a serem iniciados, o device_request ['capacidades'] em vez disso se parece com [['gpu']].

Fiz uma correção temporária local para contornar esse problema apenas para colocar meus contêineres em funcionamento a partir da linha 1010 em compose / service.py:

`` `
para device_request em device_requests:
se 'capacidades' não estão em device_request:
continuar
if type (device_request ['capacity'] [0]) == lista:
device_request ['capacidades'] = [
element.split ('.') para o elemento em device_request ['capacity'] [0]]
outro:
device_request ['capacidades'] = [
element.split ('.') para o elemento em device_request ['capacidades']]

`` ``

@proximous O que você quer dizer com "sai da configuração"? Todos os arquivos de composição têm a versão 3.8? Você pode compartilhar o exemplo para que seja mais fácil de reproduzir?

@visheratin veja este exemplo, estou errado em esperar um 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 apenas o nogpu.yml:

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

use apenas o 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'

ymls de configuração de cadeia começando com um yml não-gpu (nota ... sem tempo de execução):

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

saída esperada:

$ 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, estou tentando algo mais elaborado e este é apenas um caso simplificado para destacar o comportamento inesperado.)

@jlaule @proximous Para manter este tópico no tópico, crie problemas no

Para quem precisa de algo enquanto espera, eu apenas configurei o K3S (versão edge do Kubernetes) com suporte para GPU em 30 minutos usando o docker como um tempo de execução do contêiner (ou seja, use a opção --docker para o script de instalação). Siga https://github.com/NVIDIA/k8s-device-plugin para fazer o plug-in do dispositivo Nvidia funcionar.
Espero que ajude!

@EpicWink não é um problema e desculpe por desviar do assunto :). Se eu descobrir meu problema específico, vou postá-lo aqui se for relevante.

Você já resolveu isso?

Não existe mais algo como "/ usr / bin / nvidia-container-runtime". O problema ainda é crítico.

Instale nvidia-docker2 conforme instruído aqui

Eu tenho lidado com isso recentemente e pensei que gostaria de compartilhar minha abordagem.
meu problema era que eu precisava implantar a pilha do docker e ele não queria ouvir. docker compose que trabalhei com o hack da versão docker api, mas não parecia certo e a implantação da pilha não funcionaria de qualquer maneira.

então, sem definir nenhuma solicitação de dispositivo pr de tempo de execução em meu docker compose, adicionei isto ao meu daemon:

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

você também pode usar GPU- {primeira parte do gpu guid}
mas isso era mais fácil. não precisava instalar nenhum pip + ou algo parecido, exceto o kit de ferramentas de contêiner NV. ele implanta e funciona como um encanto.

Tks muito
Para outros: não se esqueça de reiniciar o daemon do docker.

@pommedeterresautee ah, estou tão feliz que funcionou para os outros! deveria ter mencionado o reload.

tenho que dizer que após 3 semanas de atracação sem parar, estou muito perplexo como nada parece funcionar ..

@haviduck : Obrigado! Finalmente uma solução simples que funciona. Passei tanto tempo tentando adicionar dispositivos, etc, que desisti. Aí vem isso, tente e depois de alguns minutos eu tenho a transcodificação de hardware no Plex funcionando.

Vou adicionar meus 2 centavos a este assunto ... Eu li muitos posts e finalmente a solução foi bem simples.

funcionou para mim com: (talvez um pouco mais baixo também teria funcionado - não faço ideia ...)
docker-compose versão 1.27.4, compilação 40524192

1. na máquina host docker instale os pacotes nvidia-container-toolkit e nvidia-container-runtime
2. na máquina docker host: digite
   nvidia-smi e examine a versão CUDA que aparece à direita
   
3. na máquina docker host: digite: (substitua a versão cuda pela que você instalou)
   docker run --rm --gpus all nvidia / cuda: nvidia-smi
   você deve obter a mesma saída de quando executou o nvidia-smi na máquina host
4. no arquivo /etc/docker/daemon.json você deve ver:
   "runtimes": {"nvidia": {"path": "/ usr / bin / nvidia-container-runtime", "runtimeArgs": []}}
5. em seu YML docker-compose, você deve adicionar:
   runtime: nvidia

é isso aí !
implante usando o YML e você terá suporte para GPU em seu docker-compose

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

Nossa, todo esse tópico é sobre a versão 3, que não tem tempo de execução.

As versões 1.27.0+ mesclaram os formatos de arquivo v2 / v3, então agora é possível usar runtime qualquer lugar. Além disso, a especificação para aceleradores também foi encontrada (https://github.com/compose-spec/compose-spec/pull/100), embora ainda não tenha sido implementada em docker-compose .

Vou adicionar meus 2 centavos a este assunto ... Eu li muitos posts e finalmente a solução foi bem simples.

funcionou para mim com: (talvez um pouco mais baixo também teria funcionado - não faço ideia ...)
docker-compose versão 1.27.4, compilação 4052419

1. na máquina host docker instale os pacotes nvidia-container-toolkit e nvidia-container-runtime
2. na máquina docker host: digite
   nvidia-smi e examine a versão CUDA que aparece à direita
   
3. na máquina docker host: digite: (substitua a versão cuda pela que você instalou)
   docker run --rm --gpus all nvidia / cuda: nvidia-smi
   você deve obter a mesma saída de quando executou o nvidia-smi na máquina host
4. no arquivo /etc/docker/daemon.json você deve ver:
   "runtimes": {"nvidia": {"path": "/ usr / bin / nvidia-container-runtime", "runtimeArgs": []}}
5. em seu YML docker-compose, você deve adicionar:
   runtime: nvidia

é isso aí !
implante usando o YML e você terá suporte para GPU em seu docker-compose

Para sua informação, a versão cuda que você pode ver na saída de nvidia-smi refere-se à versão do driver nvidia cuda, também conhecido como seu driver nvidia (eles também o chamam de cuda, o que é confuso). O número da versão na imagem do docker, por exemplo, nvidia/cuda:10.1-base nvidia-smi refere-se à versão do kit de ferramentas da nvidia (novamente, o mesmo sistema de numeração de versão, bestas diferentes).

O driver é compatível com as versões anteriores do kit de ferramentas, então você pode executar qualquer nvidia/cuda:<version>-base nvidia-smi que desejar, desde que <version> seja menor ou igual à versão do driver.

Mais informações aqui: https://stackoverflow.com/questions/53422407/different-cuda-versions-shown-by-nvcc-and-nvidia-smi

Não vejo binários Docker Compose 1.27.4 disponíveis para sistema baseado em 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)

Olá @collabnix!

Qual é a saída de pip --version ?

O Compose 1.27 eliminou o suporte para Python 2, portanto, é possível que você não veja as versões 1.27.x se seu sistema tiver Python 2.

@collabnix porque você já tem o pip install --upgrade docker-compose

Agora posso atualizar para 1.27.4. A atualização do pip fez o truque. Obrigado @kshcherban e @ chris-crone
É uma loucura ver que a maioria dos projetos em que trabalhei no passado e que usam Python 2.7 realmente precisam de uma atualização.

Atualizar docker-compose para 1.27.4 resolveu o problema.
(pode ser atualizado para 1.19.3 mais tarde resolver o 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 bem com docker-compose.
no computador host, verifique o GPU usado pela nvidia-smi.

@ bttung-2020
@PyCod
Se eu usar o dokcer-nvidia-devel (não runtime): nvidia / cuda: 10.1-cudnn7-devel-ubuntu18.04 no docker-hub
É trabalho? Como devo editar o arquivo docker-compose.yaml?