Compose: Поддержка графических процессоров NVIDIA в Docker Compose

Созданный на 9 мая 2019  ·  160Комментарии  ·  Источник: docker/compose

В Docker 19.03.0 Beta 2 поддержка графического процессора NVIDIA была представлена ​​в виде нового API интерфейса командной строки --gpus. https://github.com/docker/cli/pull/1714 поговорим об этом включении.

Теперь можно просто передать параметр --gpus для приложения на основе Docker с ускорением на 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                                                 |
+-----------------------------------------------------------------------------+
:~$ 

На сегодняшний день Compose не поддерживает это. Это запрос функции для включения поддержки Compose для графического процессора NVIDIA.

kinenhancement statu0-triage

Самый полезный комментарий

Это насущная необходимость. Спасибо за ваши усилия!

Все 160 Комментарий

Это имеет повышенное значение сейчас, когда устаревшая 'nvidia runtime' кажется сломанной из-за Docker 19.03.0 и 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

Это работает: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Это не так: docker run --runtime=nvidia nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Работа над этим ведется?

Я получил новый Docker CE 19.03.0 на новом компьютере Ubuntu 18.04 LTS, у меня есть текущая и соответствующая версия NVIDIA Container Toolkit (née nvidia-docker2), но я не могу ее использовать, потому что docker-compose.yml 3.7 не поддерживает --gpus флаг.

Есть ли обходной путь для этого?

Это работает: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Это не так: docker run --runtime=nvidia nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Тебе нужно иметь

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

в вашем /etc/docker/daemon.json за --runtime=nvidia чтобы продолжить работу. Больше информации здесь .

пинг @KlaasH @ulyssessouza @Goryudyuma @ chris-crone. Есть новости по этому поводу?

Это насущная необходимость. Спасибо за ваши усилия!

Предполагается ли, что пользователь вручную заполняет /etc/docker/daemon.json после перехода на docker> = 19.03 и удаления nvidia-docker2 чтобы вместо этого использовать nvidia-container-toolkit ?

Похоже, это ломает много установок. Тем более, что --gpus недоступен в compose .

Нет, это работа, пока compose не поддерживает флаг gpus.

установить nvidia-docker-runtime:
https://github.com/NVIDIA/nvidia-container-runtime#docker -engine-setup
добавить в /etc/docker/daemon.json
{
"время выполнения": {
"nvidia": {
"путь": "/ usr / bin / nvidia-container-runtime",
"runtimeArgs": []
}
}
}

docker-compose:
время выполнения: nvidia
окружающая обстановка:
- NVIDIA_VISIBLE_DEVICES = все

Больше не существует такой вещи, как "/ usr / bin / nvidia-container-runtime". Проблема по-прежнему критическая.

это поможет запустить среду nvidia с docker-compose, пока не исправит docker-compose

установить nvidia-docker-runtime:
https://github.com/NVIDIA/nvidia-container-runtime#docker -engine-setup
добавить в /etc/docker/daemon.json
{
"время выполнения": {
"nvidia": {
"путь": "/ usr / bin / nvidia-container-runtime",
"runtimeArgs": []
}
}
}

docker-compose:
время выполнения: nvidia
окружающая обстановка:

  • NVIDIA_VISIBLE_DEVICES = все

Это не работает для меня, все еще получаю Unsupported config option for services.myservice: 'runtime' при попытке запустить docker-compose up

есть идеи?

Это не работает для меня, все еще получаю Unsupported config option for services.myservice: 'runtime' при попытке запустить docker-compose up

есть идеи?

после изменения /etc/docker/daemon.json перезапустите службу докеров
systemctl перезапустить докер
используйте формат Compose 2.3 и добавьте runtime: nvidia в службу GPU. Docker Compose должен быть версии 1.19.0 или выше.
файл docker-compose:
версия: '2.3'

Сервисы:
nvsmi:
изображение: ubuntu: 16.04
время выполнения: nvidia
окружающая обстановка:
- NVIDIA_VISIBLE_DEVICES = все
команда: nvidia-smi

@cheperuiz , вы можете установить nvidia в качестве среды выполнения по умолчанию в daemon.json и не будет зависеть от docker-compose. Но все ваши док-контейнеры будут использовать среду выполнения nvidia - пока у меня нет проблем.
{ "default-runtime": "nvidia", "runtimes": { "nvidia": { "path": "/usr/bin/nvidia-container-runtime", "runtimeArgs": [] } }, }

Ах! спасибо @Kwull , я пропустил эту default-runtime часть ... Теперь все работает :)

@uderik , runtime больше не присутствует ни в текущей схеме формата файла compose 3.7, ни в ожидаемой версии 3.8, которая в конечном итоге должна соответствовать Docker 19.03: https://github.com/docker/compose/blob/ 5e587d574a94e011b029c2fb491fb0f4bdeef71c / compose / config / config_schema_v3.8.json

@johncolby runtime никогда не был флагом 3.x. Он присутствует только в треке 2.x (2.3 и 2.4).

Да, я знаю, и хотя мой файл docker-compose.yml включает version: '2.3' (которые работали в прошлом), похоже, что последние версии игнорируются ...
Каким будет правильный способ включения / отключения доступа к графическому процессору для будущих проектов? просто сделать его переменными по умолчанию + env? или будет ли поддержка флага --gpus ?

@johncolby какая замена runtime в 3.X?

@ Daniel451 Я только что generic_resources , что-то вроде:

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

(из https://github.com/docker/cli/blob/9a39a1/cli/compose/loader/full-example.yml#L71-L74)
Документ дизайна здесь: https://github.com/docker/swarmkit/blob/master/design/generic_resources.md

Вот проблема создания, касающаяся поддержки схемы compose 3.8, которая уже объединена: https://github.com/docker/compose/issues/6530

На стороне демона возможность gpu может быть зарегистрирована путем включения ее в daemon.json или dockerd CLI (как в предыдущем жестко заданном временном обходном пути), что-то вроде

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

который затем регистрируется путем подключения к утилите NVIDIA docker:
https://github.com/moby/moby/blob/09d0f9/daemon/nvidia_linux.go

Похоже, что техника в основном на месте, наверное, просто нужно задокументировать ...

Есть обновления?

Также ждем обновлений, используя bash с docker run --gpus до официального исправления ...

Жду обновлений asw ell.

Тоже ждем обновлений :)

Хорошо ... Я не понимаю, почему это все еще открыто. Эти 3 дополнительные строки позволяют работать со схемой версии 3.7. Приятно знать, что docker реагирует на тривиальные проблемы сообщества. Итак, клонируйте это репо, добавьте эти три строки и python3 setup.py build && install и убедитесь, что ваш docker-compose.yml версии 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'),

Я просто добавил внутреннюю проблему, чтобы отслеживать это.
Помните, что пиарщики приветствуются: smiley:

Хорошо ... Я не понимаю, почему это все еще открыто. Эти 3 дополнительные строки позволяют работать со схемой версии 3.7. Приятно знать, что docker реагирует на тривиальные проблемы сообщества. Итак, клонируйте это репо, добавьте эти три строки и python3 setup.py build && install и убедитесь, что ваш docker-compose.yml версии 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'),

Я пробовал ваше решение, но получаю много ошибок по поводу этого флага:

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'

Нужен ли мне конкретный пакет python docker ?

@DarioTurchi Да, я встретил точную проблему. Похоже, нужно обновить и тип HostConfig.

Я не верю, что изменения, описанного @ruckc , достаточно, потому что docker-py также потребует изменений. И похоже, что необходимое изменение docker-py все еще продолжается. Глянь сюда:
https://github.com/docker/docker-py/pull/2419

Вот ветка с изменениями:
https://github.com/sigurdkb/docker-py/tree/gpus_parameter

Поэтому, если вы хотите исправить это сейчас, вам придется создать docker-compose против модифицированного docker-py из https://github.com/sigurdkb/docker-py/tree/gpus_parameter

Я не понимаю, что здесь происходит:

1) У меня есть в /etc/docker/daemon.json

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

но runtime ключ больше не может использоваться в v3.x как для https://github.com/docker/compose/issues/6239

Я также пробовал:

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

Поэтому я больше не могу запускать свои контейнеры с поддержкой gpu на 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

До этих изменений это работало, что мне теперь делать?

+1 будет очень полезно иметь такую ​​фичу в docker-compose!

Любая эта?

внутренне отслеживается как https://docker.atlassian.net/browse/COMPOSE-82

+1 была бы полезной функцией для docker-compose

Эта функция была бы отличным дополнением к docker-compose

Сейчас мое решение для этого заключается в использовании версии 2.3 файла docker-compose, которая поддерживает среду выполнения, и ручной установке nvidia-container-runtime (поскольку она больше не устанавливается с nvidia-docker).
Также я настраиваю конфигурации времени выполнения в /etc/docker/daemon.json (не по умолчанию, а только как доступное время выполнения).
При этом я могу использовать файл для создания файла как таковой:

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

Сейчас мое решение для этого заключается в использовании версии 2.3 файла docker-compose, которая поддерживает среду выполнения, и ручной установке nvidia-container-runtime (поскольку она больше не устанавливается с nvidia-docker).
Также я настраиваю конфигурации времени выполнения в /etc/docker/daemon.json (не по умолчанию, а только как доступное время выполнения).
При этом я могу использовать файл для создания файла как таковой:

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

@arruda Не daemon.json пожалуйста?

Сейчас мое решение для этого заключается в использовании версии 2.3 файла docker-compose, которая поддерживает среду выполнения, и ручной установке nvidia-container-runtime (поскольку она больше не устанавливается с nvidia-docker).
Также я настраиваю конфигурации времени выполнения в /etc/docker/daemon.json (не по умолчанию, а только как доступное время выполнения).
При этом я могу использовать файл для создания файла как таковой:

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

@arruda Не daemon.json пожалуйста?

Да нет проблем, вот оно:

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

Привет

У меня есть приложение, для которого требуются драйверы NVIDIA. Я создал образ докера на основе (FROM)
nvidia / cudagl: 10.1-время выполнения-ubuntu18.04

Используя рекомендованный выше подход - означает ли это, что мое изображение не обязательно должно быть получено из nvidia / cudagl: 10.1-runtime-ubuntu18.04 ? Т.е. я мог бы просто получить от (FROM) python: 3.7.3-stretch
и добавить runtime: nvidia в службу в docker-compose?

благодаря

@rfsch Нет, это другое дело. runtime: nvidia в docker-compose относится к среде выполнения Docker. Это делает графический процессор доступным для контейнера. Но вам по-прежнему нужен способ их использования, когда они станут доступны. runtime в nvidia/cudagl:10.1-runtime-ubuntu18.04 относится к компонентам времени выполнения CUDA. Это позволяет использовать графические процессоры (доступные в контейнере Docker) с помощью CUDA.

На этом изображении:

Docker architecture

runtime: nvidia заменяет часть runc / containerd. nvidia/cudagl:10.1-runtime-ubuntu18.04 полностью выходит за рамки картинки .

нам нужна эта функция

@ Daniel451 Я только что generic_resources , что-то вроде:

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

(из https://github.com/docker/cli/blob/9a39a1/cli/compose/loader/full-example.yml#L71-L74)
Документ дизайна здесь: https://github.com/docker/swarmkit/blob/master/design/generic_resources.md

Вот проблема создания, касающаяся поддержки схемы compose 3.8, которая уже объединена: # 6530

На стороне демона возможность gpu может быть зарегистрирована путем включения ее в daemon.json или dockerd CLI (как в предыдущем жестко заданном временном обходном пути), что-то вроде

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

который затем регистрируется путем подключения к утилите NVIDIA docker:
https://github.com/moby/moby/blob/09d0f9/daemon/nvidia_linux.go

Похоже, что техника в основном на месте, наверное, просто нужно задокументировать ...

Эй, @johncolby , я пробовал, но не смог:

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)

какие-либо предложения?

благодаря
Дэвид

Установка nvidia-container-runtime 3.1.4.1 с https://github.com/NVIDIA/nvidia-container-runtime и установка

runtime: nvidia

здесь отлично работает с docker-compose 1.23.1 и 1.24.1 установленными с https://docs.docker.com/compose/install/, с помощью этой хитроумной команды:

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

и, например, контейнер nvidia / cudagl / 10.1-base из dockerhub. Я пробовал рендеринг cuda и OpenGL, и все это почти нативно.

Отслеживается внутри как COMPOSE-82
Обратите внимание, что такое изменение также необходимо реализовать в docker stack (https://github.com/docker/cli/blob/master/cli/compose/types/types.go#L156) для согласованности

Установка nvidia-container-runtime 3.1.4.1 с https://github.com/NVIDIA/nvidia-container-runtime и установка

runtime: nvidia

здесь отлично работает с docker-compose 1.23.1 и 1.24.1 установленными с https://docs.docker.com/compose/install/, с помощью этой хитроумной команды:

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

и, например, контейнер nvidia / cudagl / 10.1-base из dockerhub. Я пробовал рендеринг cuda и OpenGL, и все это почти нативно.

вы можете поделиться своим docker-compose.yml?

эй, @ jdr-face,

вот мой тест после вашего предложения, установив nvidia-container-runtime на хост-машине.

version: '3.0'

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

он все еще дает ошибку:

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

@ david- gwa, как ранее отмечал

runtime никогда не был флагом 3.x. Он присутствует только в треке 2.x (2.3 и 2.4).

@ david-gwa

вы можете поделиться своим 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

В зависимости от ваших потребностей некоторые из этих опций могут оказаться ненужными. Как и предсказывал

спасибо, ребята, @ jdr-face, @muru , compose v2 действительно работает,
Я неправильно понял ваше решение для v3 compose.

Для справки, традиционно говоря: compose v2 не старше compose v3. Это разные варианты использования. v3 ориентирован на рой, а v2 - нет. v1 устарела.

Обсуждается ли поддержка Docker-compose для поддержки встроенного GPU в Docker?

Поддержка опции runtime не является решением для поддержки GPU в будущем. NVIDIA описывает будущее nvidia-docker2 в https://github.com/NVIDIA/nvidia-docker следующим образом.

Обратите внимание, что с выпуском Docker 19.03 использование пакетов nvidia-docker2 не рекомендуется, поскольку графические процессоры NVIDIA теперь изначально поддерживаются как устройства в среде выполнения Docker.

В настоящее время поддержка графического процессора может быть реализована путем изменения среды выполнения, но весьма вероятно, что это не будет работать в будущем.

Откровенно говоря, возможно, это не лучшая практика, но как-то мы заставляем ее работать.

Сложность заключается в том, что мы должны придерживаться docker-compose v3.x, поскольку мы используем docker swarm, а тем временем мы хотим использовать Nvidia Runtime для поддержки GPU / CUDA в контейнерах.

Чтобы избежать явного указания Nvidia Runtime внутри файла docker-compose, мы установили Nvidia в качестве среды выполнения по умолчанию в /etc/docker/daemon.json , и это будет выглядеть так:

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

Таким образом, все контейнеры, работающие на машинах с графическим процессором, по умолчанию будут включать среду выполнения Nvidia.

Надеюсь, это поможет кому-нибудь столкнуться с подобным блокировщиком

Откровенно говоря, возможно, это не лучшая практика, но как-то мы заставляем ее работать.

Сложность заключается в том, что мы должны придерживаться docker-compose v3.x, поскольку мы используем docker swarm, а тем временем мы хотим использовать Nvidia Runtime для поддержки GPU / CUDA в контейнерах.

Чтобы избежать явного указания Nvidia Runtime внутри файла docker-compose, мы установили Nvidia в качестве среды выполнения по умолчанию в /etc/docker/daemon.json , и это будет выглядеть так:

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

Таким образом, все контейнеры, работающие на машинах с графическим процессором, по умолчанию будут включать среду выполнения Nvidia.

Надеюсь, это поможет кому-нибудь столкнуться с подобным блокировщиком

Это действительно то, что мы делаем. На данный момент это работает, но мне кажется немного взломанным. Надеемся на полную поддержку compose-v3 в ближайшее время. :)

Предполагается ли, что пользователь вручную заполняет /etc/docker/daemon.json после перехода на docker> = 19.03 и удаления nvidia-docker2 чтобы вместо этого использовать nvidia-container-toolkit ?

Похоже, это ломает много установок. Тем более, что --gpus недоступен в compose .

--gpus недоступен в Compose
Я не могу использовать pycharm, чтобы связать докер для запуска tensorflow-gpu

Есть новости по этой проблеме? Есть ли шанс, что --gpus скоро будет поддерживаться в docker-compose?

Для тех из вас, кто ищет обходной путь, вот что мы в итоге сделали:

А затем запустите COMPOSE_API_VERSION=auto docker-compose run gpu со следующим файлом:

version: '3.7'

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

В Docker 19.03.0 Beta 2 поддержка графического процессора NVIDIA была представлена ​​в виде нового API интерфейса командной строки --gpus. docker / cli # 1714 поговорить об этом включении.

Теперь можно просто передать параметр --gpus для приложения на основе Docker с ускорением на 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                                                 |
+-----------------------------------------------------------------------------+
:~$ 

На сегодняшний день Compose не поддерживает это. Это запрос функции для включения поддержки Compose для графического процессора NVIDIA.

Я решил эту проблему , вы можете попробовать следующее, мой адрес блога csdn: https://blog.csdn.net/u010420283/article/details/104055046

~ $ sudo apt-get установить nvidia-container-runtime
~ $ sudo vim /etc/docker/daemon.json

затем в этот файл daemon.json добавьте это содержимое:

{
"время выполнения по умолчанию": "nvidia"
"время выполнения": {
"nvidia": {
"путь": "/ usr / bin / nvidia-container-runtime",
"runtimeArgs": []
}
}
}

~ $ sudo systemctl демон-перезагрузка
~ $ sudo systemctl перезапустить докер

Для пользователей ansible, которые хотят настроить описанный ранее обходной путь, есть роль для установки nvidia-container-runtime и настройки /etc/docker/deamon.json для использования runtime: nvidia :

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

(по какой-то причине он работает только на Ubuntu и RHEL, но его довольно легко изменить. Я запускаю его на Debian)

Затем в вашем docker-compose.yml :

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

какое-либо обновление официальной версии 3.x с поддержкой графического процессора? Нам нужен рой :)

Есть ли планы добавить эту функцию?

Эта функция зависит от того, как docker-py реализует параметры device_requests , что и переводит --gpus . Было сделано несколько запросов на добавление этой функции (https://github.com/docker/docker-py/pull/2419, https://github.com/docker/docker-py/pull/2465, https: / /github.com/docker/docker-py/pull/2471), но никакой реакции со стороны сопровождающих нет. # 7124 использует https://github.com/docker/docker-py/pull/2471, чтобы предоставить его в Compose, но по-прежнему никто не отвечает.

Как я уже упоминал в №7124, я более чем счастлив сделать PR более совместимым, но поскольку ему уделяется очень мало внимания, я не хочу тратить свое время на то, что не будет объединено ...

Пожалуйста, добавьте эту функцию, будет круто!

Пожалуйста, добавьте эту функцию! Я был более чем доволен старой версией nevidia-docker2, которая позволила мне изменить время выполнения в daemon.json. Было бы очень приятно получить это обратно.

Это нужно, пожалуйста. Действительно нужно: /

Я бы тоже хотел накапливать ... нам нужна эта функция!

Мне нужно запустить контейнеры ЦП и ГП на одном компьютере, поэтому взлом времени выполнения по умолчанию у меня не работает. Есть ли у нас идеи, когда это будет работать на compose? Учитывая, что у нас нет флага времени выполнения в compose, это представляет собой серьезное снижение функциональности, не так ли? Мне нужно писать сценарии, чтобы это работало - фу!

Мне нужно запустить контейнеры ЦП и ГП на одном компьютере, поэтому взлом времени выполнения по умолчанию у меня не работает. Есть ли у нас идеи, когда это будет работать на compose? Учитывая, что у нас нет флага времени выполнения в compose, это представляет собой серьезное снижение функциональности, не так ли? Мне нужно писать сценарии, чтобы это работало - фу!

вы можете сделать это с помощью docker cli (docker run --gpu ....), у меня есть такой трюк (добавив прокси, чтобы иметь возможность общаться с другими контейнерами, работающими на других узлах в рое). Мы все ждем возможности запустить его в swarm, потому что он не работает ни с помощью команды docker service (насколько я знаю), ни с помощью compose.

@dottgonzo . Ну да ;-). Я знаю об этом и, следовательно, ссылку на скрипты. Но это довольно ужасный и непереносимый способ сделать это, поэтому я хотел бы сделать это более динамичным способом. Как я уже сказал, я думаю, что это регресс, а не вопрос функции.

COMPOSE_API_VERSION=auto docker-compose run gpu

@ggregoire, где мы запускаем: COMPOSE_API_VERSION = auto docker-compose run gpu?

@joehoeller из вашей оболочки - это то, что вы сделали бы для любой другой команды.

Прямо сейчас мы решаем для каждого проекта, нужны ли нам функции 3.x или мы можем использовать docker-compose 2.x, где все еще поддерживается опция GPU. Такие функции, как запуск многоступенчатых целей из файла Docker, к сожалению, нельзя использовать, если требуется графический процессор. Пожалуйста, добавьте это снова!

Я хотел бы порекомендовать что-то вроде поля «дополнительные параметры» для docker-compose, где мы можем просто добавить флаги, такие как --gpus=all в команду docker start / run, которые еще / больше не поддерживаются в docker-compose но находятся в последней версии докера. Таким образом, пользователям Compose не придется ждать, пока docker-compose наверстает упущенное, если им понадобится новая, еще не поддерживаемая функция docker.

По-прежнему необходимо запускать это в Docker Swarm для производственных сред. Будет ли это полезно для Docker Swarm?

@sebastianfelipe Это очень полезно, если вы хотите развернуть свой рой с помощью compose.
Сравните:
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\"

к чему-то вроде этого

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

@sebastianfelipe Это очень полезно, если вы хотите развернуть свой рой с помощью compose.
Сравните:
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\"

к чему-то вроде этого

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

Извините, так он уже работает с Docker Swarm с использованием yaml-файла docker-compose? На всякий случай: О. Благодаря!

только для docker compose 2.x

Вся суть этой проблемы заключается в том, чтобы запросить поддержку nvidia-docker gpu для docker-compose 3+

С момента первоначального запроса прошел почти год !! Почему задержка ?? Можем ли мы продвинуться вперед?

пинг @KlaasH @ulyssessouza @Goryudyuma @ chris-crone. Есть новости по этому поводу?

Для тех из вас, кто ищет обходной путь, вот что мы в итоге сделали:

  • Установите docker-py из этого PR: docker / docker-py # 2471
  • Установите docker-compose из этого PR: # 7124

А затем запустите COMPOSE_API_VERSION=auto docker-compose run gpu со следующим файлом:

version: '3.7'

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

Для тех из вас, кто так же нетерпелив, как и я, вот простая pip install версия вышеуказанного обходного пути:

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

Огромное спасибо @yoanisgil !
Все еще с нетерпением жду официального патча. При наличии всех PR это не кажется трудным по любым стандартам.

пинг @KlaasH @ulyssessouza @Goryudyuma @ chris-crone. Есть новости по этому поводу?

Нет, я не знаю, почему меня позвали.
Я хочу, чтобы ты сказал мне, что мне делать?

Я надеюсь, что есть обновления по этому поводу.

Ага, уже больше года прошло ... почему они не сливаются в докер-ру ...

Я не уверен, что предлагаемые реализации подходят для формата Compose. Хорошей новостью является то, что мы открыли спецификацию формата Compose с намерением добавить такие вещи. Вы можете найти спецификацию на https://github.com/compose-spec.

Я бы посоветовал нам добавить проблему в спецификацию, а затем обсудить ее на одном из предстоящих собраний сообщества Compose (ссылка для приглашения внизу этой страницы ).

Это работает: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi
Это не так: docker run --runtime=nvidia nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Тебе нужно иметь

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

в вашем /etc/docker/daemon.json за --runtime=nvidia чтобы продолжить работу. Больше информации здесь .

Dockerd не запускается с этого daemon.json

Господи, на это уйдут годы: @

Это работает: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi
@deniswal : Да, мы это знаем, но мы спрашиваем о функциональности компоновки.

@ chris-crone: Я запутался: это регресс от прежнего поведения, зачем ему новая спецификация функции? Разве не разумно запускать контейнеры, некоторые из которых используют GPU, а некоторые - CPU, на одном физическом устройстве?

Спасибо за внимание.

@ vk1z AFAIK Docker Compose никогда не поддерживал GPU, так что это не регресс. Та часть , которая нуждается в дизайне, как объявить нуждающийся сервис для GPU (или другого устройства) в Compose Формат- конкретно меняется , как это . После этого все должно быть просто подключено к бэкэнду.

Привет, ребята, я пробовал несколько предложенных здесь решений, и у меня ничего не получилось, например,
У меня i7 с оперативной памятью 16 ГБ, но сборка некоторых проектов занимает слишком много времени, моя цель - также использовать мощность графического процессора для ускорения процесса, возможно ли это? Благодаря!

@ chris-crone: Опять же, я хочу, чтобы меня исправили, но разве это не из-за того, что параметр runtime: исчез из compose после конфигурации 2.4? Вот почему я чувствовал, что это регресс. Но нет, теперь это не важно, ведь мы все должны быть на 3.x.

Я был бы рад сообщить о проблеме, мы делаем это в соответствии со спецификацией в репозитории спецификаций, правильно?

но не потому ли, что параметр runtime: исчез из compose после конфигурации 2.4? Вот почему я чувствовал, что это регресс.

Да, точно. У меня есть несколько проектов, в которых мы полагаемся на использование runtime: nvidia в наших файлах docker-compose, и эта проблема не позволяет нам перейти на 3.x, потому что мы не нашли способ использовать там графические процессоры.

Привет, пожалуйста, пожалуйста, исправьте это.
Это должно быть отмечено критически важным приоритетом -20.

Опять же, я хотел бы, чтобы меня исправили, но разве это не потому, что параметр runtime: исчез из состава после конфигурации 2.4? Вот почему я чувствовал, что это регресс. Но нет, теперь это не важно, ведь мы все должны быть на 3.x.

Меня не было здесь, когда было внесено изменение, поэтому я не уверен на 100%, почему оно было отменено. Я знаю , что вы не нуждаетесь в среде выполнения NVIDIA для графических процессоров используют больше и что мы развиваемся при компоновке v3 спецификации в открытой здесь с целью создания единой версии спецификации. Это может означать перенос некоторых функций v2 в v3.

Что касается поля runtime , я не думаю, что это то, как его следует добавлять в спецификацию Compose, поскольку оно очень специфично для работы на одном узле. В идеале нам нужно что-то, что позволило бы вам указать, что ваша рабочая нагрузка требует устройства (например, GPU, TPU, что угодно, что будет дальше), а затем позволить оркестратору назначить рабочую нагрузку узлу, который предоставляет эту возможность.

Это обсуждение должно касаться спецификации, поскольку она не относится к Python Docker Compose.

@ chris-crone: Я в основном согласен с вашим утверждением. Добавление краткосрочных хаков, вероятно, является неправильным способом сделать это, поскольку у нас есть множество граничных устройств, каждое из которых имеет собственное время выполнения. Например, как вы указываете, TPU (Google), VPU (Intel) и ARM GPU на Pi. Так что нам действительно нужна более полная история.

Я сообщу о проблеме со спецификацией сегодня и обновлю эту ветку, как только сделаю это. Однако я считаю, что оркестратор должен быть независимым - например, если я хочу использовать Kube, я должен уметь это делать. Я предполагаю, что это будет в рамках.

Однако я не согласен с оператором using GPUs, поскольку он не работает с compose - вот о чем идет речь. Но я думаю, все мы понимаем, какую проблему хотим решить.

@ chris-crone: см. проблему со спецификацией docker-compose. С этого момента я буду следить за обновлениями по этой проблеме.

Можем ли мы просто добавить параметр (что-то вроде extra_docker_run_args ) для передачи аргументов непосредственно в базовый docker run ? Это не только решит текущую проблему, но и обеспечит перспективу: что, если докер добавит поддержку любых «XPU», «YPU» или любых других новых функций, которые могут появиться в будущем?

Если нам нужно долгое обсуждение взад и вперед каждый раз, когда докер добавляет новую функцию, это будет крайне неэффективно и вызовет неизбежную задержку (и ненужную путаницу) между обновлениями docker-compose и docker . Поддержка делегирования аргументов может временно решить эту повторяющуюся проблему для всех будущих функций.

@miriaford Я не уверен, что передача неинтерпретируемого BLOB-объекта поддерживает декларативное представление compose. Старый тег времени выполнения, по крайней мере, указывал, что это как-то связано со средой выполнения. Учитывая направление, в котором развивается докер (docker-apps), мне кажется, что это усложнит декларативное развертывание, поскольку оркестратору придется анализировать произвольные капли.

Но я согласен с тем, что compose и docker должны быть синхронизированы, и отключение рабочих функций, от которых зависят люди (даже если это был основной выпуск), не совсем кошерный.

@ vk1z Я согласен - должен быть гораздо лучший механизм синхронизации между compose и docker . Однако я не ожидаю, что в ближайшее время будет разработан такой механизм. Между тем нам также нужен временный способ выполнить нашу собственную синхронизацию без глубокого взлома исходного кода.

Если предложение о делегировании аргументов невозможно, что мы предлагаем делать? Я согласен, что это не очень хорошее решение, но оно, по крайней мере, намного лучше, чем этот обходной путь, не так ли? https://github.com/docker/compose/issues/6691#issuecomment -616984053

@miriaford docker-compose не вызывает исполнителя докера с аргументом, он фактически использует docker_py, который использует http API для демона докера. Таким образом, нет никакой "базовой docker run " команды. Интерфейс командной строки докера - это не API, соединение сокета - это точка контакта API. Вот почему это не всегда так просто.

Чтобы упростить задачу, в процессе запуска докера есть два основных вызова: один создает контейнер, а другой запускает его, каждый из которых принимает разные фрагменты информации, и для определения того, какой из них, требуется кто-то, обладающий знаниями API, что Не знаю, как мы привыкли знать docker CLI. Я не думаю, что возможность добавлять дополнительные аргументы к вызовам docker_py будет столь же полезной, как вы думаете, за исключением некоторых случаев использования.

Что еще более усложняет задачу, иногда библиотека docker_py находится за API и не имеет сразу всего, что вам нужно, и вам нужно дождаться ее обновления. При этом extra_docker_run_args - не простое решение.

@andyneff Спасибо за ваше объяснение. В самом деле, я не слишком хорошо знаком с внутренним устройством Docker. Если я правильно понимаю, есть 4 API, которые необходимо синхронизировать вручную для любых обновлений новых функций:

  1. Docker socket API
  2. docker_py который предоставляет интерфейс Python для API сокетов
  3. Docker CLI (наша знакомая точка входа в набор инструментов Docker)
  4. Интерфейс Docker-compose, который вызывает API сокетов докеров

Напрашивается вопрос: почему нет автоматического (или хотя бы полуавтоматического) механизма синхронизации? Распространение обновлений новых функций вручную через 4 API кажется обреченным быть подверженным ошибкам, задержкам и запутанным ...

PS Я не говорю, что автоматическая синхронизация _ простая_ задача, но я действительно думаю, что она должна быть, чтобы облегчить жизнь в будущем.

Я сейчас как бы вхожу в педантику ... Но я бы описал это как ...

  • Докер-сокет - это официальный API для докеров. Часто это файловый сокет, но также может быть TCP (или любой другой, я полагаю, используя socat )
  • docker CLI использует этот API, чтобы дать нам пользователям отличный инструмент

    • Docker пишет API и CLI, поэтому они всегда синхронизируются во время выпуска. (Я думаю, можно с уверенностью сказать, что CLI - первоклассный гражданин экосистемы докеров)

  • Библиотека docker_py берет этот API и помещает его в замечательную библиотеку, которую могут использовать другие библиотеки Python. Без этого вы бы сами выполняли все эти HTTP-вызовы и рвали бы за волосы.

    • Однако docker_py был запущен как сторонняя библиотека, и поэтому он традиционно отслеживал API-интерфейс докеров и добавлял вещи позже или по мере необходимости (ограниченные ресурсы).

  • compose использует версию docker_py, а затем добавляет все эти замечательные функции, снова по мере необходимости (на основе таких же проблем)

    • Однако compose мало что может сделать, пока docker_py (я не говорю, что это задерживает эту проблему, я не знаю, я просто говорю в целом)

Так что да, это идет:

  • "составить yaml + составить аргументы" -> "docker_py" -> "docker_api"
  • И CLI не является частью этого (и поверьте мне, это правильный способ делать что-то)

Я не могу говорить о docker_py или compose, но я полагаю, что у них есть ограниченное количество человеко-часов, способствующих этому, поэтому труднее не отставать от ВСЕХ сумасшедших безумных функций докеров, которые docker ПОСТОЯННО добавляет. Но поскольку docker - это библиотека go, и я понимаю, что поддержка python (в настоящее время) не является первоклассным гражданином. Хотя приятно, что оба проекта находятся под зонтиком докеров, по крайней мере, с точки зрения организации github.


Итак, все сказано ... Я тоже жду эквивалентной поддержки --gpus и должен вместо этого использовать старый метод runtime: nvidia , который, по крайней мере, даст мне "путь" для перемещения вперед в docker-compose 2.x.

@andyneff К вашему сведению, в последней версии docker-compose есть поддержка Docker CLI. Это позволяет, например, использовать buildkit. https://www.docker.com/blog/faster-builds-in-compose-thanks-to-buildkit-support/

@andyneff, это очень полезный обзор! еще раз спасибо

@lig классный ! Спасибо за исправление! Я на самом деле думал: "Каким образом buildkit впишется во все это", когда писал это

Что меня немного удивляет, так это то, что docker-compose является неотъемлемой частью новой платформы docker-app, и я предполагаю, что они захотят синхронизировать docker-compose и docker хотя бы по этой причине. Интересно, что такое блокировщик на самом деле: недостаточно пропускной способности Python? Кажется немного невероятным.

Итак, как Docker Swarm вписывается в структуру, которую только что описал docker ?

Приносим извинения, если это не по теме для данной конкретной проблемы. Я скорее потерял понимание, какая проблема есть какая, но я начал следить за этим, потому что я хотел бы иметь возможность сообщить службе, работающей в рое, что ей необходимо использовать определенную среду выполнения. Мы можем сделать это только с v2 спецификации compose-file, что означает, что мы не можем сделать это с помощью Swarm, для которого требуется v3. Другими словами, меня не очень интересует, что делает CLI docker-compose, а интересует только спецификация, определенная для файлов docker-compose.yml, которые используются docker swarm.

О, рой, тот, что сбежал ... (от меня). К сожалению, это номер 6239, который закрыл бот. :( Кто-то пробовал в # 6240, но ему сказали, что ...

@miriaford , похоже, есть пиар за их синхронизацию! # 6642 ?! (Это только для v3 ???)


Итак, из-за природы роя есть определенные вещи, которые вы делаете и не делаете на узлах роя. Таким образом, Docker API не всегда позволяет выполнять те же параметры при запуске роя, что и при обычном запуске. Я не знаю, является ли среда выполнения одной из этих вещей, но часто именно поэтому вы не можете делать что-то в v3 (версия, совместимая с роем) и можете в v2 (версия, не совместимая с роем).

Никто, читающий это, не знает, о чем вы, ребята.
Мы все пытаемся развернуть jellyfin с аппаратным ускорением.
Пока вы, ребята, не исправите это так, как должно быть, когда он говорит service, 3.x не годится.
Не используйте это.

Нужно поставить 2.4 на сервис.
Затем вы можете использовать аппаратное ускорение для jellyfin, ez

Так что давай, ребята, какое расчетное время прибытия на этот раз, 1 год, 2 года?

@KlaasH @ulyssessouza @Goryudyuma @ chris-crone Привет, я работаю над этой проблемой, я обнаружил, что поддержка отсутствует в "docker-py", работал над этой частью. Теперь, чтобы заставить его работать, мне нужно передать конфигурации через файл docker-compose.yml. Вы можете помочь мне со схемой? т.е. для того, чтобы добавить его, я должен добавить его в новую схему или есть какое-нибудь место, где могут быть переданы конфигурации

@fakabbir Я бы предположил, что для этого можно просто использовать COMPOSE_DOCKER_CLI_BUILD . Добавление возможности предоставлять произвольный список аргументов docker run может даже помочь избежать подобных проблем в будущем.

@lig как поступить, когда доступ к графическому процессору требуется только для одной службы?

@lig AFAICS compose использует docker-py вместо docker run cli. Таким образом, добавление произвольных аргументов docker run не будет работать, если docker-py поддерживает его.

ссылка: https://github.com/docker/compose/issues/6691#issuecomment -585199425

Эта единственная вещь сильно снижает полезность docker-compose для многих людей. То, что он не получил особого внимания и желания исправить это, особенно когда он работал в старой версии docker-compose, довольно удивительно.
Разве нельзя было бы разрешить произвольные аргументы docker --run в файле docker-compose? Затем --gpus all, например, можно передать докеру.

Я понимаю, что могут быть философские или технические причины, по которым кто-то может захотеть сделать это определенным образом. Но то, что вы не возьмете руки и не сделаете это НИКАКИМ образом, потрясает разум.

@lig как поступить, когда доступ к графическому процессору требуется только для одной службы?

Ну, переменная среды NVIDIA_VISIBLE_DEVICES позволит вам контролировать, что нет?

Эта единственная вещь сильно снижает полезность docker-compose для многих людей. То, что он не получил особого внимания и желания исправить это, особенно когда он работал в старой версии docker-compose, довольно удивительно.
Разве нельзя было бы разрешить произвольные аргументы docker --run в файле docker-compose? Затем --gpus all, например, можно передать докеру.

Я не думаю, что разрешить передачу docker --run args - это выход. compose самом деле не вызывает docker отдельно, а вместо этого использует docker-py .

Я понимаю, что могут быть философские или технические причины, по которым кто-то может захотеть сделать это определенным образом. Но то, что вы не возьмете руки и не сделаете это НИКАКИМ образом, потрясает разум.

Об этом открыто пиарщик: https://github.com/docker/compose/pull/7124. Пожалуйста, не стесняйтесь «брать его в свои руки».

Я считаю, что согласно изменениям в спецификации docker compose , мы должны скоро вернуться к более ранней совместимости согласно compose 2.4, и тогда среда выполнения nvidia будет работать. Очевидно, что это не будет работать с TPU или другими ускорителями - что очень прискорбно, но для тех, кто хочет запускать (дорогой) nvidia gpus, он будет работать.

Так что просто ждем, когда зеленый PR в docker-py будет объединен https://github.com/docker/docker-py/pull/2471

ДА УЖ! PR на докер-ру утвержден! https://github.com/docker/docker-py/pull/2471
Какой следующий шаг здесь?

Что здесь? Было бы здорово иметь возможность поддерживать среду выполнения nvidia в docker-compose

Теперь, когда docker / docker-py # 2471 объединен, мы можем установить docker-py из мастера. Но поскольку docker-compose изменился с момента крутого [PR]

Для тех, кто оказался здесь, не увидев предыдущих комментариев:

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

Затем используйте следующий шаблон в своем файле создания. (источник: комментарий ):

А затем запустите COMPOSE_API_VERSION=auto docker-compose run gpu со следующим файлом:

version: '3.7'

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

Я подтверждаю, что это сработало на моем локальном компьютере. Не знаю, что это работает с Swarm.

Не может быть конкретной фиксации docker-compose в производстве. Нужно ли перебазировать # 7124 или есть еще один PR, который будет включать новый docker-py ?

Привет @bkakilli ,

Спасибо за помощь! Я только что попробовал ваше предложение, но получаю сообщение об ошибке при запуске docker-compose

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

_analysis - имя моего контейнера_

Я изменил свой docker-compose.yml с:

version: '2.3'

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

кому:

version: '3.7'

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

Есть ли что-нибудь еще, кроме pip install git+ чтобы правильно это настроить? А может я плохо отредактировал файл конфигурации?

@frgfm убедитесь, что вы устанавливаете compose и docker-py по правильным ссылкам. Возможно, вы использовали собственное репо docker-compose вместо вилки (и ветки) yoanisgil. Посмотрите, используете ли вы следующую ссылку:

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

Вы можете попробовать установить --upgrade param для установки pip. В противном случае я бы заподозрил настройки виртуальной среды. Может быть, у вас есть другая установка docker-compose, которая используется по умолчанию? Например, вы могли установить его для системы с помощью инструкций "Linux" здесь: https://docs.docker.com/compose/install/. Я предлагаю вам взглянуть на «Альтернативные варианты установки» и установить через pip в виртуальной среде (но используйте команду pip install выше. Не устанавливайте docker-compose по умолчанию из PyPI).

Привет!
Спасибо за всю информацию. Я пытался запустить ваш подход @bkakilli, и docker-compose build работал, но при запуске docker-compose up я получил ошибку:
docker.errors.InvalidVersion: device_requests param is not supported in API versions < 1.40

Мой docker_compose.yml выглядит так:

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

Заранее спасибо!

@ugmSorcero Установите переменную окружения COMPOSE_API_VERSION=1.40 затем повторно запустите свои команды

@ugmSorcero вам удалось исправить эту ошибку? @EpicWink @bkakilli Я использую версию, указанную при установке пакета, но все равно получаю сообщение об ошибке device_requests param is not supported in API versions < 1.40 даже если я экспортирую такую ​​переменную в 1.40

Для данного составного файла

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

Используя версию docker-compose установленную, как указано выше, в Bash для Linux успешно выполняет следующую команду:

COMPOSE_API_VERSION=1.40 docker-compose up

Следующая команда не работает:

docker-compose up

Это вывод ошибки:

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 большое спасибо. Я не понимал, что docker-compose up должно быть выполнено таким образом. Я воспринял это как 2 шага, когда сначала я экспортировал COMPOSE_API_VERSION отдельно. Работать вместе, кажется, работает :)

Но у меня есть другая проблема. Если я запустил COMPOSE_API_VERSION=1.40 docker-compose run nvidiatest то nvidia-smi не будет найден в пути, а если я запустил прямо из изображения, проблем не возникнет.

Вот как я это воспроизвожу.

Локальный файл docker-compose содержит:

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

Если я запустил свою текущую настройку (обе версии api auto и 1.40), я получаю следующую ошибку:

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

Возможно ли, что это связано с использованием файлов переопределения? Если я просто запустил базовый образ cuda с помощью Docker, не возникнет проблем с получением вывода из 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      |
|=============================================================================|
+-----------------------------------------------------------------------------+

Я установил docker-compose следуя приведенным выше инструкциям из git, после удаления версии, установленной из официальных документов. Вот информация об установленной версии:

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

Я что-нибудь упускаю? Спасибо за помощь!

@jjrugui, это становится не по теме, и я не могу воспроизвести вашу проблему. Извините за то, что не смог помочь

@EpicWink не проблема, извините за отклонение от темы :). Если я выясню свою конкретную проблему, я опубликую ее здесь, если она актуальна.

Кто-то работает над другим PR, или мы отлаживаем ветку device-requests , чтобы подготовиться к PR?

Пока PR застрял, я перенес изменения с # 7124 на последнюю версию из ветки master чтобы сопоставить зависимости и т. Д. - https://github.com/beehiveai/compose Вы можете установить с помощью pip install git+https://github.com/beehiveai/compose.git и измените версию в docker-compose.yml на 3.8 :

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

В этой настройке все работает как положено.

Как обсуждалось вчера на совещании по вопросам управления составлением спецификации , мы начнем работу над предложением принять что-то сопоставимое с # 7124, которое может быть близко к generic_resouces уже доступному в разделе deploy .

@ndeloof Это здорово! Если есть возможность, разместите ссылку на предложение здесь. Я думаю, что многие люди будут счастливы внести свой вклад в это, поскольку поддержка графического процессора имеет решающее значение для развертываний глубокого обучения.

@ndeloof исторически, сколько времени требуется руководящему комитету для принятия решения, 6 месяцев, год?

+1

+1

@visheratin Есть ли шанс, что вы можете улучшить свое исправление, чтобы оно

@proximous Что вы имеете в виду под "выпадает из

Возникла проблема с кодом в compose / service.py при попытке использовать параметр --scale с docker-compose up. Это не поддерживается?

Отслеживание (последний вызов последний):
Файл "/ usr / local / bin / docker-compose", строка 11, в
load_entry_point ('docker-compose == 1.27.0.dev0', 'console_scripts', 'docker-compose') ())
Файл "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", строка 67, в основном
команда ()
Файл "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", строка 123, в perform_command
обработчик (команда, параметры_команды)
Файл "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", строка 1067, вверху
to_attach = up (Ложь)
Файл "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", строка 1063, вверху
cli = native_builder,
Файл "/usr/local/lib/python3.6/site-packages/compose/project.py", строка 648, вверху
get_deps,
Файл "/usr/local/lib/python3.6/site-packages/compose/parallel.py", строка 108, в parallel_execute
поднять error_to_reraise
Файл "/usr/local/lib/python3.6/site-packages/compose/parallel.py", строка 206, у производителя
результат = функция (объект)
Файл "/usr/local/lib/python3.6/site-packages/compose/project.py", строка 634, в do
override_options = override_options,
Файл "/usr/local/lib/python3.6/site-packages/compose/service.py", строка 579, в execute_convergence_plan
Renew_anonymous_volumes,
Файл "/usr/local/lib/python3.6/site-packages/compose/service.py", строка 509, в _execute_convergence_recreate
масштаб - len (контейнеры), отдельный, начало
Файл "/usr/local/lib/python3.6/site-packages/compose/service.py", строка 479, в _execute_convergence_create
"Создание"
Файл "/usr/local/lib/python3.6/site-packages/compose/parallel.py", строка 108, в parallel_execute
поднять error_to_reraise
Файл "/usr/local/lib/python3.6/site-packages/compose/parallel.py", строка 206, у производителя
результат = функция (объект)
Файл "/usr/local/lib/python3.6/site-packages/compose/service.py", строка 477, в
лямбда имя_службы: create_and_start (self, service_name.number),
Файл "/usr/local/lib/python3.6/site-packages/compose/service.py", строка 456, в create_and_start
container = service.create_container (число = n, quiet = True)
Файл "/usr/local/lib/python3.6/site-packages/compose/service.py", строка 333, в create_container
предыдущий_контейнер = предыдущий_контейнер,
Файл "/usr/local/lib/python3.6/site-packages/compose/service.py", строка 936, в _get_container_create_options
one_off = one_off)
Файл "/usr/local/lib/python3.6/site-packages/compose/service.py", строка 1014, в _get_container_host_config
element.split (',') для элемента в device_request ['возможности']]
Файл "/usr/local/lib/python3.6/site-packages/compose/service.py", строка 1014, в
element.split (',') для элемента в device_request ['возможности']]
AttributeError: объект 'list' не имеет атрибута 'split'

После дальнейшей отладки я обнаружил, что при использовании --scale по какой-то причине один экземпляр имеет device_requests ['features'] как ['gpu']. Но для запуска всех других контейнеров device_request ['features'] вместо этого выглядит как [['gpu']].

Я сделал временное исправление локально, чтобы обойти эту проблему, просто чтобы мои контейнеры заработали, начиная со строки 1010 в compose / service.py:

``
для device_request в device_requests:
если "возможностей" нет в device_request:
Продолжить
если тип (device_request ['возможности'] [0]) == список:
device_request ['возможности'] = [
element.split ('.') для элемента в device_request ['features'] [0]]
еще:
device_request ['возможности'] = [
element.split ('.') для элемента в device_request ['features']]

`` ''

@proximous Что вы имеете в виду под "выпадает из

@visheratin посмотрите этот пример, я ошибаюсь, ожидая другого результата?

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

используйте только nogpu.yml:

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

используйте только 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, начинающаяся с yml, отличного от gpu (примечание ... отсутствует среда выполнения):

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

ожидаемый результат:

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

(Очевидно, я пытаюсь придумать что-то более сложное, и это просто упрощенный случай, чтобы выделить неожиданное поведение.)

@jlaule @proximous Для того, чтобы тема оставалась в теме, пожалуйста, создавайте проблемы в разветвленном репо, я

Для тех, кому что-то нужно во время ожидания, я просто настраиваю K3S (крайнюю версию Kubernetes) с поддержкой графического процессора за 30 минут, используя докер в качестве времени выполнения контейнера (т.е. используйте параметр --docker в сценарии установки). Перейдите по ссылке https://github.com/NVIDIA/k8s-device-plugin, чтобы запустить плагин для устройства Nvidia.
Надеюсь, это поможет!

@EpicWink не проблема, извините за отклонение от темы :). Если я выясню свою конкретную проблему, я опубликую ее здесь, если она актуальна.

Вы когда-нибудь решали это?

Больше не существует такой вещи, как "/ usr / bin / nvidia-container-runtime". Проблема по-прежнему критическая.

Установите nvidia-docker2, как указано здесь.

Я занимался этим в последнее время и подумал, что разделяю мой подход.
Моя проблема заключалась в том, что мне нужно было развернуть стек докеров, и он не хотел слушать. docker compose Я работал с хаком версии docker api, но он не чувствовал себя правильным, и развертывание стека не сработало бы независимо.

поэтому, не задавая никаких запросов устройства времени выполнения в моем docker compose, я добавил это в свой демон:

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

вы также можете использовать GPU- {первая часть gpu guid}
но это было проще. не нужно было устанавливать какой-либо pip + или что-то в этом роде, кроме инструментария контейнера NV. он разворачивается и работает как шарм.

Большое спасибо @haviduck , просто попробовал на моей машине (Ubuntu 20.04, docker CE 19.03.8), и это сработало как шарм.
Для других: не забудьте перезапустить демон Docker.

@pommedeterresautee, я так рад, что это сработало для других! должен был упомянуть перезагрузку.

Должен сказать, что после 3 недель безостановочной стыковки я довольно озадачен тем, что ничего не работает ...

@haviduck : Спасибо! Наконец, простое решение, которое просто работает. Я потратил столько времени, пытаясь добавить устройства и т. Д., Что сдался. Затем это приходит, пробует, и через пару минут у меня работает аппаратное перекодирование в Plex.

Я добавлю к этому свои 2 цента ... Я прочитал много сообщений, и, наконец, решение оказалось довольно простым.

это сработало для меня с: (может быть, немного ниже тоже сработало бы - не знаю ...)
docker-compose версия 1.27.4, сборка 40524192

  1. на хост-машине докера установите пакеты nvidia-container-toolkit и nvidia-container-runtime
  2. на хост-машине докера: введите
    nvidia-smi и изучите версию CUDA, которая появляется справа
    image
  3. на хост-машине docker: введите: (замените версию cuda той, которую вы установили)
    docker run --rm --gpus all nvidia / cuda: 10.1-base nvidia-smi
    вы должны получить тот же результат, что и при запуске nvidia-smi на хост-машине
  4. в файле /etc/docker/daemon.json вы должны указать:
    "время выполнения": {"nvidia": {"путь": "/ usr / bin / nvidia-container-runtime", "runtimeArgs": []}}
  5. в YML-код для создания докеров следует добавить:
    время выполнения: nvidia

это оно !
развернуть с помощью YML, и у вас будет поддержка графического процессора в вашем docker-compose

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

О боже, вся эта ветка посвящена версии 3, в которой нет среды выполнения.

В версиях 1.27.0+ объединены форматы файлов v2 / v3, поэтому теперь можно использовать runtime где угодно. Кроме того, появилась спецификация для ускорителей (https://github.com/compose-spec/compose-spec/pull/100), хотя она еще не реализована в docker-compose .

Я добавлю к этому свои 2 цента ... Я прочитал много сообщений, и, наконец, решение оказалось довольно простым.

это сработало для меня с: (может быть, немного ниже тоже сработало бы - не знаю ...)
docker-compose версия 1.27.4, сборка 4052419

  1. на хост-машине докера установите пакеты nvidia-container-toolkit и nvidia-container-runtime
  2. на хост-машине докера: введите
    nvidia-smi и изучите версию CUDA, которая появляется справа
    image
  3. на хост-машине docker: введите: (замените версию cuda той, которую вы установили)
    docker run --rm --gpus all nvidia / cuda: 10.1-base nvidia-smi
    вы должны получить тот же результат, что и при запуске nvidia-smi на хост-машине
  4. в файле /etc/docker/daemon.json вы должны указать:
    "время выполнения": {"nvidia": {"путь": "/ usr / bin / nvidia-container-runtime", "runtimeArgs": []}}
  5. в YML-код для создания докеров следует добавить:
    время выполнения: nvidia

это оно !
развернуть с помощью YML, и у вас будет поддержка графического процессора в вашем docker-compose

К вашему сведению, версия cuda, которую вы можете увидеть в выводе nvidia-smi относится к версии драйвера nvidia cuda, также известной как ваш драйвер nvidia (они тоже называют ее cuda, что сбивает с толку). Номер версии в образе докера, например nvidia/cuda:10.1-base nvidia-smi относится к версии инструментария nvidia (опять же, по ошибке та же система нумерации версий, разные звери).

Драйвер обратно совместим с набором инструментов, поэтому вы можете запустить любой nvidia/cuda:<version>-base nvidia-smi своему желанию, если <version> меньше или равен версии драйвера.

Подробнее здесь: https://stackoverflow.com/questions/53422407/different-cuda-versions-shown-by-nvcc-and-nvidia-smi

Я не вижу двоичных файлов Docker Compose 1.27.4, доступных для системы на базе 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)

Привет @collabnix!

Что дает pip --version ?

Compose 1.27 отказался от поддержки Python 2, поэтому, возможно, вы не увидите выпуски 1.27.x, если в вашей системе установлен Python 2.

@collabnix , потому что вы уже установили pip install --upgrade docker-compose

Теперь я могу обновиться до 1.27.4. Обновление пункта помогло. Спасибо @kshcherban и @ chris-crone
Безумие видеть, что большинство проектов, над которыми я работал в прошлом, действительно нуждаются в обновлении.

Обновление docker-compose до 1.27.4 решило проблему.
(возможно обновление до 1.19.3 позже решит проблему)

$ 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
хорошо работать с docker-compose.
на главном компьютере проверьте gpu, используемый nvidia-smi.

@ bttung-2020
@PyCod
Если я использую dokcer-nvidia-devel (не время выполнения): nvidia / cuda: 10.1-cudnn7-devel-ubuntu18.04 в docker-hub
Это работает? Как мне отредактировать файл docker-compose.yaml?

Была ли эта страница полезной?
4 / 5 - 1 рейтинги