Compose: Unterstützung für NVIDIA-GPUs unter Docker Compose

Dies ist von zunehmender Bedeutung, da die (jetzt) ​​ältere 'nvidia-Laufzeit' mit Docker 19.03.0 und nvidia-container-toolkit-1.0.0-2 defekt zu sein scheint: 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

Dies funktioniert: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Dies bedeutet nicht: docker run --runtime=nvidia nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Arbeiten daran?

Ich habe den neuen Docker CE 19.03.0 auf einem neuen Ubuntu 18.04 LTS-Computer erhalten, habe die aktuelle und passende NVIDIA Container Toolkit-Version (geb. nvidia-docker2), kann ihn aber nicht verwenden, da docker-compose.yml 3.7 das --gpus nicht unterstützt

Gibt es eine Problemumgehung dafür?

Dies funktioniert: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Dies bedeutet nicht: docker run --runtime=nvidia nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Du brauchst

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

in Ihrem /etc/docker/daemon.json für --runtime=nvidia um weiter zu arbeiten. Mehr Infos hier .

ping @KlaasH @ulyssessouza @Goryudyuma @ chris-crone. Gibt es hierzu Neuigkeiten?

Es ist ein dringender Bedarf. Vielen Dank für Ihre Mühen!

Soll der Benutzer /etc/docker/daemon.json nach der Migration zu Docker> = 19.03 manuell ausfüllen und nvidia-docker2 entfernen, um stattdessen nvidia-container-toolkit verwenden?

Es scheint, dass dies viele Installationen bricht. Insbesondere, da --gpus in compose nicht verfügbar ist.

Nein, dies ist eine Problemumgehung, bis compose das gpus-Flag unterstützt.

installiere nvidia-docker-runtime:
https://github.com/NVIDIA/nvidia-container-runtime#docker -engine-setup
zu /etc/docker/daemon.json hinzufügen
{
"Laufzeiten": {
"nvidia": {
"path": "/ usr / bin / nvidia-container-runtime",
"runtimeArgs": []
}}
}}
}}

Docker-Compose:
Laufzeit: nvidia
Umgebung:
- NVIDIA_VISIBLE_DEVICES = all

Es gibt keine "/ usr / bin / nvidia-container-runtime" mehr. Das Problem ist immer noch kritisch.

Es wird helfen, die NVIDIA-Umgebung mit Docker-Compose auszuführen, bis Docker-Compose behoben ist

installiere nvidia-docker-runtime:
https://github.com/NVIDIA/nvidia-container-runtime#docker -engine-setup
zu /etc/docker/daemon.json hinzufügen
{
"Laufzeiten": {
"nvidia": {
"path": "/ usr / bin / nvidia-container-runtime",
"runtimeArgs": []
}}
}}
}}

Docker-Compose:
Laufzeit: nvidia
Umgebung:

• NVIDIA_VISIBLE_DEVICES = all

Dies funktioniert bei mir nicht, da beim Versuch, docker-compose up auszuführen, immer noch Unsupported config option for services.myservice: 'runtime' angezeigt wird

irgendwelche Ideen?

Dies funktioniert bei mir nicht, da beim Versuch, docker-compose up auszuführen, immer noch Unsupported config option for services.myservice: 'runtime' angezeigt wird

irgendwelche Ideen?

Starten Sie nach dem Ändern von /etc/docker/daemon.json den Docker-Dienst neu
Systemctl Docker neu starten
Verwenden Sie das Compose-Format 2.3 und fügen Sie Ihrem GPU-Dienst Runtime: NVIDIA hinzu. Docker Compose muss Version 1.19.0 oder höher sein.
Docker-Compose-Datei:
Version: '2.3'

Dienstleistungen:
nvsmi:
Bild: Ubuntu: 16.04
Laufzeit: nvidia
Umgebung:
- NVIDIA_VISIBLE_DEVICES = all
Befehl: nvidia-smi

@cheperuiz , Sie können nvidia als Standardlaufzeit in daemon.json festlegen und sind nicht von Docker-Compose abhängig. Aber alle Docker-Container verwenden die NVIDIA-Laufzeit - ich habe bisher keine Probleme.
{ "default-runtime": "nvidia", "runtimes": { "nvidia": { "path": "/usr/bin/nvidia-container-runtime", "runtimeArgs": [] } }, }

Ah! danke @Kwull , ich habe diesen default-runtime Teil verpasst ... Alles funktioniert jetzt :)

@uderik , runtime ist weder im aktuellen 3.7 Compose-Dateiformatschema noch in der ausstehenden 3.8-Version vorhanden, die eventuell mit Docker 19.03 übereinstimmen sollte: https://github.com/docker/compose/blob/ 5e587d574a94e011b029c2fb491fb0f4bdeef71c / compose / config / config_schema_v3.8.json

@johncolby runtime noch nie eine 3.x-Flagge. Es ist nur in der 2.x-Spur (2.3 und 2.4) vorhanden.

Ja, ich weiß, und obwohl meine Datei docker-compose.yml die version: '2.3' (die in der Vergangenheit funktioniert haben), scheint sie von den neuesten Versionen ignoriert zu werden ...
Was wäre für zukünftige Projekte der richtige Weg, um den Zugriff auf die GPU zu aktivieren / deaktivieren? nur Standard + env Variablen machen? oder wird es die --gpus Flagge unterstützen?

@ Johncolby Was ist der Ersatz für runtime in 3.X?

@ Daniel451 Ich habe gerade die Peripherie verfolgt, aber es sieht so aus, als würde es unter der Taste generic_resources , so etwas wie:

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

(von https://github.com/docker/cli/blob/9a39a1/cli/compose/loader/full-example.yml#L71-L74)
Designdokument hier: https://github.com/docker/swarmkit/blob/master/design/generic_resources.md

Hier ist das Compose-Problem bezüglich der Unterstützung von Compose 3.8-Schemas, das bereits zusammengeführt wurde in: https://github.com/docker/compose/issues/6530

Auf der Daemon-Seite kann die gpu -Funktion registriert werden, indem sie in die daemon.json oder dockerd CLI aufgenommen wird (wie die vorherige fest codierte Laufzeitumgehung)

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

Das wird dann registriert, indem Sie sich in das NVIDIA Docker-Dienstprogramm einbinden:
https://github.com/moby/moby/blob/09d0f9/daemon/nvidia_linux.go

Es sieht so aus, als ob die Maschinerie im Grunde genommen vorhanden ist und wahrscheinlich nur dokumentiert werden muss ...

Irgendein Update?

Warten Sie auch auf Updates und verwenden Sie bash mit docker run --gpus bis zum offiziellen Fix ...

Warten auf Updates.

Warten auch auf Updates :)

Ok ... ich verstehe nicht, warum das noch offen ist. Mit diesen 3 zusätzlichen Zeilen funktioniert es mit Schema Version 3.7. Ich bin froh zu wissen, dass Docker auf triviale Community-Probleme reagiert. Klonen Sie also dieses Repo, fügen Sie diese drei Zeilen hinzu und python3 setup.py build && installiere es und stelle sicher, dass deine docker-compose.yml Version 3.7 ist.

[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'),

Ich habe gerade ein internes Problem hinzugefügt, um dies zu verfolgen.
Denken Sie daran, dass PRs willkommen sind: smiley:

Ok ... ich verstehe nicht, warum das noch offen ist. Mit diesen 3 zusätzlichen Zeilen funktioniert es mit Schema Version 3.7. Ich bin froh zu wissen, dass Docker auf triviale Community-Probleme reagiert. Klonen Sie also dieses Repo, fügen Sie diese drei Zeilen hinzu und python3 setup.py build && installiere es und stelle sicher, dass deine docker-compose.yml Version 3.7 ist.

[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'),

Ich habe Ihre Lösung ausprobiert, aber ich bekomme viele Fehler über dieses Flag:

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'

Benötige ich ein bestimmtes Python docker -Paket?

@DarioTurchi Ja, ich habe das genaue Problem getroffen. Scheint, dass der Typ von HostConfig ebenfalls aktualisiert werden muss.

Ich glaube nicht, dass die von @ruckc beschriebene
https://github.com/docker/docker-py/pull/2419

Hier ist der Zweig mit den Änderungen:
https://github.com/sigurdkb/docker-py/tree/gpus_parameter

Wenn Sie dies jetzt patchen möchten, müssen Sie Docker-Compose gegen einen modifizierten Docker-Py von https://github.com/sigurdkb/docker-py/tree/gpus_parameter erstellen

Ich verstehe nicht, was hier los ist:

1) Ich habe in /etc/docker/daemon.json

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

Der Schlüssel runtime kann in Version 3.x jedoch nicht mehr wie für https://github.com/docker/compose/issues/6239 verwendet werden

Ich habe auch versucht:

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

Daher kann ich meine Container nicht mehr mit GPU-Unterstützung für docker-compose starten:

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

Vor diesen Änderungen hat es funktioniert. Was kann ich jetzt tun?

+1 es wird sehr nützlich sein, eine solche Funktion in Docker-Compose zu haben!

Irgendein eta?

intern verfolgt als https://docker.atlassian.net/browse/COMPOSE-82

+1 wäre eine nützliche Funktion für Docker-Compose

Diese Funktion wäre eine großartige Ergänzung zu docker-compose

Momentan verwende ich die 2.3-Version der Docker-Compose-Datei, die die Laufzeit unterstützt, und installiere die nvidia-container-runtime manuell (da sie nicht mehr mit dem nvidia-docker installiert wird).
Außerdem stelle ich die Laufzeitkonfigurationen in der Datei /etc/docker/daemon.json ein (nicht als Standard, nur als verfügbare Laufzeit).
Damit kann ich eine Compose-Datei als solche verwenden:

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

Momentan verwende ich die 2.3-Version der Docker-Compose-Datei, die die Laufzeit unterstützt, und installiere die nvidia-container-runtime manuell (da sie nicht mehr mit dem nvidia-docker installiert wird).
Außerdem stelle ich die Laufzeitkonfigurationen in der Datei /etc/docker/daemon.json ein (nicht als Standard, nur als verfügbare Laufzeit).
Damit kann ich eine Compose-Datei als solche verwenden:

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

@arruda Würde es Ihnen etwas daemon.json bitte zu teilen?

Momentan verwende ich die 2.3-Version der Docker-Compose-Datei, die die Laufzeit unterstützt, und installiere die nvidia-container-runtime manuell (da sie nicht mehr mit dem nvidia-docker installiert wird).
Außerdem stelle ich die Laufzeitkonfigurationen in der Datei /etc/docker/daemon.json ein (nicht als Standard, nur als verfügbare Laufzeit).
Damit kann ich eine Compose-Datei als solche verwenden:

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

@arruda Würde es Ihnen etwas daemon.json bitte zu teilen?

Ja, kein Problem, hier ist es:

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

Hallo

Ich habe eine Anwendung, für die NVIDIA-Treiber erforderlich sind. Ich habe ein Docker-Image basierend auf (FROM) erstellt.
nvidia / cudagl: 10.1-runtime-ubuntu18.04

Verwenden Sie den oben empfohlenen Ansatz - bedeutet dies, dass mein Bild nicht von nvidia / cudagl: 10.1-runtime-ubuntu18.04 abgeleitet werden muss ? Dh ich könnte einfach von (FROM) Python ableiten
und füge runtime: nvidia zum service in docker-compose hinzu?

Vielen Dank

@rfsch Nein, das ist etwas anderes. runtime: nvidia in Docker-Compose bezieht sich auf die Docker-Laufzeit. Dadurch wird die GPU dem Container zur Verfügung gestellt. Sie müssen sie jedoch noch verwenden, sobald sie verfügbar sind. runtime in nvidia/cudagl:10.1-runtime-ubuntu18.04 bezieht sich auf die CUDA-Laufzeitkomponenten. Auf diese Weise können Sie die GPUs (von Docker in einem Container verfügbar gemacht) mit CUDA verwenden.

In diesem Bild:

runtime: nvidia ersetzt den Runc / Containerd-Teil. nvidia/cudagl:10.1-runtime-ubuntu18.04 ist völlig außerhalb des Bildes .

Wir brauchen diese Funktion

@ Daniel451 Ich habe gerade die Peripherie verfolgt, aber es sieht so aus, als würde es unter der Taste generic_resources , so etwas wie:

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

(von https://github.com/docker/cli/blob/9a39a1/cli/compose/loader/full-example.yml#L71-L74)
Designdokument hier: https://github.com/docker/swarmkit/blob/master/design/generic_resources.md

Hier ist das Compose-Problem bezüglich der Unterstützung von Compose 3.8-Schemas, das bereits zusammengeführt wurde in: # 6530

Auf der Daemon-Seite kann die gpu -Funktion registriert werden, indem sie in die daemon.json oder dockerd CLI aufgenommen wird (wie die vorherige fest codierte Laufzeitumgehung)

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

Das wird dann registriert, indem Sie sich in das NVIDIA Docker-Dienstprogramm einbinden:
https://github.com/moby/moby/blob/09d0f9/daemon/nvidia_linux.go

Es sieht so aus, als ob die Maschinerie im Grunde genommen vorhanden ist und wahrscheinlich nur dokumentiert werden muss ...

Hey, @johncolby , ich habe es versucht, bin aber gescheitert:

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)

irgendwelche Vorschläge?

Vielen Dank
David

Installieren von nvidia-container-runtime 3.1.4.1 von https://github.com/NVIDIA/nvidia-container-runtime und Putten

runtime: nvidia

funktioniert hier einwandfrei mit docker-compose 1.23.1 und 1.24.1 wie von https://docs.docker.com/compose/install/ installiert, mit diesem zwielichtig aussehenden Befehl:

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

und zB der nvidia / cudagl / 10.1-base container von dockerhub. Ich habe Cuda und OpenGL Rendering ausprobiert und es ist alles in der Nähe der nativen Leistung.

Intern als COMPOSE-82 verfolgt
Bitte beachten Sie, dass eine solche Änderung aus Konsistenzgründen auch in docker stack (https://github.com/docker/cli/blob/master/cli/compose/types/types.go#L156) implementiert werden muss

Installieren von nvidia-container-runtime 3.1.4.1 von https://github.com/NVIDIA/nvidia-container-runtime und Putten

runtime: nvidia

funktioniert hier einwandfrei mit docker-compose 1.23.1 und 1.24.1 wie von https://docs.docker.com/compose/install/ installiert, mit diesem zwielichtig aussehenden Befehl:

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

und zB der nvidia / cudagl / 10.1-base container von dockerhub. Ich habe Cuda und OpenGL Rendering ausprobiert und es ist alles in der Nähe der nativen Leistung.

können Sie Ihre docker-compose.yml teilen?

hey, @ jdr-face,

Hier ist mein Test, der Ihrem Vorschlag folgt, indem Sie nvidia-container-runtime auf dem Host-Computer installieren.

version: '3.0'

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

es gibt immer noch den Fehler:

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

@ david-gwa wie von andyneff früher bemerkt :

runtime noch nie eine 3.x-Flagge. Es ist nur in der 2.x-Spur (2.3 und 2.4) vorhanden.

@ David-Gwa

können Sie Ihre docker-compose.yml teilen?

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

Abhängig von Ihren Anforderungen sind einige dieser Optionen möglicherweise nicht erforderlich. Wie @muru vorausgesagt hat, besteht der Trick darin, eine alte Version anzugeben. Zumindest für meinen Anwendungsfall ist dies kein Problem, aber ich biete diese Konfiguration nur als Problemumgehung an. Eigentlich sollte dies mit der neuesten Version möglich sein.

danke jungs, @ jdr-face, @muru , komponiere v2 funktioniert,
Ich habe falsch verstanden, dass Ihre Lösung für v3 compose ist.

Für die Aufzeichnung, traditionell gesprochen: compose v2 ist nicht älter als compose v3. Sie sind verschiedene Anwendungsfälle. v3 ist auf Schwarm ausgerichtet, v2 nicht. v1 ist alt.

Gibt es eine Diskussion über die Unterstützung von Docker-compose für die native GPU-Unterstützung von Docker?

Die Unterstützung der Option runtime ist in Zukunft keine Lösung für die GPU-Unterstützung. NVIDIA beschreibt die Zukunft von nvidia-docker2 unter https://github.com/NVIDIA/nvidia-docker wie folgt.

Beachten Sie, dass mit der Veröffentlichung von Docker 19.03 die Verwendung von nvidia-docker2-Paketen veraltet ist, da NVIDIA-GPUs jetzt nativ als Geräte in der Docker-Laufzeit unterstützt werden.

Derzeit kann die GPU-Unterstützung durch Ändern der Laufzeit realisiert werden. Es ist jedoch sehr wahrscheinlich, dass dies in Zukunft nicht mehr funktioniert.

Um ehrlich zu sein, ist dies vielleicht nicht die beste Vorgehensweise, aber irgendwie schaffen wir es.

Der schwierige Teil ist, dass wir uns an Docker-Compose v3.x halten müssen, da wir Docker-Schwarm verwenden. In der Zwischenzeit möchten wir die Nvidia Runtime verwenden, um GPU / CUDA in den Containern zu unterstützen.

Um zu vermeiden, dass die Nvidia-Laufzeit in der Docker-Compose-Datei explizit angegeben wird, setzen wir Nvidia als Standardlaufzeit in /etc/docker/daemon.json , und es sieht so aus

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

Damit alle Container, die auf den GPU-Computern ausgeführt werden, standardmäßig die Nvidia-Laufzeit aktivieren.

Hoffe, dies kann jemandem helfen, der sich dem ähnlichen Blocker gegenübersieht

Um ehrlich zu sein, ist dies vielleicht nicht die beste Vorgehensweise, aber irgendwie schaffen wir es.

Der schwierige Teil ist, dass wir uns an Docker-Compose v3.x halten müssen, da wir Docker-Schwarm verwenden. In der Zwischenzeit möchten wir die Nvidia Runtime verwenden, um GPU / CUDA in den Containern zu unterstützen.

Um zu vermeiden, dass die Nvidia-Laufzeit in der Docker-Compose-Datei explizit angegeben wird, setzen wir Nvidia als Standardlaufzeit in /etc/docker/daemon.json , und es sieht so aus

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

Damit alle Container, die auf den GPU-Computern ausgeführt werden, standardmäßig die Nvidia-Laufzeit aktivieren.

Hoffe, dies kann jemandem helfen, der sich dem ähnlichen Blocker gegenübersieht

Dies ist in der Tat auch das, was wir tun. Es funktioniert im Moment, aber es fühlt sich für mich ein wenig hackig an. Ich hoffe bald auf volle Unterstützung für Compose-v3. :) :)

Soll der Benutzer /etc/docker/daemon.json nach der Migration zu Docker> = 19.03 manuell ausfüllen und nvidia-docker2 entfernen, um stattdessen nvidia-container-toolkit verwenden?

Es scheint, dass dies viele Installationen bricht. Insbesondere, da --gpus in compose nicht verfügbar ist.

--gpus ist in compose nicht verfügbar
Ich kann Pycharm nicht verwenden, um Docker zu verknüpfen, um Tensorflow-GPU auszuführen

Irgendwelche Updates zu diesem Thema? Gibt es eine Chance, dass das --gpus bald in Docker-Compose unterstützt wird?

Für diejenigen unter Ihnen, die nach einer Problemumgehung suchen, haben wir Folgendes getan:

• Installieren Sie Docker-Py von diesem PR: https://github.com/docker/docker-py/pull/2471
• Installieren Sie Docker-Compose von diesem PR: https://github.com/docker/compose/pull/7124

Führen Sie dann COMPOSE_API_VERSION=auto docker-compose run gpu mit der folgenden Datei aus:

version: '3.7'

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

Unter Docker 19.03.0 Beta 2 wurde die Unterstützung für NVIDIA GPU in Form der neuen CLI-API --gpus eingeführt. Docker / CLI # 1714 sprechen über diese Aktivierung.

Jetzt kann man einfach die Option --gpus für eine GPU-beschleunigte Docker-basierte Anwendung übergeben.

$ 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                                                 |
+-----------------------------------------------------------------------------+
:~$ 

Bis heute unterstützt Compose dies nicht. Dies ist eine Funktionsanforderung, um Compose für die Unterstützung der NVIDIA-GPU zu aktivieren.

Ich habe dieses Problem gelöst. Sie können es wie folgt versuchen: Meine csdn-Blog-Adresse: https://blog.csdn.net/u010420283/article/details/104055046

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

Fügen Sie dann in dieser Datei daemon.json den folgenden Inhalt hinzu:

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

~ $ sudo systemctl Daemon-Reload
~ $ sudo systemctl Docker neu starten

Für die ansiblen Benutzer, die die zuvor beschriebene nvidia-container-runtime und zum Konfigurieren von /etc/docker/deamon.json für die Verwendung von runtime: nvidia :

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

(Aus irgendeinem Grund läuft es nur unter Ubuntu und RHEL, aber es ist ziemlich einfach zu ändern. Ich führe es unter Debian aus)

Dann in Ihrer docker-compose.yml :

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

Gibt es ein Update der offiziellen 3.x-Version mit GPU-Unterstützung? Wir brauchen auf Schwarm :)

Gibt es Pläne, diese Funktion hinzuzufügen?

Diese Funktion hängt davon ab, ob Docker-Py die device_requests -Parameter implementiert, was --gpus bedeutet. Es gab mehrere Pull-Anforderungen zum Hinzufügen dieser Funktion (https://github.com/docker/docker-py/pull/2419, https://github.com/docker/docker-py/pull/2465, https: / /github.com/docker/docker-py/pull/2471), aber es gibt keine Reaktionen von einem Betreuer. # 7124 verwendet https://github.com/docker/docker-py/pull/2471 , um es in Compose bereitzustellen, aber immer noch keine Antwort von irgendjemandem.

Wie ich in # 7124 erwähnt habe, bin ich mehr als glücklich, die PR-Konformität zu verbessern, aber da sie nur sehr wenig Beachtung findet, möchte ich meine Zeit nicht mit etwas verschwenden, das nicht zusammengeführt wird ...

Bitte fügen Sie diese Funktion hinzu, wird fantastisch!

Bitte fügen Sie diese Funktion hinzu! Ich war mehr als zufrieden mit dem alten nevidia-docker2, mit dem ich die Laufzeit in der Datei daemon.json ändern konnte. Wäre sehr schön, das wieder zu haben.

Brauche es bitte. Brauche es wirklich: /

Ich würde mich auch gerne anhäufen ... wir brauchen diese Funktion!

Ich muss sowohl CPU- als auch GPU-Container auf demselben Computer ausführen, damit der Standard-Laufzeit-Hack für mich nicht funktioniert. Haben wir eine Idee, wann dies beim Komponieren funktionieren wird? Angesichts der Tatsache, dass wir beim Verfassen kein Laufzeitflag haben, stellt dies eine ernsthafte Regression der Funktionalität dar, nicht wahr? Ich muss Skripte schreiben, damit das funktioniert - igitt!

Ich muss sowohl CPU- als auch GPU-Container auf demselben Computer ausführen, damit der Standard-Laufzeit-Hack für mich nicht funktioniert. Haben wir eine Idee, wann dies beim Komponieren funktionieren wird? Angesichts der Tatsache, dass wir beim Verfassen kein Laufzeitflag haben, stellt dies eine ernsthafte Regression der Funktionalität dar, nicht wahr? Ich muss Skripte schreiben, damit das funktioniert - igitt!

Sie können es mit Docker Cli (Docker Run - GPU ....) tun, ich habe diese Art von Trick (durch Hinzufügen eines Proxys, um mit anderen Containern kommunizieren zu können, die auf anderen Knoten auf Schwarm laufen). Wir warten alle auf die Möglichkeit, es auf Swarm auszuführen, da es weder mit dem Docker-Service-Befehl (wie ich weiß) noch mit Compose funktioniert.

@ Dottgonzo . Nun ja ;-). Mir ist dies und damit der Verweis auf Skripte bewusst. Aber dies ist eine ziemlich schreckliche und nicht tragbare Methode, also würde ich es gerne dynamischer machen. Wie gesagt, ich denke, dass dies eine Regression darstellt, keine Feature-Frage.

COMPOSE_API_VERSION=auto docker-compose run gpu

@ggregoire wo laufen wir: COMPOSE_API_VERSION = Auto Docker-Compose Run GPU?

@joehoeller von Ihrer Shell war genau das, was Sie für jeden anderen Befehl tun würden.

Im Moment entscheiden wir für jedes Projekt, ob wir 3.x-Funktionen benötigen oder ob wir Docker-Compose 2.x verwenden können, wo die GPU-Option weiterhin unterstützt wird. Funktionen wie das Ausführen mehrstufiger Ziele von einer Docker-Datei aus können leider nicht verwendet werden, wenn eine GPU erforderlich ist. Bitte fügen Sie dies wieder hinzu!

Ich möchte so etwas wie ein Feld "Zusätzliche Optionen" für Docker-Compose empfehlen, in dem wir dem Docker-Start / Run-Befehl einfach Flags wie --gpus=all hinzufügen können, die in Docker-Compose noch nicht / nicht mehr unterstützt werden sind aber in der neuesten Docker-Version. Auf diese Weise müssen Compose-Benutzer nicht warten, bis Docker-Compose aufholt, wenn sie eine neue, noch nicht unterstützte Docker-Funktion benötigen.

Ist weiterhin erforderlich, um dies auf Docker Swarm für Produktionsumgebungen auszuführen. Wird dies für Docker Swarm nützlich sein?

@sebastianfelipe Es ist sehr nützlich, wenn Sie mit compose auf Ihrem Schwarm bereitstellen möchten.
Vergleichen Sie:
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\"

zu so etwas

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

@sebastianfelipe Es ist sehr nützlich, wenn Sie mit compose auf Ihrem Schwarm bereitstellen möchten.
Vergleichen Sie:
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\"

zu so etwas

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

Tut mir leid, funktioniert es bereits mit Docker Swarm unter Verwendung der Docker-Compose-Yaml-Datei? Nur um sicher zu gehen: O. Vielen Dank!

nur für Docker komponieren 2.x.

In diesem Problem geht es darum, die Unterstützung von nvidia-docker gpu für docker-compose 3+ anzufordern

Es ist fast ein Jahr seit der ursprünglichen Anfrage vergangen !! Warum die Verzögerung?? Können wir das vorantreiben?

ping @KlaasH @ulyssessouza @Goryudyuma @ chris-crone. Gibt es hierzu Neuigkeiten?

Für diejenigen unter Ihnen, die nach einer Problemumgehung suchen, haben wir Folgendes getan:

• Installieren Sie Docker-Py von diesem PR: Docker / Docker-Py # 2471
• Installieren Sie Docker-Compose von diesem PR: # 7124

Führen Sie dann COMPOSE_API_VERSION=auto docker-compose run gpu mit der folgenden Datei aus:

version: '3.7'

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

Für diejenigen unter Ihnen, die genauso ungeduldig sind wie ich, gibt es hier eine einfache pip install -Version der obigen Problemumgehung:

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

Ein großes Lob an
Ich warte immer noch gespannt auf einen offiziellen Patch. Mit all den PRs scheint es in keiner Weise schwierig zu sein.

ping @KlaasH @ulyssessouza @Goryudyuma @ chris-crone. Gibt es hierzu Neuigkeiten?

Nein, ich weiß nicht, warum ich gerufen wurde.
Ich möchte, dass du mir sagst, was ich tun soll?

Ich hoffe es gibt ein Update dazu.

Ja, es ist jetzt mehr als ein Jahr her ... warum verschmelzen sie nicht zu Docker-Py ...

Ich bin nicht sicher, ob die vorgeschlagenen Implementierungen die richtigen für das Compose-Format sind. Die gute Nachricht ist, dass wir die Compose-Formatspezifikation mit der Absicht geöffnet haben, solche Dinge hinzuzufügen. Sie finden die Spezifikation unter https://github.com/compose-spec.

Ich würde vorschlagen, dass wir der Spezifikation ein Problem hinzufügen und es dann bei einem der bevorstehenden Compose-Community-Meetings diskutieren (Link zum Einladen unten auf dieser Seite ).

Dies funktioniert: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi
Dies bedeutet nicht: docker run --runtime=nvidia nvidia/cudagl:9.2-runtime-centos7 nvidia-smi

Du brauchst

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

in Ihrem /etc/docker/daemon.json für --runtime=nvidia um weiter zu arbeiten. Mehr Infos hier .

Dockerd beginnt nicht mit dieser daemon.json

Gott, das wird Jahre dauern: @

Dies funktioniert: docker run --gpus all nvidia/cudagl:9.2-runtime-centos7 nvidia-smi
@deniswal : Ja, das wissen wir, aber wir fragen nach der Kompositionsfunktionalität.

@ chris-crone: Ich bin verwirrt: Dies stellt eine Regression des früheren Verhaltens dar. Warum benötigt es eine neue Funktionsspezifikation? Ist es nicht sinnvoll, Container auszuführen, von denen einige GPU und einige CPU auf derselben physischen Box verwenden?

Vielen Dank für die Überlegung.

@ vk1z AFAIK Docker Compose hatte noch nie GPU-Unterstützung, daher ist dies keine Regression. Der Teil, der entworfen werden muss, ist, wie die Notwendigkeit eines Dienstes für eine GPU (oder ein anderes Gerät) im Compose-Format deklariert wird - speziell Änderungen wie diese . Danach sollte es nur noch zum Backend führen.

Hallo Leute, ich habe einige hier vorgeschlagene Lösungen ausprobiert und nichts hat bei mir funktioniert, zum Beispiel @miriaford hat in meinem Fall nicht funktioniert.
Ich habe einen i7 mit 16 GB RAM, aber der Build für einige Projekte dauert zu lange. Mein Ziel ist es, auch GPU-Leistung zu verwenden, um den Prozess zu beschleunigen. Ist das möglich? Vielen Dank!

@ chris-crone: Auch hier werde ich bereit sein, korrigiert zu werden, aber war das nicht so, weil der Parameter runtime: nach 2.4 config aus compose verschwunden ist? Deshalb hatte ich das Gefühl, dass es eine Regression war. Aber nein, egal jetzt, da wir alle sowieso auf 3.x sein sollten.

Ich würde gerne ein Problem einreichen. Tun wir das gegen die Spezifikation im Spezifikations-Repo, richtig?

aber war das nicht so, weil der Parameter runtime: nach 2.4 config aus compose verschwunden ist? Deshalb hatte ich das Gefühl, dass es eine Regression war.

Ja genau. Ich habe einige Projekte, in denen wir uns darauf verlassen, runtime: nvidia in unseren Docker-Compose-Dateien zu verwenden. Dieses Problem hindert uns daran, auf 3.x zu aktualisieren, da wir dort keine Möglichkeit gefunden haben, GPUs zu verwenden.

Hallo, bitte, bitte, bitte behebe das.
Dies sollte als geschäftskritische Priorität -20 markiert werden

Auch hier bin ich bereit, korrigiert zu werden, aber war das nicht so, weil der Parameter runtime: nach 2.4 config aus compose verschwunden ist? Deshalb hatte ich das Gefühl, dass es eine Regression war. Aber nein, egal jetzt, da wir alle sowieso auf 3.x sein sollten.

Ich war nicht hier, als die Änderung vorgenommen wurde, daher bin ich mir nicht 100% sicher, warum sie fallengelassen wurde. Ich weiß, dass Sie die NVIDIA-Laufzeit nicht mehr benötigen, um GPUs zu verwenden, und dass wir die Compose v3-Spezifikation hier offen weiterentwickeln

In Bezug auf das Feld runtime denke ich nicht, dass es so zur Compose-Spezifikation hinzugefügt werden sollte, da es sehr spezifisch für die Ausführung auf einem einzelnen Knoten ist. Im Idealfall möchten wir etwas, mit dem Sie angeben können, dass Ihre Workload einen Gerätebedarf hat (z. B. GPU, TPU, was auch immer als Nächstes kommt), und dann den Orchestrator die Workload einem Knoten zuweisen lassen, der diese Funktion bereitstellt.

Diese Diskussion sollte jedoch über die Spezifikation geführt werden, da sie nicht spezifisch für Python Docker Compose ist.

@ chris-crone: Ich stimme deiner Aussage größtenteils zu. Das Hinzufügen von kurzfristigen Hacks ist wahrscheinlich der falsche Weg, da es immer mehr Edge-Geräte mit jeweils eigenen Laufzeiten gibt. Zum Beispiel, wie Sie hervorheben, TPU (Google), VPU (Intel) und ARM GPU auf dem Pi. Wir brauchen also eine vollständigere Geschichte.

Ich werde heute ein Problem gegen die Spezifikation einreichen und diesen Thread aktualisieren, sobald ich dies getan habe. Ich denke jedoch, dass der Orchestrator unabhängig sein sollte - wenn ich beispielsweise Kube verwenden möchte, sollte ich dazu in der Lage sein. Ich gehe davon aus, dass dies in den Geltungsbereich fällt.

Ich bin jedoch nicht mit der Anweisung zur Verwendung von GPUs einverstanden, da dies mit compose nicht funktioniert - darum geht es hier. Aber ich denke, wir alle verstehen, welches Problem wir gerne gelöst hätten.

@ chris-crone: Bitte beachten Sie das Docker-Compose-Spezifikationsproblem. Ich werde von nun an Updates gegen dieses Problem verfolgen.

Können wir einfach eine Option hinzufügen (so etwas wie extra_docker_run_args ), um Argumente direkt an das zugrunde liegende docker run ? Dies wird nicht nur das aktuelle Problem lösen, sondern auch zukunftssicher sein: Was ist, wenn Docker Unterstützung für "XPU", ​​"YPU" oder andere neue Funktionen hinzufügt, die möglicherweise in Zukunft verfügbar sein werden?

Wenn wir jedes Mal, wenn Docker eine neue Funktion hinzufügt, eine lange Diskussion hin und her benötigen, ist dies äußerst ineffizient und führt zu unvermeidlichen Verzögerungen (und unnötiger Verwirrung) zwischen docker-compose und docker Updates. Die unterstützende Argumentdelegierung kann dieses wiederkehrende Problem für alle zukünftigen Funktionen vorübergehend lösen.

@miriaford Ich bin mir nicht sicher, ob das Übergeben eines nicht interpretierten Blobs die kompositorische Vorstellung unterstützt, deklarativ zu sein. Das alte Laufzeit-Tag zeigte zumindest an, dass es etwas mit der Laufzeit zu tun hatte. Angesichts der Richtung, in die Docker tendiert (Docker-Apps), scheint es mir, dass dies die deklarative Bereitstellung erschweren würde, da ein Orchestrator beliebige Blobs analysieren müsste.

Aber ich stimme zu, dass compose und Docker sollten Arbeitsfunktionen synchronisiert werden und Zappen , dass die Menschen davon abhängen , (obwohl es eine Major - Release war) ist nicht ganz koscher.

@ vk1z Ich stimme zu - es sollte einen viel besseren Synchronisationsmechanismus zwischen compose und docker . Ich erwarte jedoch nicht, dass ein solcher Mechanismus bald entwickelt wird. In der Zwischenzeit brauchen wir auch eine vorübergehende Möglichkeit, unsere eigene Synchronisation durchzuführen, ohne tief in den Quellcode einzudringen.

Was schlagen wir vor, wenn der Vorschlag zur Delegation von Argumenten keine Option ist? Ich bin damit einverstanden, dass es keine schöne Lösung ist, aber es ist zumindest viel besser als diese Problemumgehung, nicht wahr? https://github.com/docker/compose/issues/6691#issuecomment -616984053

@miriaford Docker-compose nicht die Docker Exekutive mit dem Argumente nennen, verwendet es tatsächlich die docker_py , die den http - API an das Docker - Dämon verwendet. Es gibt also keinen "zugrunde liegenden Befehl docker run ". Die Docker-CLI ist keine API, die Socket-Verbindung ist der API-Kontaktpunkt. Deshalb ist es nicht immer so einfach.

Um die Dinge zu vereinfachen, gibt es beim Ausführen eines Dockers zwei Hauptaufrufe, einen, der den Container erstellt, und einen, der ihn startet, wobei jeder unterschiedliche Informationen aufnimmt und weiß, welche während jemand mit API-Kenntnissen welche benötigt Ich weiß nicht wie ich, wir neigen dazu, die docker CLI zu kennen. Ich denke nicht, dass es so nützlich sein wird, zusätzliche Argumente zu docker_py-Aufrufen hinzuzufügen, wie Sie denken, außer in ausgewählten Anwendungsfällen.

Um die Sache noch schwieriger zu machen, befindet sich die docker_py-Bibliothek manchmal hinter der API und verfügt auch nicht sofort über alles, was Sie benötigen, und Sie müssen warten, bis sie aktualisiert wird. Alles in allem ist extra_docker_run_args keine einfache Lösung.

@andyneff Danke für deine Erklärung. In der Tat bin ich mit dem Innenleben von Docker nicht allzu vertraut. Wenn ich das richtig verstehe, gibt es 4 APIs , die für neue Feature-Updates manuell synchronisiert werden müssen:

1. Docker-Socket-API
2. docker_py , das Python-Frontend für die Socket-API bereitstellt
3. Docker CLI (unser bekannter Einstiegspunkt in die Docker-Toolchain)
4. Docker-Compose-Schnittstelle, die die Docker-Socket-API aufruft

Dies wirft die Frage auf: Warum gibt es keinen automatischen (oder zumindest halbautomatischen) Synchronisationsmechanismus? Die manuelle Weitergabe neuer Feature-Updates über 4 APIs scheint fehleranfällig, verzögerungsanfällig und verwirrend zu sein.

PS Ich sage nicht, dass es eine einfache Aufgabe ist, eine automatische Synchronisierung zu haben, aber ich denke wirklich, dass es eine geben sollte, die das Leben in Zukunft einfacher macht.

Ich steige jetzt ein bisschen in die Pedantik ... Aber wie ich es beschreiben würde als ...

• Der Docker-Socket ist DIE offizielle API für Docker. Es ist oft ein Dateisocket, kann aber auch TCP sein (oder jedes andere, ich stelle mir vor, socat )
• Die docker CLI verwendet diese API, um uns Benutzern ein fantastisches Tool zu bieten
  
  
  
  • Docker schreibt die API und die CLI, sodass sie immer zum Zeitpunkt der Veröffentlichung synchronisiert werden. (Ich denke, das ist sicher zu sagen, die CLI ist ein erstklassiger Bürger des Docker-Ökosystems.)
  
  
• Die docker_py-Bibliothek nimmt diese API und legt sie in einer fantastischen Bibliothek ab, die andere Python-Bibliotheken verwenden können. Ohne dies würden Sie all diese HTTP-Anrufe selbst tätigen und sich die Haare ausreißen.
  
  
  
  • Docker_py wurde jedoch als Bibliothek eines Drittanbieters gestartet. Daher wurde die Docker-API traditionell nachverfolgt und später oder nach Bedarf hinzugefügt (begrenzte Ressourcen).
  
  
• compose verwendet eine Version von docker_py und fügt dann nach Bedarf all diese fantastischen Funktionen hinzu (basierend auf solchen Problemen).
  
  
  
  • Compose kann jedoch nicht viel bewirken, bis docker_py (was ich nicht sage, hält dieses Problem auf, ich weiß nicht, ich spreche nur allgemein)
  
  

Also ja, es geht:

• "compose yaml + compose args" -> "docker_py" -> "docker_api"
• Und die CLI ist kein Teil davon (und glauben Sie mir, das ist der richtige Weg, um Dinge zu tun)

Ich kann nicht für docker_py sprechen oder komponieren, aber ich kann mir vorstellen, dass sie nur begrenzte Arbeitsstunden haben, um dazu beizutragen. Daher ist es schwieriger, mit ALLEN verrückten verrückten Docker-Funktionen Schritt zu halten, die Docker ständig hinzufügt. Aber da Docker eine Go-Bibliothek ist und ich verstehe, dass Python-Unterstützung (derzeit) kein erstklassiger Bürger ist. Obwohl es schön ist, dass beide Projekte unter dem Dach des Dockers stehen, zumindest aus Sicht der Github-Organisation.

Damit alles gesagt ist ... Ich warte auch auf eine entsprechende Unterstützung von --gpus und muss stattdessen die alte runtime: nvidia -Methode verwenden, die mir zumindest einen "Weg" gibt, mich zu bewegen vorwärts in Docker-Compose 2.x.

@andyneff FYI Es gibt Docker CLI-Unterstützung in der neuesten Docker-Komposition. Es ermöglicht beispielsweise die Verwendung von Buildkit. https://www.docker.com/blog/faster-builds-in-compose-thanks-to-buildkit-support/

@andyneff das ist eine sehr hilfreiche Übersicht! Danke noch einmal

@lig super ! Danke für die Korrektur! Ich dachte tatsächlich "Wie wird das Buildkit in all das passen", als ich das aufschrieb

Was mich ein bisschen überrascht, ist, dass Docker-Compose ein ziemlich wesentlicher Bestandteil des neuen Docker-App-Frameworks ist, und ich würde mir vorstellen, dass sie Docker-Compose und Docker zumindest aus diesem Grund synchronisieren möchten. Ich frage mich, was der Blocker wirklich ist: Nicht genug Python-Bandbreite? Scheint ein bisschen unglaublich.

Wie passt Docker Swarm in die Struktur, die @andyneff gerade beschrieben hat? Swarm verwendet das Compose-Dateiformat Version 3 (definiert durch das "Compose" -Projekt?), Wird jedoch als Teil von docker ? Entwickelt.

Entschuldigung, wenn dies für dieses spezielle Problem nicht zum Thema gehört. Ich habe den Überblick darüber verloren, welches Problem welches ist, aber ich habe damit begonnen, weil ich einem Dienst, der auf einem Schwarm ausgeführt wird, mitteilen möchte, dass er eine bestimmte Laufzeit verwenden muss. Wir können das nur mit v2 der Compose-File-Spezifikation machen, was bedeutet, dass wir es nicht mit Swarm machen können, für das v3 erforderlich ist. Mit anderen Worten, ich bin nicht wirklich daran interessiert, was die Docker-Compose-CLI tut, sondern nur an der Spezifikation, die für Docker-Compose.yml-Dateien definiert ist, die vom Docker-Schwarm verwendet werden.

Oh Schwarm, derjenige, der entkommen ist ... (von mir). Leider ist das # 6239, das von einem BOT geschlossen wurde. :( Jemand hat es in # 6240 versucht, aber es wurde ihm gesagt, dass ...

@miriaford , es sieht so aus, als gäbe es eine PR für die Synchronisierung! # 6642?! (Ist das nur für v3 ???)

Aufgrund der Natur des Schwarms gibt es bestimmte Dinge, die Sie an Schwarmknoten tun und nicht tun. Daher können Sie mit der Docker-API bei einem Schwarmlauf nicht immer dieselben Optionen ausführen wie bei einem normalen Lauf. Ich weiß nicht, ob die Laufzeit eines dieser Dinge ist, aber das ist oft der Grund, warum Sie in Version 3 (der schwarmkompatiblen Version) und in Version 2 (der nicht schwarmkompatiblen Version) keine Dinge tun können.

Niemand, der dies liest, weiß, wovon ihr redet.
Wir alle versuchen, Jellyfin mit Hardwarebeschleunigung einzusetzen.
Bis ihr das wieder so macht, wie es sein soll, wenn es heißt, Service, ist 3.x nicht gut.
Benutze es nicht.

Sie müssen 2.4 für den Service setzen.
Dann können Sie die Hardwarebeschleunigung für Jellyfin verwenden, z

Also, Leute, was ist die ETA dazu, 1 Jahr, 2 Jahre?

@KlaasH @ulyssessouza @Goryudyuma @ chris-crone Hallo, ich arbeite an diesem Problem. Ich habe festgestellt, dass die Unterstützung in "docker-py" fehlte. Ich habe an diesem Teil gearbeitet. Damit es funktioniert, muss ich die Konfigurationen über die Datei docker-compose.yml übergeben. Können Sie mir mit dem Schema helfen? dh Um es hinzuzufügen, sollte ich es einem neuen Schema hinzufügen oder gibt es einen Ort, an dem die Konfigurationen übergeben werden könnten

@fakabbir Ich würde annehmen, dass es in COMPOSE_DOCKER_CLI_BUILD dafür zu verwenden. Das Hinzufügen einer Fähigkeit zur Bereitstellung einer willkürlichen Liste von docker run Argumenten könnte sogar dazu beitragen, ähnliche Probleme in Zukunft zu vermeiden.

@lig Wie gehen Sie vor, wenn nur ein Dienst Zugriff auf eine GPU benötigt?

@lig AFAICS compose verwendet docker-py anstelle von docker run cli. Das Hinzufügen beliebiger docker run -Argumente würde also nur funktionieren, wenn docker-py unterstützt.

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

Diese einzige Sache verringert die Nützlichkeit von Docker-Compose für viele Menschen enorm. Dass es nicht viel Aufmerksamkeit und den Wunsch gesehen hat, es zu reparieren, besonders wenn es in älteren Docker-Kompositionen funktioniert hat, ist ziemlich erstaunlich.
Wäre es nicht möglich, beliebige Docker-Run-Argumente in einer Docker-Compose-Datei anzugeben? Dann könnte zum Beispiel --gpus all an Docker übergeben werden.

Ich verstehe, dass es philosophische oder technische Gründe geben kann, warum man es auf eine bestimmte Weise tun möchte. Aber nicht in die Hände zu bekommen und es auf irgendeine Weise zu tun, taumelt den Geist.

@lig Wie gehen Sie vor, wenn nur ein Dienst Zugriff auf eine GPU benötigt?

Nun, mit der Umgebungsvariablen NVIDIA_VISIBLE_DEVICES können Sie steuern, dass nein?

Diese einzige Sache verringert die Nützlichkeit von Docker-Compose für viele Menschen enorm. Dass es nicht viel Aufmerksamkeit und den Wunsch gesehen hat, es zu reparieren, besonders wenn es in älteren Docker-Kompositionen funktioniert hat, ist ziemlich erstaunlich.
Wäre es nicht möglich, beliebige Docker-Run-Argumente in einer Docker-Compose-Datei anzugeben? Dann könnte zum Beispiel --gpus all an Docker übergeben werden.

Ich denke nicht, dass es der richtige Weg ist, docker --run args zu übergeben. compose nennt docker nicht wirklich selbst, sondern verwendet stattdessen docker-py .

Ich verstehe, dass es philosophische oder technische Gründe geben kann, warum man es auf eine bestimmte Weise tun möchte. Aber nicht in die Hände zu bekommen und es auf irgendeine Weise zu tun, taumelt den Geist.

Eine PR ist darüber offen: https://github.com/docker/compose/pull/7124. Bitte zögern Sie nicht, "es in die Hände zu bekommen".

Ich glaube, dass wir gemäß der Änderung der Docker-Compose-Spezifikation bald wieder zu einer früheren Kompatibilität gemäß Compose 2.4 zurückkehren sollten und die NVIDIA-Laufzeit funktionieren wird. Es wird offensichtlich nicht für TPUs oder andere Beschleuniger funktionieren - was sehr unglücklich ist, aber für diejenigen, die (teure) nvidia gpus ausführen möchten, wird es funktionieren.

Warten Sie also einfach auf eine grüne PR in Docker-Py, um sie zusammenzuführen. Https://github.com/docker/docker-py/pull/2471

JA! Die PR bei Docker-Py wurde genehmigt! https://github.com/docker/docker-py/pull/2471
Was ist der nächste Schritt hier?

Was geht hier ab ? Es wäre cool, die NVIDIA-Laufzeit in Docker-Compose unterstützen zu können

https://github.com/docker/docker-py/pull/2471 wurde zusammengeführt.

Nachdem Docker / Docker-Py # 2471 zusammengeführt wurde, können wir Docker-Py vom Master installieren. Da sich die Docker-Komposition seit @yoanisgils coolem [PR] (https://github.com/docker/compose/pull/7124) (Kudos!)

Für diejenigen, die hier gelandet sind, ohne die vorherigen Kommentare zu sehen:

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

Verwenden Sie dann die folgende Vorlage in Ihrer Erstellungsdatei. (Quelle: Kommentar ):

Führen Sie dann COMPOSE_API_VERSION=auto docker-compose run gpu mit der folgenden Datei aus:

version: '3.7'

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

Ich bestätige, dass dies auf meinem lokalen Computer funktioniert hat. Ich weiß nicht, ob es mit Swarm funktioniert.

Es kann kein bestimmtes Commit für Docker-Compose in der Produktion geben. Muss # 7124 neu basiert werden oder gibt es eine andere PR, die das neue docker-py ?

Hallo @bkakilli ,

Danke für die Hilfe! Ich habe gerade Ihren Vorschlag ausprobiert, aber beim Ausführen meines Docker-Compose wird eine Fehlermeldung angezeigt

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

Analyse ist der Name meines Containers

Ich habe mein docker-compose.yml geändert von:

version: '2.3'

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

zu:

version: '3.7'

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

Gibt es außer pip install git+ noch etwas anderes, um dies richtig einzurichten? Oder habe ich die Konfigurationsdatei schlecht bearbeitet?

@frgfm Stellen Sie sicher, dass Sie compose und docker-py über die richtigen Links installieren. Möglicherweise haben Sie anstelle von Yoanisgils Gabel (und Zweig) das eigene Repo des Docker-Compose verwendet. Überprüfen Sie, ob Sie den folgenden Link verwenden:

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

Sie können versuchen, --upgrade param für die Pip-Installation zu verwenden. Andernfalls würde ich die Einstellungen der virtuellen Umgebung vermuten. Vielleicht haben Sie eine andere Docker-Compose-Installation, die standardmäßig verwendet wird? Möglicherweise haben Sie es mit den "Linux" -Anweisungen hier für das System installiert: https://docs.docker.com/compose/install/. Ich empfehle Ihnen, einen Blick auf "Alternative Installationsoptionen" zu werfen und über pip in der virtuellen Umgebung zu installieren (verwenden Sie jedoch den obigen Befehl pip install. Installieren Sie nicht das Standard-Docker-Compose von PyPI).

Hallo!
Danke für all die Infos. Ich habe versucht, Ihren Ansatz @bkakilli auszuführen, und docker-compose build funktioniert, aber beim Ausführen von docker-compose up Fehlermeldung angezeigt :
docker.errors.InvalidVersion: device_requests param is not supported in API versions < 1.40

Meine docker_compose.yml sieht folgendermaßen aus:

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

Danke im Voraus!

@ugmSorcero Setzen Sie die Umgebungsvariable COMPOSE_API_VERSION=1.40 und führen Sie Ihre Befehle erneut aus

@ugmSorcero haben Sie es geschafft, diesen Fehler zu beheben? @EpicWink @bkakilli Ich erhalte aber trotzdem den Fehler für device_requests param is not supported in API versions < 1.40 selbst wenn ich eine solche Variable nach 1.40 exportiere

Für die angegebene Erstellungsdatei

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

Unter Verwendung der wie oben installierten Version von docker-compose in Bash unter Linux ist der folgende Befehl erfolgreich:

COMPOSE_API_VERSION=1.40 docker-compose up

Der folgende Befehl schlägt fehl:

docker-compose up

Dies hat Fehlerausgabe:

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 vielen Dank. Mir war nicht klar, dass docker-compose up auf diese Weise ausgeführt werden musste. Ich habe es als einen 2-Schritt genommen, bei dem ich zuerst COMPOSE_API_VERSION separat exportiert habe. Es zusammen zu laufen scheint zu funktionieren :)

Ich habe jedoch ein anderes Problem. Wenn ich COMPOSE_API_VERSION=1.40 docker-compose run nvidiatest ausführe, wird nvidia-smi nicht im Pfad gefunden, während es kein Problem gibt, wenn ich direkt vom Image aus starte.

So reproduziere ich es.

Die lokale Docker-Compose-Datei enthält:

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

Wenn ich mein aktuelles Setup ausführe (sowohl API-Version Auto als auch 1.40), wird folgende Fehlermeldung angezeigt:

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

Ist es möglich, dass es mit der Verwendung von Override-Dateien zu tun hat? Wenn ich nur das Cuda-Basis-Image mit Docker ausführe, ist es kein Problem, eine Ausgabe von 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      |
|=============================================================================|
+-----------------------------------------------------------------------------+

Ich habe docker-compose gemäß den obigen Anweisungen von git installiert, nachdem ich die aus den offiziellen Dokumenten installierte Version deinstalliert hatte. Hier sind die Informationen der installierten Version:

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

Vermisse ich etwas Danke für die Hilfe!

@jjrugui dies wird nicht mehr zum Thema und ich kann Ihr Problem nicht replizieren. Entschuldigen Sie, dass Sie nicht helfen können

@EpicWink kein Problem, und sorry für die Abweichung vom Thema :). Wenn ich mein spezielles Problem herausfinde, werde ich es hier posten, wenn es relevant ist.

Arbeitet jemand an einer anderen PR oder debuggen wir den Zweig device-requests , um uns auf eine PR vorzubereiten?

Während die PR stecken bleibt, habe ich Änderungen von # 7124 auf die neueste Version aus dem Zweig master portiert, um Abhängigkeiten usw. zu entsprechen. - https://github.com/beehiveai/compose Sie können mit pip install git+https://github.com/beehiveai/compose.git installieren docker-compose.yml in 3.8 :

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

In dieser Einstellung funktioniert alles wie erwartet.

Wie gestern auf dem Compose-Spec-Governance-Meeting besprochen , werden wir mit der Ausarbeitung eines Vorschlags beginnen, der mit # 7124 vergleichbar ist und nahe an generic_resouces bereits im Abschnitt deploy verfügbar ist.

@ndeloof Das ist toll! Wenn es möglich ist, posten Sie bitte den Link zum Vorschlag hier. Ich denke, viele Menschen würden gerne dazu beitragen, da die GPU-Unterstützung für Deep-Learning-Bereitstellungen von entscheidender Bedeutung ist.

@ndeloof historisch gesehen, wie lange braucht der Lenkungsausschuss, um eine Entscheidung zu treffen, 6 Monate, ein Jahr?

+1

+1

@visheratin Gibt es eine Chance, dass Sie Ihr

@proximous Was meinst du mit "fällt aus der Konfiguration aus"? Haben alle Compose-Dateien Version 3.8? Können Sie das Beispiel teilen, damit es einfacher zu reproduzieren ist?

Beim Versuch, die Option --scale mit docker-compose up zu verwenden, tritt ein Problem mit dem Code in compose / service.py auf. Wird das nicht unterstützt?

Traceback (letzter Anruf zuletzt):
Datei "/ usr / local / bin / docker-compose", Zeile 11, in
load_entry_point ('docker-compose == 1.27.0.dev0', 'console_scripts', 'docker-compose') ()
Datei "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", Zeile 67, in main
Befehl()
Datei "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", Zeile 123, in perform_command
Handler (Befehl, Befehlsoptionen)
Datei "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", Zeile 1067, in up
to_attach = up (False)
Datei "/usr/local/lib/python3.6/site-packages/compose/cli/main.py", Zeile 1063, in up
cli = native_builder,
Datei "/usr/local/lib/python3.6/site-packages/compose/project.py", Zeile 648, in up
get_deps,
Datei "/usr/local/lib/python3.6/site-packages/compose/parallel.py", Zeile 108, in parallel_execute
Erhöhen Sie error_to_reraise
Datei "/usr/local/lib/python3.6/site-packages/compose/parallel.py", Zeile 206, im Produzenten
Ergebnis = func (obj)
Datei "/usr/local/lib/python3.6/site-packages/compose/project.py", Zeile 634, in do
override_options = override_options,
Datei "/usr/local/lib/python3.6/site-packages/compose/service.py", Zeile 579, in execute_convergence_plan
erneuern_anonyme_Volumen,
Datei "/usr/local/lib/python3.6/site-packages/compose/service.py", Zeile 509, in _execute_convergence_recreate
Waage (Container), abgenommen, starten
Datei "/usr/local/lib/python3.6/site-packages/compose/service.py", Zeile 479, in _execute_convergence_create
"Erstellen"
Datei "/usr/local/lib/python3.6/site-packages/compose/parallel.py", Zeile 108, in parallel_execute
Erhöhen Sie error_to_reraise
Datei "/usr/local/lib/python3.6/site-packages/compose/parallel.py", Zeile 206, im Produzenten
Ergebnis = func (obj)
Datei "/usr/local/lib/python3.6/site-packages/compose/service.py", Zeile 477, in
lambda service_name: create_and_start (self, service_name.number),
Datei "/usr/local/lib/python3.6/site-packages/compose/service.py", Zeile 456, in create_and_start
container = service.create_container (number = n, quiet = True)
Datei "/usr/local/lib/python3.6/site-packages/compose/service.py", Zeile 333, in create_container
previous_container = previous_container,
Datei "/usr/local/lib/python3.6/site-packages/compose/service.py", Zeile 936, in _get_container_create_options
one_off = one_off)
Datei "/usr/local/lib/python3.6/site-packages/compose/service.py", Zeile 1014, in _get_container_host_config
element.split (',') für Element in device_request ['functions']]
Datei "/usr/local/lib/python3.6/site-packages/compose/service.py", Zeile 1014, in
element.split (',') für Element in device_request ['functions']]
AttributeError: Das Objekt 'list' hat kein Attribut 'split'.

Nach dem weiteren Debuggen stellte ich fest, dass bei Verwendung der --scale aus irgendeinem Grund eine Instanz die device_requests ['functions'] als ['gpu'] hat. Wenn jedoch alle anderen Container gestartet werden sollen, sieht die device_request ['functions'] stattdessen wie [['gpu']] aus.

Ich habe lokal eine vorübergehende Korrektur vorgenommen, um dieses Problem zu umgehen und meine Container ab Zeile 1010 in compose / service.py zum Laufen zu bringen:

`` `
für device_request in device_requests:
Wenn 'Funktionen' nicht in device_request enthalten sind:
fortsetzen
if type (device_request ['functions'] [0]) == list:
device_request ['functions'] = [
element.split ('.') für Element in device_request ['functions'] [0]]
sonst:
device_request ['functions'] = [
element.split ('.') für Element in device_request ['functions']]

`` ``

@proximous Was meinst du mit "fällt aus der Konfiguration aus"? Haben alle Compose-Dateien Version 3.8? Können Sie das Beispiel teilen, damit es einfacher zu reproduzieren ist?

@visheratin siehe dieses Beispiel, bin ich falsch, ein anderes Ergebnis zu erwarten?

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

benutze nur die nogpu.yml:

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

benutze nur die gpu.yml:

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

Chain Config Ymls beginnend mit einem Nicht-GPU-Yml (Hinweis ... es fehlt die Laufzeit):

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

erwartete Ausgabe:

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

(Offensichtlich versuche ich etwas Ausgefeilteres und dies ist nur ein vereinfachter Fall, um das unerwartete Verhalten hervorzuheben.)

@jlaule @proximous Um diesen Thread auf dem neuesten Stand zu halten, erstellen Sie bitte Probleme im gegabelten Repo. Ich werde sie untersuchen, wenn ich Zeit habe.

Für diejenigen, die etwas brauchen, während sie warten, richte ich einfach K3S (Edge-Version von Kubernetes) mit GPU-Unterstützung in 30 Minuten mit Docker als Container-Laufzeit ein (dh benutze die Option --docker für das Installationsskript). Folgen Sie https://github.com/NVIDIA/k8s-device-plugin , damit das Nvidia-Geräte-Plugin funktioniert.
Hoffentlich hilft das!

@EpicWink kein Problem, und sorry für die Abweichung vom Thema :). Wenn ich mein spezielles Problem herausfinde, werde ich es hier posten, wenn es relevant ist.

Haben Sie das jemals gelöst?

Es gibt keine "/ usr / bin / nvidia-container-runtime" mehr. Das Problem ist immer noch kritisch.

Installieren Sie nvidia-docker2 wie hier beschrieben

Ich habe dies in letzter Zeit in Angriff genommen und dachte, ich teile meinen Ansatz.
Mein Problem war, dass ich Docker Stack bereitstellen musste und es nicht hören wollte. Docker Compose Ich hatte die Arbeit mit dem Docker API-Version Hack, aber es fühlte sich nicht richtig an und Stack Deploy würde nicht funktionieren, unabhängig davon.

Also, ohne irgendwelche Laufzeit-PR-Geräteanforderungen in meinem Docker-Compose festzulegen, habe ich Folgendes zu meinem Daemon hinzugefügt:

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

Sie können auch GPU- {erster Teil von gpu guid} verwenden
aber das war einfacher. Ich musste kein Pip + oder ähnliches installieren, außer das NV-Container-Toolkit. es wird eingesetzt und wirkt wie ein Zauber.

Tks viel @haviduck , habe es gerade auf meinem eigenen Computer versucht (Ubuntu 20.04, Docker CE 19.03.8) und es hat wie ein Zauber funktioniert.
Für andere: Vergessen Sie nicht, Ihren Docker-Daemon neu zu starten.

@pommedeterresautee ah

Ich muss sagen, nach 3 Wochen ununterbrochenem Andocken bin ich ziemlich verblüfft, wie nichts zu funktionieren scheint.

@ Raviduck : Danke! Endlich eine einfache Lösung, die einfach funktioniert. Ich habe so viel Zeit damit verbracht, Geräte usw. hinzuzufügen, dass ich aufgegeben habe. Dann kommt dies, versucht es und nach ein paar Minuten habe ich Hardware-Transcodierung in Plex arbeiten.

Ich werde meine 2 Cent zu dieser Angelegenheit hinzufügen ... Ich habe viel Post gelesen und schließlich war die Lösung ziemlich einfach.

es hat bei mir geklappt mit: (vielleicht hätte auch ein bisschen niedriger geklappt - keine Ahnung ...)
Docker-Compose Version 1.27.4, Build 40524192

1. Installieren Sie auf dem Docker -Hostcomputer die Pakete nvidia-container-toolkit und nvidia-container-runtime
2. auf Docker-Host-Computer: Typ
   nvidia-smi und untersuchen Sie die CUDA-Version, die rechts angezeigt wird
   
3. Auf dem Docker-Host-Computer: Geben Sie Folgendes ein: (Ersetzen Sie die Cuda-Version durch die von Ihnen installierte.)
   docker run --rm --gpus all nvidia / cuda: 10.1-base nvidia-smi
   Sie sollten die gleiche Ausgabe erhalten wie beim Ausführen von nvidia-smi auf dem Host-Computer
4. In der Datei /etc/docker/daemon.json sollten Sie Folgendes sehen:
   "runtimes": {"nvidia": {"path": "/ usr / bin / nvidia-container-runtime", "runtimeArgs": []}}
5. In Ihrem Docker-Compose-YML sollten Sie Folgendes hinzufügen:
   Laufzeit: nvidia

das ist es !
Wenn Sie die Bereitstellung mithilfe von YML durchführen, erhalten Sie GPU-Unterstützung in Ihrem Docker-Compose

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

Oh Mann, in diesem ganzen Thread geht es um Version 3, die keine Laufzeit hat.

In den Versionen 1.27.0+ wurden die Dateiformate v2 / v3 zusammengeführt, sodass Sie jetzt überall runtime . Darüber hinaus wurde auch die Spezifikation für Beschleuniger gelandet (https://github.com/compose-spec/compose-spec/pull/100), obwohl sie noch nicht in docker-compose implementiert ist.

Ich werde meine 2 Cent zu dieser Angelegenheit hinzufügen ... Ich habe viel Post gelesen und schließlich war die Lösung ziemlich einfach.

es hat bei mir geklappt mit: (vielleicht hätte auch ein bisschen niedriger geklappt - keine Ahnung ...)
Docker-Compose Version 1.27.4, Build 4052419

1. Installieren Sie auf dem Docker -Hostcomputer die Pakete nvidia-container-toolkit und nvidia-container-runtime
2. auf Docker-Host-Computer: Typ
   nvidia-smi und untersuchen Sie die CUDA-Version, die rechts angezeigt wird
   
3. Auf dem Docker-Host-Computer: Geben Sie Folgendes ein: (Ersetzen Sie die Cuda-Version durch die von Ihnen installierte.)
   docker run --rm --gpus all nvidia / cuda: 10.1-base nvidia-smi
   Sie sollten die gleiche Ausgabe erhalten wie beim Ausführen von nvidia-smi auf dem Host-Computer
4. In der Datei /etc/docker/daemon.json sollten Sie Folgendes sehen:
   "runtimes": {"nvidia": {"path": "/ usr / bin / nvidia-container-runtime", "runtimeArgs": []}}
5. In Ihrem Docker-Compose-YML sollten Sie Folgendes hinzufügen:
   Laufzeit: nvidia

das ist es !
Wenn Sie die Bereitstellung mithilfe von YML durchführen, erhalten Sie GPU-Unterstützung in Ihrem Docker-Compose

Zu Ihrer Information, die Cuda-Version, die Sie in der Ausgabe von nvidia-smi bezieht sich auf die Version des NVIDIA-Cuda-Treibers, auch bekannt als Ihr NVIDIA-Treiber (sie nennen es auch Cuda, was verwirrend ist). Die Versionsnummer im Docker-Image, z. B. nvidia/cuda:10.1-base nvidia-smi bezieht sich auf die Version des NVIDIA-Toolkits (wiederum verwirrend dasselbe Versionsnummerierungssystem, verschiedene Bestien).

Der Treiber ist abwärtskompatibel mit dem Toolkit, sodass Sie jedes nvidia/cuda:<version>-base nvidia-smi ausführen können, solange <version> kleiner oder gleich der Treiberversion ist.

Weitere Infos hier: https://stackoverflow.com/questions/53422407/different-cuda-versions-shown-by-nvcc-and-nvidia-smi

Ich sehe keine Docker Compose 1.27.4-Binärdateien für ARM-basierte Systeme.

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)

Hallo @collabnix!

Was ist die Ausgabe von pip --version ?

Compose 1.27 hat die Unterstützung für Python 2 eingestellt, sodass Sie möglicherweise die Versionen 1.27.x nicht sehen, wenn Ihr System über Python 2 verfügt.

@collabnix , weil Sie Compose bereits installiert haben, versuchen Sie pip install --upgrade docker-compose

Jetzt kann ich auf 1.27.4 upgraden. Das Pip-Upgrade hat es geschafft. Danke @kshcherban & @ chris-crone
Es ist verrückt zu sehen, dass die meisten Projekte, an denen ich in der Vergangenheit gearbeitet habe und die Python 2.7 verwenden, wirklich ein Upgrade benötigen.

Das Upgrade von Docker-Compose auf 1.27.4 löste das Problem.
(Möglicherweise wird ein Upgrade auf 1.19.3 später durchgeführt, um das Problem zu beheben.)

$ 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
Laufen Sie gut mit Docker-Compose.
auf dem Host-Computer überprüfen Sie die von nvidia-smi verwendete GPU.

@ bttung-2020
@ PyCod
Wenn ich den dokcer-nvidia-devel (nicht zur Laufzeit) verwende: nvidia / cuda: 10.1-cudnn7-devel-ubuntu18.04 im Docker-Hub
Ist es Arbeit? Wie soll ich die Datei docker-compose.yaml bearbeiten?