Compose: DockerComposeでのNVIDIAGPUのサポート

（現在の）レガシー「nvidiaruntime」がDocker 19.03.0とnvidia-container-toolkit-1.0.0-2壊れているように見えるため、これはますます重要になっています： https ：

$ 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

これで何か作業が起こっていますか？

新しいUbuntu18.04LTSマシンで新しいDockerCE 19.03.0を入手し、現在の一致するNVIDIA Container Toolkit（néenvidia-docker2）バージョンを使用していますが、docker-compose.yml3.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を使用して、作業を続行します。 詳細はこちら。

ping @KlaasH @ulyssessouza @Goryudyuma @ chris-

それは緊急の必要性です。 あなたの努力に感謝！

docker> = 19.03に移行し、 nvidia-docker2を削除して、代わりにnvidia-container-toolkitを使用した後、ユーザーが手動で/etc/docker/daemon.json入力するようにすることを目的としていますか？

これは多くのインストールを壊すようです。 特に、 --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 = all

「/ usr / bin / nvidia-container-runtime」のようなものはもうありません。 問題は依然として重大です。

docker-composeを修正するまで、docker-composeでnvidia環境を実行するのに役立ちます

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 = all

これは私には機能しませんが、 docker-compose upを実行しようとするとUnsupported config option for services.myservice: 'runtime'取得します

何か案は？

これは私には機能しませんが、 docker-compose upを実行しようとするとUnsupported config option for services.myservice: 'runtime'取得します

何か案は？

/etc/docker/daemon.jsonを変更した後、dockerサービスを再起動します
systemctl restart docker
Compose format 2.3を使用し、ランタイム：nvidiaをGPUサービスに追加します。 DockerComposeはバージョン1.19.0以降である必要があります。
docker-composeファイル：
バージョン：「2.3」

サービス：
nvsmi：
画像： ubuntu：16.04
ランタイム：nvidia
環境：
-NVIDIA_VISIBLE_DEVICES = all
コマンド：nvidia-smi

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

ああ！ ありがとう@Kwull 、私はそのdefault-runtime部分を逃しました...すべてが今働いています:)

@uderik 、 runtimeは、現在の3.7構成ファイル形式スキーマにも、最終的にDocker 19.03と整合する予定の保留中の3.8バージョンにも存在しなくなりました： https ：

@johncolby runtimeは3.xフラグではありませんでした。 2.xトラック（2.3および2.4）にのみ存在します。

ええ、私は知っています、そして私のdocker-compose.ymlファイルにはversion: '2.3' （過去に機能していました）が含まれていますが、最新バージョンでは無視されているようです...
将来のプロジェクトでは、GPUへのアクセスを有効/無効にする正しい方法は何でしょうか？ デフォルト+環境変数にするだけですか？ または、 --gpusフラグのサポートはありますか？

@johncolby 3.Xのruntime代わりは何ですか？

@ 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 ：

すでにマージされているcompose3.8スキーマサポートに関するcomposeの問題は次のとおりです： https ：

デーモン側では、 gpu機能をdaemon.jsonまたはdockerd CLIに含めることで登録できます（以前のハードコードされたランタイム回避策のように）。

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

次に、NVIDIAdockerユーティリティにフックすることで登録されます。
https://github.com/moby/moby/blob/09d0f9/daemon/nvidia_linux.go

機械は基本的に設置されているようですが、おそらく文書化する必要があります...

すべてのアップデート？

また、公式の修正までbashとdocker run --gpusを使用して、更新を待っています...

更新を待っています。

また、更新を待っています:)

わかりました...なぜこれがまだ開いているのかわかりません。 これらの3つの追加行により、スキーマバージョン3.7で機能します。 dockerがコミュニティの些細な問題に対応していることを知ってうれしいです。 したがって、このリポジトリのクローンを作成し、これらの3行を追加して、python3 setup.pyビルド&&インストールし、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'),

それを追跡するために内部の問題を追加しました。
PRは大歓迎です：smiley：

わかりました...なぜこれがまだ開いているのかわかりません。 これらの3つの追加行により、スキーマバージョン3.7で機能します。 dockerがコミュニティの些細な問題に対応していることを知ってうれしいです。 したがって、このリポジトリのクローンを作成し、これらの3行を追加して、python3 setup.pyビルド&&インストールし、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のタイプも更新する必要があるようです。

docker -pyにも変更が必要になるため、
https://github.com/docker/docker-py/pull/2419

変更されたブランチは次のとおりです。
https://github.com/sigurdkb/docker-py/tree/gpus_parameter

したがって、これにパッチを適用する場合は、 https：//github.com/sigurdkb/docker-py/tree/gpus_parameterから変更されたdocker-pyに対してdocker-composeをビルドする必要があり

ここで何が起こっているのかわかりません：

1） /etc/docker/daemon.json

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

ただし、 https：//github.com/docker/compose/issues/6239の場合と同様に、v3.xではruntimeキーを使用できなくなりました。

私も試しました：

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

そのため、 docker-composeでgpuサポートを使用してコンテナを起動できなくなりました。

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）に基づいてDockerイメージを作成しました
nvidia / cudagl：10.1-runtime-ubuntu18.04

上記で推奨されているアプローチを使用する-それは私の画像がnvidia / cudagl：10.1-runtime-ubuntu18.04から派生する必要がないことを意味しpython：3.7.3-stretchから簡単に派生でき
そしてランタイムを追加します：nvidiaをdocker-composeのサービスに追加しますか？

ありがとう

@rfschいいえ、それは別のことです。 docker-composeのruntime: nvidiaは、Dockerランタイムを指します。 これにより、GPUをコンテナで使用できるようになります。 ただし、利用可能になった後でも、それらを使用するための何らかの方法が必要です。 runtimeでnvidia/cudagl:10.1-runtime-ubuntu18.04 CUDAランタイムコンポーネントを指します。 これにより、CUDAを使用してGPU（Dockerによってコンテナーで使用可能になります）を使用できます。

この画像では：

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 ：

すでにマージされているcompose3.8スキーマサポートに関するcomposeの問題は次のとおりです。＃6530

デーモン側では、 gpu機能をdaemon.jsonまたはdockerd CLIに含めることで登録できます（以前のハードコードされたランタイム回避策のように）。

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

次に、NVIDIAdockerユーティリティにフックすることで登録されます。
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)

助言がありますか？

ありがとう
デビッド

https://github.com/NVIDIA/nvidia-container-runtimeからnvidia-container-runtime 3.1.4.1をインストールし、

runtime: nvidia

この危険な外観のコマンドを使用してhttps://docs.docker.com/compose/install/からインストールされたdocker-compose 1.23.1と1.24.1 、ここでdocker-compose 1.23.1正常に機能します。

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

たとえば、dockerhubのnvidia / cudagl /10.1-baseコンテナ。 私はcudaとOpenGLレンダリングを試しましたが、それはすべてネイティブパフォーマンスに近いものです。

COMPOSE-82として内部的に追跡
一貫性を保つために、このような変更はdocker stack （https://github.com/docker/cli/blob/master/cli/compose/types/types.go#L156）にも実装する必要があることに注意してください。

https://github.com/NVIDIA/nvidia-container-runtimeからnvidia-container-runtime 3.1.4.1をインストールし、

runtime: nvidia

この危険な外観のコマンドを使用してhttps://docs.docker.com/compose/install/からインストールされたdocker-compose 1.23.1と1.24.1 、ここでdocker-compose 1.23.1正常に機能します。

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

たとえば、dockerhubのnvidia / cudagl /10.1-baseコンテナ。 私は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は、以前にandyneffが指摘した

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

ニーズによっては、これらのオプションの一部が不要な場合があります。 @muruが予測したように、トリックは古いバージョンを指定することです。 少なくとも私のユースケースでは、これは問題ではありませんが、回避策としてこの構成を提供するだけです。実際には、最新バージョンを使用して可能にする必要があります。

おかげでみんな、@ JDR-顔、@muru、コンv2は作業を行い、
私はあなたの解決策がv3作曲のためのものであると誤解しました。

ちなみに、伝統的に言えば、composev2はcomposev3よりも古いものではありません。 それらは異なるユースケースです。 v3は群れを対象としていますが、v2はそうではありません。 v1は古いです。

Dockerのサポートについての議論はありますか？DockerのネイティブGPUサポートのためのcompose？

runtimeオプションをサポートすることは、将来のGPUサポートのソリューションではありません。 NVIDIAは、 https： //github.com/NVIDIA/nvidia-dockerでnvidia-docker2の将来について次のように説明しています。

Docker 19.03のリリースでは、NVIDIA GPUがDockerランタイムのデバイスとしてネイティブにサポートされるようになったため、nvidia-docker2パッケージの使用は非推奨になっていることに注意してください。

現在、GPUサポートはランタイムを変更することで実現できますが、将来的には機能しなくなる可能性が高くなります。

率直に言って、これはベストプラクティスではないかもしれませんが、どういうわけか私たちはそれを機能させます。

トリッキーな部分は、docker swarmを使用しているため、docker-compose v3.xに固執する必要があることです。一方、コンテナーでGPU / CUDAをサポートするためにNvidiaランタイムを使用する必要があります。

docker-composeファイル内でNvidiaランタイムを明示的に通知しないようにするために、Nvidiaを/etc/docker/daemon.jsonのデフォルトランタイムとして設定すると、次のようになります。

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

GPUマシンで実行されているすべてのコンテナーが、デフォルトでNvidiaランタイムを有効にするようにします。

これが同様のブロッカーに直面している誰かを助けることができることを願っています

率直に言って、これはベストプラクティスではないかもしれませんが、どういうわけか私たちはそれを機能させます。

トリッキーな部分は、docker swarmを使用しているため、docker-compose v3.xに固執する必要があることです。一方、コンテナーでGPU / CUDAをサポートするためにNvidiaランタイムを使用する必要があります。

docker-composeファイル内でNvidiaランタイムを明示的に通知しないようにするために、Nvidiaを/etc/docker/daemon.jsonのデフォルトランタイムとして設定すると、次のようになります。

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

GPUマシンで実行されているすべてのコンテナーが、デフォルトでNvidiaランタイムを有効にするようにします。

これが同様のブロッカーに直面している誰かを助けることができることを願っています

これは確かに私たちも行っていることです。 今のところは機能しますが、私には少しハッキーな感じがします。 すぐに完全なcompose-v3サポートを期待しています。 :)

docker> = 19.03に移行し、 nvidia-docker2を削除して、代わりにnvidia-container-toolkitを使用した後、ユーザーが手動で/etc/docker/daemon.json入力するようにすることを目的としていますか？

これは多くのインストールを壊すようです。 特に、 --gpusはcomposeでは利用できないためです。

--gpusはcomposeでは使用できません
pycharmを使用してdockerをリンクしてtensorflow-gpuを実行することはできません

この問題に関する更新はありますか？ --gpusがdocker-composeですぐにサポートされる可能性はありますか？

これを回避する方法を探している方のために、私たちがやったことは次のとおりです。

• このPRからdocker-pyをインストールします： https ：
• このPRからdocker-composeをインストールします： https ：

次に、次のファイルを使用して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では、NVIDIAGPUのサポートが新しいCLIAPI--gpusの形式で導入されました。 docker / cli＃1714は、この有効化について説明しています。

これで、GPUで高速化されたDockerベースのアプリケーションに--gpusオプションを渡すだけで済みます。

$ 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がNVIDIAGPUをサポートできるようにするための機能リクエストです。

私はこの問題を解決しました。次のように試すことができます。私のcsdnブログアドレス： https ：//blog.csdn.net/u010420283/article/details/104055046

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

次に、このdaemon.jsonファイルに次のコンテンツを追加します。

{{
"default-runtime"： "nvidia"
「ランタイム」：{
"nvidia"：{
"パス"： "/ usr / bin / nvidia-container-runtime"、
"runtimeArgs"：[]
}
}
}

〜$ sudosystemctlデーモン-リロード
〜$ sudo systemctl restart docker

前述の回避策を設定したいansibleユーザーには、 nvidia-container-runtimeをインストールし、 runtime: nvidiaを使用するように/etc/docker/deamon.jsonを構成する

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"

GPUをサポートする公式3.xバージョンのアップデートはありますか？ 私たちは群れで必要です:)

この機能を追加する予定はありますか？

この機能は、 device_requestsパラメーターを実装するdocker-pyに依存します。これは、 --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のランタイムを変更することができました。 これを取り戻すのは非常に素晴らしいことです。

必要です。 本当に必要です：/

私も積み上げたいです...この機能が必要です！

CPUコンテナとGPUコンテナの両方を同じマシンで実行する必要があるため、デフォルトのランタイムハックは機能しません。 これがいつcomposeで機能するか、私たちは何か考えがありますか？ 作成時にランタイムフラグがないことを考えると、これは深刻な機能の低下を表していますね。 これを機能させるには、スクリプトを作成する必要があります。

CPUコンテナとGPUコンテナの両方を同じマシンで実行する必要があるため、デフォルトのランタイムハックは機能しません。 これがいつcomposeで機能するか、私たちは何か考えがありますか？ 作成時にランタイムフラグがないことを考えると、これは深刻な機能の低下を表していますね。 これを機能させるには、スクリプトを作成する必要があります。

docker cli（docker run --gpu ....）で実行できますが、この種のトリックがあります（プロキシを追加して、群れの他のノードで実行されている他のコンテナーと通信できるようにします）。 docker serviceコマンド（私が知っているように）でもcomposeでも機能しないため、swarmで実行できるようになるのを待っています。

@dottgonzo 。 はい、そうです ;-）。 私はこれを認識しているため、スクリプトへの参照があります。 しかし、これはかなりひどく移植性のない方法なので、もっと動的な方法でやりたいと思います。 私が言ったように、これは機能の質問ではなく、回帰を表していると思います。

COMPOSE_API_VERSION=auto docker-compose run gpu

@ggregoireどこで実行しますか：COMPOSE_API_VERSION = auto docker-compose run gpu？

シェルからの

現在、すべてのプロジェクトについて、3.x機能が必要かどうか、またはGPUオプションが引き続きサポートされているdocker-compose2.xを使用できるかどうかを決定しています。 GPUが必要な場合、Dockerfileからマルチステージターゲットを実行するなどの機能は残念ながら使用できません。 これを追加してください！

docker-composeの「追加オプション」フィールドのようなものをお勧めします。docker-composeではまだ/もうサポートされていない--gpus=allようなフラグをdocker start / runコマンドに追加できます。ただし、最新のDockerバージョンです。 このように、composeユーザーは、まだサポートされていない新しいdocker機能が必要な場合に、docker-composeが追いつくのを待つ必要がありません。

実稼働環境のDockerSwarmでこれを実行する必要があります。 これはDockerSwarmで役立ちますか？

@sebastianfelipecomposeを使用してスウォームにデプロイする場合に非常に便利です。
比較：
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

@sebastianfelipecomposeを使用してスウォームにデプロイする場合に非常に便利です。
比較：
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-composeyamlファイルを使用してDockerSwarmですでに動作していますか？ 念のために：O。 ありがとう！

docker compose2.xの場合のみ

この問題の全体的なポイントは、docker-compose3 +のnvidia-dockergpuサポートを要求することです。

当初のご要望からほぼ1年になります!! なぜ遅れるの？ これを前進させることはできますか？

ping @KlaasH @ulyssessouza @Goryudyuma @ chris-

これを回避する方法を探している方のために、私たちがやったことは次のとおりです。

• このPRからdocker-pyをインストールします： 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が整っているので、どの基準でも難しいことではないようです。

ping @KlaasH @ulyssessouza @Goryudyuma @ chris-

いいえ、なぜ呼ばれたのかわかりません。
どうしたらいいか教えてほしいの？

これに関する更新があることを願っています。

ええ、もう1年以上経ちます...なぜ彼らはdocker-pyにマージされないのですか...

提案された実装がCompose形式に適しているかどうかはわかりません。 幸いなことに、このようなものを追加することを目的として、Compose形式の仕様を公開しました。 仕様はhttps://github.com/compose-specで見つけることができ

私が提案するのは、仕様に問題を追加してから、今後開催されるComposeコミュニティミーティングの1つでそれについて話し合うことです（このページの下部にある招待へのリンク）。

これは機能します： 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（または他のデバイス）に対するサービスの必要性を作成形式で宣言する方法です。具体的には、このように変更

こんにちはみんな、私はここで提案されたいくつかの解決策を試しましたが、何もうまくいきませんでした。たとえば、私の場合は機能しません。また、GPUを使用して既存のDockerコンテナを実行する方法はありますか？
私は16GBのRAMを搭載したi7を持っていますが、一部のプロジェクトのビルドは完了するのに時間がかかりすぎます。私の目標は、GPUパワーを使用してプロセスを高速化することです。それは可能ですか？ ありがとう！

@ chris-crone：繰り返しになりますが、修正するつもりですが、ランタイム：パラメーターが2.4構成後に作成から消えたため、修正されませんでしたか？ だから退行だと感じました。 とにかく私たち全員が3.xにいるはずなので、今は問題ではありません。

問題を提出していただければ幸いです。スペックリポジトリのスペックに対してそれを行いますか？

しかし、それは、ランタイム：パラメーターが2.4構成後にcomposeから消えたためではありませんか？ だから退行だと感じました。

はい、正確に。 docker-composeファイルでruntime: nvidiaを使用することに依存しているプロジェクトがいくつかありますが、GPUを使用する方法が見つからないため、この問題により3.xへのアップグレードが妨げられます。

こんにちは、お願いします、これを修正してください。
これは、ミッションクリティカルな優先度-20とマークする必要があります

繰り返しになりますが、私は喜んで修正しますが、ランタイム：パラメーターが2.4構成後にcomposeから消えたためではありませんでしたか？ だから退行だと感じました。 とにかく私たち全員が3.xにいるはずなので、今は問題ではありません。

変更が行われたとき、私はここにいなかったので、なぜそれが削除されたのか100％確信が持てません。 GPUを使用するためにNVIDIAランタイムはもう必要ないこと、そして仕様の単一バージョンを作成することを目的として、ここで公開されているComposev3仕様を進化させていることを私は知っています。 これは、一部のv2機能をv3に移行することを意味する場合があります。

runtimeフィールドに関しては、単一ノードでの実行に非常に固有であるため、これをCompose仕様に追加する方法ではないと思います。 理想的には、ワークロードにデバイスのニーズがあることを指定し（GPU、TPU、次に来るものなど）、オーケストレーターがその機能を提供するノードにワークロードを割り当てられるようにするものが必要です。

Python Docker Compose固有ではないため、この議論は仕様について行う必要があります。

@ chris-crone：私はあなたの発言にほとんど同意します。 それぞれ独自のランタイムを持つエッジデバイスが急増しているため、短期間のハッキングを追加することは、おそらくこれを行うための誤った方法です。 たとえば、ご指摘のとおり、Pi上のTPU（Google）、VPU（Intel）、およびARMGPUです。 したがって、より完全なストーリーが必要です。

今日、仕様に対して問題を提起し、そうしたらこのスレッドを更新します。 ただし、オーケストレーターは独立している必要があると思います。たとえば、久部を使用したい場合は、そうすることができるはずです。 私はそれが範囲内にあると思います。

ただし、GPUステートメントの使用には同意しません。composeでは機能しないためです。これがすべてです。 しかし、私たちは皆、私たちが解決したい問題を理解していると思います。

@ chris-crone：提出されたdocker-compose仕様の問題を参照してください。 今後、その問題に対する最新情報をフォローします。

基になるdocker run引数を直接渡すオプション（ extra_docker_run_args ）を追加するだけでいいですか？ これにより、現在の問題が解決されるだけでなく、将来にわたって利用できるようになります。dockerが「XPU」、「YPU」、または将来登場する可能性のあるその他の新機能のサポートを追加した場合はどうなるでしょうか。

dockerが新しい機能を追加するたびに長い往復の議論が必要な場合、それは非常に非効率的であり、 docker-composeとdocker更新の間に避けられない遅延（および不必要な混乱）を引き起こします。 引数の委任をサポートすることで、将来のすべての機能について、この再発する問題を一時的に緩和できます。

@miriaford解釈されていないblobを渡すことが、宣言型であるという構成概念をサポートするかどうかは

しかし、composeとdockerを同期させる

@ vk1z同意します- composeとdocker間にははるかに優れた同期メカニズムがあるはずです。 しかし、そのようなメカニズムがすぐに設計されるとは思いません。 一方、ソースコードを深くハッキングせずに、独自の同期を行う一時的な方法も必要です。

議論の委任の提案が選択肢ではない場合、私たちは何をすることを提案しますか？ 私はそれがきれいな解決策ではないことに同意しますが、それはこの回避策よりも少なくとも_はるかに_優れていますね？ https://github.com/docker/compose/issues/6691#issuecomment -616984053

@miriaford docker -composeは、引数を使用してdocker Executiveを呼び出しません。実際には、dockerデーモンへのhttpAPIを使用するdocker_pyを使用します。 したがって、「基になるdocker run 」コマンドはありません。 Docker CLIはAPIではなく、ソケット接続がAPIの連絡先です。 これが、必ずしも簡単ではない理由です。

物事を単純化するために、Dockerを実行するプロセスでは、2つの主要な呼び出しがあります。1つはコンテナーを作成し、もう1つはコンテナーを開始します。それぞれが異なる情報を取り込み、どちらがAPIの知識を持っているかを知る必要があります。 docker CLIを知っている傾向があるように私は知りません。 docker_py呼び出しに引数を追加できることは、一部のユースケースを除いて、思ったほど役立つとは思いません。

さらに難しいことに、docker_pyライブラリがAPIの背後にあり、必要なものがすべてすぐに揃っていない場合があり、更新されるのを待つ必要があります。 そうは言っても、 extra_docker_run_argsは単純な解決策ではありません。

@andyneff説明ありがとうございます。 確かに、私はDockerの内部動作にあまり精通していません。 私が正しく理解している場合、新機能の更新のために手動で同期する必要がある4つのAPIがあります。

1. DockerソケットAPI
2. ソケットAPIにPythonフロントエンドを提供するdocker_py
3. Docker CLI（Dockerツールチェーンへの使い慣れたエントリポイント）
4. Docker-DockerソケットAPIを呼び出すcomposeインターフェース

これは疑問を投げかけます：なぜ自動（または少なくとも半自動）同期メカニズムがないのですか？ 4つのAPI間で新機能の更新を手動で伝播することは、エラーが発生しやすく、遅延が発生しやすく、混乱を招く運命にあるようです...

PS自動同期を行うのが_単純な_タスクだと言っているわけではありませんが、将来的には生活を楽にするためのタスクがあるはずだと本当に思います。

私は今ちょっとペダンティックスに入っています...しかし、私がそれを説明するように...

• dockerソケットはdockerの公式APIです。 多くの場合、ファイルソケットですが、TCP（またはその他のsocatを使用することを想像します）にすることもできます。
• docker CLIはそのAPIを使用して、ユーザーにすばらしいツールを提供します
  
  
  
  • DockerはAPIとCLIを作成するため、リリース時に常に同期されます。 （CLIはDockerエコシステムの第一級市民であると言っても過言ではありません）
  
  
• docker_pyライブラリは、そのAPIを受け取り、他のPythonライブラリが使用できる素晴らしいライブラリに配置します。 これがないと、これらすべてのHTTP呼び出しを自分で行い、髪の毛を抜くことになります。
  
  
  
  • ただし、docker_pyはサードパーティのライブラリとして開始されたため、従来はdocker APIに続いており、後でまたは必要に応じて追加されます（限られたリソース）。
  
  
• composeはdocker_pyのバージョンを使用してから、必要に応じてこれらすべてのすばらしい機能を追加します（このような問題に基づいて）
  
  
  
  • ただし、composeはdocker_pyまで多くのことを実行できません（私はこの問題を抱えているとは言っていませんが、わかりません。一般的に話しているだけです）
  
  

そうです、それは行きます：

• "compose yaml + compose args"-> "docker_py"-> "docker_api"
• そして、CLIはこれの一部ではありません（そして私を信じてください、それは物事を行う正しい方法です）

docker_pyについて話すことも作成することもできませんが、それに貢献する工数が限られていると思います。そのため、dockerが絶えず追加しているすべてのクレイジーな非常識なdocker機能についていくのは難しいです。 しかし、dockerはgoライブラリであり、Pythonのサポートは（現在）一級市民ではないことを理解しています。 少なくともgithub組織の観点からは、両方のプロジェクトがDockerの傘下にあることは素晴らしいことです。

つまり、私も同等の--gpusサポートを待っているので、代わりに古いruntime: nvidiaメソッドを使用する必要があります。これにより、少なくとも移動するための「a」パスが得られます。 docker-compose2.xで転送します。

@andyneff参考までに、最新のdocker-composeにはhttps://www.docker.com/blog/faster-builds-in-compose-thanks-to-buildkit-support/

@andyneffこれは非常に役立つ概要です！ 再度、感謝します

@lig素晴らしい！ 訂正してくれてありがとう！ 私はそれを書いているときに実際に「ビルドキットはこれらすべてにどのように適合するのか」を考えていました

私が少し驚いているのは、docker-composeが新しいdocker-appフレームワークのかなり本質的な部分であり、少なくともその理由で、docker-composeとdockerを同期させたいと思っていることです。 ブロッカーが実際に何であるか疑問に思います：十分なPython帯域幅がありませんか？ 少し信じられないようです。

では、Docker Swarmは、 @ andyneffが今説明した構造にどのように適合しますか？ Swarmはcomposeファイル形式バージョン3（ "compose"プロジェクトで定義されていますか？）を使用しますが、 docker ？の一部として開発されています。

それがこの特定の問題のトピックから外れている場合はお詫びします。 どの問題がどれであるかがわからなくなってしまいましたが、群​​れで実行されているサービスに特定のランタイムを使用する必要があることを伝えたいので、これを追跡し始めました。 これは、compose-file仕様のv2でのみ実行できます。つまり、v3を必要とするSwarmでは実行できません。 言い換えれば、私はdocker-compose CLIが何をするのかにはあまり興味がなく、dockerswarmによって消費されるdocker-compose.ymlファイルに対して定義された仕様にのみ興味があります。

ああ群れ、逃げたもの...（私から）。 残念ながら、それはBOTによって閉鎖された＃6239です。 :(誰かが＃6240で試しましたが、言われました...

@miriaford 、それらを同期するためのPRがあるようです！ ＃6642？！ （これはv3専用ですか？）

したがって、スウォームの性質上、スウォームノードで実行することと実行しないことがあります。 そのため、Docker APIでは、通常の実行と同じオプションをスウォーム実行で実行できるとは限りません。 ランタイムがこれらの手元にあるものの1つであるかどうかはわかりませんが、v3（スウォーム互換バージョン）およびv2（非スウォーム互換バージョン）では実行できないことがよくあります。

これを読んでいる人は誰もあなたたちが何について話しているのか知りません。
私たちは皆、ハードウェアアクセラレーションを備えたジェリーフィンを展開しようとしています。
皆さんがこれを想定どおりに修正するまで、サービスと表示されている場合、3.xは適切ではありません。
使用しないでください。

あなたはサービスのために2.4を置く必要があります。
次に、ジェリーフィン、ezのハードウェアアクセラレーションを使用できます。

さあ、1年2年のETAはどうですか？

@KlaasH @ulyssessouza @Goryudyuma @ chris-

@fakabbirこれにはCOMPOSE_DOCKER_CLI_BUILDを使用しても問題ないと思います。 docker run引数の任意のリストを提供する機能を追加すると、将来同様の問題を回避するのに役立つ可能性もあります。

@lig 1つのサービスのみがGPUへのアクセスを必要とする場合、どのように対処しますか？

@lig AFAICS作成では、 docker run cliの代わりにdocker-py使用します。 したがって、任意のdocker run引数を追加しても、 docker-pyがそれをサポートしない限り、機能しません。

参照： https ：

この1つのことで、docker-composeの有用性が大幅に低下します。 特に古いdocker-composeで機能した場合、それを修正したいという関心や要望があまり見られなかったことは、非常に驚​​くべきことです。
任意のdocker--run引数をdocker-composeファイルで指定できるようにするのが1つの方法ではないでしょうか？ 次に、たとえば--gpusallをdockerに渡すことができます。

私は、特定の方法でそれをやりたいと思うかもしれない哲学的または技術的な理由があるかもしれないことを理解しています。 しかし、実際に手に入れず、それを何らかの方法で行わないと、心がよろめきます。

@lig 1つのサービスのみがGPUへのアクセスを必要とする場合、どのように対処しますか？

さて、環境変数NVIDIA_VISIBLE_DEVICESを使用すると、それを制御できますか？

この1つのことで、docker-composeの有用性が大幅に低下します。 特に古いdocker-composeで機能した場合、それを修正したいという関心や要望があまり見られなかったことは、非常に驚​​くべきことです。
任意のdocker--run引数をdocker-composeファイルで指定できるようにするのが1つの方法ではないでしょうか？ 次に、たとえば--gpusallをdockerに渡すことができます。

docker --run引数を渡すことを許可するのは道ではないと思います。 composeは、実際にはdocker自体を呼び出すのでdocker-pyます。

私は、特定の方法でそれをやりたいと思うかもしれない哲学的または技術的な理由があるかもしれないことを理解しています。 しかし、実際に手に入れず、それを何らかの方法で行わないと、心がよろめきます。

PRはそれについて開かれています： https ：

docker compose仕様の変更により、 compose 2.4による以前の互換性にすぐに戻る必要があり、nvidiaランタイムが機能すると思います。 明らかに、TPUやその他のアクセラレータでは機能しません。これは非常に残念ですが、（高価な）nvidiagpusを実行したい人にとっては機能します。

したがって、docker-pyのグリーンPRがマージされるのを待っているだけですhttps://github.com/docker/docker-py/pull/2471

うん！ docker-pyでのPRが承認されました！ https://github.com/docker/docker-py/pull/2471
ここで次のステップは何ですか？

ここは何ですか？ docker-composeでnvidiaランタイムをサポートできるのは素晴らしいことです

https://github.com/docker/docker-py/pull/2471が統合されました。

docker / docker-py＃2471がマージされたので、masterからdocker-pyをインストールできます。 しかし、 @ yoanisgilのクールな[PR]（https://github.com/docker/compose/pull/7124）（Kudos！）以降、 マージされる可能性はほとんどありません。 したがって、この時点で、docker-composeをそのPRからインストールして、1日を節約できます。

以前のコメントを見ずにここにたどり着いた人のために：

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をリベースする必要がありますか、それとも新しいdocker-pyを組み込む別のPRがありますか？

こんにちは@bkakilli 、

助けてくれてありがとう！ 私はあなたの提案を試しましたが、docker-composeの実行中にエラーが発生します

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

_分析は私のコンテナの名前です_

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と

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

--upgradeパラメータをpipinstallに入れてみてください。 そうでなければ、仮想環境の設定が疑われます。 デフォルトで使用されている別のdocker-composeインストールがあるかもしれませんか？ たとえば、 https ： ます。 「代替インストールオプション」を確認し、仮想環境に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 pipインストールで指定されたバージョンを実行していますが、そのような変数を1.40にエクスポートしても、 device_requests param is not supported in API versions < 1.40のエラーが発生します。

指定された作成ファイルについて

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

上記のようにインストールされたバージョンのdocker-composeを使用して、Linux上のBashで、次のコマンドが成功します。

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をそのように実行する必要があることに気づきませんCOMPOSE_API_VERSION個別にエクスポートする2つのステップとして実行しました。 一緒に実行するとうまくいくようです:)

しかし、別の問題があります。 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バージョンの自動と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

オーバーライドファイルの使用に関係している可能性はありますか？ Dockerでcudaベースイメージを実行するだけなら、 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      |
|=============================================================================|
+-----------------------------------------------------------------------------+

公式ドキュメントからインストールされたバージョンをアンインストールした後、gitから上記の手順に従ってdocker-composeをインストールしました。 インストールされているバージョンの情報は次のとおりです。

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に取り組んでいますか、それともPRの準備をするためにdevice-requestsブランチをデバッグしていますか？

PRがスタックしている間に、依存関係などに一致するように、＃7124からの変更をmasterブランチから最新バージョンに移植しました。- https：//github.com/beehiveai/compose pip install git+https://github.com/beehiveai/compose.gitインストールできます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

この設定では、すべてが期待どおりに機能します。

昨日のcompose-specガバナンス会議でdeployセクションですでに利用可能なgeneric_resouces近い可能性があります。

@ndeloofそれは素晴らしいです！ 可能であれば、ここに提案へのリンクを投稿してください。 GPUサポートはディープラーニングの展開に不可欠であるため、多くの人がこれに貢献して喜んでいると思います。

@ndeloofの歴史上、運営委員会が決定を下すのに6か月、1年かかるのはどれくらいですか。

+1

+1

@visheratin複数のcomposeymlファイルを使用するときに機能するように修正を改善できる可能性はありますか？ 非nvidiaコンテナーを使用するベースdocker-compose.ymlがあり、GPUがある場合はnvidiaコンテナーでオーバーライドしたいのですが、修正により、複数のcomposeymlファイルを「-」で指定した場合のようです。 f」の場合、「device_requests」フィールドは構成から削除されます。

@proximous 「設定から外れる」とはどういう意味ですか？ すべての作成ファイルのバージョンは3.8ですか？ 再現しやすいように例を共有できますか？

docker-compose upで--scaleオプションを使用しようとすると、compose /service.pyのコードに問題が発生します。 これはサポートされていませんか？

トレースバック（最後の最後の呼び出し）：
ファイル "/ 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
ハンドラー（コマンド、command_options）
ファイル "/usr/local/lib/python3.6/site-packages/compose/cli/main.py"、行1067、上
to_attach = up（False）
ファイル "/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
結果= func（obj）
ファイル "/usr/local/lib/python3.6/site-packages/compose/project.py"、行634、in do
override_options = override_options、
execute_convergence_planのファイル "/usr/local/lib/python3.6/site-packages/compose/service.py"、行579
renew_anonymous_volumes、
_execute_convergence_recreateのファイル "/usr/local/lib/python3.6/site-packages/compose/service.py"、行509
スケール-len（コンテナ）、デタッチ、開始
_execute_convergence_createのファイル "/usr/local/lib/python3.6/site-packages/compose/service.py"、行479
"作成"
ファイル "/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
結果= func（obj）
ファイル "/usr/local/lib/python3.6/site-packages/compose/service.py"、行477、
ラムダservice_name：create_and_start（self、service_name.number）、
create_and_startのファイル "/usr/local/lib/python3.6/site-packages/compose/service.py"、行456
container = service.create_container（number = n、quiet = True）
create_containerのファイル "/usr/local/lib/python3.6/site-packages/compose/service.py"、行333
previous_container = previous_container、
_get_container_create_options内のファイル "/usr/local/lib/python3.6/site-packages/compose/service.py"、936行目
one_off = one_off）
_get_container_host_configのファイル "/usr/local/lib/python3.6/site-packages/compose/service.py"、行1014
device_request ['capabilities']]の要素のelement.split（ '、'）
ファイル "/usr/local/lib/python3.6/site-packages/compose/service.py"、行1014、
device_request ['capabilities']]の要素のelement.split（ '、'）
AttributeError： 'list'オブジェクトに属性 'split'がありません

さらにデバッグした後、-scaleを使用すると、何らかの理由で1つのインスタンスにdevice_requests ['capabilities']が['gpu']として含まれていることがわかりました。 ただし、他のすべてのコンテナーを開始する場合、device_request ['capabilities']は代わりに[['gpu']]のようになります。

この問題を回避するために、compose / service.pyの1010行目からコンテナを起動して実行するために、ローカルで一時的な修正を行いました。

`` `
device_requestsのdevice_requestの場合：
'capabilities'がdevice_requestにない場合：
継続する
if type（device_request ['capabilities'] [0]）==リスト：
device_request ['capabilities'] = [
device_request ['capabilities'] [0]]の要素のelement.split（ '。'）
そうしないと：
device_request ['capabilities'] = [
device_request ['capabilities']]の要素のelement.split（ '。'）

「」

@proximous 「設定から外れる」とはどういう意味ですか？ すべての作成ファイルのバージョンは3.8ですか？ 再現しやすいように例を共有できますか？

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

非gpuymlで始まるチェーン構成ymls（注...ランタイムがありません）：

$ 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このスレッドをトピックに保つために、フォークされたリポジトリで問題を作成してください。時間があれば調査します。

待っている間に何かが必要な場合は、Dockerをコンテナーランタイムとして使用して（つまり、インストールスクリプトに--dockerオプションを使用して）、GPUをサポートするK3S（Kubernetesのエッジバージョン）を30分でセットアップします。 https://github.com/NVIDIA/k8s-device-pluginをフォローして、Nvidiaデバイスプラグインを機能させます。
お役に立てば幸いです。

@EpicWinkは問題ありません、そしてトピックから逸​​脱して申し訳ありません:)。 私が自分の特定の問題を理解した場合、それが関連している場合はここに投稿します。

これを解決したことはありますか？

「/ usr / bin / nvidia-container-runtime」のようなものはもうありません。 問題は依然として重大です。

ここで説明されているようにnvidia-docker2をインストールし

iveはこれに最近取り組んでおり、思考IDは私のアプローチを共有しています。
私の問題は、スタックスタックのデプロイをドッキングする必要があり、リッスンしたくないということでした。 dockercompose私はdockerapiバージョンハックで作業していましたが、それは正しく感じられず、スタックデプロイは関係なく機能しませんでした。

そのため、Docker ComposerでランタイムPRデバイス要求を設定せずに、これをデーモンに追加しました。

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

GPUを使用することもできます-{gpuguidの最初の部分}
しかし、これは簡単でした。 NVコンテナツールキットを除いて、pip +などをインストールする必要はありませんでした。 それは展開し、魅力のように機能します。

@haviduckをたくさん使って、自分のマシン（Ubuntu 20.04、docker CE 19.03.8）で試してみたところ、魅力のように機能しました。
その他の場合：dockerデーモンを再起動することを忘れないでください。

@pommedeterresauteeああ、他の人のために働いてよかったです！ リロードについて言及する必要があります。

3週間ノンストップのドッキングを行った後、何も機能していないように見えるのでかなり困惑したと言わざるを得ません。

@haviduck ：ありがとう！ 最後に、うまく機能する簡単なソリューション。 私はあきらめたデバイスなどを追加しようとして非常に多くの時間を費やしました。 次に、これが実行され、試してみます。数分後、Plexでハードウェアトランスコーディングが機能します。

私はこの問題に私の2セントを追加します...私はたくさんの投稿を読みました、そして最終的に解決策はかなり簡単でした。

それは私のために働いた:(多分少し低いかもしれません-わからない...）
docker-composeバージョン1.27.4、ビルド40524192

1. Dockerホストマシンにnvidia-container-toolkitおよびnvidia-container-runtimeパッケージをインストールします
2. Dockerホストマシンの場合：タイプ
   nvidia-smiと、右側に表示されるCUDAバージョンを調べます
   
3. Dockerホストマシンの場合：タイプ:( cudaバージョンをインストールしたバージョンに置き換えます）
   docker run --rm --gpus all nvidia / cuda：10.1-base nvidia-smi
   ホストマシンでnvidia-smiを実行したときと同じ出力が得られるはずです
4. ファイル/etc/docker/daemon.jsonで、次のことを確認する必要があります。
   "runtimes"：{"nvidia"：{"path"： "/ usr / bin / nvidia-container-runtime"、 "runtimeArgs"：[]}}
5. docker-composeYMLに次を追加する必要があります。
   ランタイム：nvidia

それでおしまい ！
YMLを使用してデプロイすると、docker-composeでGPUがサポートされます。

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

ああ、このスレッド全体は、ランタイムがないバージョン3に関するものです。

リリース1.27.0以降ではv2 / v3ファイル形式がruntimeどこでも使用できるようになりました。 さらに、 docker-composeまだ実装されていませんが、アクセラレータの仕様も公開されました（https://github.com/compose-spec/compose-spec/pull/100）。

私はこの問題に私の2セントを追加します...私はたくさんの投稿を読みました、そして最終的に解決策はかなり簡単でした。

それは私のために働いた:(多分少し低いかもしれません-わからない...）
docker-composeバージョン1.27.4、ビルド4052419

1. Dockerホストマシンにnvidia-container-toolkitおよびnvidia-container-runtimeパッケージをインストールします
2. Dockerホストマシンの場合：タイプ
   nvidia-smiと、右側に表示されるCUDAバージョンを調べます
   
3. Dockerホストマシンの場合：タイプ:( cudaバージョンをインストールしたバージョンに置き換えます）
   docker run --rm --gpus all nvidia / cuda：10.1-base nvidia-smi
   ホストマシンでnvidia-smiを実行したときと同じ出力が得られるはずです
4. ファイル/etc/docker/daemon.jsonで、次のことを確認する必要があります。
   "runtimes"：{"nvidia"：{"path"： "/ usr / bin / nvidia-container-runtime"、 "runtimeArgs"：[]}}
5. docker-composeYMLに次を追加する必要があります。
   ランタイム：nvidia

それでおしまい ！
YMLを使用してデプロイすると、docker-composeでGPUがサポートされます。

参考までに、 nvidia-smiの出力に表示されるcudaバージョンは、nvidia cudaドライバーバージョン（別名nvidiaドライバー）を指します（これもcudaと呼ばれ、混乱を招きます）。 Dockerイメージのバージョン番号（例： nvidia/cuda:10.1-base nvidia-smi ）は、nvidiaツールキットのバージョンを示します（ここでも、紛らわしいことに同じバージョン番号付けシステム、異なる獣）。

ドライバーはツールキットと下位互換性があるため、 <version>がドライバーのバージョン以下である限り、任意のnvidia/cuda:<version>-base nvidia-smi実行できます。

詳細はこちら： https ：

ARMベースのシステムで利用できるDockerCompose1.27.4バイナリが表示されません。

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の出力は何ですか？

Compose1.27はPython2のサポートを終了したため、システムにPython 2がある場合、1.27.xリリースが表示されない可能性があります。

@collabnixは、composeがすでにインストールされているため、 pip install --upgrade docker-compose試してください

これで、1.27.4にアップグレードできます。 ピップのアップグレードでうまくいきました。 @ kshcherban ＆@ chris-
私が過去に取り組んだほとんどのプロジェクトを見るのはクレイジーで、Python2.7を使用しているので本当にアップグレードが必要です。

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でうまく動作します。
ホストコンピューターで、nvidia-smiが使用するGPUを確認します。

@ bttung-2020
@PyCod
docker-hubでdokcer-nvidia-devel（ランタイムではない）：nvidia / cuda：10.1-cudnn7-devel-ubuntu18.04を使用する場合
それは機能しますか？ docker-compose.yamlファイルを編集するにはどうすればよいですか？